1.測試過程與測試架構(gòu)

1、測試過程與測試架構(gòu)1議題1.對比需求驗證方式測試與缺陷大掃除方式測試2.對比V測試模型與W測試模式3.敏捷測試過程是降低了測試質(zhì)量嗎？4.不同測試類型在軟件工程上的時間點2它山之石可以攻玉微軟在軟件測試方面有很多值得一提的經(jīng)驗，這里有一點須要特別說明，盡管微軟的方法已被微軟的實踐多次證明是成功的，非常有效的，但這并不意味著這些方法在中國的軟件企業(yè)中有廣泛的可行性。一種方法是否可行，還受到很多其他因素的影響，比如企業(yè)類型（微軟是生產(chǎn)平臺軟件和通用軟件產(chǎn)品的企業(yè)），企業(yè)管理體制，企業(yè)文化等等。3兩類經(jīng)典的軟件測試方法在具體介紹微軟的軟件測試方法之前，我想首先從概念，或理念的層面上來理解究竟甚么是軟

2、件測試，目的是從中導出微軟測試方法的理論根源。傳統(tǒng)上認為軟件測試的方法從總體上分為兩類。第一類測試方法是試圖驗證軟件是“工作的”，所謂“工作的”就是指軟件的功能是按照預(yù)先的設(shè)計執(zhí)行的；而第二類測試方法則是設(shè)法證明軟件是“不工作的”。4提出第一類方法的代表人物是軟件測試領(lǐng)域的先驅(qū)Dr. Bill Hetzel（代表論著The Complete Guide to Software Testing），他曾于1972年6月在美國的北卡羅來納大學組織了歷史上第一次正式的關(guān)于軟件測試的論壇。他首先在1973年給軟件測試一個這樣的定義：“就是建立一種信心，認為程序能夠按預(yù)期的設(shè)想運行。Establish c

3、onfidence that a program does what it is supposed to do. ”后來在1983年他又將定義修訂為：“評價一個程序和系統(tǒng)的特性或能力，并確定它是否達到預(yù)期的結(jié)果。軟件測試就是以此為目的的任何行為。 Any activities aimed at evaluating an attribute or capability of a program or system. ”在他的定義中的“設(shè)想”和“預(yù)期的結(jié)果”其實就是我們現(xiàn)在所說的用戶需求或功能設(shè)計。他還把軟件的質(zhì)量定義為“符合要求”。5第一類測試第一類測試可以簡單抽象地描述為這樣的過程：在設(shè)計規(guī)

4、定的環(huán)境下運行軟件的功能，將其結(jié)果與用戶需求或設(shè)計結(jié)果相比較，如果相符則測試通過，如果不相符則視為Bug。這一過程的終極目標是將軟件的所有功能在所有設(shè)計規(guī)定的環(huán)境全部運行，并通過。在軟件行業(yè)中一般把第一類方法奉為主流和行業(yè)標準。1990年的IEEE/ANSI標準將軟件測試進行了這樣的定義：“就是在既定的狀況條件下，運行一個系統(tǒng)或組建，觀察記錄結(jié)果，并對其某些方面進行評價的過程。The process of operating a system or component under specified conditions, observing or recording the results,

5、 and making an evaluation of some aspect of the system or component (IEEE/ANSI, 1990 Std 610.12-1990”這里所謂“既定的狀況”也可理解為需求或設(shè)計。6第二類測試方法盡管如此，這一方法還是受到很多業(yè)界權(quán)威的質(zhì)疑和挑戰(zhàn)。代表人物是Glenford J. Myers（代表論著The Art of Software Testing）。他認為測試不應(yīng)該著眼于驗證軟件是工作的，相反應(yīng)該首先認定軟件是有錯誤的，然后去發(fā)現(xiàn)盡可能多的錯誤。他還從人的心理學的角度論證，將 “驗證軟件是工作的”作為測試的目的，非常不利

6、于測試人員發(fā)現(xiàn)軟件的錯誤。于是他于1979年提出了他對軟件測試的定義：“就是以發(fā)現(xiàn)錯誤為目的而運行程序的過程。The process of executing a program or system with the intent of finding errors.” 這就是軟件測試的第二類方法，簡單地說就是驗證軟件是“不工作的”，或者說是有錯誤的。他甚至極端地認為，一個成功的測試必須是發(fā)現(xiàn)Bug的測試，不然就沒有價值。這就如同一個病人（假定此人確有?。?，到醫(yī)院做一項醫(yī)療檢查，結(jié)果各項指標都正常，那說明該項醫(yī)療檢查對于診斷該病人的病情是沒有價值的，是失敗的。我并不完全同意這一看法。7第二類軟

7、件測試方法在業(yè)界也很流行，受到很多學術(shù)界專家的支持。大家熟悉的Ron Patton在軟件測試（ 中文版由機械工業(yè)出版社出版，具說此書是目前國內(nèi)測試新手入門的經(jīng)典教材）一書的第10頁，有一個明確而簡潔的定義：“軟件測試員的目標是找到軟件缺陷，盡可能早一些，并確保其得以修復?！庇行┸浖髽I(yè)以Bug數(shù)量來作為考核測試人員業(yè)績的一項指標，其實就是接受了這樣的方法。8兩類方法的優(yōu)劣對比雖然軟件測試總的目的是為了軟件產(chǎn)品的質(zhì)量，但很明顯這兩類測試方法在具體目標、或指導思想上截然相反。由此也決定了它們在思路、過程和測重點上有很大的差別，并各有利弊的。第一類測試方法以需求和設(shè)計為本，因此有利于界定測試工作的范

8、疇，更便于部署測試的側(cè)重點，加強針對性。這一點對于大型軟件的測試，尤其是在有限的時間和人力資源情況下顯得格外重要。而第二類測試方法與需求和設(shè)計沒有必然的關(guān)聯(lián)，如果計劃管理不當，測試活動很容易丟失重點，走入歧途。第一類測試方法可以與軟件的架構(gòu)和軟件開發(fā)的計劃相配合，使軟件測試活動逐層次的展開，從而使軟件的功能和質(zhì)量有計劃地逐步完善和提高（關(guān)于測試的層次問題，我會在今后的討論中專門介紹）。第二類測試方法不具備這種過程的漸進性。第一類測試方法的缺點是缺乏靈活性，不利于測試人員主觀能動性的發(fā)揮，正像Myers先生所說，不容易找到軟件的錯誤（Bug）。而這方面正是第二類測試方法的長處。9微軟的策略正是因

9、為認識到兩類測試方法各有利弊，微軟在軟件測試活動中將兩類方法結(jié)合起來，以第一類測試方法為基礎(chǔ)和主要線索，階段性地運用第二類測試方法。10微軟的第一類測試微軟的第一類測試總體上說分為三個步驟進行：審核需求和設(shè)計設(shè)計測試實施運行測試11審核需求與設(shè)計第一類測試是以需求和設(shè)計為本來驗證軟件的正確性。大家很自然的想到，需求和設(shè)計本身也有正確性的問題。依據(jù)不正確的需求和設(shè)計不可能開發(fā)出正確的軟件產(chǎn)品，測試也將是徒勞的。因此驗證需求和設(shè)計是微軟進行第一類測試的第一步。有必要指出的是，這里所說的需求和設(shè)計具體說來它一般包括：（1）由項目經(jīng)理根據(jù)用戶要求（信息來源于市場部門，用戶支持部門等等）而編寫的需求文本

10、（Requirement Specification）；（2）由項目經(jīng)理根據(jù)需求文本而編寫的功能設(shè)計文本（Functional Design Specification）；（3）由開發(fā)人員根據(jù)功能文本而編寫的實施設(shè)計文本（Implementation Design Specification）。微軟的測試人員要參與所有這些文本的審核。作為測試人員，審核重點是檢查文本對用戶需求定義的完整性、嚴密性和功能設(shè)計的可測性。同時這種審核對于測試人員也是一種熱身活動，使他們盡早地進入技術(shù)和業(yè)務(wù)狀態(tài)。12設(shè)計測試用例第二步，測試人員要根據(jù)已審核通過的需求和設(shè)計編制測試計劃，設(shè)計測試用例。在前面提到的三種文本

11、中，功能設(shè)計文本是主要依據(jù)。原因很簡單，這類測試關(guān)心的是軟件是否能正確地實現(xiàn)功能，而不是這些功能如何被具體實施的。從這里大家可以看出這是典型的“黑盒測試”。確實微軟的測試主要是從用戶角度進行的黑盒測試。這一步的完成就意味著“測試計劃”和“測試用例設(shè)計”兩個文本的完成?！皽y試計劃” 文本主要闡述測試的范疇、領(lǐng)域、方法、工具、資源和計劃時間表等等?！皽y試用例設(shè)計”文本要列出測試用例、每個用例的設(shè)置、執(zhí)行步驟和預(yù)期結(jié)果。測試的這兩個文本也要被項目經(jīng)理和開發(fā)人員審核。這樣經(jīng)過各種相互的審核，大家對項目形成了基本的共識。13運行測試用例第三步的實施運行測試是整個開發(fā)過程中最長最復雜的一個階段。 從總體上

12、說就是將上一步設(shè)計的測試用例按計劃付諸實施的過程。這包括編寫自動化測試程序、反復運行自動化測試程序，也包括階段性執(zhí)行手動測試用例。這一階段的測試必須在周密的計劃下進行，這正是第一類測試的特點和長處。這種計劃性首先體現(xiàn)在開發(fā)和測試的相互協(xié)調(diào)配合，根據(jù)產(chǎn)品的架構(gòu)和功能模塊的依賴關(guān)系，按照項目的總體計劃共同推進。從測試的過程來看，總是先運行或執(zhí)行簡單用例，然后再復雜用例；先驗證單一的基本功能，再綜合的端到端的功能；先發(fā)現(xiàn)解決表面的，影響面大的Bug，再深層的，不容易重現(xiàn)的Bug。因此隨著項目開發(fā)和測試的進程，產(chǎn)品的功能不斷完善，質(zhì)量不斷提高。這里有一點要特別指出，有很多測試用例是要反復運行的，特別是

13、基本的自動化測試每一天，每一個Build上都要運行。盡管這些測試大多數(shù)情況下都是通過的，很少再發(fā)現(xiàn)新的Bug，但其價值是顯而易見的，就是為了防止質(zhì)量回歸?？梢奙yers的理論在這里是不適用的。這一階段測試人員還有一項繁瑣但卻很重要的工作，就是對已有的測試用例的維護。比如通常以下兩種情況下要新增一些測試用例，一是對于當初測試設(shè)計不周全的領(lǐng)域，二是對于外部的Bug（比如從Beta客戶報告來的），沒有被現(xiàn)有測試用例所覆蓋。當產(chǎn)品的功能設(shè)計出現(xiàn)更改時（在微軟這是常事），所涉及的測試用例當然也要相應(yīng)地修改。14微軟的第二類測試微軟的第二類測試是階段性的，常常根據(jù)需要而帶有隨機性和突擊性。對于這類測試，在

14、微軟有一個專門的名稱：“Bug Bash（Bug大掃除）”。Bug Bash通常發(fā)生在項目開發(fā)各階段（微軟叫里程碑）的末期，比如Beta版發(fā)布前，劃出一個專門的時間段（通常1-3天），在這期間所有參與項目的人員，集中全部精力，運用各方面的知識，盡全部智慧來搜尋項目的Bug。這是一個非常有意思的活動，但要組織好這樣的活動并非易事。一般有以下要點：（1）盡管這是一個測試活動，但參與者并不僅限于測試人員。項目經(jīng)理，開發(fā)人員甚至于高層管理人員都應(yīng)參加，如同全民動員。目的是要集思廣益；（2）要鼓勵各部門，領(lǐng)域交叉搜索，因為新的思路和視角通常有助于發(fā)現(xiàn)更多的Bug；（3）為調(diào)動積極性，增強趣味性，可以適當

15、引入競爭機制，比如當活動結(jié)束時，評出發(fā)現(xiàn)Bug最多，發(fā)現(xiàn)最嚴重Bug的個人，給以物質(zhì)和精神獎勵。（4）可以分專題展開，比如安全性、用戶界面可用性、國際化和本地化等等。微軟的第二類測試除了Bug Bash外，經(jīng)常還有一些專業(yè)性的測試，最典型的是針對安全性攻擊測試。一般會邀請公司內(nèi)部，或業(yè)界的專家來搜尋產(chǎn)品的安全漏洞。15以上從傳統(tǒng)軟件測試概念的角度，介紹了微軟的策略和兩類傳統(tǒng)測試方法的具體做法，及其側(cè)重點。這其實僅僅是一個基礎(chǔ)，一個很原始的基礎(chǔ)。軟件測試在微軟軟件產(chǎn)品開發(fā)中的作用、地位遠不是這些原始的方法所能達到的，也不是傳統(tǒng)軟件測試概念所函蓋的。微軟在軟件測試方面有很多特有的做法，和概念上的突

16、破，比如“軟件測試的信息服務(wù)功能”、“以用戶為中心的宏觀質(zhì)量體系”、“分級測試”、“項目的質(zhì)量管理系統(tǒng)”、“Bug三方會審”、“測試自動化”和“軟件測試的軟硬件部門、團隊、人和基礎(chǔ)設(shè)施”等等。16ProductCycleModel計劃設(shè)計執(zhí)行穩(wěn)定發(fā)布產(chǎn)品市場的定位,遠景規(guī)劃分析市場的調(diào)查和反饋 用戶需求總結(jié) 制定項目范圍 確定開發(fā)資源 制定產(chǎn)品的市場定位 設(shè)計規(guī)范書 開發(fā)構(gòu)架設(shè)計 測試計劃 開發(fā)時間表 開發(fā)人員產(chǎn)品功能的開發(fā) 測試人員進行功能性的測試UE（UserEducation）寫用戶文檔 市場人員制訂市場計劃 程序經(jīng)理控制整體開發(fā)進度集成測試功能測試全部完成程序到達”zero bug”

17、使用說明內(nèi)容完成最后校驗最終版本送交發(fā)行使用說明書提交發(fā)行 市場營銷及發(fā)布活動 發(fā)行后勤準備售后服務(wù)及用戶支持系統(tǒng)運行17Process OverviewSpec ReviewTestingSoftware LocUA LocDesignSpecDogfoodBuildsBeta2B2TRRC1M1M3M2CCBetaRelease CandidateRC2 Beta 1CodingPlanningRTMVisualFreeze18Test RoadmapPlanningGet ReadySpec reviewTest PlanTest CasesCoding (Private, Dogfoo

18、d builds)Milestone M1-M3Unit TestFeature crew testCheck-in testCode CompleteAcceptance testInternational Sufficiently testing startBetaBeta1, B1TR, Beta2, B2TRUser Scenario testingLocalization testing startZBBTriageRelease Candidate (RC build)RC1, RC2Test passBug bashFeature Sign offTriageRelease to Manufacture (RTM)Exit CriteriaTesting sign offService Pack, hot fixSP1, SP2, Hot fix 一般是安全更新Sanity check test19測試活動在軟件項目生命周期中的位置Project Scope項目范圍單元測試準備系統(tǒng)測試階段集成測試階段單元測試階段編碼階段詳細設(shè)計階段概要設(shè)計階段軟件需求規(guī)格階段系統(tǒng)測試計劃集成測試計劃系統(tǒng)測試準備單元測試計劃集成測試準備單元測試執(zhí)行單元測試報告系統(tǒng)測試執(zhí)行系統(tǒng)測試報告集成測試執(zhí)行集成測試報告項目計劃階段項目準備階段