9.2 黎明前的黑暗--漏網之蟲
坐在實驗室的機器前，小艾用DVD光碟按照安裝指示文檔安裝好產品，就開始運行所分配的功能測試案例。因為所分配給的測試案例都是小艾在測試第一和第二階段運行過的案例，小艾感覺執行起來輕車熟路。一上午就完成了快一半，小艾暗暗松口氣，為自己的進度感到高興。
9.2.1 老案例生新蟲子
中午吃過飯之后，小艾又急忙回到實驗室運行測試案例。接近下午3點時，小艾在運行一個案例時發現了一個較嚴重的問題。小艾記得自己兩周前在功能測試第二階段運行過這個案例，當時沒有發現任何問題。小艾怕自己記錯，趕忙到數據庫里查了一下這個測試案例運行的歷史，發現最后一次成功運行的確是在兩周前。
小艾于是懷疑最近兩周這個功能有新的代碼改動，為了進一步確定，他就又查了一下和這個功能有關的最近兩周的缺陷修改歷史，發現一周前開發團隊的姚圳曾由于修復和這個功能有關的性能缺陷而修改過相關代碼。由此，小艾基本肯定他新發現的功能問題是由于最近的代碼改動引起的。于是他在代碼管理系統里開了一個缺陷記錄，標明是回歸問題，并把自己的一些初步調查結果也注明在記錄里，以方便開發人員參考。
考慮到問題比較嚴重，時間又很緊迫，小艾立即給姚圳打了個電話，把情況說了一下，并告訴姚圳可以參考他所開的缺陷記錄來得到案例步驟及錯誤信息等詳細情況。
姚圳聽后說：“好的，謝謝你及時通知我，我會立即看一下。這個問題聽起來很嚴重，而且對客戶影響很大，需要馬上解決。我會爭取今天找到問題原因和解決辦法。不知你明天能否早一點到公司，我需要你幫忙試一下代碼補丁。由于現在是成品測試階段，項目組要求所有正式源代碼改動都需要事先在測試環境里通過案例測試和相關回歸案例測試，測試完成后才能得到項目經理授權集成到下一個成品測試候選驅動里。”
第二天早晨小艾早早來到辦公室，就看到姚圳發來的電子郵件。從電子郵件時間上看，姚圳一定為這個問題忙到了半夜。小艾不敢耽誤，馬上開始安裝補丁并進行相應案例測試。為了保險起見，小艾又把和這個功能有關的一些主要案例運行了一遍，以防止又產生新的回歸問題。
接近中午時，小艾終于順利完成了補丁測試，他于是興沖沖地跑去通知了姚圳。
姚圳松了一口氣，笑著對小艾說：“太好了，我們在昨天下午4點的成品測試缺陷評判例會上已討論過你發現的這個問題及它對客戶的影響，項目組讓我們兩天內盡快解決這個缺陷。這下好了，我們提前一天完成了任務。我會參加今天下午4點的成品測試缺陷評判例會并匯報一下最新情況。如果不出意外，這個問題的源代碼改動應集成在明天的成品測試候選驅動里。”
小艾很不好意思地說：“呵呵，我可知道你昨天為了解決這個問題熬到快半夜1點，你才是勞苦功高呢。姚圳，你是公司的老員工，參加了好多項目開發工作。你能告訴我成品測試缺陷評判例會主要有哪些內容嗎？”
姚圳拍了拍小艾的肩膀說：“你可問對人了！ 我參加了好多次這樣的例會，的確有一些了解。這個例會主要用來及時分析所發現的缺陷并根據缺陷影響給出解決方案。一般項目經理都會要求各開發團隊代表、各測試團隊代表、客戶支持代表甚至產品補丁版本項目經理一起參加。在會上項目經理通過聽取各方意見來決定缺陷的最終解決方案。”
小艾很疑惑地問道：“難道我們不應該通過及時修訂代碼，在把產品交付客戶之前滅掉所有發現的蟲子嗎？”
姚圳回答道：“你說的是理想情況。實際來講，成品測試階段時間有限，所有測試都已基本接近尾聲。如果這時改動大量代碼，又沒有足夠時間進行必要回歸測試，就很容易造成回歸缺陷不被發現。這樣反而會給客戶造成更大損失。所以成品測試階段有和測試前期階段不同的滅蟲策略。我們一般需要在此期間對發現的蟲子進行綜合分析，并根據對客戶的影響和其緊迫性提出相應解決方案。”
小艾很期盼地問道：“根據這么多年的經驗，你能告訴我一般都對蟲子做哪些分析，相應地都有哪些解決方案嗎？”
9.2.2 艱難抉擇--漏網之蟲綜合分析及滅蟲策略
在中午吃飯時間里，姚圳給小艾詳細解說了成品測試階段缺陷綜合分析及相應滅蟲策略。
缺陷綜合分析要點：
缺陷是如何發現的。如果不是回歸問題，為什么在測試前期沒有發現，是否存在其他潛在的測試漏洞。
通過對蟲子漏網原因的分析，能夠更清晰地明白是否存在嚴重測試漏洞。修復此缺陷后是否需要增加回歸測試范圍以防再出現同樣功能的回歸問題。
有幾種方法可以解決缺陷，每種方法的優缺點及客戶接受程度。
例如某些缺陷是可通過多種方法解決的，但每種方法對代碼架構的影響、對測試成本的影響和對客戶的影響都不盡相同。需要平衡時間、成本及客戶接受程度等要素來決定此時最佳解決方案。
缺陷修改對當前代碼架構的影響，會影響到哪些測試團隊。
例如有些代碼改動可能需要功能測試團隊，性能測試團隊和安裝測試團隊重新運行一些測試案例。
受影響的測試團隊需要多少時間和人力來完成由于代碼修改而必須運行的測試案例包括回歸測試案例。
通過測試成本計算，能夠清晰地知道是否能有足夠時間和人力在產品交付時間之前完成缺陷修復。
如果此缺陷不在當前版本里修改，會對客戶和客戶技術支持團隊造成什么影響。
客戶影響是非常重要的一個要素。有些缺陷被叫做“禁止交付”缺陷，顧名思義就是如果產品存在這些缺陷，則產品不能交付給客戶。因此所有“禁止交付”缺陷一定要在產品交付前有解決方案。
另外，客戶技術支持團隊需要衡量一下，如果某缺陷不在當前版本修復，在當前產品版本推向市場后如果客戶遇到相同問題，客戶技術支持團隊會需要額外付出多少人力資源來和客戶溝通并解決客戶問題。
客戶對此產品缺陷的最大容忍時間大約多久。
通過分析客戶對修復此缺陷的緊迫性來決定是在當前產品版本修復還是將缺陷修復推延到以后的產品新版本包括補丁版本、小版本或產品下一升級版本。
根據缺陷分析結果，一般會有以下解決方案：
在當前產品版本里修改缺陷，并按時交付客戶。
例如：某些缺陷對客戶影響大且缺陷修改對代碼構架影響較小，測試團隊能按期完成測試任務。
在成品測試階段，所有缺陷修改必須經過項目經理同意并通過案例測試和回歸測試后才能集成到下一個成品測試候選驅動上。
在當前產品版本里不修訂缺陷，盡快在產品補丁版本或小版本里修改缺陷，并盡快交付客戶。
例如一些產品功能客戶在產品上線初期不會用到，和此功能有關的一些缺陷可以在隨后發布的補丁版本里修復。
在當前產品版本里不修復缺陷，在下一個產品升級版本里修改缺陷。
例如有些缺陷對客戶業務影響不是很大，只是在應用上需要一些改進而使客戶應用起來更方便，對于此類缺陷，如果是在測試前期當然是盡可能修復。但在測試后期，尤其是成品測試階段，就盡量不要因為此類缺陷改代碼而引起不必要的回歸問題。
在當前產品版本里修改缺陷，但需要推遲交付客戶。
這種情況很少見。原因可能是前期測試存在重大漏洞，而存在的缺陷是客戶不能接受的，但產品開發團隊又無法在原定交付時間完成缺陷修復和相關測試。當然這種情況是每個產品項目都要想方設法避免的。
注意：如果缺陷修復需要推延到以后的產品新版本包括補丁版本、小版本或產品下一升級版本，除了需要得到開發團隊、測試團隊和項目經理的同意外，還需要得到客戶技術支持團隊的同意和支持，以便客戶遇到相同問題時，可以和客戶溝通。如果對此問題有臨時解決方案，也需要第一時間通知客戶支持團隊以便在客戶需要時提供給客戶。
小艾在姚圳的詳盡介紹中受益匪淺，他開始考慮或許這些缺陷綜合分析方法不只在成品測試階段需要，也可借鑒到整個測試階段，尤其是測試后期。
9.3 金蛋閃亮登場
下午的測試進行得非常順利，小艾在3點時就完成了所有案例測試和清單列表的檢測，并把結果報告發給凱文。報告中也詳細說明了缺陷產生的原因和缺陷修復進度，以及對姚圳所提供代碼補丁的測試結果。
9.3.1 成品測試勝利退出
5點多，凱文找到小艾說：“你報告的那個缺陷項目組已決定會在今夜的驅動里修復。明天早晨10點左右你應該就能拿到新的驅動。需要你在新驅動上重新運行和這個缺陷有關的一些案例并確保沒有產生新的回歸問題。”
小艾問道：“這會是最后一個成品測試候選驅動嗎？”
凱文搖了搖頭說：“很遺憾，不是最后一個。安裝測試團隊在卸載產品案例中發現了一個比較嚴重的問題，開發團隊正在研究解決方案，目前來看代碼改動無論如何也進不了今天晚上的驅動。最好情況是明天讓安裝測試團隊測試一下代碼補丁，確保沒問題了再進下一個成品測試候選驅動。另外遷移測試團隊的測試案例明天才能全部測試完成，現在不知是否會有新的缺陷產生。”
第二天，小艾按照所定計劃完成了對缺陷修復相關案例的測試，再沒有發現新的問題。小艾稍稍松了口氣。
由于其他測試團隊在新驅動里又發現了些問題，需要多個系統環境進行問題調查，小艾在接下來的幾天里，被找去幫忙準備測試環境。凱文穿梭在不同團隊之間協調人員和機器資源以加速整體測試進度，忙得不可開交。
所有人都忙而有序地工作著，等待著最后的勝利。
終于，凱文發出電子郵件給所有人員，計劃將第四個成品測試候選驅動擬定為最終成品候選驅動，要求各測試團隊按照計劃對最后成品測試驅動進行最后一輪測試。
又經過兩天緊張的忙碌，所有測試最終勝利完成，所有測試團隊包括性能測試團隊都相繼發出電子郵件正式宣布測試完成，成品測試勝利退出。
凱文在接到成品測試勝利退出的喜訊之后，隨即宣布確定第四個成品測試候選驅動即為最終成品驅動，并告知大家質量檢查報告也剛已通過最終審批。按計劃明天將最終ISO文件交付給生產商制造物理光碟和供網上下載的電子光碟。
整個辦公室充盈著喜悅的氣氛，經過近一年的努力，終于結出了勝利的果實，捧出了沉甸甸的金蛋，小艾由衷地為自己和團隊感到驕傲和自豪。高興之余，小艾對凱文信中提到的質量檢測報告有些迷惑，于是他就去找凱文請教。
凱文一見到小艾，就拍著他的肩膀笑著說：“你在這個項目中成長了很多，表現不錯。下一個項目你就是老員工，不再是菜鳥啦！”
小艾很不好意思地說：“要學的東西太多了，我也就剛入門。接觸的事情越多，覺得要學習的東西就越多。這不又來向你請教了。”
凱文說：“你之所以能夠成長很快，就是因為你有很好的求知欲。我很高興能幫到你，有什么問題盡管說。”
小艾于是問道：“在你的郵件里提到的質量檢測報告是怎么回事？我在測試階段并沒有接觸到，你能給我簡單介紹一下報告內容嗎？”
凱文于是給小艾做了詳盡的介紹，并把一些資料發給小艾供他參考和學習。
9.3.2 質量檢測報告之大觀
小艾認真閱讀了相關材料，對質量檢測報告有了很深的了解。
質量檢測報告是項目中需要完成并得到審批的一個重要文件。在項目初期，項目經理需要和各團隊負責人共同制定產品質量檢測計劃，其中大致包括：
1、項目特征
其中包括產品交付日期、項目大致介紹、項目大約所需人力物力數據、項目管理所需的幾個關鍵日期、已知或潛在的開源產品介紹、開發流程特征等。
2、產品用戶體驗
需要給所開發產品的可用性、可靠性、安全性、集成性、維護性等方面制定一些具體指標，以保證用戶在使用該產品時有良好的用戶體驗。
3、性能指標
需要制定一些性能方面的指標，客戶可根據這些數據來配置硬件設施以期有效地應用產品，避免超負載、運行過慢等有害現象。
4、產品試用版本計劃
需要指明產品是否有產品試用版本計劃，如果有此計劃，需要列明試用版本交付日期（一般要早于產品正式交付日期）和潛在試用客戶名單。最后還需列明期望客戶在哪些方面（例如可用性、可靠性、功能性、維護性、安裝性等方面）給予反饋信息以促進產品的改進和提高。當然在產品正式交付前，還應有個客戶試用版滿意度調查，以了解客戶對產品的功能和質量的總體看法，從客戶反饋方面看產品是否達到交付標準。
5、質量預見性指標
這項指標是產品質量保障的重要監測指標。通過這些指標的制定，可以對開發和測試環節的流程，方法及范圍起到有效的監督作用。主要包括：
評審指標：這項指標會通過判定相關人員是否評審了產品構架方案、設計方案、測試架構、測試方案、測試案例及程序源代碼來進行質量把關。它會對每項評審列出詳細評審方法。評審指標非常重要，通過專家一起評審，能夠有效杜絕嚴重設計錯誤和測試漏洞。
測試指標：這項指標會通過判定測試是否包括功能測試、全球化測試、性能測試、系統測試及回歸測試來進行質量把關。
指標還包括缺陷發現計劃進度和實際進度的比較，誤差越小越好，最好小于某指定百分比（例如10%），說明測試計劃和實際相吻合，產品質量危險系數小。否則需要進行誤差分析，看是否存有潛在的問題。
如圖9-1所示，實際和計劃進度誤差在上下10%之內。可以說測試基本是按計劃進行的，沒有太多出入。后期缺陷發現率顯著下降最后趨于零，說明產品已趨于穩定，可以交付使用。
測試指標還包括各測試類別測試案例嘗試執行和測試案例成功完成的百分比。在產品質量檢測報告里需要明確指出在測試計劃里是否所有測試案例都能100%嘗試執行，也需要明確預期在交付產品時各測試類別能最終成功完成多少測試案例。
一般情況下，如果交付產品時缺陷修復在95%以上，所有測試案例成功率在95%以上，可以認為產品質量是有保障的，存在問題的風險系數比較低。如果交付產品時各測試類別達不到90%的測試案例成功率，這個產品的質量就會有較大隱患，以后出問題的風險比較高。
項目退出指標：在這項指標里會要求在交付產品里，所允諾的功能都完成了開發和測試。如果是升級版本，還會要求沒有回歸問題產生，即老版本中的功能在新版本中依然正常工作。
延緩缺陷指標：我們在前面提到過（請參考9.2.2節），出于時間和安全性考慮，某些缺陷修復需要推延到以后的產品新版本包括補丁版本、小版本或產品下一升級版本。在延緩缺陷指標里一般會要求交付產品時，這些延緩修復缺陷不能超過總體發現缺陷的一定百分比（例如10%），從而對產品所知缺陷率有總體控制，保證產品質量。在這項指標里一般也會硬性規定不能延緩修復任何嚴重缺陷。
源代碼分析指標：這項指標會評測源代碼是否利用一些工具進行了靜態代碼分析、架構分析、代碼測試覆蓋度分析，用于從側面判定產品質量是否有保障。
質量檢測計劃報告通過審批后，所列項目特征和指標就不能隨便改了。如需改動，需要重新審批。
在項目測試完成后，需要把最終結果填寫到報告中通過最終審批，拿到質量檢測合格證書，才能交付產品。最終審批主要是看以下幾個方面：
項目最終是否和計劃的項目特征相符，是否按照計劃進行開發流程。
產品用戶體驗的指標諸如可用性、可靠性、安全性、集成性、可維護性等方面是否達到要求。
所定性能指標是否能達到計劃的標準。
產品試用版本的客戶滿意度調查結果是否達到交付標準。
是否按照計劃評審了產品構架方案、設計方案、測試架構、測試方案、測試案例及程序源代碼。
缺陷發現計劃進度和實際進度誤差是否小于指定百分比（例如10%）。
各測試類別測試案例是否100%嘗試執行，測試案例成功率是否能達到指定百分比（例如95%）。
所允諾的功能是否都完成了開發和測試。如果是升級版本，是否沒有回歸問題產生。
延緩修復缺陷是否小于總體發現缺陷的指定百分比（例如10%），而且無嚴重缺陷延緩修復。
9.3.3 趁熱打鐵總結經驗教訓
產品順利交付了，各個團隊都在組織討論和總結經驗教訓。項目經理也發出產品調查表讓大家填寫，希望大家在評定產品質量如何的同時，進一步總結在開發和測試過程中好的經驗和需要改進的方面，鼓勵大家提出如何改進的建議以便在將來的項目中進行改善，從而使產品質量得到持續的提高。
產品調查表包括下列幾個問題。
請選擇你在項目中的角色：
（1）產品架構師
（2）產品開發人員
（3）文檔開發人員
（4）測試人員
（5）其他
請評估項目產品質量如何：（分為1級到5級，其中1級為最差，5級為最好）
（ ）5 （ ）4 （ ）3 （ ）2 （ ）1
請列舉項目中你認為產品質量最好的部分：
請列舉項目中你認為需要提高的部分：
請列舉項目中你認為應該在將來的項目中繼續執行的最重要的經驗（包括影響力，相關團隊，以及如何在將來的項目中執行）：
請列舉項目中你認為應該在將來的項目中改進的最重要的部分（包括影響力，相關團隊，潛在的問題或者原因，改進的建議）：
請列舉你是否有其他的建議：
小艾根據自己測試的部分填寫了自己對產品不同功能的意見和建議。并認真回顧了一下在整個項目中的所有測試歷程，給團隊和項目組提出了如下反饋：
應該在將來的項目中繼續執行的最重要的經驗：
（1）各團隊之間總體有很好的溝通，有問題能夠很快找到相關人員解決。
（2）測試計劃和實際基本相符，開發及測試都能按計劃時間完成。
（3）各測試類型團隊之間沒有壁壘，能夠很快互相調動人力物力互相支持，以保障測試整體順利按期完成。比如，功能測試人員幫助安裝測試等。
應該在將來的項目中改進的最重要的部分：
產品功能上存在設計變動時，開發團隊需要和測試團隊提前溝通。測試團隊需要根據新的設計來變動或添加測試案例。否則，測試團隊會根據老的設計而開出無效缺陷，不但浪費了測試人員和開發人員的時間，還容易產生測試漏洞。
在產品測試階段，任何人有需要安裝產品時，也一定要嚴格按照安裝文檔來安裝，如果發現文檔里步驟不正確，要報告問題并要求相關團隊修改文檔。因為安裝測試需要涵蓋的范圍太廣，安裝測試團隊不可能涵蓋所有情況。其他人可在力所能及的情況下，幫助安裝團隊發現問題。
項目組在收集到所有反饋后，會召開會議和各團隊代表一起逐條討論。對于有效反饋需要相關團隊制定改進計劃以便在今后的項目里實施。這些反饋里，既包括開發和測試流程的改進建議，也有對產品設計和所用開發及測試工具的改進建議。總之，給大家一個平臺可以讓所有人暢所欲言，總結經驗教訓，并以此作為參考來更好地完善今后的項目計劃和實施。
（未完待續）
相關鏈接：
一個軟件測試工程師的成長日記（連載一）
一個軟件測試工程師的成長日記（連載二）
一個軟件測試工程師的成長日記（連載三）
一個軟件測試工程師的成長日記（連載四）
一個軟件測試工程師的成長日記（連載五）