微軟的軟件測(cè)試方法開(kāi)發(fā)者在線
本文關(guān)鍵詞： 微軟 軟件測(cè)試
這里的“技術(shù)”指的是具體的戰(zhàn)術(shù)問(wèn)題，比如說(shuō)如何使用某種工具來(lái)解決某一特定測(cè)試問(wèn)題，或者某一類型軟件有哪些測(cè)試手段等等。而這里的“方
法”指的是宏觀的戰(zhàn)略問(wèn)題，或者叫方法論，這包括從軟件測(cè)試的概念或理念，到企業(yè)軟件質(zhì)量控制體系；從軟件測(cè)試的過(guò)程，到測(cè)試團(tuán)隊(duì)的設(shè)置及其職責(zé)的界定等
等。
作為測(cè)試人員，熱衷于“技術(shù)”討論和交流是一件可喜可賀的事。從中可以感覺(jué)到軟件測(cè)試在中國(guó)迅速發(fā)展的開(kāi)端和潛力。但是作為企業(yè)的管理決策者，是否
也應(yīng)該以同樣的熱情來(lái)思考“方法”問(wèn)題呢？特別是當(dāng)一個(gè)軟件企業(yè)的軟件測(cè)試從無(wú)到有，或者當(dāng)企業(yè)已有一定的軟件測(cè)試的投入，但發(fā)現(xiàn)其實(shí)效并不顯著，甚至由
于測(cè)試的引入而帶來(lái)了新的管理上的混亂。
這個(gè)時(shí)候方法論的思考，更有利于發(fā)現(xiàn)問(wèn)題的根源。
即便是一個(gè)基層的測(cè)試人員，當(dāng)積累了一定的技術(shù)經(jīng)驗(yàn)后，也應(yīng)該不時(shí)從日常的具體工作中走出來(lái)，在一個(gè)較高層次上進(jìn)行回顧總結(jié)和借鑒，并試著提出一些
優(yōu)化和改進(jìn)的措施，這無(wú)論對(duì)專業(yè)上還是對(duì)事業(yè)上的成長(zhǎng)都是非常有意義的。微軟在軟件測(cè)試方面有很多值得一提的經(jīng)驗(yàn)，在此我想以我個(gè)人的體會(huì)和思考，同大家
一同進(jìn)行一些探討。
這里有一點(diǎn)須要特別說(shuō)明，盡管微軟的方法已被微軟的實(shí)踐多次證明是成功的，非常有效的，但這并不意味著這些方法在中國(guó)的軟件企業(yè)中有廣泛的可行性。
一種方法是否可行還受到很多其他因素的影響，比如企業(yè)類型（微軟是生產(chǎn)平臺(tái)軟件和通用軟件產(chǎn)品的企業(yè)），企業(yè)管理體制，企業(yè)文化等等。所以我的目的只是給
大家一些思路和借鑒。
兩類經(jīng)典的軟件測(cè)試方法
在具體介紹微軟的軟件測(cè)試方法之前，我想首先從概念，或理念的層面上來(lái)理解究竟甚么是軟件測(cè)試，目的是從中導(dǎo)出微軟測(cè)試方法的理論根源。
傳統(tǒng)上認(rèn)為軟件測(cè)試的方法從總體上分為兩類。
第一類測(cè)試方法是試圖驗(yàn)證軟件是“工作的”，所謂“工作的”就是指軟件的功能是按照預(yù)先的設(shè)計(jì)執(zhí)行的；而第二類測(cè)試方法則是設(shè)法證明軟件是“不工作的”。
提出第一類方法的代表人物是軟件測(cè)試領(lǐng)域的先驅(qū)Dr. Bill Hetzel（代表論著《The Complete Guide to
Software
Testing》），他曾于1972年6月在美國(guó)的北卡羅來(lái)納大學(xué)組織了歷史上第一次正式的關(guān)于軟件測(cè)試的論壇。他首先在1973年給軟件測(cè)試一個(gè)這樣的
定義：“就是建立一種信心，認(rèn)為程序能夠按預(yù)期的設(shè)想運(yùn)行。Establish confidence that a program does
what it is supposed to do.
”后來(lái)在1983年他又將定義修訂為：“評(píng)價(jià)一個(gè)程序和系統(tǒng)的特性或能力，并確定它是否達(dá)到預(yù)期的結(jié)果。軟件測(cè)試就是以此為目的的任何行為。 Any
activities aimed at evaluating an attribute or capability of a program
or system. ”在他的定義中的“設(shè)想”和“預(yù)期的結(jié)果”其實(shí)就是我們現(xiàn)在所說(shuō)的用戶需求或功能設(shè)計(jì)。他還把軟件的質(zhì)量定義為“符合要求”。
第一類測(cè)試可以簡(jiǎn)單抽象地描述為這樣的過(guò)程：在設(shè)計(jì)規(guī)定的環(huán)境下運(yùn)行軟件的功能，將其結(jié)果與用戶需求或設(shè)計(jì)結(jié)果相比較，如果相符則測(cè)試通過(guò)，如果不相符則視為Bug。這一過(guò)程的終極目標(biāo)是將軟件的所有功能在所有設(shè)計(jì)規(guī)定的環(huán)境全部運(yùn)行，并通過(guò)。
在軟件行業(yè)中一般把第一類方法奉為主流和行業(yè)標(biāo)準(zhǔn)。1990年的IEEE/ANSI標(biāo)準(zhǔn)將軟件測(cè)試進(jìn)行了這樣的定義：“就是在既定的狀況條件下，運(yùn)
行一個(gè)系統(tǒng)或組建，觀察記錄結(jié)果，并對(duì)其某些方面進(jìn)行評(píng)價(jià)的過(guò)程。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]”這里所謂“既定的狀況”也可理解為需求或設(shè)計(jì)。
盡管如此，這一方法還是受到很多業(yè)界權(quán)威的質(zhì)疑和挑戰(zhàn)。代表人物是Glenford J. Myers（代表論著《The Art of
Software
Testing》）。他認(rèn)為測(cè)試不應(yīng)該著眼于驗(yàn)證軟件是工作的，相反應(yīng)該首先認(rèn)定軟件是有錯(cuò)誤的，然后去發(fā)現(xiàn)盡可能多的錯(cuò)誤。他還從人的心理學(xué)的角度論
證，將
“驗(yàn)證軟件是工作的”作為測(cè)試的目的，非常不利于測(cè)試人員發(fā)現(xiàn)軟件的錯(cuò)誤。于是他于1979年提出了他對(duì)軟件測(cè)試的定義：“就是以發(fā)現(xiàn)錯(cuò)誤為目的而運(yùn)行程
序的過(guò)程。The process of executing a program or system with the intent of
finding errors.”
這就是軟件測(cè)試的第二類方法，簡(jiǎn)單地說(shuō)就是驗(yàn)證軟件是“不工作的”，或者說(shuō)是有錯(cuò)誤的。他甚至極端地認(rèn)為，一個(gè)成功的測(cè)試必須是發(fā)現(xiàn)Bug的測(cè)試，
不然就沒(méi)有價(jià)值。這就如同一個(gè)病人（假定此人確有病），到醫(yī)院做一項(xiàng)醫(yī)療檢查，結(jié)果各項(xiàng)指標(biāo)都正常，那說(shuō)明該項(xiàng)醫(yī)療檢查對(duì)于診斷該病人的病情是沒(méi)有價(jià)值
的，是失敗的。
我并不完全同意這一看法。第二類軟件測(cè)試方法在業(yè)界也很流行，受到很多學(xué)術(shù)界專家的支持。大家熟悉的Ron Patton在《軟件測(cè)試》（
中文版由機(jī)械工業(yè)出版社出版，具說(shuō)此書是目前國(guó)內(nèi)測(cè)試新手入門的經(jīng)典教材）一書的第10頁(yè)，有一個(gè)明確而簡(jiǎn)潔的定義：“軟件測(cè)試員的目標(biāo)是找到軟件缺陷，
盡可能早一些，并確保其得以修復(fù)。”有些軟件企業(yè)以Bug數(shù)量來(lái)作為考核測(cè)試人員業(yè)績(jī)的一項(xiàng)指標(biāo)，其實(shí)就是接受了這樣的方法。
兩類方法的優(yōu)劣對(duì)比
雖然軟件測(cè)試總的目的是為了軟件產(chǎn)品的質(zhì)量，但很明顯這兩類測(cè)試方法在具體目標(biāo)、或指導(dǎo)思想上截然相反。由此也決定了它們?cè)谒悸贰⑦^(guò)程和測(cè)重點(diǎn)上有很大的差別，并各有利弊的。
第一類測(cè)試方法以需求和設(shè)計(jì)為本，因此有利于界定測(cè)試工作的范疇，更便于部署測(cè)試的側(cè)重點(diǎn)，加強(qiáng)針對(duì)性。這一點(diǎn)對(duì)于大型軟件的測(cè)試，尤其是在有限的
時(shí)間和人力資源情況下顯得格外重要。而第二類測(cè)試方法與需求和設(shè)計(jì)沒(méi)有必然的關(guān)聯(lián)，如果計(jì)劃管理不當(dāng)，測(cè)試活動(dòng)很容易丟失重點(diǎn)，走入歧途。
第一類測(cè)試方法可以與軟件的架構(gòu)和軟件開(kāi)發(fā)的計(jì)劃相配合，使軟件測(cè)試活動(dòng)逐層次的展開(kāi)，從而使軟件的功能和質(zhì)量有計(jì)劃地逐步完善和提高（關(guān)于測(cè)試的層次問(wèn)題，我會(huì)在今后的討論中專門介紹）。第二類測(cè)試方法不具備這種過(guò)程的漸進(jìn)性。
第一類測(cè)試方法的缺點(diǎn)是缺乏靈活性，不利于測(cè)試人員主觀能動(dòng)性的發(fā)揮，正像Myers先生所說(shuō)，不容易找到軟件的錯(cuò)誤（Bug）。而這方面正是第二類測(cè)試方法的長(zhǎng)處。
微軟的策略
正是因?yàn)檎J(rèn)識(shí)到兩類測(cè)試方法各有利弊，微軟在軟件測(cè)試活動(dòng)中將兩類方法結(jié)合起來(lái)，以第一類測(cè)試方法為基礎(chǔ)和主要線索，階段性地運(yùn)用第二類測(cè)試方法。
微軟的第一類測(cè)試
微軟的第一類測(cè)試總體上說(shuō)分為三個(gè)步驟進(jìn)行：審核需求和設(shè)計(jì)—〉設(shè)計(jì)測(cè)試—〉實(shí)施運(yùn)行測(cè)試。
前文已述，第一類測(cè)試是以需求和設(shè)計(jì)為本來(lái)驗(yàn)證軟件的正確性。大家很自然的想到，需求和設(shè)計(jì)本身也有正確性的問(wèn)題。依據(jù)不正確的需求和設(shè)計(jì)不可能開(kāi)發(fā)出正確的軟件產(chǎn)品，測(cè)試也將是徒勞的。因此驗(yàn)證需求和設(shè)計(jì)是微軟進(jìn)行第一類測(cè)試的第一步。
有必要指出的是，這里所說(shuō)的需求和設(shè)計(jì)具體說(shuō)來(lái)它一般包括：
由項(xiàng)目經(jīng)理根據(jù)用戶要求（信息來(lái)源于市場(chǎng)部門，用戶支持部門等等）而編寫的需求文本（Requirement Specification）；
由項(xiàng)目經(jīng)理根據(jù)需求文本而編寫的功能設(shè)計(jì)文本（Functional Design Specification）；
由開(kāi)發(fā)人員根據(jù)功能文本而編寫的實(shí)施設(shè)計(jì)文本（Implementation Design Specification）。
微軟的測(cè)試人員要參與所有這些文本的審核。作為測(cè)試人員，審核重點(diǎn)是檢查文本對(duì)用戶需求定義的完整性、嚴(yán)密性和功能設(shè)計(jì)的可測(cè)性。同時(shí)這種審核對(duì)于測(cè)試人員也是一種熱身活動(dòng)，使他們盡早地進(jìn)入技術(shù)和業(yè)務(wù)狀態(tài)。
第二步，測(cè)試人員要根據(jù)已審核通過(guò)的需求和設(shè)計(jì)編制測(cè)試計(jì)劃，設(shè)計(jì)測(cè)試用例。在前面提到的三種文本中，功能設(shè)計(jì)文本是主要依據(jù)。原因很簡(jiǎn)單，這類測(cè)試關(guān)心的是軟件是否能正確地實(shí)現(xiàn)功能，而不是這些功能如何被具體實(shí)施的。
從這里大家可以看出這是典型的“黑盒測(cè)試”。確實(shí)微軟的測(cè)試主要是從用戶角度進(jìn)行的黑盒測(cè)試。
這一步的完成就意味著“測(cè)試計(jì)劃”和“測(cè)試用例設(shè)計(jì)”兩個(gè)文本的完成。“測(cè)試計(jì)劃”
文本主要闡述測(cè)試的范疇、領(lǐng)域、方法、工具、資源和計(jì)劃時(shí)間表等等。“測(cè)試用例設(shè)計(jì)”文本要列出測(cè)試用例、每個(gè)用例的設(shè)置、執(zhí)行步驟和預(yù)期結(jié)果。測(cè)試的這
兩個(gè)文本也要被項(xiàng)目經(jīng)理和開(kāi)發(fā)人員審核。這樣經(jīng)過(guò)各種相互的審核，大家對(duì)項(xiàng)目形成了基本的共識(shí)。
第三步的實(shí)施運(yùn)行測(cè)試是整個(gè)開(kāi)發(fā)過(guò)程中最長(zhǎng)最復(fù)雜的一個(gè)階段。從總體上說(shuō)就是將上一步設(shè)計(jì)的測(cè)試用例按計(jì)劃付諸實(shí)施的過(guò)程。這包括編寫自動(dòng)化測(cè)試程
序、反復(fù)運(yùn)行自動(dòng)化測(cè)試程序，也包括階段性執(zhí)行手動(dòng)測(cè)試用例。這一階段的測(cè)試必須在周密的計(jì)劃下進(jìn)行，在前面我已提到，這正是第一類測(cè)試的特點(diǎn)和長(zhǎng)處。
這種計(jì)劃性首先體現(xiàn)在開(kāi)發(fā)和測(cè)試的相互協(xié)調(diào)配合，根據(jù)產(chǎn)品的架構(gòu)和功能模塊的依賴關(guān)系，按照項(xiàng)目的總體計(jì)劃共同推進(jìn)。從測(cè)試的過(guò)程來(lái)看，總是先運(yùn)行
或執(zhí)行簡(jiǎn)單用例，然后再?gòu)?fù)雜用例；先驗(yàn)證單一的基本功能，再綜合的端到端的功能；先發(fā)現(xiàn)解決表面的，影響面大的Bug，再深層的，不容易重現(xiàn)的Bug。因
此隨著項(xiàng)目開(kāi)發(fā)和測(cè)試的進(jìn)程，產(chǎn)品的功能不斷完善，質(zhì)量不斷提高。
這里有一點(diǎn)要特別指出，有很多測(cè)試用例是要反復(fù)運(yùn)行的，特別是基本的自動(dòng)化測(cè)試每一天，每一個(gè)Build上都要運(yùn)行。盡管這些測(cè)試大多數(shù)情況下都是通過(guò)的，很少再發(fā)現(xiàn)新的Bug，但其價(jià)值是顯而易見(jiàn)的，就是為了防止質(zhì)量回歸。
可見(jiàn)Myers的理論在這里是不適用的。這一階段測(cè)試人員還有一項(xiàng)繁瑣但卻很重要的工作，就是對(duì)已有的測(cè)試用例的維護(hù)。比如通常以下兩種情況下要新
增一些測(cè)試用例，一是對(duì)于當(dāng)初測(cè)試設(shè)計(jì)不周全的領(lǐng)域，二是對(duì)于外部的Bug（比如從Beta客戶報(bào)告來(lái)的），沒(méi)有被現(xiàn)有測(cè)試用例所覆蓋。當(dāng)產(chǎn)品的功能設(shè)計(jì)
出現(xiàn)更改時(shí)（在微軟這是常事），所涉及的測(cè)試用例當(dāng)然也要相應(yīng)地修改。
微軟的第二類測(cè)試
微軟的第二類測(cè)試是階段性的，常常根據(jù)需要而帶有隨機(jī)性和突擊性。對(duì)于這類測(cè)試，在微軟有一個(gè)專門的名稱：“Bug Bash（Bug大掃除）”。
Bug Bash通常發(fā)生在項(xiàng)目開(kāi)發(fā)各階段（微軟叫里程碑）的末期，比如Beta版發(fā)布前，劃出一個(gè)專門的時(shí)間段（通常1-3天），在這期間所有參與項(xiàng)目的人員，集中全部精力，運(yùn)用各方面的知識(shí)，盡全部智慧來(lái)搜尋項(xiàng)目的Bug。
這是一個(gè)非常有意思的活動(dòng)，但要組織好這樣的活動(dòng)并非易事。一般有以下要點(diǎn)：
盡管這是一個(gè)測(cè)試活動(dòng)，但參與者并不僅限于測(cè)試人員。項(xiàng)目經(jīng)理，開(kāi)發(fā)人員甚至于高層管理人員都應(yīng)參加，如同全民動(dòng)員。目的是要集思廣益；
要鼓勵(lì)各部門，領(lǐng)域交叉搜索，因?yàn)樾碌乃悸泛鸵暯峭ǔＳ兄诎l(fā)現(xiàn)更多的Bug；
為調(diào)動(dòng)積極性，增強(qiáng)趣味性，可以適當(dāng)引入競(jìng)爭(zhēng)機(jī)制，比如當(dāng)活動(dòng)結(jié)束時(shí)，評(píng)出發(fā)現(xiàn)Bug最多，發(fā)現(xiàn)最嚴(yán)重Bug的個(gè)人，給以物質(zhì)和精神獎(jiǎng)勵(lì)。
可以分專題展開(kāi)，比如安全性、用戶界面可用性、國(guó)際化和本地化等等。
微軟的第二類測(cè)試除了Bug Bash外，經(jīng)常還有一些專業(yè)性的測(cè)試，最典型的是針對(duì)安全性攻擊測(cè)試。一般會(huì)邀請(qǐng)公司內(nèi)部，或業(yè)界的專家來(lái)搜尋產(chǎn)品的安全漏洞。
以上我從傳統(tǒng)軟件測(cè)試概念的角度，介紹了微軟的策略和兩類傳統(tǒng)測(cè)試方法的具體做法，及其側(cè)重點(diǎn)。這其實(shí)僅僅是一個(gè)基礎(chǔ)，一個(gè)很原始的基礎(chǔ)。多特有的
做法，和概念上軟件測(cè)試在微軟軟件產(chǎn)品開(kāi)發(fā)中的作用、地位遠(yuǎn)不是這些原始的方法所能達(dá)到的，也不是傳統(tǒng)軟件測(cè)試概念所函蓋的。微軟在軟件測(cè)試方面有很的突
破，比如“軟件測(cè)試的信息服務(wù)功能”、“以用戶為中心的宏觀質(zhì)量體系”、“分級(jí)測(cè)試”、“項(xiàng)目的質(zhì)量管理系統(tǒng)”、“Bug三方會(huì)審”、“測(cè)試自動(dòng)化”和“
軟件測(cè)試的軟硬件—部門、團(tuán)隊(duì)、人和基礎(chǔ)設(shè)施”等等。這些我會(huì)在以后的討論中分專題進(jìn)行介紹。
_______________________
我在前一篇“微軟的軟件測(cè)試方法”中介紹了微軟的兩類基本測(cè)試方法，其基本思想大家應(yīng)該是比較熟悉的，因?yàn)樗鼈冞€只是傳統(tǒng)的軟件測(cè)試方法的綜合。所
以單從形式上，它并沒(méi)有體現(xiàn)出對(duì)傳統(tǒng)框架的突破。但是從另一個(gè)層面來(lái)考察微軟軟件測(cè)試時(shí)，你會(huì)對(duì)一些基本的事實(shí)感到驚訝。比如，“微軟的測(cè)試人員和開(kāi)發(fā)人
員數(shù)量大致相等或略多”，“微軟的產(chǎn)品成本中測(cè)試大約占40%以上”等等。人們會(huì)有疑問(wèn)，僅僅是作為功能驗(yàn)證和搜尋Bug的測(cè)試能消耗這么大量的資源嗎？
有必要付出如此大的代價(jià)嗎？
應(yīng)該有理由相信，微軟作為一個(gè)軟件企業(yè)，其每一份投入都是有意義的，因此也可斷定微軟在軟件測(cè)試方面的努力一定超出傳統(tǒng)測(cè)試方法的范疇。
歷史回顧
為了更好的理解微軟件測(cè)試在方法和理念上的突破，我想首先回顧一下軟件開(kāi)發(fā)和軟件測(cè)試的發(fā)展歷史，并從中揭示其必然性。
Edward Kit 在他的暢銷書“Software Testing In The Real World : Improving The
Process（1995， ISBN: 0201877562）”中將整個(gè)軟件開(kāi)發(fā)歷史分為三個(gè)階段：
第一個(gè)階段是60年代及其以前，那時(shí)軟件規(guī)模都很小、復(fù)雜程度低，軟件開(kāi)發(fā)的過(guò)程隨意。開(kāi)發(fā)人員的Debug過(guò)程被認(rèn)為是唯一的測(cè)試活動(dòng)。其實(shí)這并不是現(xiàn)代意義上的軟件測(cè)試，當(dāng)然一階段也還沒(méi)有專門測(cè)試人員的出現(xiàn)。
第二個(gè)階段是70年代，這個(gè)階段開(kāi)發(fā)的軟件仍然不復(fù)雜，但人們已開(kāi)始思考開(kāi)發(fā)流程問(wèn)題，并提出“軟件工程Software
Engineering”的概念。但是這一階段人們對(duì)軟件測(cè)試的理解僅限于基本的功能驗(yàn)證和Bug搜尋，而且測(cè)試活動(dòng)僅出現(xiàn)在整個(gè)軟件開(kāi)發(fā)流程的后期，雖
然測(cè)試由專門的測(cè)試人員來(lái)承擔(dān)，但測(cè)試人員都是行業(yè)和軟件專業(yè)的入門新手。
第三個(gè)階段是80年代及其以后，軟件和IT行業(yè)進(jìn)入了大發(fā)展。軟件趨向大型化。與之相應(yīng)，人們?yōu)檐浖_(kāi)發(fā)設(shè)計(jì)了各種復(fù)雜而精密的流程和管理方法（比
如CMM和MSF），并將“質(zhì)量”的概念融入其中。軟件測(cè)試已有了行業(yè)標(biāo)準(zhǔn)（IEEE/ANSI
），它再也不是一個(gè)一次性的，而且只是開(kāi)發(fā)后期的活動(dòng)，而是與整個(gè)開(kāi)發(fā)流程融合成一體。軟件測(cè)試已成為一個(gè)專業(yè)，需要運(yùn)用專門的方法和手段，需要專門人才
和專家來(lái)承擔(dān)。
測(cè)試與開(kāi)發(fā)的融合
在這一歷史發(fā)展過(guò)程中，最值得注意的是測(cè)試與開(kāi)發(fā)流程融合的趨勢(shì)。人們對(duì)這種融合也許并不陌生。比如測(cè)試活動(dòng)的早期展
開(kāi)，讓測(cè)試人員參與用戶需求的驗(yàn)證，參加功能設(shè)計(jì)和實(shí)施設(shè)計(jì)的審核。再比如測(cè)試人員與開(kāi)發(fā)人員的密切合作，隨著開(kāi)發(fā)進(jìn)展而逐步實(shí)施單元測(cè)試、模塊功能測(cè)試
和系統(tǒng)整合測(cè)試。
的確這些都是測(cè)試與開(kāi)發(fā)融合的表現(xiàn)形式，而且初期的融合也只反映在這個(gè)層次上。90年代以后，軟件的規(guī)模和復(fù)雜程度迅速提高，這種形式上的融合也迅速走向更深層次，更具實(shí)際意義。
具體地說(shuō)這種融合就是整個(gè)軟件開(kāi)發(fā)活動(dòng)對(duì)測(cè)試的依賴性。傳統(tǒng)上認(rèn)為，只有軟件的質(zhì)量控制依賴于測(cè)試，但是現(xiàn)代軟件開(kāi)發(fā)的實(shí)踐證明，不僅軟件的質(zhì)量控制依賴于測(cè)試，開(kāi)發(fā)本身離開(kāi)測(cè)試也將無(wú)法推進(jìn)，項(xiàng)目管理離開(kāi)了測(cè)試也從根本上失去了依據(jù)。
在微軟，測(cè)試的確有這樣的地位和作用。這就是為什么微軟在軟件測(cè)試上有如此大的投入。
開(kāi)發(fā)對(duì)測(cè)試的依賴
現(xiàn)代軟件開(kāi)發(fā)，特別是大型軟件開(kāi)發(fā)通常會(huì)遇到以下兩個(gè)問(wèn)題：
在開(kāi)發(fā)初期，如何能夠展開(kāi)大規(guī)模團(tuán)隊(duì)，群體齊頭并進(jìn)，而同時(shí)保持開(kāi)發(fā)的有序性。從而有效利用資源，縮短開(kāi)發(fā)周期。
在開(kāi)發(fā)后期，如何解決深層次的Bug，如何面對(duì)設(shè)計(jì)更改，而能夠保證產(chǎn)品的質(zhì)量不出現(xiàn)或少出現(xiàn)回落。
對(duì)于小型簡(jiǎn)單的軟件，這兩個(gè)問(wèn)題也存在，但不突出，而且容易解決。但對(duì)于復(fù)雜的大型軟件的開(kāi)發(fā)，這兩個(gè)問(wèn)題常常會(huì)成為難以逾越的障礙。
通常大型項(xiàng)目的功能豐富，但架構(gòu)、層次也會(huì)相當(dāng)復(fù)雜。穩(wěn)妥的開(kāi)發(fā)方式是，一次投入少量的人員，逐層開(kāi)發(fā)，逐層穩(wěn)定。但這種方式顯然資源利用率低，開(kāi)發(fā)周期長(zhǎng)，不能滿足現(xiàn)代軟件和IT行業(yè)高速發(fā)展、瞬息萬(wàn)變的需要。因此大型項(xiàng)目需要大型團(tuán)隊(duì)。
在微軟，產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)（主要包括開(kāi)發(fā)、測(cè)試和項(xiàng)目管理）一般都有百人以上規(guī)模，有些產(chǎn)品甚至上幾千人（Windows2000的開(kāi)發(fā)部門曾有
3000多人）。這樣大規(guī)模的人力資源作用在一個(gè)動(dòng)態(tài)的，內(nèi)部相互聯(lián)系的系統(tǒng)中，若沒(méi)有有效的協(xié)同，其混亂是不可避免的。試想，有兩個(gè)開(kāi)發(fā)人員，分別在開(kāi)
發(fā)兩個(gè)不同的功能模塊，其相互有依賴關(guān)系。為了相互協(xié)調(diào)，他們可以隨時(shí)進(jìn)行當(dāng)面討論。如果這種關(guān)系發(fā)生在五個(gè)開(kāi)發(fā)人員和五個(gè)功能模塊之間，這種協(xié)調(diào)就只能
通過(guò)定期的會(huì)議來(lái)進(jìn)行。而一個(gè)大型項(xiàng)目，會(huì)有許許多多這樣的關(guān)系，而且很多時(shí)候這種關(guān)系有著不確定性和不可預(yù)見(jiàn)性。當(dāng)一個(gè)開(kāi)發(fā)人員編寫一段新的代碼或?qū)σ?
有代碼進(jìn)行改動(dòng)和調(diào)整時(shí)，他（或她）常常無(wú)法確定，或無(wú)法完全確定究竟有哪些相關(guān)的模塊會(huì)受到影響，以及在什么請(qǐng)況下這種影響會(huì)帶來(lái)什么結(jié)果。因?yàn)橄到y(tǒng)的
復(fù)雜性已遠(yuǎn)遠(yuǎn)超出了人的邏輯思維、技能和經(jīng)驗(yàn)所能力及的范疇。因此這種傳統(tǒng)的協(xié)調(diào)手段是遠(yuǎn)不能滿足需要的。
在微軟，這種協(xié)調(diào)是通過(guò)測(cè)試來(lái)實(shí)現(xiàn)的。具體來(lái)說(shuō)就是：每日建造+自動(dòng)化測(cè)試。
關(guān)于每日編譯和自動(dòng)化測(cè)試，我將來(lái)會(huì)作專門介紹，這里簡(jiǎn)單的說(shuō)就是每天都建造一個(gè)新版本，每個(gè)版本都要運(yùn)行通過(guò)一定量的自動(dòng)測(cè)試用例，以檢驗(yàn)當(dāng)天工作的質(zhì)量。這里所說(shuō)的質(zhì)量當(dāng)然有一般意義上質(zhì)量的概念，但同時(shí)它也反映項(xiàng)目在開(kāi)發(fā)過(guò)程中的整體協(xié)調(diào)性。
自動(dòng)測(cè)試的最大優(yōu)點(diǎn)在于它的高度可重復(fù)性。一個(gè)理想的自動(dòng)測(cè)試系統(tǒng)能夠讓人隨時(shí)、方便和迅速的運(yùn)行大量的測(cè)試用例。因此一個(gè)開(kāi)發(fā)人員可以通過(guò)檢查當(dāng)
天的自動(dòng)測(cè)試結(jié)果來(lái)分析前一天代碼的質(zhì)量（事后檢查），也可以在當(dāng)天存入代碼前，先運(yùn)行自動(dòng)測(cè)試以進(jìn)一步確保存入代碼的質(zhì)量（事前檢查）。
在微軟，每日建造都是在午夜開(kāi)始，完成后緊接著就是全面的自動(dòng)測(cè)試，到早晨上班時(shí)間之前就會(huì)把結(jié)果自動(dòng)通過(guò)e-mail等方式發(fā)送出來(lái)。開(kāi)發(fā)人員上
班后的第一件事往往就是檢查測(cè)試結(jié)果。如果沒(méi)有問(wèn)題就會(huì)開(kāi)始新的工作。如果有測(cè)試有用例沒(méi)有通過(guò)，開(kāi)發(fā)人員則必須協(xié)同測(cè)試人員一起立刻找出原因，解決后才
能開(kāi)始新的代碼。
有時(shí)一個(gè)小的失誤會(huì)引起大面積的測(cè)試用例失敗，很大一部分開(kāi)發(fā)團(tuán)隊(duì)會(huì)受到影響。為盡量避免這種情況，要求開(kāi)發(fā)人員在存入代碼之前先在自己的個(gè)人建造
版本上運(yùn)行一定量的自動(dòng)測(cè)試，全部通過(guò)后在存入。如開(kāi)發(fā)人員沒(méi)有按照這樣的要求，而擅自存入質(zhì)量不高的代碼而造成大量測(cè)試失敗，這種不負(fù)責(zé)任的行為是要受
到嚴(yán)厲批評(píng)的。
從這一過(guò)程可以看出，開(kāi)發(fā)人員依賴測(cè)試來(lái)保證開(kāi)發(fā)工作的質(zhì)量，使開(kāi)發(fā)整體地協(xié)調(diào)地向前推進(jìn)。
當(dāng)開(kāi)發(fā)進(jìn)入后期階段，盡管項(xiàng)目已總體成型，開(kāi)發(fā)人員也會(huì)不時(shí)遇到一些技術(shù)上的挑戰(zhàn)。比如一些Bug的解決涉及對(duì)項(xiàng)目深層次結(jié)構(gòu)的調(diào)整；再比如由于客
戶反饋的意見(jiàn)造成設(shè)計(jì)的修改。每一次這樣的修改和調(diào)整事實(shí)上都是對(duì)一個(gè)穩(wěn)定系統(tǒng)的破壞，如果處理不當(dāng)往往一個(gè)Bug的修改會(huì)生成很多新的Bug，就像一系
列聯(lián)鎖的惡性循環(huán)。很多項(xiàng)目工期的延誤都是這樣造成的。
要避免或至少將這種破壞減少到最低限度，開(kāi)發(fā)人員首先需要知道這種破壞的影響面。在這里單靠開(kāi)發(fā)人員自身的邏輯思維、技能和經(jīng)驗(yàn)是遠(yuǎn)遠(yuǎn)不夠的，自動(dòng)
測(cè)試再一次成為一種有效的工具。往往開(kāi)發(fā)人員會(huì)制定不止一個(gè)方案，對(duì)每個(gè)方案上都運(yùn)行一遍同樣一套自動(dòng)測(cè)試用例，然后比較結(jié)果，選出最佳方案。
自動(dòng)測(cè)試在這方面所起的作用不僅在產(chǎn)品的開(kāi)發(fā)過(guò)程中，它還延續(xù)到產(chǎn)品發(fā)布后。產(chǎn)品支持部門在為客戶提供應(yīng)急解決方案時(shí)也要依賴自動(dòng)測(cè)試。
管理對(duì)測(cè)試的依賴
在微軟，軟件項(xiàng)目管理的主要線索就是Bug的管理，其中最直接具體的管理活動(dòng)就是“Bug三方討論會(huì)（Bug
Triage）”。會(huì)議一般由項(xiàng)目管理Program
Manager（簡(jiǎn)稱PM）來(lái)主持，有開(kāi)發(fā)人員和測(cè)試人員參加（所以叫三方會(huì)議）。會(huì)上對(duì)每個(gè)新生成的Bug進(jìn)行討論，并決定
是否接受這個(gè)Bug；
Bug的嚴(yán)重級(jí)別和優(yōu)先級(jí)別；
Bug由誰(shuí)來(lái)負(fù)責(zé)，是由測(cè)試提供進(jìn)一步詳細(xì)信息，還是交由開(kāi)發(fā)人員解決，以及大致的解決方案等等。
會(huì)議還要對(duì)老的Bug檢查解決進(jìn)度。這種討論會(huì)常常會(huì)發(fā)生爭(zhēng)論，要求測(cè)試人員具有足夠的技術(shù)基礎(chǔ)和用戶經(jīng)驗(yàn)，來(lái)捍衛(wèi)產(chǎn)品的質(zhì)量。
可以說(shuō)項(xiàng)目開(kāi)發(fā)到了某一階段后就是由這種Bug的管理所驅(qū)動(dòng)的。這其中的原動(dòng)力來(lái)自測(cè)試。
項(xiàng)目管理中一項(xiàng)非常重要但也十分困難的工作是衡量項(xiàng)目的進(jìn)度，包括判斷項(xiàng)目的狀態(tài)，確定項(xiàng)目是否能預(yù)期完成。這方面，測(cè)試提供了兩個(gè)非常重要的參數(shù)，一個(gè)是Bug數(shù)量的趨勢(shì)，另一個(gè)是測(cè)試結(jié)果的趨勢(shì)。
Bug趨勢(shì)就是將每天新生成的Bug數(shù)和每天被解決的Bug數(shù)標(biāo)成一個(gè)趨勢(shì)圖表。一般在項(xiàng)目的開(kāi)始階段新生Bug數(shù)曲線會(huì)呈上升趨勢(shì)，到項(xiàng)目中后期
被解決Bug數(shù)曲線會(huì)趨于上升，而新生Bug數(shù)曲線應(yīng)下降，到項(xiàng)目最后，兩條曲線都趨向于零。PM會(huì)持續(xù)觀察這張圖表，確保項(xiàng)目健康發(fā)展，同時(shí)通過(guò)分析預(yù)
測(cè)項(xiàng)目Bug趨于零的時(shí)間。
在一定的歷史經(jīng)驗(yàn)的基礎(chǔ)上分析使用這一圖表會(huì)得到很多有價(jià)值的信息，比如說(shuō)，可分析開(kāi)發(fā)和測(cè)試在人力資源的配比上是否恰當(dāng)，可以分析出某個(gè)嚴(yán)重的Bug所造成的項(xiàng)目質(zhì)量的波動(dòng)。
每天的自動(dòng)測(cè)試結(jié)果同樣可以形成類似的圖表。它同樣非常有助于了解當(dāng)前項(xiàng)目的質(zhì)量狀況，開(kāi)發(fā)測(cè)試進(jìn)度。
由測(cè)試產(chǎn)生的這些數(shù)據(jù)不僅在項(xiàng)目開(kāi)發(fā)過(guò)程中為項(xiàng)目管理提供有效的依據(jù)，而且也是產(chǎn)品通過(guò)發(fā)布的必要條件。在微軟，每個(gè)產(chǎn)品都要經(jīng)過(guò)評(píng)審才能通過(guò)發(fā)
布。前面介紹的幾個(gè)圖表是發(fā)布評(píng)審的重要內(nèi)容，如果從圖表中發(fā)現(xiàn)臨評(píng)審前還出現(xiàn)過(guò)較大的質(zhì)量波動(dòng)，評(píng)審人員一定會(huì)對(duì)此提出質(zhì)疑。
因此軟件項(xiàng)目管理依賴軟件測(cè)試提供其基本的管理素材。
可以說(shuō)，現(xiàn)代大型軟件開(kāi)發(fā)過(guò)程中開(kāi)發(fā)和管理對(duì)測(cè)試的依賴性是測(cè)試與開(kāi)發(fā)流程融合的一個(gè)根本因素。從另一個(gè)角度看，測(cè)試與開(kāi)發(fā)流程融合決不僅僅是簡(jiǎn)單
的時(shí)間上的同步，更不是雙方空間上的接近，而是這種內(nèi)在的依存關(guān)系的外在表現(xiàn)。開(kāi)發(fā)對(duì)測(cè)試的這種依賴性對(duì)測(cè)試和測(cè)是人員提出了更高的要求。在理念上，軟件
測(cè)試已遠(yuǎn)不僅僅只是軟件功能的驗(yàn)證和Bug的搜尋；在具體方法上，自動(dòng)測(cè)試和測(cè)試工具的使用已成為基本的要求。
在微軟，測(cè)試不僅使用一些通用的工具，每一個(gè)產(chǎn)品還有專門開(kāi)發(fā)的專用工具庫(kù)，測(cè)試的代碼量常常超過(guò)項(xiàng)目本身的代碼量。
一個(gè)軟件企業(yè)要提高其軟件開(kāi)發(fā)的能力，特別是針對(duì)大型軟件的大規(guī)模的快速開(kāi)發(fā)能力，在測(cè)試方面對(duì)傳統(tǒng)理念和方法進(jìn)行突破是必要的。微軟的實(shí)踐就是一個(gè)很好
的印證。