9.3.4 貫穿始終的缺陷分析
小艾完成調查表后，就去找凱文看是否有下一步任務。看到凱文正在畫花花綠綠的表格，他就很好奇地問："這是什么？"
凱文抬起頭說："我正在做項目最終缺陷分析，你來得正是時候，我正想給你詳細介紹一下缺陷分析，好讓你做個幫手。"
在凱文圖文并茂地認真講解下，小艾對缺陷分析有了深刻的了解。
在整個項目測試過程中，會不間斷地做一些缺陷分析，來幫助監控在開發和測試中是否存在問題和漏洞，并根據分析結果來調整測試范圍和策略。在最終測試完成后，會系統做一次缺陷分析，并以此總結經驗教訓以便在今后的項目中做出改進。
不同測試類型會有不同的缺陷分析側重點。比如安裝測試和遷移測試，會專注于分析產品安裝在不同操作系統及數據庫上出現的問題，所以會專門分析不同操作系統，不同數據庫上出現的缺陷，看是否這個問題只發生在特定系統或數據庫上。
一般來講，所有測試類型都會對以下方面進行分析。
1、有效缺陷和無效缺陷的比率
前面的章節中詳細介紹了缺陷管理模型中的缺陷生命周期狀態及相關信息。 簡而言之，缺陷從被發現到最終解決存在下列典型狀態：關閉狀態，開啟狀態，工作狀態，驗證狀態，退回狀態，取消狀態。
其中，在關閉狀態和取消狀態下的缺陷稱為完結缺陷，除此之外狀態的缺陷稱為活躍缺陷。項目結束時，理論上所有缺陷都應處在關閉狀態或取消狀態。當然由于時間原因，還存在極少量開啟狀態下的缺陷被延緩到補丁版本或新版本里修復。我們把關閉狀態缺陷和延緩缺陷稱為有效缺陷。而把取消狀態下的缺陷稱為無效缺陷。在測試過程中，應盡量提高有效缺陷比率，避免開出無效缺陷。
如圖9-2所示，測試過程共發現103個缺陷，其中有效缺陷85個，占總缺陷的83%，無效缺陷18個，占總缺陷的17%。一般來講，有效缺陷在80%以上就算是比較良好的。
造成無效缺陷的原因大致有以下幾點：
重復缺陷：是指在系統里相同原因的缺陷已經被其他人報告。在此缺陷被作為重復缺陷返回時，先不要立即取消。必須等到核查修復后，才在系統里取消。這是因為有些缺陷被誤認為是重復缺陷，實際上是不同原因造成的問題。我們只有在核查修復代碼后，才能確認這是否是無效缺陷。
用法錯誤：是指測試人員在測試過程中有一些操作錯誤或對功能的錯誤理解而造成測試案例失敗，由此開出的缺陷是無效缺陷。
符合設計：是指測試人員在測試過程中主觀上認為測試結果是有問題的，并開出缺陷。但實際上產品設計就是應該如此表現。如果測試人員也同意如此設計是有道理的，就應取消所開缺陷，并視之為無效缺陷。
產品局限性：是指所開缺陷由于產品本身設計框架等局限性而無法修復。這樣的缺陷通過改動代碼是無法修復的，一般來講最好轉變為修改文檔，通過文檔來告訴用戶這些局限性。如果既不能修改代碼又不能修改文檔，那么只好取消缺陷，并視之為無效缺陷。
未來功能：是指所開缺陷實際上是要求產品增加新功能。如果新功能不能在當前版本里實現，就應記錄在未來版本的新功能候選名單上，并取消此缺陷且視之為無效缺陷。
不可重現：是指所開缺陷無法在相同場景中重現。有時可能由于網絡，機器等問題而使測試案例無法正常運行，但重新測試很多遍也無法重現當時的問題。這種情況會建議取消缺陷，一旦同樣問題再次發生，就需重開缺陷。
一般應該對無效缺陷進行分析，找出導致無效缺陷比例高的原因并提出相應的改進計劃。
如圖9-3所示，在18個無效缺陷里，重復缺陷占比例最高，其次是用法錯誤。所以就要進一步了解造成重復缺陷比例高的原因并予以改進。例如，可通過一些方法來提高測試團隊之間的溝通，來有效降低重復缺陷。但有些重復缺陷是很難避免的，尤其是那些顯示不同錯誤信息，但造成問題的代碼是相同的缺陷。這些缺陷在很多測試專家眼里可以認為是有效缺陷。
用法錯誤的無效缺陷，在測試過程中應該盡量避免。這就要求測試人員要對測試案例有正確的理解而避免不必要的用法錯誤。另一方面，有些用法錯誤的缺陷可以轉換成提高實用性的有效缺陷。
例如，小艾在安裝測試時安裝失敗，小艾認為是安裝代碼的問題而報告了這個缺陷。開發人員在經過調查后發現是小艾不小心輸入了錯誤的數據庫密碼而導致安裝失敗，就認為是用法錯誤而返回缺陷。小艾咨詢了安裝測試負責人，安裝負責人認為雖然是測試人員用法錯誤，但從使用性上來講，客戶會遇到相同問題，產品應該能夠在客戶輸入錯誤密碼時提示客戶，并禁止進一步安裝。最終，開發人員接受了安裝負責人的建議并修改了代碼。而小艾所開的缺陷也成為提高使用性的有效缺陷。
2、按嚴重性分析缺陷
缺陷按問題的嚴重程度分為以下幾個等級。
一級嚴重：是指缺陷造成整個應用或功能不工作，從而導致產品不能交付。
二級嚴重：是指缺陷造成功能輸出結果錯誤。
三級嚴重：是指缺陷造成功能沒有按預期方式實現。
四級嚴重：是指功能上需要加強。
在測試過程中，一級和四級嚴重缺陷應占比例較少，二級和三級嚴重缺陷比例應該占大多數。這是因為大部分一級嚴重缺陷在開發過程的單元測試中應該被發現和解決，而不應該流入到測試流程。
如圖9-4所示，一級嚴重缺陷占39%，二級嚴重缺陷占33%，三級嚴重缺陷占21%，四級嚴重缺陷占7%。在此圖中，可以發現一級嚴重缺陷的比例偏高。需要分析一下為什么會出現這種狀況，是否有些缺陷應該在開發過程的單元測試中發現。應該把分析結果反饋給相關開發人員，并共同完善單元測試的測試范圍，盡量讓一級嚴重缺陷在早期發現并修復。
3、按功能分析缺陷
我們一般會看不同功能上發現多少缺陷。有些功能邏輯比較復雜，涉及的方面較多。這種情況所發現缺陷比例就會稍大。有些功能較簡單，和其他功能沒有太大交集，所發現缺陷就會相應較少。
如圖9-5所示，功能2所發現缺陷占總數的41%，而功能4僅為7%。這說明功能2的復雜度相對大些，可能有必要再重新看看測試范圍并增加一些測試案例。
4、按修復時間分析缺陷
一般來講，一級嚴重缺陷需要開發人員一天之內解決，二級嚴重缺陷需要兩天之內解決，三級嚴重缺陷要在一周內解決，四級嚴重缺陷應在兩周內解決。
所以大部分缺陷從開始報告到最終核對并確認修復的周期應在一周內。不同測試類型缺陷修復時間是會稍微有一些差別的。例如性能測試的缺陷和遷移測試的缺陷由于測試環境較為復雜，并且較難找出造成缺陷原因，所以這兩個測試類型的缺陷完成周期會相應長一些。
圖9-6和圖9-7分別是安裝測試缺陷修復時間和性能測試缺陷修復時間數據圖，從圖中可看出，性能測試缺陷修復在20天以上的明顯增多。這是由性能問題的復雜性決定的。依照經驗，解決一個復雜的性能問題，有時候需要一個月甚至兩個月的時間。所以對缺陷修復時間的分析要根據不同測試類別去進行。不同測試類別的缺陷修復數據可以用來作為今后各測試團隊做項目測試計劃的參考數據，例如性能測試要計劃出足夠的時間來核查缺陷修復。
5、按所屬類別分析缺陷
理想情況下，各測試團隊在測試時只發現自己所測類型的缺陷。但現實情況是所有測試類型雖然測試有先后，但也存在很大程度的時間重迭。
例如，由于性能測試的環境和數據要求很復雜，性能測試的測試成本遠遠大于功能測試的測試成本。所以性能測試一般會在其所需要的主要功能測試基本完成的情況下開始。但主要功能測試基本完成，并不代表此功能不存在缺陷。另外，主要功能在測試成功后，也可能由于后來的某些相關代碼改動而存在回歸缺陷。這就造成性能測試中不可避免地發現功能方面的問題。
通過對性能測試團隊所發現缺陷的分析，可以統計出功能測試缺陷所占比例，看是否功能測試缺陷比例過高，是否嚴重影響了性能測試的進度，從而分析在今后的測試過程中，哪些測試流程需要提高而盡量減少性能測試中的功能缺陷。例如增強和功能團隊的溝通，盡量了解性能測試中，每個測試案例里所需主要功能的進展情況等。
另外，性能測試需要安裝和客戶相近的測試環境，所以也會不可避免地發現安裝缺陷。它的測試環境的復雜度也會幫助安裝團隊擴大安裝測試范圍。
如圖9-8所示，在性能測試中，功能缺陷占大約28%。這個比例稍微偏高，會對性能測試的進度有所影響。我們在分析過程中可以著重看看哪些功能缺陷是可以通過提高流程而避免的，并制定好相應計劃，在今后測試中有所改進。
6、操作系統分析缺陷
如果是Java EE的應用程序，應該不會有太多操作系統相關的測試缺陷。但由于安裝程序或多或少會和操作系統的設置文件有關，所以在測試中不可避免地會發現操作系統特定問題，例如某些缺陷只在Solaris上存在，在其他操作系統上沒有問題。
通過缺陷分析，可以清晰地了解操作系統特定缺陷所占比例。如果比例不大，在測試中可以把大部分測試案例都放在機器資源相對充足、便宜且操作系統相對簡單的環境里測試，以減少測試人員和機器資源的消耗。
如圖9-9所示，安裝測試中和操作系統無關的缺陷占88%，所以大部分測試案例可在一種操作系統上進行測試。但因為其他操作系統也存在特定缺陷，所以在所有其他操作系統上，也要安排一些測試案例。
7、按數據庫分析缺陷
現在絕大部分軟件產品會需要數據庫來存儲并提取數據。不同的數據庫處理數據的方式會有所不同。如果一個產品同時支持多種數據庫，就可能存在同樣的測試案例，在一種數據庫上工作正常、但在另外數據庫上出現問題的情況。
在測試過程中要盡量覆蓋所有支持的數據庫。如果有些功能對數據庫不敏感，就只需在某一數據庫上集中測試，在其他數據庫上做些小測試即可。如果功能對數據庫極度敏感，就要考慮不同數據庫都要有足夠的測試范圍。
按數據庫分析缺陷，可以相應看到哪些功能對數據庫敏感且特定缺陷多，就需要考慮是否在此功能上增加不同數據庫的測試范圍。
8、按可用性分析缺陷
在測試過程中，不但要測試產品功能是否正確，還要看產品是否好用，即通過用戶的使用角度來評估產品。由于它反映了用戶的真實使用經驗，所以可以視為一種不可或缺的可用性檢驗過程，例如界面是否友好、是否提供在線幫助，用戶在使用錯誤的情況下是否顯示容易理解的異常信息等。測試團隊應鼓勵測試人員盡可能多地發現可用性缺陷來提高產品的質量，從而使用戶有非常好的產品使用經歷。
例如在安裝產品過程中，如果操作系統不符合產品安裝要求，就應該報出錯誤信息，并終止安裝。如果測試過程中沒有報錯誤信息，只是在安裝中途失敗，這就是一個可用性缺陷。在測試過程中，一定要從客戶的角度來看問題。對于任何在使用時覺得不方便，不通用且容易造成用戶困惑的功能，都要想想是否是可用性缺陷，是否應該進行修訂而提高其易用性。
例如在網上商店注冊時，會要求用戶輸入很多個人信息，例如姓名、年齡、職業、住址、家庭狀況等。有些是必填項，有些是自愿填的。假設在輸入信息時忘記填寫必填的一項，在單擊“完成”按鈕時，如果系統只是提示你有未填項目，并要求你重填所有信息，這對于用戶來講是非常不能忍受的。這種情況就應該開出可用性缺陷。
可用性好的產品會這樣處理：系統提示你有一項沒填，并把未填項標志出來方便你繼續填寫。其他已填好信息依舊保存在頁面上。這樣既方便又快捷地幫客戶解決了問題，從而使用戶得到非常好的使用體驗。
測試過程中可用性缺陷的多少能夠在一定程度上衡量測試人員的專業性和產品質量的高低。一般產品可用性測試沒有專門事先寫好的測試案例，更多的是依靠測試人員的測試經驗和對產品的熟悉程度。如果整個測試過程中，只有很少甚至沒有可用性缺陷，就要好好分析一下原因，看是否是因為測試時間緊張，測試人員只是著重測試了產品的正確性，而忽略了產品使用性的測試。
9、按照其他指標分析缺陷
缺陷分析的指標多種多樣，每個團隊的側重點存在一些差別。我們在前面列舉了幾種分析缺陷的主要方面，除此之外，還有許多指標可以用來做缺陷分析。
例如把缺陷的創始人作為指標來分析，可以看到哪些測試人員所發現的缺陷數量最多，有效性最高。一般來講，同樣的測試類型，有經驗的測試人員平均比無經驗的測試人員發現缺陷多且有效性高。缺陷的擁有者也可以作為指標來分析，從中可以看到哪些開發人員在整個項目中所修復的缺陷最多。
總之，缺陷分析是項目測試時和完成后都需要重視的一項任務。它既能幫助測試人員隨時調整測試范圍和側重點以防患于未然，又能很好地幫助總結經驗教訓，以便于今后項目的提高和發展。
9.4 學習筆記--成品測試之小艾觀
小艾通過成品測試及成品測試之后的經驗總結學到了很多東西：
成品測試的一個主要目的是測試最終介質和包裝有無缺陷，以保證客戶拿到最終產品時能順利安裝并使用我們提供的光盤（CD或DVD）或網上下載的應用程序。成品測試另外一個測試目的是保證產品在前期缺陷修復過程中沒有因為代碼改動而產生新問題。
成品測試階段有其獨特的測試策略和滅蟲方案：
在已存在的測試案例里挑5%～10%重要案例來重新測試以保障以前的代碼改動沒帶來新的質量問題。所被挑選的回歸測試案例盡量能夠涵蓋程序的主要功能，以確保程序的主框架沒有由于前期代碼改動而產生缺陷。
盡量不要在此階段運行新的測試案例，用于保障成品測試能在合理時間內完成（一般為2～4周）并成功交付給客戶或投放市場。
由于不同操作系統平臺或數據庫調用的安裝程序和啟動的包裝有可能不同，所以在測試中各測試團隊要協同作戰，盡可能涵蓋所有系統平臺和數據庫，以保障客戶在不同系統上的正常應用。
所有測試都應基于DVD或DVD ISO文件安裝的應用程序，嚴禁再用測試驅動來安裝應用程序并進行測試。
由于成品測試是測試的最后一個環節，且周期很短，因此就要求代碼改動要特別慎重，以防引起回歸問題。成品測試階段項目組一般要每天審核所發現缺陷并做缺陷綜合分析，根據分析結果制定相應滅蟲策略，有些缺陷可延緩到以后修復。對于要修復的缺陷，必須要有足夠的回歸測試，以保證代碼改動沒帶來新的質量問題。
成品測試之后，需要把最終結果填寫到質量檢測報告中并通過最終審批，產品才能最終交付客戶。質量檢測報告是項目中需要完成并得到審批的一個重要文件，其中包括下面幾個方面：
項目特征；
產品用戶體驗；
性能指標；
產品試用版本計劃；
質量預見性指標，包括評審指標、測試指標、項目退出指標、延緩缺陷指標、源代碼分析指標。
在產品交付后，需要對項目做經驗總結，同時各測試團隊要對所有缺陷做最終缺陷分析，以此總結經驗教訓，以便在今后的項目中做出改進。不同測試類型會有不同的缺陷分析側重點。一般包括缺陷有效性分析、缺陷嚴重性分析、不同功能上發現的缺陷分析、按修復時間分析、按缺陷類別分析、按操作系統或數據庫分析、按可用性分析等。
缺陷分析應該貫穿整個項目測試過程，而不僅僅是在測試完成后。通過不斷進行缺陷分析，來監控在開發和測試中是否存在問題和漏洞，并根據分析結果來調整測試范圍和策略，防患于未然。
（連載完）
相關鏈接：
一個軟件測試工程師的成長日記（連載一）
一個軟件測試工程師的成長日記（連載二）
一個軟件測試工程師的成長日記（連載三）
一個軟件測試工程師的成長日記（連載四）
一個軟件測試工程師的成長日記（連載五）
一個軟件測試工程師的成長日記（連載六）