軟體開發與測試管理

 摘自電腦世界報

　　要想真正保證軟體項目如期完成，不僅取決於開發人員，更取決於測試人員。

　　專案經理經常犯的錯誤之一，是以為只要僱用軟體工程師就行，其他的人都不必要，或是讓軟體工程師占整個團隊很高的比例。他們也許認為開發人員越多，寫出來的程式也越多，這是錯誤的概念。項目的目的是為了完成軟體，而不是完成更多的程式碼。在Team Dev中，實際有一些工作是不適宜交給軟體工程師做的。

　　要想真正保證軟體項目如期完成，不僅取決於開發人員，更取決於測試人員。軟體開發好像是在趕進度，而不是在演奏交響樂：交響樂是和諧有序而優雅的，而軟體開發卻更像是一堆排山倒海、蜂擁而至的工作。交響樂任何兩個音符都不能相互抵觸，整體表現出來的才是一段優美的音樂。在一切都不確定的軟體開發過程中，讓測試人員的“Bug指揮棒”來使大家知道什麼時候該表現，知道什麼時候該退後一點，正是微軟將軟體開發過程帶向高潮的不二法則！

　　測試組不是開發組的助手

　　似乎沒有誰比微軟更重視測試的力量。在微軟的產品組中，測試組是與產品規劃組、產品管理組、開發組和使用者教育組等並列的隊伍。測試與軟體成本的關係是，發現產品中存在的問題越早，開發費用越低，產品品質越高，軟體發布後維護費用越低。在微軟開發週期的四個階段中，測試的目的在於保證軟體品質，滿足設計的要求和客戶的需求；系統地揭示出不同類型的錯誤，並耗費最少時間和最小工作量；降低軟體的開發成本和維護成本。

　　軟體開發過程中開發人員很可能因為一些偶發的小事，或某種無關的靈感而不知不覺中偏離了實際的需要，暫時忘記了什麼才是產品最該有的功能，把他們拉回原定軌道中的正是測試工程師。測試人員的職責是配合整個項目組保證按照預定的時間表完成達到預定設計目標的產品。測試人員的工作是具有整體性、持久性的軟體開發活動中的一環，而不是偶爾拿出來點綴一下。軟體產品的品質是由用於測試的資源、產品的功能和項目的時間表來決定的，是三者的平衡。對任何的一個產品組來說，無論是主觀，還是客觀上，都要重視測試工程師的存在，這是產品品質的重要保證。

　　羅馬不是一天建成的。早期的微軟開發隊伍中也沒有設立單獨的測試組。那個時候的微軟幾百個人做幾個項目，通常是程式員寫完程式了，自己測試一下就算完事。後來微軟的項目越來越大，軟體越來越複雜，寫代碼和測試的工作要平行進行，漸漸產生了獨立的測試組。一個重要的數字是，微軟產品組中測試人員和開發人員的比例大約是1∶1。其實，要想真正保證軟體項目如期完成，不僅取決於開發人員，更取決於測試人員。

　　測試組獨立於開發組之外的好處在於，程式員總是傾向於認為自己設計的代碼足夠好，獨立的測試組可以使測試人員在不帶任何假設的情況下從不同的角度來測試軟體，有利於保證軟體的品質始終得到控制，並使測試資源得到重用和不斷改進。但是，測試組獨立於開發組之外，並不意味著程式員寫完代碼就扔過“牆壁”，等待測試工程師找到所有的bug，當測試人員認為他的工作就是測試程式，而開發人員認為他的工作就是寫程式給測試人員測試時，如果你是專案經理，要小心了！開發人員的優越感會使測試人員感覺自己是被歧視的少數民族，這勢必會影響到軟體的品質。程式人員在寫完代碼、改正問題後必須完成基本的測試，比如代碼的路徑測試、單元測試和問題驗證等。產品品質控制，存在於開發過程的每一個環節中。

　　有一個笑話，微軟的測試人員工作時間長了，都有挑刺兒的習慣，下了班見了太太做的飯都要評價一番。對微軟來說，那些聰明、細緻、認真，有耐心，追求完美的產品，對使用者有負責任的態度，思維方式獨立又開放，既有足夠的技術背景，但又願意學習新的技術的測試工程師更容易得到“老闆”的青睞。

　　軟體測試的階段性

　　軟體開發的過程就像是一支隊伍正在急行軍，但跑著跑著這支隊伍就會“散了架”，設立裡程碑的作用就彷彿是到了某一個“點”，大家必須要重新整理步伐，實現同步。就測試組的工作模式而言，測試的階段劃分是與項目的進度相對應的。也就是說，測試人員應當與項目組的其他人員始終保持以相同的步伐“跑步”的狀態，與整個項目的每一個裡程碑配合，完成相應的測試工作。

　　把大項目劃分成若干子項目的裡程碑式的開發模式是微軟軟體開發管理的精髓做法，如上一期《微軟研發方法（上）》所述，在微軟的每一個產品開發週期中都有以下幾個重要的裡程碑：CC（Code complete:程式碼完成）；Beta測試；RC（Release Candidate：候選版）；RTM（Release To Manufacture:投入生產），測試人員和產品組的其他人員一起，共同達到每一個裡程碑。一個完整的測試迴圈應當包括運行所有的測試案例、Beta標準測試、bug校正和解所有的bug、隨機測試。好的測試迴圈能夠保證對軟體品質有一個全面完整的評價，每個裡程碑之前至少要有一個完整的測試迴圈。

　　在微軟的產品開發週期中，在規劃階段當開發人員在做計劃、編進度，進行功能實現的可行性研究，對計劃的功能進行反饋時，測試人員應當研究規格說明，編寫測試計劃；在第二個階段即開發階段，當開發人員在編寫代碼、測試和調試的同時，測試人員應當開始設計測試案例，開發自動化的測試工具和程式，熟悉必需的環境、工具、軟體和硬體，不斷地豐富測試案例，直到達到CC（程式碼完成）裡程碑——這個時候的軟體可以進行一次整體測試，使用者介面可能不完美但能夠工作，可能有很多明顯的bug。

　　進入開發週期的第三階段，測試人員大顯身手，展開大規模的測試，比如系統級整體測試，互動性和深層測試。測試之後，測試人員應當對新增的功能說“不”，直至達到Bate測試裡程碑。達到這個裡程碑，意味著所有的Beta致命問題已經被修正和關閉，所有計劃的功能都已經在軟體中並能工作，產品穩定，大部分介面還可以，儘管可能只是一部分，但已經有了線上協助和使用者手冊，即使是發布了也不會引起負面的影響。

　　Beta測試的目的是確定產品是否能在預計的各種硬體平台和作業系統中正常運行，雖然Beta測試的反饋意見很有參考價值，但除非存在重大問題，否則不應對功能集再做修改，所有建議和反饋都留在下一版中再考慮納入。Beta測試之後就要向RC和RTM進軍。測試人員要著重測試Beta後的變動。到達RC，意味著軟體品質狀態為沒有活躍的bug（Active bug）；沒有懸而未決的事；已經穩定了一段時間，如一周內很少或沒有變動，或變動很小。如果RC後的測試沒有發現新的需要改的bug，可以達到RTM，隨後查病毒，驗證光碟片，檢查內容。

　　需要注意的是，在整個階段性的軟體測試過程中，品質不僅僅是測試組的責任。一定要防止完全依賴測試組來保證品質的做法，否則結果只能是品質差、進度延遲。採用Zero-Defect策略的好處在於，可以同時保證產品的品質、進度和功能集，儘早發現和修正產品中的bug，始終把產品的狀態和bug數量控制在可以管理的範圍之內，程式員應該修正所有的優先順序為一級（P1）的bug才能寫新的代碼。

　　同時測試組應當開發一些好的測試管理工具，比如測試案例管理工具和bug的管理工具等等。測試工程師應當細化測試子領域，重視測試案例的數量和品質，對bug狀態的變化要反應迅速。要防止僅以bug多少來評價工程師的工作。

　　bug的發現和管理

　　在微軟的測試人員看來，那些功能沒有實現或與規格說明不一致的問題是bug；不能工作（死機、沒反應）的部分是bug；不相容的部分是bug；邊界條件未做處理是bug；介面、訊息、提示不夠準確是bug；有時把尚未完成的工作也作為一個bug。微軟把軟體中常見的bug類型歸為以下幾類：功能錯誤；使用者介面錯誤；邊界值相關錯誤；初始化錯誤；計算錯誤；記憶體相關錯誤；硬體相關錯誤和文檔錯誤。

　　測試工程師發現bug之後所採取的措施，首先應當是去想法驗證是不是自己的偶然失誤造成bug出現，如不是則應立即建立每一個新的bug記錄，包括具體的再現步驟、環境、螢幕等；儘可能地分析產生bug的原因；設計合適的優先順序和嚴重層級，要記住，測試人員的目標不是找出更多的bug，而是改進產品的品質；依據bug的優先順序和嚴重層級指派給某一個相應的人，如程式員、專案經理和測試組的負責人等。

　　一般來說，bug在資料庫中有三種狀態：活躍（Active）、被解（Resolved）、關閉（Closed）。這三個狀態在微軟通常用“紅黃綠”三個顏色來代表。活躍狀態指的是測試人員建立一個bug時的狀態，必須指派給相應的設計人員、開發人員或者是使用者教育人員，表明bug的狀態是等待糾正的。被解狀態指的是設計人員、開發人員或者使用者教育人員修正bug後的狀態，必須重新指派給報告bug的測試人員，表明bug已經得到修正，但等待校正。關閉狀態指的是測試人員校正完成並關掉之後的狀態，表明bug已經得到修正，並完成了校正，但如果同樣的問題再次出現後，還可能重新啟用成活躍狀態，則又開始了另一輪的狀態迴圈。活躍bug數量的變化趨勢是，一般在程式碼完成前很少，程式碼完成後增長很快，接近Beta測試時會下降，接近RC時奔向零。因此依據每天建立的bug數量與修正的bug數量相比較和處於活躍狀態的bug數量亦可判斷產品品質和裡程碑的訊號。

　　永遠有缺憾是所有智力活動的特徵。軟體一定有數不清的缺點，問題不是在於判斷這個產品好與不好，而是決定修改哪一部分從而可以使產品比較能被使用者接受或喜愛。微軟把這個判斷並修改的過程稱為“急救術”。在急診室中醫生必須非常迅速地察看患者面臨的所有問題，採取最急迫必要的急救醫學措施，然後再依優先順序分別施救。微軟產品組也一樣，他們把bug的嚴重性分為四個層級：導致死機；主要問題，導致嚴重的問題，如某個小功能未實現；小問題，不太嚴重，如提示資訊不太準確；微小的問題，如有個別錯別字。把bug的優先順序分為四個層級：儘快修正；每個裡程碑結束前必須修正；如果時間允許就修正；低優先順序。微軟有“bug法庭”，通常由程式經理召集，由專案經理、開發負責人、測試負責人組成，可根據產品的功能區域分成具體的“bug急救小組（bug
triage team）”，審查每一個bug，選擇和修改產品中最重要的錯誤，決定相應解決方案，盡量使大部分的使用者在大部分的時間內都能夠使用愉快。當然，“bug法庭”開會的頻度取決於處於哪一個階段。

　　測試組應當有一個地區專門放置記錄所有bug的資料庫。這個資料庫應當是整個產品組的中央記錄和控制區，而且其中所有的記錄都無法刪除，對於每個記錄只能一直新增內容。測試組應當有與項目組所有成員交流與溝通的公用工具；與bug mail配合，能根據bug的目前狀態及時通知bug的當前責任人；有效地跟蹤項目的進展，為產品發布提供判斷標準；能積累測試人員成果。

　　秘密武器：測試案例和測試計劃

　　概括來看，微軟測試的精髓做法是：系統可重用的測試案例；以問題（bug）發現和跟蹤為核心的測試活動；獨立的測試人員；基於產品規劃、產品設計規格的測試計劃；與整個項目配合的基於裡程碑的軟體測試周期。而基於產品規劃、產品設計規格的測試計劃和系統可重用的測試案例則是微軟的“秘密武器”。

　　在微軟，測試計劃是協助測試人員管理測試專案和發現bug的重要工具，是綱領性檔案。測試計劃明確了項目的測試工作、測試內容清單，這些內容不能只存在於測試人員的腦海裡，而必須被專案經理、開發經理所瞭解，測試計劃必須增強測試工作和測試實施過程的溝通，具有指導性。測試計劃還必須提供組織管理測試專案的架構結構，協助控制進度。

　　測試計劃涉及的範圍應當有產品概述、測試策略、測試的方法學、測試地區、測試的配置（軟體環境、硬體環境、網路環境）、測試周期（與項目的裡程碑配合）、測試資源的規劃、風險分析和案例等。測試計劃不是一成不變的。雖然測試計劃在產品設計階段就開始被撰寫，但在後來的開發過程中會隨著項目進度表的改變而改變。

　　一個好的測試案例有以下幾個特徵：首先，是最有可能抓住錯誤的；其次，不是重複的、多餘的；第三，一組相似測試案例中最有效；最後，不要太簡單，也不要太複雜。因此，在測試人員設計測試案例時應當遵循以下原則：在人員變化和新項目中能夠重用；能夠分類； 測試的內容不重複；儲存在測試案例的資料庫中；在項目進行過程中可不斷增強。

　　設計測試案例時的一些通常考慮“點”是：根據產品規格測試準系統；設計普通使用者的使用方式情節；設計稀有或特殊的使用方式情節；與系統其他組成部分的配合（如FAX和上網可能都要用到數據機，測試中要考慮對裝置的共用）；考慮特殊情況（比如記憶體和硬體的衝突等）；設計極端情況（比如記憶體流失、破壞性測試等）。