測試總結(jié)和報(bào)告

    測試人員的工作通常并不像開發(fā)人員那樣能直接體現(xiàn)出來，讓大家一目了然。開發(fā)人員做的是建設(shè)性的工作，如開發(fā)了哪些功能，寫了幾行代碼，設(shè)計(jì)了幾個(gè)類，都能直觀地看到，而且，通過軟件能很鮮活地演示開發(fā)人員的工作成果。
    但是測試人員的工作相對隱蔽一點(diǎn)，測試人員做的是破壞性的工作，并且沒有很多可以直觀體現(xiàn)測試人員貢獻(xiàn)的東西。筆者曾經(jīng)聽到公司人事部的一位同事說：“你們做測試的真好，整天坐在那里”。當(dāng)然，這是外行人看內(nèi)行時(shí)說的話，但是給筆者的一個(gè)啟示是：測試人員需要更多地表現(xiàn)自己，展現(xiàn)自己的工作成果。
    說明：由于缺陷列表太細(xì)、太大，測試用例過于專業(yè)，很多人對其不感興趣，因此測試報(bào)告能很好地展示自己的工作狀況，測試報(bào)告是提供給很多人看的一份文檔。

下面是一個(gè)項(xiàng)目的測試報(bào)告的綱要：
1 簡介
1.1 編寫目的
1.2 項(xiàng)目背景
1.3 術(shù)語和縮略詞
1.4 參考資料
2 目標(biāo)及范圍
2.1 測試目的及標(biāo)準(zhǔn)
2.2 測試范圍
3 測試過程
3.1 測試內(nèi)容
3.2 測試時(shí)間
3.3 測試環(huán)境
3.4 測試方法及測試用例設(shè)計(jì)
4 測試情況分析
4.1 測試概要
4.2 測試用例執(zhí)行情況
4.3 缺陷情況
4.4 測試覆蓋率分析
4.5 產(chǎn)品質(zhì)量情況分析
5 測試總結(jié)
5.1 測試資源消耗情況
5.2 測試經(jīng)驗(yàn)總結(jié)
6 附件
附件1 測試用例清單
附件2 缺陷清單

一、缺陷分類報(bào)告

   缺陷分類報(bào)告是測試報(bào)告的重要組成部分，可以再細(xì)分為：缺陷類型分布報(bào)告、缺陷區(qū)域分布報(bào)告和缺陷狀態(tài)分布報(bào)告等。

1．缺陷類型分布報(bào)告

   缺陷類型分布報(bào)告主要描述缺陷類型的分布情況，看缺陷屬于哪些類型的錯(cuò)誤。這些信息有助于引起開發(fā)人員的注意，并分析缺陷為什么會(huì)集中在這種類型。例如，如果缺陷主要是界面類型的，如界面提示信息不規(guī)范、界面布局凌亂等問題，那么就要討論是否需要制定相應(yīng)的界面規(guī)范，讓開發(fā)人員遵循，從而防止類似問題的出現(xiàn)。
   缺陷類型分布報(bào)告一般用餅圖或柱狀圖顯示。如圖一所示，用餅圖表示了幾種類型的缺陷各自所占的比例。

圖一  缺陷分布報(bào)告

2.缺陷區(qū)域分布報(bào)告

   缺陷區(qū)域分布報(bào)告主要描述缺陷在不同功能模塊出現(xiàn)的情況，這些信息有助于開發(fā)人員分析為什么缺陷會(huì)集中出現(xiàn)在某個(gè)功能模塊。例如，如果缺陷主要集中在單據(jù)的審批過程中，那么就要分析是否是審批流程調(diào)用的工作流接口設(shè)計(jì)不合理。
   缺陷區(qū)域分布報(bào)告一般使用餅圖或柱狀圖表示。如圖二所示，用柱狀圖表示缺陷分布在不同的功能模塊的個(gè)數(shù)。

圖二  缺陷區(qū)域分布報(bào)告

3.缺陷狀態(tài)分布報(bào)告

   缺陷狀態(tài)分布報(bào)告主要描述缺陷各種狀態(tài)的比例情況，例如Open、Fixed、Closed、Reopen、Rejected、Delay的Bug分別占了百分之多少。這些信息有助于評估測試和產(chǎn)品的現(xiàn)狀：
   如果Open的Bug比例過高，則考慮讓開發(fā)人員暫停開發(fā)新功能，先集中精力修改Bug；
   如果Fixed狀態(tài)的Bug很多，則考慮讓測試人員暫停測試新功能，先集中精力做一次回歸測試，把修改的Bug驗(yàn)證完；
   如果Closed的Bug居多，則可能意味著功能模塊趨于穩(wěn)定；
   如果Reopen的Bug比較多，則需要分析開發(fā)人員的開發(fā)狀態(tài)，是什么原因造成缺陷修改不徹底；
   如果Rejected的Bug比例過高，則要看開發(fā)人員與測試人員是否對需求存在理解上的分歧；
   如果Delay的Bug比例過高，則要考慮這個(gè)版本是否滿足用戶的要求，是否缺少了太多應(yīng)該在這個(gè)版本出現(xiàn)的功能特性。
   缺陷狀態(tài)分布報(bào)告一般使用餅圖或柱狀圖表示。如圖三所示，用餅圖表示各種狀態(tài)的缺陷個(gè)數(shù)以及所占的百分比。

圖三  缺陷狀態(tài)分布報(bào)告

　　注意：其他的缺陷分類報(bào)告也可以寫到測試報(bào)告中，例如，嚴(yán)重級別分類報(bào)告、優(yōu)先級別分類報(bào)告、負(fù)責(zé)人分類報(bào)告、發(fā)現(xiàn)人分類報(bào)告、版本分類報(bào)告等。但是要注意，應(yīng)該用這些分類報(bào)告來說明問題，而不要用來指責(zé)別人，例如使用負(fù)責(zé)人分類報(bào)告來嘲笑某個(gè)開發(fā)人員是“Bug大王”等。

二、缺陷趨勢報(bào)告

    缺陷趨勢報(bào)告主要描述一段時(shí)間內(nèi)的缺陷情況。如果項(xiàng)目管理比較規(guī)范，缺陷管理和測試流程比較正常的話，缺陷趨勢報(bào)告還可以用來估算軟件可發(fā)布的日期。
　　例如，如圖四所示的缺陷趨勢圖，表示在2001年9月3號至2001年9月24號之間的Bug狀態(tài)變化。

　　　　　　　　　　　　　圖四  缺陷趨勢圖

    從圖四可以看出，Open狀態(tài)的Bug在不斷地增加，F(xiàn)ixed狀態(tài)的Bug在2001年9月16號后開始驟然下降，這表示，這段時(shí)間開發(fā)人員有可能在開發(fā)幾種新的功能，忽略了Bug的修改工作。
    發(fā)現(xiàn)并錄入Bug，與修改并關(guān)閉Bug是一對互相對沖的兩個(gè)變量，軟件產(chǎn)品就是在這樣此消彼漲的過程中不斷完善和改進(jìn)質(zhì)量的。有經(jīng)驗(yàn)的項(xiàng)目經(jīng)理和測試人員會(huì)非常關(guān)注這樣的發(fā)展曲線，從而判斷項(xiàng)目產(chǎn)品的質(zhì)量狀態(tài)和發(fā)展趨勢。筆者曾經(jīng)在某個(gè)項(xiàng)目中與一位項(xiàng)目經(jīng)理在項(xiàng)目的待發(fā)布階段每天都在觀察缺陷趨勢圖，這位項(xiàng)目經(jīng)理甚至把它戲稱為軟件產(chǎn)品的“股市”技術(shù)圖。
    但是確實(shí)能從這些圖中看出一個(gè)產(chǎn)品的質(zhì)量趨勢，如果項(xiàng)目管理得比較規(guī)范的話，甚至可以從這些圖的某些關(guān)鍵點(diǎn)推算出可發(fā)布版本的日期。在微軟的項(xiàng)目管理中，把這種關(guān)鍵點(diǎn)稱為零Bug反彈點(diǎn)。例如，圖五就有幾個(gè)零Bug反彈點(diǎn)（用圓圈圈住的地方）。

圖五 零Bug反彈

    項(xiàng)目在第一次達(dá)到零缺陷，即所有Bug（或者大部分Bug）都基本處理掉了，沒有發(fā)現(xiàn)新的Bug時(shí)，還不能馬上發(fā)布版本，因?yàn)锽ug會(huì)反彈。由于缺陷的“隱蔽特性”和“免疫特性”，第一個(gè)零缺陷點(diǎn)是一個(gè)質(zhì)量安全的假像，測試人員很快就會(huì)在新版本中發(fā)現(xiàn)更多的Bug，有些項(xiàng)目甚至要到第三個(gè)或第四個(gè)零Bug點(diǎn)才能安全地發(fā)布，這取決于項(xiàng)目的實(shí)際控制方式。

三、典型缺陷與Bug模式

   軟件開發(fā)有設(shè)計(jì)模式，測試其實(shí)也有模式存在，需要測試人員進(jìn)行總結(jié)和歸納。測試人員應(yīng)從經(jīng)常出現(xiàn)的Bug中學(xué)習(xí)，總結(jié)出Bug模式，用于指導(dǎo)測試。如果開發(fā)人員能關(guān)注這些Bug模式，還能起到預(yù)防錯(cuò)誤的效果。
   要成為典型缺陷，必須滿足以下條件：
   ＊　重復(fù)出現(xiàn)、經(jīng)常出現(xiàn)；
   ＊　能代表某種類型的錯(cuò)誤；
   ＊　能通過相對固定的測試方法或測試手段來發(fā)現(xiàn)這些錯(cuò)誤。
   總結(jié)這些典型缺陷出現(xiàn)的現(xiàn)象，出現(xiàn)的原因，以及測試方法，就能成為一個(gè)Bug模式。

    說明：根據(jù)不同的開發(fā)平臺(tái)、開發(fā)工具、開發(fā)語言、產(chǎn)品類型、采用的架構(gòu)等，可以總結(jié)出不同的Bug模式，不同的Bug模式可能在不同的平臺(tái)、語言、產(chǎn)品類型中才會(huì)出現(xiàn)。測試人員應(yīng)該總結(jié)適合自己項(xiàng)目特點(diǎn)的Bug模式。

　　提煉Bug模式的一般步驟如下：
    步驟1：分析缺陷報(bào)告，找出經(jīng)常出現(xiàn)的Bug類型。
    步驟2：分析Bug的根源，找出Bug產(chǎn)生的深層次原因。
    步驟3：分析找到Bug的方法，總結(jié)如何才能每次都發(fā)現(xiàn)該類型的Bug。
   下面舉一個(gè)例子來說明這個(gè)過程。
   首先，測試人員在分析缺陷報(bào)告時(shí)發(fā)現(xiàn)，有一類Bug經(jīng)常出現(xiàn)，并且錯(cuò)誤現(xiàn)象一致：執(zhí)行某功能時(shí)提示Time Out。
    測試人員與程序員一起分析原因，發(fā)現(xiàn)這些錯(cuò)誤都是在操作數(shù)據(jù)庫時(shí)發(fā)生，發(fā)送的SQL語句被數(shù)據(jù)庫長時(shí)間執(zhí)行未返回，因此提示Time Out。通過進(jìn)一步地分析表明，.NET的SqlCommand的CommandTimeOut屬性是用于獲取或設(shè)置在終止執(zhí)行命令的嘗試并生成錯(cuò)誤之前的等待時(shí)間。等待命令執(zhí)行的時(shí)間（以秒為單位）默認(rèn)為30s，而數(shù)據(jù)庫操作在較大數(shù)據(jù)量的情況下一般都超過這個(gè)時(shí)間，因此會(huì)提示超時(shí)的錯(cuò)誤信息。
    這樣就可以把這種類型的Bug歸納為“數(shù)據(jù)庫操作超時(shí)Bug模式”。
    那么，如何才能找出這樣的Bug呢？一般情況下，這類Bug基本上不會(huì)出現(xiàn)，只有數(shù)據(jù)量足夠大時(shí)才會(huì)出現(xiàn)，因此需要設(shè)置大批數(shù)據(jù)，結(jié)合性能測試或壓力測試來發(fā)現(xiàn)此類問題。也可以通過白盒的方式，查找程序在使用SqlCommand時(shí)是否合理地設(shè)置了Command TimeOut屬性，這樣將更有針對性地揭露上述的錯(cuò)誤。
    至此就完成了一個(gè)Bug模式的歸納、提煉和總結(jié)，如果程序員積極地參與到該總結(jié)和分析過程中來，則可形成一個(gè)良性的反饋，當(dāng)下次程序員編寫相同的程序時(shí)就會(huì)避免類似的錯(cuò)誤發(fā)生。

四、測試中的PDCA循環(huán)

    PDCA循環(huán)是一種放之四海皆準(zhǔn)的原則。在軟件測試的過程中，也充斥著各種PDCA循環(huán)。PDCA循環(huán)是一個(gè)自我完善和改進(jìn)的全閉環(huán)模型，如圖六所示，對質(zhì)量的不斷提高和改進(jìn)非常有效。

 圖六 PDCA循環(huán)模型

   在軟件測試中應(yīng)用PDCA循環(huán)的目的是為了提高測試質(zhì)量和產(chǎn)品質(zhì)量。大到整個(gè)測試過程，小到執(zhí)行一個(gè)測試或者錄入一個(gè)Bug，都可以體現(xiàn)PDCA的精神。
   首先制定好測試計(jì)劃，執(zhí)行測試計(jì)劃，通過測試執(zhí)行結(jié)果來檢查測試計(jì)劃制定的合理性，然后分析計(jì)劃偏離的原因，把總結(jié)出來的經(jīng)驗(yàn)用于指導(dǎo)下一次測試的計(jì)劃，這樣就形成了一個(gè)PDCA循環(huán)過程。
   編寫一份測試報(bào)告或者一個(gè)Bug也可以應(yīng)用PDCA循環(huán)。例如，先策劃好報(bào)告的主題和內(nèi)容，打好腹稿，再寫下來，寫完要檢查，看是否準(zhǔn)確，是否有錯(cuò)別字，然后提交審核，對提出的意見進(jìn)行分析，將總結(jié)的經(jīng)驗(yàn)用于指導(dǎo)下一次報(bào)告的編寫，這樣的過程同樣也是一個(gè)PDCA。
   編寫測試用例也是一個(gè)PDCA。首先計(jì)劃測試用例的編寫方式，搭建測試用例的大綱和框架，然后設(shè)計(jì)和編寫測試用例，并自行檢查或與同行一起交叉檢查，最后通過評審來發(fā)現(xiàn)更多的問題，如有哪些沒有考慮周全的，或設(shè)計(jì)不完善的地方；或者通過執(zhí)行測試用例，發(fā)現(xiàn)Bug，再根據(jù)執(zhí)行的情況和Bug的情況來分析測試用例的有效性，把這些總結(jié)出來的經(jīng)驗(yàn)用于指導(dǎo)下一次的測試用例設(shè)計(jì)。
    測試的執(zhí)行過程則是一個(gè)可間接用于改進(jìn)產(chǎn)品質(zhì)量和程序員能力的PDCA循環(huán)。例如，首先開發(fā)人員寫出代碼，策劃擁有一定質(zhì)量水平的產(chǎn)品，測試人員對產(chǎn)品執(zhí)行測試，發(fā)現(xiàn)Bug，通過分析Bug出現(xiàn)的原因，對開發(fā)人員的開發(fā)方式做出新的指導(dǎo)，從而避免下一次錯(cuò)誤的出現(xiàn)。通過這種方式改進(jìn)質(zhì)量，同時(shí)也提高了程序員編寫高質(zhì)量代碼的能力，把錯(cuò)誤遏制在產(chǎn)生的源頭。

五、客觀全面的測試報(bào)告

    測試需要以一個(gè)完美的方式結(jié)束，編寫一份出色的測試總結(jié)報(bào)告可為一個(gè)完美的測試過程劃上一個(gè)圓滿的句號。
    一份測試報(bào)告應(yīng)該包括測試資源的使用情況：投入了多少測試人員，所用時(shí)間多長，執(zhí)行了多少測試用例，以及覆蓋了多少功能模塊等。
    另外，對測試對象的缺陷分析也是必須的，包括共發(fā)現(xiàn)了多少缺陷，缺陷的類型主要是哪些，缺陷集中在哪些功能模塊，缺陷主要發(fā)生在哪幾個(gè)開發(fā)人員的身上。這些信息都是大家關(guān)心的，需要及時(shí)報(bào)告，項(xiàng)目經(jīng)理或QA需要根據(jù)這些信息做出決策。

        注意：報(bào)告應(yīng)該盡可能客觀、盡可能全面地反應(yīng)測試情況和缺陷情況。

六、實(shí)用測試經(jīng)驗(yàn)的總結(jié)
    測試總結(jié)報(bào)告應(yīng)該包括測試過程的成功與失敗經(jīng)驗(yàn)，從測試過程的管理經(jīng)驗(yàn)，具體到某個(gè)Bug的分析總結(jié)，或者是與開發(fā)人員合作交流的經(jīng)驗(yàn)，都可以總結(jié)出來。
    測試總結(jié)報(bào)告應(yīng)該分析測試的整個(gè)過程，如是否合理安排了測試資源，測試進(jìn)度是否按計(jì)劃進(jìn)行，如果沒有其原因是什么，如何避免下次出現(xiàn)類似的問題？風(fēng)險(xiǎn)是如何控制的？出現(xiàn)了什么意外情況？下次能否預(yù)計(jì)到這些問題，等等。
   測試總結(jié)報(bào)告還應(yīng)包括某些專門類型的測試經(jīng)驗(yàn)總結(jié)。例如，性能測試采用了什么好的方法？碰到的問題是如何解決的？自動(dòng)化測試腳本如何編寫？應(yīng)該選取哪些功能模塊進(jìn)行自動(dòng)化測試？等等。
   測試總結(jié)報(bào)告應(yīng)該包括對測試用例的分析。例如，測試用例的設(shè)計(jì)經(jīng)驗(yàn)總結(jié)，哪些用例設(shè)計(jì)得好，能非常有效地發(fā)現(xiàn)Bug，總結(jié)的這些東西無論是對本項(xiàng)目組的測試人員，還是對其他項(xiàng)目組的測試人員都會(huì)大有幫助。
   如果能分析總結(jié)出Bug模式，那么總結(jié)報(bào)告還應(yīng)該包括Bug模式的總結(jié)。