測試何時結束? 在按計劃結束的那一天結束！ 我這個答案你聽了一定不滿意。但這個答案告訴你微軟所依據的最基本的原則，這就是計劃。在我前面介紹微軟的第一類測試時我提到“測試計劃”，這個“測試計劃”實際上就是要回答測試的投入問題，包括人力資源、時限和過程。確定測試計劃有這么幾個依據：1）產品的功能。功能的量和復雜性直接影響測試的工作量；2）質量標準，有公司的標準、行業的標準、市場反饋的標準和客戶要求的標準等；3）以往的經驗，有以往的產品的經驗，也有個人的經驗。這一“測試計劃”還要被項目的各方（開發，項目管理）審核通過，從而在整個產品部門形成一種共識，這種共識最終被納入項目總體計劃的一部分。對于第二類測試，它也是總項目總體計劃的一部分，而且量也是可知的。一般地說在每個里程碑都會有幾個分專題的“Bug Bash”，每次歷時1-3天。在微軟的項目計劃書中總有那么一天，叫做“測試完成日 Test Complete Day”。它標志著所有計劃的測試活動已全部完成，所有被發現的Bug被全部解決，并被測試所驗證（有一些會因為某些原因被研究決定推遲解決）。 對于以上的分析你也許仍然不滿意：難道微軟的計劃總能按期完成嗎？當然不是，逾期的情況時常會有。幾乎可以肯定，項目的實際執行與預先的計劃一定會有或多或少的差距。微軟會在項目過程中采取一些方法來感知這種差距，比如bitter提到的代碼“覆蓋率”分析和bug數量的變化趨勢分析等。目的是為了盡早地發現差距，重新評估和修訂計劃。這樣計劃可以變化，但測試總是在計劃結束的那一天結束。
對于TL_geong提到的隨機測試造成收斂的缺陷趨勢出現嚴重的發散現象，在微軟也有。通常Bug Bash會產生超乎尋常數量的Bug。一般我們認為，產生Bug的量越大越好。因為，如果產生Bug的數量少，你很難判斷是因為產品的質量確實很高，還是Bug Bash做得不徹底。而且事實往往是后者。 那么對Bug Bash所產生的大量Bug該怎么辦？在微軟，我們有“Bug Triage （測試，開發和項目管理，三方會審）”的制度。對于每個Bug，經過會審后不外乎有以下三中歸宿（總體上來說）： （1）被確認為“缺陷性”Bug，這樣的Bug必須交開發人員解決，然后由原發現人驗證。 （2）被調整為非“缺陷性”Bug，不用開發人員作任何更改，但必須將問題納入產品用戶文檔，明確向用戶解釋，并告訴用戶如何避免和應對。比如這里舉一個假想的例子：產品的某個功能在系統內存嚴重不足的情況下，會暫時停止工作，并生成很多不易被用戶理解的警告信息。這顯然是個Bug（按微軟的標準），正確的應該是，首先軟件不應該完全停止工作，其次不應該多次警告，第三，警告信息應簡明易懂，并給用戶以措施和建議。但是考慮到，一方面這種情況在用戶實際使用產品時發生的機率很低，而另一方面，從開發角度，解決這個問題有很大的技術難度，影響面也太大。這種情況下會把這個Bug改為“文本性”Bug，也就是要求文本遍寫人員將這一情況作一技術性解釋，并建議用戶不要將此產品同其他消耗大量內存的軟件同時使用。這類的Bug在Bug Bash中很常見，因為大家在這種測試活動中思維方式比較超常。 （3）被完全否定，立刻關閉，不再糾纏。這類的情況在Bug Bash中也很常見。因為參與Bug Bash人并不都很了解產品功能的準確用法，誤報是難免的。盡管對這類問題沒有直接的后續措施，但這些信息仍然是有一定價值的，因為將來用戶中的新手很可能會犯同樣的毛病，而產品支持部門如果預先有這樣的經驗，就能及時準確地提供幫助。所以這些信息要保存在Bug的管理庫中，以備將來產品支持部門查詢。 經過這樣的會審，篩選，如果（1）（2）類Bug，特別是（1）類Bug仍然很多，那測試部門很可能需要重新論證原先的測試計劃和測試用例設計，看是否需要增加測試用例。必要時還要盡早提出更改項目總體計劃和發布日期。 大量Bug的出現也許不是件愉快的事，但和把這些Bug留給用戶相比，代價要小得太多了�？傊畬τ诋a品的Bug，要相對待身體的疾病一樣，切末諱疾忌醫。
微軟的軟件測試方法（二） 我在前一篇“微軟的軟件測試方法”中介紹了微軟的兩類基本測試方法，其基本思想大家應該是比較熟悉的，因為它們還只是傳統的軟件測試方法的綜合。所以單從形式上，它并沒有體現出對傳統框架的突破。但是從另一個層面來考察微軟軟件測試時，你會對一些基本的事實感到驚訝。比如，“微軟的測試人員和開發人員數量大致相等或略多”，“微軟的產品成本中測試大約占40%以上”等等。人們會有疑問，僅僅是作為功能驗證和搜尋Bug的測試能消耗這么大量的資源嗎？有必要付出如此大的代價嗎？應該有理由相信，微軟作為一個軟件企業，其每一份投入都是有意義的，因此也可斷定微軟在軟件測試方面的努力一定超出傳統測試方法的范疇。
歷史回顧 為了更好的理解微軟件測試在方法和理念上的突破，我想首先回顧一下軟件開發和軟件測試的發展歷史，并從中揭示其必然性。Edward Kit 在他的暢銷書“Software Testing In The Real World : Improving The Process（1995， ISBN: 0201877562）”中將整個軟件開發歷史分為三個階段：
第一個階段是60年代及其以前，那時軟件規模都很小、復雜程度低，軟件開發的過程隨意。開發人員的Debug過程被認為是唯一的測試活動。其實這并不是現代意義上的軟件測試，當然一階段也還沒有專門測試人員的出現。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
