測試基本知識簡介課件

1、第 1 頁 測試的常識和道理測試的分類和比較軟件產(chǎn)品的主要測試內(nèi)容及技術(shù)一二三四測試人員的組織第1頁，共24頁。1.測試的常識和道理1.1 你真的懂測試嗎 編程大師說：沒有錯(cuò)誤的程序世間難求。 （編程之道）你在學(xué)校里學(xué)過測試嗎？（讀到博士可能也不懂測試）你所在的企業(yè)重視測試嗎？ （小公司程序員的技能更加全面）臨時(shí)抱佛腳行嗎？你以為有文檔模板就會測試了嗎？ 如果不懂得有效地進(jìn)行測試，你不僅得不到功勞，也沒人欣賞你的苦勞，你擁有最多的將只是疲勞。 職業(yè)軟件工程師應(yīng)當(dāng)掌握需求開發(fā)、系統(tǒng)設(shè)計(jì)、編程、測試、維護(hù) 所有技能。1.2 測試的目的是什么測試的目的是為了發(fā)現(xiàn)盡可能多的缺陷，不是為了說明軟件中沒有

2、缺陷。 推論：成功的測試在于發(fā)現(xiàn)了迄今尚未發(fā)現(xiàn)的缺陷。所以測試人員的職責(zé)是設(shè)計(jì)這樣的測試用例，它能有效地揭示潛伏在軟件里的缺陷。 千萬不要將“測試”與“演示”混為一談。例如科研鑒定會。如果產(chǎn)品通過了嚴(yán)格的測試，大家不要不吭氣，應(yīng)當(dāng)好好地宣傳一把 。第 2 頁第2頁，共24頁。1.測試的常識和道理1.3 一些常識和經(jīng)驗(yàn)之談測試能提高軟件的質(zhì)量，但是提高質(zhì)量不能依賴測試。 測試只能證明缺陷存在，不能證明缺陷不存在?！皬氐椎販y試”難以成為現(xiàn)實(shí)，要考慮時(shí)間、費(fèi)用等限制，不允許無休止地測試。我們應(yīng)當(dāng)祈禱：軟件的缺陷在產(chǎn)品被淘汰之前一直沒有機(jī)會發(fā)作。 測試的主要困難是不知道如何進(jìn)行有效地測試，也不知道什么

3、時(shí)候可以放心地結(jié)束測試。 每個(gè)開發(fā)人員應(yīng)當(dāng)測試自己的程序（份內(nèi)之事），但是不能作為該程序已經(jīng)通過測試的依據(jù)（所以項(xiàng)目需要獨(dú)立測試人員）。 80-20原則：80的缺陷聚集在20的模塊中，經(jīng)常出錯(cuò)的模塊改錯(cuò)后還會經(jīng)常出錯(cuò)測試應(yīng)當(dāng)循序漸進(jìn)，不要企圖一次性干完，注意“欲速則不達(dá)”。 第 3 頁第3頁，共24頁。1.測試的分類和比較2.1 測試方式白盒測試：關(guān)心軟件內(nèi)部設(shè)計(jì)和程序?qū)崿F(xiàn)，主要測試依據(jù)是設(shè)計(jì)文檔黑盒測試：不關(guān)心軟件內(nèi)部，只關(guān)心輸入輸出，主要測試依據(jù)是需求文檔2.2 測試階段單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試。是“從小到大”、“由內(nèi)至外”、“循序漸進(jìn)”的測試過程，體現(xiàn)了“分而治之”的思想。

4、 單元測試的粒度最小，一般由開發(fā)小組采用白盒方式來測試，主要測試單元是否符合“設(shè)計(jì)”。 集成測試界于單元測試和系統(tǒng)測試之間，起到“橋梁作用”，一般由開發(fā)小組采用白盒加黑盒的方式來測試，既要驗(yàn)證“設(shè)計(jì)”又要驗(yàn)證“需求”。 系統(tǒng)測試的粒度最大，一般由獨(dú)立測試小組采用黑盒方式來測試，主要測試系統(tǒng)是否符合“需求規(guī)格說明書”。 驗(yàn)收測試與系統(tǒng)測試非常相似，主要區(qū)別是測試人員不同，驗(yàn)收測試由用戶執(zhí)行。 第 4 頁第4頁，共24頁。2. 測試的分類與比較2.3 開發(fā)與測試的 V 型關(guān)系如果軟件開發(fā)過程采用嚴(yán)格的瀑布模型，那么開發(fā)與測試有“V”型的對應(yīng)關(guān)系 。需求開發(fā)高層設(shè)計(jì)詳細(xì)設(shè)計(jì)編程單元測試集成測試系統(tǒng)測

5、試驗(yàn)收測試第5頁，共24頁。2. 測試的分類與比較2.4 測試內(nèi)容接口與路徑測試。 功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試 測試階段 主要依據(jù) 測試人員、測試方式 主要測試內(nèi)容 單元測試系統(tǒng)設(shè)計(jì)文檔由開發(fā)小組執(zhí)行白盒測試 接口測試、路徑測試 集成測試系統(tǒng)設(shè)計(jì)文檔需求文檔由開發(fā)小組執(zhí)行白盒測試和黑盒測試 接口測試、路徑測試功能測試、性能測試 系統(tǒng)測試需求文檔由獨(dú)立測試小組執(zhí)行黑盒測試 功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試 驗(yàn)收測試需求文檔由用戶執(zhí)行黑盒測試 第6頁，共24頁。2.

6、 測試的分類與比較2.5 問題問題1：有了“黑盒”測試為什么還要“白盒”測試？黑盒測試只能觀察軟件的外部表現(xiàn)，即使軟件的輸入輸出都是正確的，卻并不能說明軟件就是正確的。因?yàn)槌绦蛴锌赡苡缅e(cuò)誤的運(yùn)算方式得出正確的結(jié)果，例如“負(fù)負(fù)得正，錯(cuò)錯(cuò)得對”，只有白盒測試才能發(fā)現(xiàn)真正的原因。白盒測試能發(fā)現(xiàn)程序里的隱患，象內(nèi)存泄漏、誤差累計(jì)問題。在這方面，黑盒測試存在嚴(yán)重的不足。 問題2：由于單元測試要寫測試驅(qū)動程序，非常麻煩，能否等到整個(gè)系統(tǒng)全部開發(fā)完后，再集中精力進(jìn)行一次性地單元測試呢？ 如果這樣做，在開發(fā)過程中，缺陷會越積越多并且分布得更廣、隱藏得更深，反而導(dǎo)致測試與改錯(cuò)的代價(jià)大大增加。最糟糕的是無法估計(jì)測

7、試與改錯(cuò)的工作量，使進(jìn)度失去控制。因此為圖眼前省事而省略單元測試或者“偷工減料”，是“得不償失”的做法。 問題3：如果每個(gè)單元都通過了測試，把它們集成一起難道會有什么不妥嗎？集成測試是否多此一舉？要把N個(gè)單元集成一起肯定靠接口耦合，這時(shí)可能會產(chǎn)生在單元測試中無法發(fā)現(xiàn)的問題。例如：數(shù)據(jù)通過不同的接口時(shí)可能出錯(cuò)；幾個(gè)函數(shù)關(guān)聯(lián)在一起時(shí)可能達(dá)不到預(yù)期的功能；在某個(gè)單元里可以接受的誤差可能在集成后被擴(kuò)大到無法接受的程度。所以集成測試是必要的，不是多此一舉。第7頁，共24頁。2. 測試的分類與比較2.5 問題問題4：在集成測試的時(shí)候，已經(jīng)對一些子系統(tǒng)進(jìn)行了功能測試、性能測試等等，那么在系統(tǒng)測試時(shí)能否跳過相

8、同內(nèi)容的測試? 不能！因?yàn)榧蓽y試是在仿真環(huán)境中開展的，那不是真正的目標(biāo)系統(tǒng)。再者，單元測試和集成測試通常由開發(fā)小組執(zhí)行。根據(jù)測試心理學(xué)的分析，開發(fā)人員測試自己的工作成果雖然是必要的，但不能作為成果已經(jīng)通過測試的依據(jù)。 問題5：既然系統(tǒng)測試與驗(yàn)收測試的內(nèi)容幾乎是相同的，為什么還要驗(yàn)收測試？首先是“信任”問題。對于合同項(xiàng)目而言，如果測試小組是開發(fā)方的人員，客戶怎么能夠輕易相信“別人”呢? 所以當(dāng)項(xiàng)目進(jìn)行系統(tǒng)測試之后，客戶再進(jìn)行驗(yàn)收測試是情理之中的事。否則，那是客戶失職。 不論是合同項(xiàng)目還是非合同項(xiàng)目，軟件的最終用戶各色各樣（如受教育程度不同、使用習(xí)慣不同等等）。測試小組至多能夠模仿小部分用戶的行

9、為，但并不具有普遍的代表性。 問題6：能否將系統(tǒng)測試和驗(yàn)收測試“合二為一”？ 系統(tǒng)測試不是一會兒就能做完的，比較長時(shí)間的用戶測試很難組織。用戶還有自己的事情要做，他們?yōu)槭裁匆獮閯e人測試呢？即使用戶愿意做系統(tǒng)測試，他們消耗的時(shí)間、花費(fèi)的金錢大多比測試小組的高。系統(tǒng)測試時(shí)會找出相當(dāng)多的軟件缺陷，軟件需要反反復(fù)復(fù)地改錯(cuò)。如果讓用戶發(fā)現(xiàn)“內(nèi)幕”，一是丟臉，二是會嚇跑買主。所以還是關(guān)起門來，先讓測試小組做完系統(tǒng)測試的好。 第8頁，共24頁。3. 測試人員的組織3.1 了解開發(fā)人員的測試心理測試的目的是找出盡可能多的缺陷。所以測試是“破壞性”的，而開發(fā)卻是“建設(shè)性”的。開發(fā)人員總是喜歡欣賞程序的成功之處，

10、而不愿看到失敗之處。讓開發(fā)者去做“蓄意破壞”的測試，就象殺自己的孩子一樣難以接受。 開發(fā)者對自己的程序印象深刻，并總以為是正確的（自信是應(yīng)該的）。倘若在設(shè)計(jì)時(shí)就存在理解錯(cuò)誤，或因不良的編程習(xí)慣而流下了隱患，他本人很難發(fā)現(xiàn)這類錯(cuò)誤.開發(fā)者對自己的程序的功能、接口十分熟悉，他自己幾乎不可能因?yàn)槭褂貌划?dāng)而引發(fā)錯(cuò)誤，這與大眾用戶的情況不太相似，所以測試自己的程序不具備典型性。 結(jié)論：開發(fā)人員應(yīng)當(dāng)測試自己的程序，這是他分內(nèi)的工作。但是開發(fā)人員在測試自己的程序時(shí)，很難做到客觀、公正，所以自我測試不具有說服力。 3.2 如何組織測試人員：應(yīng)當(dāng)視企業(yè)的人力資源而定條件特別好的公司，可以為每一個(gè)開發(fā)人員分配一名

11、獨(dú)立的測試人員。這樣的測試人員職業(yè)化程度很高，可以完成單元測試、集成測試和系統(tǒng)測試工作，能夠?qū)崿F(xiàn)開發(fā)與測試同步進(jìn)行。條件比較好的公司，可以設(shè)置一個(gè)獨(dú)立的測試小組，該測試小組輪流參加各個(gè)項(xiàng)目的系統(tǒng)測試。而單元測試、集成測試工作由項(xiàng)目的開發(fā)小組承擔(dān)。 條件一般的公司，養(yǎng)不起獨(dú)立的測試小組。單元測試、集成測試工作由項(xiàng)目開發(fā)小組承擔(dān)。當(dāng)項(xiàng)目進(jìn)展到系統(tǒng)測試階段，可以從項(xiàng)目外抽調(diào)一些人員，加上開發(fā)人員，臨時(shí)組織系統(tǒng)測試小組。 條件比較差的公司，也許只有一個(gè)項(xiàng)目和為數(shù)不多的一些開發(fā)人員。那么就讓開發(fā)人員一直兼任測試人員的角色，相互測試對方的程序。如果人員實(shí)在太少了，只好讓開發(fā)者測試自己的程序，有測試總比沒有

12、測試好吧！ 第9頁，共24頁。3. 測試人員的組織3.3 避免開發(fā)人員與測試人員產(chǎn)生矛盾開發(fā)人員的注意事項(xiàng)： 不要敵視測試人員。要理解測試的目的就是發(fā)現(xiàn)缺陷，是測試人員的工作職責(zé)。不要以為測試人員吃飽了沒事干，存心找茬。 不要輕視測試人員，別說人家技術(shù)水平差，不配搞開發(fā)只好搞測試。 測試人員的注意事項(xiàng)： 發(fā)現(xiàn)缺陷時(shí)不要嘲笑開發(fā)人員，別說他的程序真臭、到處是Bug。 在開發(fā)人員壓力太大時(shí)或心情不好時(shí)不要火上澆油，發(fā)現(xiàn)缺陷時(shí)別大聲嚷嚷。 請留意另一種極端：如果測試人員與開發(fā)人員的關(guān)系非常好，可能會導(dǎo)致在測試的時(shí)候“手下留情”，這對項(xiàng)目也是一種傷害。 第10頁，共24頁。4. 軟件系統(tǒng)的主要測試內(nèi)容

13、及技術(shù)4.1 接口與路徑測試4.2 功能測試4.3 健壯性測試4.4 性能測試4.5 用戶界面測試4.6 信息安全測試4.7 壓力測試4.8 可靠性測試4.9 安裝/反安裝測試第11頁，共24頁。4. 軟件系統(tǒng)的主要測試內(nèi)容及技術(shù)4.1 接口與路徑測試數(shù)據(jù)一般通過接口輸入和輸出，所以接口測試是白盒測試的第一步。每個(gè)接口可能有多個(gè)輸入?yún)?shù)，每個(gè)參數(shù)有“典型值”、“邊界值”、“異常值”之分，所以輸入的組合數(shù)可能并不少。根據(jù)接口的定義，可以推斷某種輸入應(yīng)當(dāng)產(chǎn)生什么樣的輸出。輸出包括函數(shù)的返回值和輸出參數(shù)。如果實(shí)際輸出與期望的輸出不一致，那么說明程序有錯(cuò)誤。白盒方式的接口測試和黑盒方式的功能測試，其方

14、法十分相似。 一個(gè)函數(shù)體內(nèi)的語句可能只有十幾條，但邏輯路徑可能有成千上萬條。想遍歷測試幾乎是不可能的，不測試或者胡亂找?guī)讞l路徑測試卻又不行。 對于非嚴(yán)格系統(tǒng)而言，在分析路徑方面化費(fèi)很多精力是不值得的。我認(rèn)為在構(gòu)造接口測試的同時(shí)已經(jīng)建立了測試路徑。因?yàn)槊恳环N輸入將產(chǎn)生唯一的輸出，輸入與輸出之間的路徑也是唯一的。由于接口測試中的輸入是有代表性的，因此相應(yīng)的路徑也具有代表性，不用得著費(fèi)煞苦心地去找測試路徑。路徑測試的檢查表數(shù)據(jù)類型、變量值、邏輯判斷、循環(huán)、內(nèi)存管理、文件I/O、錯(cuò)誤處理 由于接口測試是枚舉的，有可能漏掉某些狀況，導(dǎo)致一些重要的路徑?jīng)]有被測試。預(yù)防措施有：觀察是否有程序語句從來沒有被執(zhí)

15、行過。如果發(fā)生在這種情況，要么是程序有錯(cuò)誤，存在無用的代碼；要么是接口測試不充分，漏掉了一些路徑。要特別留意函數(shù)體內(nèi)的錯(cuò)誤處理程序塊（如果存在的話），這是最易被人疏忽的路徑，隱患最多。 第12頁，共24頁。4 軟件系統(tǒng)的主要測試內(nèi)容及技術(shù)接口與路徑測試用例的參考模板第13頁，共24頁。4. 軟件系統(tǒng)的主要測試內(nèi)容及技術(shù)4.2 功能測試功能測試的基本方法是構(gòu)造一些合理輸入（在需求范圍之內(nèi)），檢查輸出是否與期望的相同。如果兩者不一致，即表明功能有誤。也有例外的情況，如需求規(guī)格說明書中的某個(gè)功能寫錯(cuò)了，而實(shí)際上軟件的功能卻是正確的，這時(shí)要更改的是需求規(guī)格說明書。 功能測試看起來比較簡單，只要看得懂需

16、求規(guī)格說明書，誰都會做。難點(diǎn)在于如何構(gòu)造有效的輸入。由于輸入空間通常是無限的，窮舉測試顯然行不通。那么隨便輸入一些東西，碰運(yùn)氣行不行？ 功能測試有兩種比較好的測試方法：等價(jià)劃分法和邊界值分析法。 等價(jià)劃分是指把輸入空間劃分為幾個(gè)“等價(jià)區(qū)間”，在每個(gè)“等價(jià)區(qū)間”中只需要測試一個(gè)典型值就可以了。等價(jià)劃分法來源于人們的直覺與經(jīng)驗(yàn)，可令測試事半功倍。 “缺陷遺漏在角落里，聚集在邊界上”。邊界值測試法是對等價(jià)劃分法的補(bǔ)充。如果A和B是輸入空間的邊界值，那么除了典型值外還要用A和B作為測試用例。 例如測試函數(shù)。憑直覺，等價(jià)區(qū)間應(yīng)是（0, 1）和（1, +）?？扇〉湫椭祒=0.5以及x=2.0進(jìn)行“等價(jià)劃分

17、”測試。再取 x=0以及x=1進(jìn)行“邊界值”測試。 第14頁，共24頁。4. 軟件系統(tǒng)的主要測試內(nèi)容及技術(shù)功能測試用例的參考模板第15頁，共24頁。4. 軟件系統(tǒng)的主要測試內(nèi)容及技術(shù)4.3 健壯性測試健壯性是指在異常情況下，軟件還能正常運(yùn)行的能力。健壯性有兩層含義：一是容錯(cuò)能力，二是恢復(fù)能力。 容錯(cuò)性測試通常構(gòu)造一些不合理的輸入來引誘軟件出錯(cuò)，例如：（1）輸入錯(cuò)誤的數(shù)據(jù)類型。如“猴”年“馬”月。（2）輸入定義域之外的數(shù)值。如上海人常說的“十三點(diǎn)”粗暴一些方式俗稱“大猩猩”測試法。除了不能拳打腳踢嘴咬外，什么招術(shù)都可以使出來。例如在測試客戶機(jī)服務(wù)器模式的軟件時(shí)，把網(wǎng)絡(luò)線拔掉，造成通信異常中斷。

18、恢復(fù)測試重點(diǎn)考察一下幾項(xiàng)：（1）系統(tǒng)能否重新運(yùn)行；（2）有無重要的數(shù)據(jù)丟失；（3）是否毀壞了其它相關(guān)的軟件硬件。 第16頁，共24頁。4. 軟件系統(tǒng)的主要測試內(nèi)容及技術(shù)健壯性測試用例的參考模板第17頁，共24頁。4. 軟件系統(tǒng)的主要測試內(nèi)容及技術(shù)4.4 性能測試性能測試即測試軟件處理事務(wù)的速度，一是為了檢驗(yàn)性能是否符合需求，二是為了得到某些性能數(shù)據(jù)供人們參考（例如用于宣傳）。 有時(shí)人們關(guān)心測試的“絕對值”，如數(shù)據(jù)送輸速率是每秒多少比特。有時(shí)人們關(guān)心測試的“相對值”，如某個(gè)軟件比另一個(gè)軟件快多少倍。在獲取測試的“絕對值”時(shí)，我們要充分考慮并記錄運(yùn)行環(huán)境對測試的影響。例如網(wǎng)絡(luò)環(huán)境、計(jì)算機(jī)主頻，總線

19、結(jié)構(gòu)和外部設(shè)備都可能影響軟件的運(yùn)行速度。 性能測試的一些注意事項(xiàng)：不要試圖讓人拿著鐘表去測時(shí)間，應(yīng)當(dāng)編寫一段程序用于計(jì)算時(shí)間以及相關(guān)數(shù)據(jù)。 應(yīng)當(dāng)測試軟件在標(biāo)準(zhǔn)配置和最低配置下的性能。 為了排除干擾，應(yīng)當(dāng)關(guān)閉那些消耗內(nèi)存、占用CPU的其它應(yīng)用軟件（如殺毒軟件）。 不同的輸入情況會得到不同的性能數(shù)據(jù)，應(yīng)當(dāng)分檔記錄。例如傳輸文件的容量從100K到1M可以分成若干等級。 由于環(huán)境的波動，同一種輸入情況在不同的時(shí)間可能得到不同的性能數(shù)據(jù)，可以取其平均值。 第18頁，共24頁。4. 軟件系統(tǒng)的主要測試內(nèi)容及技術(shù)性能測試用例的參考模板第19頁，共24頁。4. 軟件系統(tǒng)的主要測試內(nèi)容及技術(shù)4.5 用戶界面測試

20、絕大多數(shù)軟件擁有圖形用戶界面。圖形用戶界面的測試重點(diǎn)是正確性、易用性和視覺效果。在評價(jià)易用性和視覺效果時(shí)，主觀性非常強(qiáng)，應(yīng)當(dāng)考慮多個(gè)人的觀點(diǎn)。用戶界面測試用例的參考模板： 第20頁，共24頁。4. 軟件系統(tǒng)的主要測試內(nèi)容及技術(shù)4.6 信息安全測試信息安全性（security）是指防止系統(tǒng)被非法入侵的能力，既屬于技術(shù)問題又屬于管理問題。信息安全性測試有如下步驟：（1）為非法入侵設(shè)立目標(biāo)，例如“盜竊某個(gè)文件”或“更改數(shù)據(jù)庫記錄”等。（2）邀請（或懸賞）一些人扮演黑客，讓他們想盡辦法入侵系統(tǒng)，實(shí)現(xiàn)“目標(biāo)”。（3）如果有人成功了，請他詳述入侵的過程。別忘了給予獎(jiǎng)勵(lì)。 信息安全性測試用例的參考模板第21頁，共24頁。4. 軟件