軟件開發與測試管理
摘要：測試組不是開發組的助手；軟件測試的階段性；bug的發現和管理；秘密武器：測試用例和測試計劃。
要想真正保證軟件項目如期完成，不僅取決于開發人員，更取決于測試人員。
項目經理經常犯的錯誤之一，是以為只要雇用軟件工程師就行，其他的人都不必要，或是讓軟件工程師占整個團隊很高的比例。他們也許認為開發人員越多，寫出來的程序也越多，這是錯誤的概念。項目的目的是為了完成軟件，而不是完成更多的程序代碼。在開發團隊中，實際有一些工作是不適宜交給軟件工程師做的。
要想真正保證軟件項目如期完成，不僅取決于開發人員，更取決于測試人員。軟件開發好像是在趕進度，而不是在演奏交響樂：交響樂是和諧有序而優雅的，而軟件開發卻更像是一堆排山倒海、蜂擁而至的工作。交響樂任何兩個音符都不能相互抵觸，整體表現出來的才是一段優美的音樂。在一切都不確定的軟件開發過程中，讓測試人員的“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）。這三個狀態在微軟通常用“紅黃綠”三個顏色來代表�；钴S狀態指的是測試人員新建一個bug時的狀態，必須分派給相應的設計人員、開發人員或者是用戶教育人員，表明bug的狀態是等待糾正的。被解狀態指的是設計人員、開發人員或者用戶教育人員修正bug后的狀態，必須重新分派給報告bug的測試人員，表明bug已經得到修正，但等待校驗。關閉狀態指的是測試人員校驗完成并關掉之后的狀態，表明bug已經得到修正，并完成了校驗，但如果同樣的問題再次出現后，還可能重新激活成活躍狀態，則又開始了另一輪的狀態循環�；钴Sbug數量的變化趨勢是，一般在代碼完成前很少，代碼完成后增長很快，接近Beta測試時會下降，接近RC時奔向零。因此依據每天新建的bug數量與修正的bug數量相比較和處于活躍狀態的bug數量亦可判斷產品質量和里程碑的信號。
永遠有缺憾是所有智力活動的特征。軟件一定有數不清的缺點，問題不是在于判斷這個產品好與不好，而是決定修改哪一部分從而可以使產品比較能被用戶接受或喜愛。微軟把這個判斷并修改的過程稱為“急救術”。在急診室中醫生必須非常迅速地察看患者面臨的所有問題，采取最急迫必要的急救醫療措施，然后再依優先級分別施救。微軟產品組也一樣，他們把bug的嚴重性分為四個級別：導致死機；主要問題，導致嚴重的問題，如某個小功能未實現；小問題，不太嚴重，如提示信息不太準確；微小的問題，如有個別錯別字。把bug的優先級分為四個級別：盡快修正；每個里程碑結束前必須修正；如果時間允許就修正；低優先級。微軟有“bug法庭”，通常由程序經理召集，由項目經理、開發負責人、測試負責人組成，可根據產品的功能區域分成具體的“bug急救小組（bug triage team）”，審查每一個bug，選擇和修改產品中最重要的錯誤，決定相應解決方案，盡量使大部分的用戶在大部分的時間內都能夠使用愉快。當然，“bug法庭”開會的頻度取決于處于哪一個階段。
測試組應當有一個區域專門放置記錄所有bug的數據庫。這個數據庫應當是整個產品組的中央記錄和控制區，而且其中所有的記錄都無法刪除，對于每個記錄只能一直添加內容。測試組應當有與項目組所有成員交流與溝通的公用工具；與bug mail配合，能根據bug的當前狀態及時通知bug的當前責任人；有效地跟蹤項目的進展，為產品發布提供判斷標準；能積累測試人員成果。
秘密武器：測試用例和測試計劃
概括來看，微軟測試的精髓做法是：系統可重用的測試用例；以問題（bug）發現和跟蹤為核心的測試活動；獨立的測試人員；基于產品規劃、產品設計規格的測試計劃；與整個項目配合的基于里程碑的軟件測試周期。而基于產品規劃、產品設計規格的測試計劃和系統可重用的測試用例則是微軟的“秘密武器”。
在微軟，測試計劃是幫助測試人員管理測試項目和發現bug的重要工具，是綱領性文件。測試計劃明確了項目的測試任務、測試內容清單，這些內容不能只存在于測試人員的腦海里，而必須被項目經理、開發經理所了解，測試計劃必須增強測試任務和測試實施過程的溝通，具有指導性。測試計劃還必須提供組織管理測試項目的框架結構，幫助控制進度。
測試計劃涉及的范圍應當有產品概述、測試策略、測試的方法學、測試區域、測試的配置（軟件環境、硬件環境、網絡環境）、測試周期（與項目的里程碑配合）、測試資源的規劃、風險分析和案例等。測試計劃不是一成不變的。雖然測試計劃在產品設計階段就開始被撰寫，但在后來的開發過程中會隨著項目進度表的改變而改變。
一個好的測試用例有以下幾個特征：首先，是最有可能抓住錯誤的；其次，不是重復的、多余的；第三，一組相似測試用例中最有效的；最后，不要太簡單，也不要太復雜。因此，在測試人員設計測試用例時應當遵循以下原則：在人員變化和新項目中能夠重用；能夠分類； 測試的內容不重復；保存在測試用例的數據庫中；在項目進行過程中可不斷增強。
設計測試用例時的一些通�？紤]“點”是：根據產品規格測試基本功能；設計普通用戶的使用方案；設計稀有或特殊的使用方案；與系統其他組成部分的配合（如FAX和上網可能都要用到調制解調器，測試中要考慮對設備的共享）；考慮特殊情況（比如內存和硬件的沖突等）；設計極端情況（比如內存泄漏、破壞性測試）等．
文章來源于領測軟件測試網 http://www.kjueaiud.com/
