微軟的軟體測試方法

國內近年來關於軟體測試的問題和討論越來越活躍。但從總體上說交流軟體測試技術的多，而探討軟體測試方法的少。這裡的“技術”指的是具體的戰術問題，比如說如何使用某種工具來解決某一特定測試問題，或者某一類型軟體有哪些測試手段等等。而這裡的“方法”指的是宏觀的戰略問題，或者叫方法論，這包括從軟體測試的概念或理念，到企業軟體品質控制體系；從軟體測試的過程，到測試團隊的設定及其職責的界定等等。

作為測試人員，熱衷於“技術”討論和交流是一件可喜可賀的事。從中可以感覺到軟體測試在中國迅速發展的開端和潛力。但是作為企業的管理決策者，是否也應該以同樣的熱情來思考“方法”問題呢？特別是當一個軟體企業的軟體測試從無到有，或者當企業已有一定的軟體測試的投入，但發現其實效並不顯著，甚至由於測試的引入而帶來了新的管理上的混亂。這個時候方法論的思考，更有利於發現問題的根源。即便是一個基層的測試人員，當積累了一定的技術經驗後，也應該不時從日常的具體工作中走出來，在一個較高層次上進行回顧總結和借鑒，並試著提出一些最佳化和改進的措施，這無論對專業上還是對事業上的成長都是非常有意義的。

微軟在軟體測試方面有很多值得一提的經驗，在此我想以我個人的體會和思考，同大家一同進行一些探討。這裡有一點須要特別說明，儘管微軟的方法已被微軟的實踐多次證明是成功的，非常有效，但這並不意味著這些方法在中國的軟體企業中有廣泛的可行性。一種方法是否可行還受到很多其他因素的影響，比如企業類型（微軟是生產平台軟體和通用軟體產品的企業），企業管理體制，企業文化等等。所以我的目的只是給大家一些思路和借鑒。

 

兩類經典的軟體測試方法

 

在具體介紹微軟的軟體測試方法之前，我想首先從概念，或理念的層面上來理解究竟甚麼是軟體測試，目的是從中匯出微軟測試方法的理論根源。

傳統上認為軟體測試的方法從總體上分為兩類。第一類測試方法是試圖驗證軟體是“工作的”，所謂“工作的”就是指軟體的功能是按照預先的設計執行的；而第二類測試方法則是設法證明軟體是“不工作的”。

提出第一類方法的代表人物是軟體測試領域的先驅Dr. Bill Hetzel（代表論著《The Complete Guide to Software Testing》），他曾於1972年6月在美國的北卡羅來納大學組織了曆史上第一次正式的關於軟體測試的論壇。他首先在1973年給軟體測試一個這樣的定義：“就是建立一種信心，認為程式能夠按預期的設想運行。Establish confidence that a program does what it is supposed to do.”後來在1983年他又將定義修訂為：“評價一個程式和系統的特性或能力，並確定它是否達到預期的結果。軟體測試就是以此為目的的任何行為。Any activities aimed at evaluating an attribute or capability of a program or system. ”在他的定義中的“設想”和“預期的結果”其實就是我們現在所說的使用者需求或功能設計。他還把軟體的品質定義為“符合要求”。

第一類測試可以簡單抽象地描述為這樣的過程：在設計規定的環境下運行軟體的功能，將其結果與使用者需求或設計結果相比較，如果相符則測試通過，如果不相符則視為Bug。這一過程的終極目標是將軟體的所有功能在所有設計規定的環境全部運行，並通過。

在軟體行業中一般把第一類方法奉為主流和行業標準。1990年的IEEE/ANSI標準將軟體測試進行了這樣的定義：“就是在既定的狀況條件下，運行一個系統或組建，觀察記錄結果，並對其某些方面進行評價的過程。The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component (IEEE/ANSI, 1990 [Std 610.12-1990]”這裡所謂“既定的狀況”也可理解為需求或設計。

儘管如此，這一方法還是受到很多業界權威的質疑和挑戰。代表人物是Glenford J. Myers（代表論著《The Art of Software Testing》）。他認為測試不應該著眼於驗證軟體是工作的，相反應該首先認定軟體是有錯誤的，然後去發現儘可能多的錯誤。他還從人的心理學的角度論證，將“驗證軟體是工作的”作為測試的目的，非常不利於測試人員發現軟體的錯誤。於是他於1979年提出了他對軟體測試的定義：“就是以發現錯誤為目的而運行程式的過程。The process of executing a program or system with the intent of finding errors.”這就是軟體測試的第二類方法，簡單地說就是驗證軟體是“不工作的”，或者說是有錯誤的。他甚至極端地認為，一個成功的測試必須是發現Bug的測試，不然就沒有價值。這就如同一個病人（假定此人確有病），到醫院做一項醫學檢查，結果各項指標都正常，那說明該項醫學檢查對於診斷該病人的病情是沒有價值的，是失敗的。我並不完全同意這一看法。

第二類軟體測試方法在業界也很流行，受到很多學術界專家的支援。大家熟悉的Ron Patton在《軟體測試》（ 中文版由機械工業出版社出版，具說此書是目前國內測試新手入門的經典教材）一書的第10頁，有一個明確而簡潔的定義：“軟體測試員的目標是找到軟體缺陷，儘可能早一些，並確保其得以修複。”有些軟體企業以Bug數量來作為考核測試人員業績的一項指標，其實就是接受了這樣的方法。

 

兩類方法的優劣對比

 

雖然軟體測試總的目的是為了軟體產品的品質，但很明顯這兩類測試方法在具體目標、或指導思想上截然相反。由此也決定了它們在思路、過程和測重點上有很大的差別，並各有利弊的。

第一類測試方法以需求和設計為本，因此有利於界定測試工作的範疇，更便於部署測試的側重點，加強針對性。這一點對於大型軟體的測試，尤其是在有限的時間和人力資源情況下顯得格外重要。而第二類測試方法與需求和設計沒有必然的關聯，如果計劃管理不當，測試活動很容易丟失重點，走入歧途。

第一類測試方法可以與軟體的架構和軟體開發的計劃相配合，使軟體測試活動逐層次的展開，從而使軟體的功能和品質有計劃地逐步完善和提高（關於測試的層次問題，我會在今後的討論中專門介紹）。第二類測試方法不具備這種過程的漸進性。

第一類測試方法的缺點是缺乏靈活性，不利於測試人員主觀能動性的發揮，正像Myers先生所說，不容易找到軟體的錯誤（Bug）。而這方面正是第二類測試方法的長處。

 

微軟的策略

 

正是因為認識到兩類測試方法各有利弊，微軟在軟體測試活動中將兩類方法結合起來，以第一類測試方法為基礎和主要線索，階段性地運用第二類測試方法。

 

微軟的第一類測試

 

微軟的第一類測試總體上說分為三個步驟進行：審核需求和設計—〉設計測試—〉實施運行測試。

前文已述，第一類測試是以需求和設計為本來驗證軟體的正確性。大家很自然的想到，需求和設計本身也有正確性的問題。依據不正確的需求和設計不可能開發出正確的軟體產品，測試也將是徒勞的。因此驗證需求和設計是微軟進行第一類測試的第一步。有必要指出的是，這裡所說的需求和設計具體說來它一般包括：（1）由專案經理根據使用者要求（資訊來源於市場部門，使用者支援部門等等）而編寫的需求文本（Requirement Specification）；（2）由專案經理根據需求文本而編寫的功能設計文本（Functional Design Specification）；（3）由開發人員根據功能文本而編寫的實施設計文本（Implementation Design Specification）。微軟的測試人員要參與所有這些文本的審核。作為測試人員，審核重點是檢查文本對使用者需求定義的完整性、嚴密性和功能設計的可測性。同時這種審核對於測試人員也是一種熱身活動，使他們儘早地進入技術和業務狀態。

第二步，測試人員要根據已審核通過的需求和設計編製測試計劃，設計測試案例。在前面提到的三種文本中，功能設計文本是主要依據。原因很簡單，這類測試關心的是軟體是否能正確地實現功能，而不是這些功能如何被具體實施的。從這裡大家可以看出這是典型的“黑箱測試”。確實微軟的測試主要是從使用者角度進行的黑箱測試。這一步的完成就意味著“測試計劃”和“測試案例設計”兩個文本的完成。“測試計劃”文本主要闡述測試的範疇、領域、方法、工具、資源和計劃時間表等等。“測試案例設計”文本要列出測試案例、每個用例的設定、執行步驟和預期結果。測試的這兩個文本也要被專案經理和開發人員審核。這樣經過各種相互的審核，大家對項目形成了基本的共識。

第三步的實施運行測試是整個開發過程中最長最複雜的一個階段。從總體上說就是將上一步設計的測試案例按計劃付諸實施的過程。這包括編寫自動化測試程式、反覆運行自動化測試程式，也包括階段性執行手動測試用例。這一階段的測試必須在周密的計划下進行，在前面我已提到，這正是第一類測試的特點和長處。這種計劃性首先體現在開發與測試的相互協調配合，根據產品的架構和功能模組的依賴關係，按照項目的總體計劃共同推進。從測試的過程來看，總是先運行或執行簡單用例，然後再複雜用例；先驗證單一的準系統，再綜合的端到端的功能；先發現解決表面的，影響面大的Bug，再深層的，不容易重現的Bug。因此隨著項目開發與測試的進程，產品的功能不斷完善，品質不斷提高。這裡有一點要特別指出，有很多測試案例是要反覆啟動並執行，特別是基本的自動化測試每一天，每一個Build上都要運行。儘管這些測試大多數情況下都是通過的，很少再發現新的Bug，但其價值是顯而易見的，就是為了防止品質迴歸。可見Myers的理論在這裡是不適用的。這一階段測試人員還有一項繁瑣但卻很重要的工作，就是對已有的測試案例的維護。比如通常以下兩種情況下要新增一些測試案例，一是對於當初測試設計不周全的領域，二是對於外部的Bug（比如從Beta客戶報告來的），沒有被現有測試案例所覆蓋。當產品的功能設計出現更改時（在微軟這是常事），所涉及的測試案例當然也要相應地修改。

 

微軟的第二類測試

 

微軟的第二類測試是階段性的，常常根據需要而帶有隨機性和突擊性。對於這類測試，在微軟有一個專門的名稱：“Bug Bash（Bug大掃除）”。

Bug Bash通常發生在項目開發各階段（微軟叫裡程碑）的末期，比如Beta版發布前，划出一個專門的時間段（通常1-3天），在這期間所有參與項目的人員，集中全部精力，運用各方面的知識，盡全部智慧來搜尋項目的Bug。這是一個非常有意思的活動，但要組織好這樣的活動並非易事。一般有以下要點：（1）儘管這是一個測試活動，但參與者並不僅限於測試人員。專案經理，開發人員甚至於高層管理員都應參加，如同全民動員。目的是要集思廣益；（2）要鼓勵各部門，領域交叉搜尋，因為新的思路和視角通常有助於發現更多的Bug；（3）為調動積極性，增強趣味性，可以適當引入競爭機制，比如當活動結束時，評出發現Bug最多，發現最嚴重Bug的個人，給以物質和精神獎勵。（4）可以分專題展開，比如安全性、使用者介面可用性、國際化和本地化等等。

微軟的第二類測試除了Bug Bash外，經常還有一些專業性的測試，最典型的是針對安全性攻擊測試。一般會邀請公司內部，或業界的專家來搜尋產品的安全性漏洞。

 

以上我從傳統軟體測試概念的角度，介紹了微軟的策略和兩類傳統測試方法的具體做法，及其側重點。這其實僅僅是一個基礎，一個很原始的基礎。軟體測試在微軟軟體產品開發中的作用、地位遠不是這些原始的方法所能達到的，也不是傳統軟體測試概念所函蓋的。微軟在軟體測試方面有很多特有的做法，和概念上的突破，比如“軟體測試的資訊服務功能”、“以使用者為中心的宏觀品質體系”、“分級測試”、“項目的品質管理系統”、“Bug三方會審”、“測試自動化”和“軟體測試的軟硬體—部門、團隊、人和基礎設施”等等。這些我會在以後的討論中分專題進行介紹。

 

２００４年１１月１８日