全程軟件測(cè)試之引子

在本書(shū)的開(kāi)頭，有必要先澄清對(duì)軟件測(cè)試的理解，包括軟件測(cè)試的核心價(jià)值和作用，以及軟件測(cè)試和軟件開(kāi)發(fā)的關(guān)系等，幫助讀者建立起軟件測(cè)試的正確理念，這樣對(duì)閱讀和理解以后各章的內(nèi)容會(huì)有很大幫助。

如何理解軟件測(cè)試和建立起軟件測(cè)試的正確理念呢？還是從軟件測(cè)試的基本概念出發(fā)，回答下列幾個(gè)問(wèn)題，逐步揭示軟件測(cè)試的內(nèi)涵，深入到軟件測(cè)試的核心價(jià)值觀。這個(gè)過(guò)程，通過(guò)回答下列一系列問(wèn)題來(lái)完成。

 究竟什么是軟件測(cè)試？

 究竟什么是敏捷測(cè)試？

 軟件測(cè)試的作用是什么？

 軟件測(cè)試在軟件開(kāi)發(fā)生命周期（SDLC）中處在什么樣的地位？

 傳統(tǒng)的軟件測(cè)試過(guò)程是怎樣的？

 敏捷測(cè)試的過(guò)程又有什么不同？

下面就開(kāi)始回答這些問(wèn)題。即使您不能完全理解也不要急，后面各章會(huì)慢慢幫助您理解這些內(nèi)容，掀開(kāi)軟件測(cè)試的神秘面紗。但有一點(diǎn)是明確的，當(dāng)您在看完這段“引子”后，會(huì)對(duì)軟件測(cè)試有一個(gè)整體的認(rèn)識(shí)、正確的理解，從而不至于陷入“盲人摸象”的困境，也不至于陷入困惑的境地。

0.1  究竟什么是軟件測(cè)試？

什么是軟件測(cè)試？人們常?；卮穑很浖y(cè)試就是發(fā)現(xiàn)軟件產(chǎn)品中的Bug（缺陷）。也有人說(shuō)，不對(duì)，軟件測(cè)試是驗(yàn)證軟件產(chǎn)品特性是否滿(mǎn)足用戶(hù)的需求。實(shí)際上，上述回答都沒(méi)錯(cuò)，是對(duì)軟件測(cè)試的正反兩個(gè)方面的解釋。

（1）軟件測(cè)試就是發(fā)現(xiàn)軟件產(chǎn)品中的Bug，強(qiáng)調(diào)測(cè)試人員以逆向思維方式，不斷思考開(kāi)發(fā)人員可能存在的誤區(qū)、不良的習(xí)慣、系統(tǒng)的邊界條件、異常輸入和操作、系統(tǒng)弱點(diǎn)和漏洞等，更快地發(fā)現(xiàn)軟件系統(tǒng)的問(wèn)題。畢竟開(kāi)發(fā)人員力求構(gòu)造軟件，以正向思維方式為主，所以測(cè)試人員從逆向思維出發(fā)，可以獲得更高的測(cè)試效率。

（2）軟件測(cè)試是驗(yàn)證軟件產(chǎn)品特性是否滿(mǎn)足用戶(hù)的需求，是以正向思維方式針對(duì)軟件系統(tǒng)的所有功能點(diǎn)，逐個(gè)驗(yàn)證其正確性，這是傳統(tǒng)工業(yè)的質(zhì)檢工作在軟件業(yè)的自然延伸。

但僅僅這樣理解軟件測(cè)試還不夠，需要更全面的理解軟件測(cè)試，就可以更好地做好工作，也可以適應(yīng)不同的軟件開(kāi)發(fā)過(guò)程所帶來(lái)的挑戰(zhàn)，包括敏捷方法帶給軟件測(cè)試的極大挑戰(zhàn)。

將近30年前，G.J.Myers在其經(jīng)典著作《軟件測(cè)試之藝術(shù)》（The Art of Software Testing）一書(shū)中，給出了測(cè)試的定義：“程序測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過(guò)程”。那時(shí)對(duì)軟件測(cè)試的認(rèn)識(shí)還非常具有局限性，這也是受軟件開(kāi)發(fā)瀑布模型的影響，認(rèn)為軟件測(cè)試是編程之后的一個(gè)階段。只有等待代碼開(kāi)發(fā)出來(lái)之后，通過(guò)執(zhí)行程序，像用戶(hù)那樣操作軟件發(fā)現(xiàn)問(wèn)題，這就是“動(dòng)態(tài)測(cè)試”。

如果在此時(shí)發(fā)現(xiàn)功能設(shè)計(jì)不合理或性能不好，就需要修改需求或修改設(shè)計(jì)，那就不得不返工到需求定義或系統(tǒng)設(shè)計(jì)階段，造成很大的代價(jià)。所以，有必要將軟件測(cè)試延伸到需求、設(shè)計(jì)階段，即對(duì)階段性成果——需求定義文檔、設(shè)計(jì)技術(shù)文檔進(jìn)行驗(yàn)證，從而將動(dòng)態(tài)測(cè)試延伸到靜態(tài)測(cè)試，盡早地發(fā)現(xiàn)問(wèn)題，把問(wèn)題消滅在萌芽之中，將每個(gè)階段產(chǎn)生的缺陷及時(shí)清除，極大地提高產(chǎn)品的質(zhì)量，有效地降低企業(yè)的成本。靜態(tài)測(cè)試就是在不運(yùn)行軟件系統(tǒng)時(shí)對(duì)軟件或階段性成果進(jìn)行評(píng)審，包括需求評(píng)審、設(shè)計(jì)評(píng)審、代碼掃描、代碼評(píng)審等。

軟件測(cè)試從“動(dòng)態(tài)測(cè)試”延伸到“靜態(tài)測(cè)試”，是從狹義的軟件測(cè)試發(fā)展到廣義的軟件測(cè)試，也使“軟件測(cè)試”不再停留在編程之后的某個(gè)階段上，而是貫穿整個(gè)軟件開(kāi)發(fā)生命周期（Software Development Life Cycle，SDLC）的質(zhì)量保證活動(dòng)。有了廣義軟件測(cè)試的概念，在敏捷開(kāi)發(fā)中，軟件測(cè)試就能被解釋為對(duì)軟件產(chǎn)品質(zhì)量的持續(xù)評(píng)估。在敏捷方法中，不僅提倡持續(xù)集成，而且提倡持續(xù)測(cè)試,持續(xù)集成實(shí)際上也是為了持續(xù)測(cè)試。

從國(guó)際標(biāo)準(zhǔn)對(duì)軟件測(cè)試的定義來(lái)看，軟件測(cè)試被看做是“驗(yàn)證（Verification）”和“有效性確認(rèn)（Validation）”這兩類(lèi)活動(dòng)構(gòu)成的整體，缺一不可。如果只做到其中一項(xiàng)，測(cè)試是不完整的。

（1）“驗(yàn)證”是檢驗(yàn)軟件是否已正確地實(shí)現(xiàn)了產(chǎn)品規(guī)格書(shū)所定義的系統(tǒng)功能和特性。驗(yàn)證過(guò)程提供證據(jù)表明軟件相關(guān)產(chǎn)品與所有生命周期活動(dòng)的要求相一致，即驗(yàn)證軟件實(shí)現(xiàn)（即交付給客戶(hù)的產(chǎn)品）是否達(dá)到了軟件需求定義和設(shè)計(jì)目標(biāo)。

（2）“有效性確認(rèn)”是確認(rèn)所開(kāi)發(fā)的軟件是否滿(mǎn)足用戶(hù)實(shí)際需求的活動(dòng)。因?yàn)檐浖枨蠖x和設(shè)計(jì)可能就不對(duì)，上述一致性不能保證軟件產(chǎn)品符合客戶(hù)的實(shí)際需求，而且客戶(hù)的需求也是在變化的，當(dāng)需求定義是半年前確定的，這種變化的可能性就比較大。

軟件不同于硬件，軟件一般都是應(yīng)用系統(tǒng)，常常和人們的娛樂(lè)、事務(wù)處理、商業(yè)活動(dòng)、社區(qū)交流等緊密聯(lián)系在一起，所以軟件具有很強(qiáng)的社會(huì)性，所以有測(cè)試專(zhuān)家把測(cè)試和社會(huì)性、人類(lèi)學(xué)等聯(lián)系起來(lái)，認(rèn)為軟件測(cè)試是跨學(xué)科的（interdisciplinary）活動(dòng)，以系統(tǒng)為焦點(diǎn)（systems-focused），通過(guò)不斷調(diào)查（investigative）和講故事（storytelling）方式完成軟件質(zhì)量的評(píng)估。通過(guò)其社會(huì)性，強(qiáng)調(diào)測(cè)試人員的思維能力和探索能力，強(qiáng)調(diào)測(cè)試的有效性和可靠性，在測(cè)試中要理解用戶(hù)的行為、人們活動(dòng)的背景和目的（上下文關(guān)系），不斷觀察，不斷學(xué)習(xí)，發(fā)現(xiàn)和質(zhì)量相關(guān)的信息（差異或質(zhì)疑），從客戶(hù)利益出發(fā)來(lái)守護(hù)產(chǎn)品的價(jià)值。

概括起來(lái)，究竟什么是軟件測(cè)試呢？可以這樣說(shuō)，軟件測(cè)試是貫穿整個(gè)軟件開(kāi)發(fā)生命周期、對(duì)軟件產(chǎn)品（包括階段性產(chǎn)品）進(jìn)行驗(yàn)證和確認(rèn)的活動(dòng)過(guò)程，也是對(duì)軟件產(chǎn)品質(zhì)量持續(xù)的評(píng)估過(guò)程，其目的是盡快盡早地發(fā)現(xiàn)在軟件產(chǎn)品（包括階段性產(chǎn)品）中所存在的各種問(wèn)題，盡最大可能地消除軟件開(kāi)發(fā)過(guò)程中所存在的產(chǎn)品質(zhì)量風(fēng)險(xiǎn)。

0.2  究竟什么是敏捷測(cè)試？

先從敏捷開(kāi)發(fā)這一方法論層次來(lái)討論什么是敏捷測(cè)試，即敏捷測(cè)試有什么具體特征，或有哪些主要實(shí)踐，然后再就目前非常熱的敏捷具體框架Scrum來(lái)討論Scrum中的敏捷測(cè)試（或稱(chēng)為Scrum Testing）。先研究如下敏捷宣言背后所蘊(yùn)含的12條原則^[43]。

（1）我們最重要的目標(biāo)，是通過(guò)持續(xù)不斷地及早交付有價(jià)值的軟件使客戶(hù)滿(mǎn)意。

（2）欣然面對(duì)需求變化，即使在開(kāi)發(fā)后期也一樣。為了客戶(hù)的競(jìng)爭(zhēng)優(yōu)勢(shì)，敏捷過(guò)程掌控變化。

（3）經(jīng)常地交付可工作的軟件，相隔幾星期或一兩個(gè)月，傾向于采取較短的周期。

（4）業(yè)務(wù)人員和開(kāi)發(fā)人員必須相互合作，項(xiàng)目中的每一天都不例外。

（5）激發(fā)個(gè)體的斗志，以他們?yōu)楹诵拇罱?xiàng)目。提供所需的環(huán)境和支援，輔以信任，從而達(dá)成目標(biāo)。

（6）不論團(tuán)隊(duì)內(nèi)外，傳遞信息效果最好、效率也最高的方式是面對(duì)面的交談。

（7）可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)。

（8）敏捷過(guò)程倡導(dǎo)可持續(xù)開(kāi)發(fā)。責(zé)任人、開(kāi)發(fā)人員和用戶(hù)要能夠共同維持其步調(diào)穩(wěn)定延續(xù)。

（9）堅(jiān)持不懈地追求技術(shù)卓越和良好設(shè)計(jì)，敏捷能力由此增強(qiáng)。

（10）以簡(jiǎn)潔為本，它是極力減少不必要工作量的藝術(shù)。

（11）最好的架構(gòu)、需求和設(shè)計(jì)出自自組織團(tuán)隊(duì)。

（12）團(tuán)隊(duì)定期地反思如何能提高成效，并依此調(diào)整自身的舉止表現(xiàn)。

這12條原則中沒(méi)有一條直接談到測(cè)試，那是否說(shuō)明沒(méi)有敏捷測(cè)試呢？有開(kāi)發(fā)就有測(cè)試，只是原來(lái)參加敏捷宣言的17人，基本是清一色的程序員，沒(méi)有在原則中單獨(dú)闡述一下測(cè)試的原則。但如下的一些原則和測(cè)試的關(guān)聯(lián)性很強(qiáng)。

（1）軟件測(cè)試如何支撐或協(xié)助“持續(xù)不斷地及早交付有價(jià)值的軟件”？如何在非常有限的時(shí)間內(nèi)進(jìn)行充分的測(cè)試？這就是我們經(jīng)常在敏捷測(cè)試中強(qiáng)調(diào)的“自動(dòng)化測(cè)試”，如果沒(méi)有自動(dòng)化測(cè)試，就沒(méi)有敏捷，就不能持續(xù)不斷地及早交付有價(jià)值的軟件，而且還要“使客戶(hù)滿(mǎn)意”。

（2）“欣然面對(duì)需求變化，即使在開(kāi)發(fā)后期也一樣”和傳統(tǒng)的開(kāi)發(fā)原則是不同的，傳統(tǒng)的開(kāi)發(fā)希望有嚴(yán)格的需求變更控制，越到后期控制越嚴(yán)。而敏捷開(kāi)發(fā)擁抱變化，那么測(cè)試如何適應(yīng)這種變化？如何快速地完成回歸測(cè)試？這可能要依賴(lài)于開(kāi)發(fā)做好單元測(cè)試，或全員參與測(cè)試，以及全面支持系統(tǒng)級(jí)的、端到端的回歸測(cè)試的自動(dòng)化測(cè)試執(zhí)行。

（3）傳統(tǒng)的開(kāi)發(fā)也要求“業(yè)務(wù)人員和開(kāi)發(fā)人員必須相互合作”，但存在一定的階段性，例如前期需求評(píng)審、期間產(chǎn)品走查（product walk-through）、后期驗(yàn)收測(cè)試等要求有緊密的溝通與協(xié)作。但敏捷開(kāi)發(fā)更強(qiáng)調(diào)“項(xiàng)目中的每一天都不例外”，在這樣的原則下，如何去做敏捷測(cè)試？這樣可以減少測(cè)試文檔，剛開(kāi)始也沒(méi)必要把測(cè)試計(jì)劃寫(xiě)得很詳細(xì)，而是寫(xiě)一頁(yè)紙測(cè)試計(jì)劃就可以，將來(lái)再持續(xù)地加以完善和調(diào)整。

（4）“可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)”，不再是測(cè)試計(jì)劃完成情況、完成的測(cè)試用例數(shù)目、測(cè)試腳本量等，而是如何及時(shí)驗(yàn)證每天完成的功能特性。開(kāi)發(fā)的工作量也不能按代碼行來(lái)衡量，而是看多少個(gè)具體的用戶(hù)故事（功能特性）被實(shí)現(xiàn)了（done）。某個(gè)開(kāi)發(fā)說(shuō)已完成了某個(gè)用戶(hù)故事，要么是通過(guò)他自己的驗(yàn)證，要么是通過(guò)測(cè)試人員的驗(yàn)證，誰(shuí)做的測(cè)試不重要，關(guān)鍵是要有準(zhǔn)備好的測(cè)試，隨時(shí)驗(yàn)證已完成的工作。

（5）“堅(jiān)持不懈地追求技術(shù)卓越和良好設(shè)計(jì)”，一方面要求測(cè)試的技術(shù)要不斷提高，在處理每個(gè)測(cè)試任務(wù)時(shí)，都應(yīng)該找到最有效的辦法；另一方面，在前期要更多地參與設(shè)計(jì)評(píng)審，及時(shí)發(fā)現(xiàn)設(shè)計(jì)的問(wèn)題。只有良好的設(shè)計(jì)，才能更好地支持系統(tǒng)的功能擴(kuò)充和不斷的重構(gòu)。

基于這些原則，我們就可以概括敏捷測(cè)試的下列一些特點(diǎn)。

（1）敏捷測(cè)試一定是敏捷開(kāi)發(fā)方法的一部分，應(yīng)符合敏捷測(cè)試宣言的思想，也遵守上面所列的敏捷開(kāi)發(fā)的原則，強(qiáng)調(diào)測(cè)試人員的個(gè)人技能，始終保持與客戶(hù)/用戶(hù)、其他成員（特別是業(yè)務(wù)人員、產(chǎn)品設(shè)計(jì)人員等）的緊密協(xié)作，建立良好的測(cè)試框架（特別是持續(xù)集成測(cè)試和自動(dòng)化回歸測(cè)試的基礎(chǔ)設(shè)施）以適應(yīng)需求的變化，更關(guān)注被測(cè)系統(tǒng)的本身而不是測(cè)試文檔（如測(cè)試計(jì)劃、測(cè)試用例等）。

（2）敏捷測(cè)試具有鮮明的敏捷開(kāi)發(fā)的特征，如測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（TDD）、驗(yàn)收測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（ATDD），可以見(jiàn)我的另一篇文章《敏捷測(cè)試的思考和新發(fā)展》所討論的。測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的思想是敏捷測(cè)試的核心，或者說(shuō)，單元測(cè)試是敏捷測(cè)試的基礎(chǔ)，如果沒(méi)有足夠的單元測(cè)試就無(wú)法應(yīng)付將來(lái)需求的快速變化、也無(wú)法實(shí)現(xiàn)持續(xù)的交付。這也說(shuō)明，在敏捷測(cè)試中，開(kāi)發(fā)人員承擔(dān)更多的測(cè)試，這也就是我們說(shuō)的，在敏捷測(cè)試中，是整個(gè)團(tuán)隊(duì)的共同努力。在敏捷測(cè)試中，可以沒(méi)有專(zhuān)職的測(cè)試人員，每個(gè)人都可以主動(dòng)去取設(shè)計(jì)任務(wù)和代碼任務(wù)做，也可以去拿測(cè)試任務(wù)來(lái)做。在敏捷測(cè)試中，也可以像開(kāi)發(fā)人員的結(jié)對(duì)編程那樣，實(shí)踐結(jié)對(duì)測(cè)試——一個(gè)測(cè)試人員對(duì)應(yīng)一個(gè)開(kāi)發(fā)人員、或一個(gè)測(cè)試人員對(duì)應(yīng)另一個(gè)測(cè)試人員。

（3）敏捷測(cè)試無(wú)處不在、無(wú)時(shí)不在。在傳統(tǒng)測(cè)試中也提倡盡早測(cè)試，包括需求和設(shè)計(jì)的評(píng)審；在傳統(tǒng)測(cè)試?yán)镆蔡岢^(guò)程測(cè)試。但在傳統(tǒng)測(cè)試?yán)镫A段性特征相對(duì)突出一些，例如，需求評(píng)審，意味著先讓產(chǎn)品人員去寫(xiě)需求，但需求文檔寫(xiě)好之后，測(cè)試人員再參加評(píng)審。而在敏捷測(cè)試?yán)?，團(tuán)隊(duì)每一天都在一起工作，一起討論需求、一起評(píng)審需求。在敏捷測(cè)試中，這種持續(xù)性更為顯著一些。

（4）敏捷測(cè)試是基于自動(dòng)化測(cè)試的，自動(dòng)化測(cè)試在敏捷測(cè)試中占有絕對(duì)的主導(dǎo)地位。在傳統(tǒng)測(cè)試中也提倡自動(dòng)化測(cè)試，但由于傳統(tǒng)開(kāi)發(fā)的周期比較長(zhǎng)（幾個(gè)月到幾年），即使沒(méi)有自動(dòng)化測(cè)試也是可以應(yīng)付的，一般來(lái)說(shuō)，回歸測(cè)試能夠獲得幾周時(shí)間，甚至1～2個(gè)月的時(shí)間。而敏捷測(cè)試的持續(xù)性迫切要求測(cè)試的高度自動(dòng)化，在1～3天內(nèi)就能完成整個(gè)的驗(yàn)收測(cè)試（包括回歸測(cè)試）。沒(méi)有自動(dòng)化，就沒(méi)有敏捷。

敏捷測(cè)試就是符合敏捷宣言思想，遵守敏捷開(kāi)發(fā)原則，在敏捷開(kāi)發(fā)環(huán)境下能夠很好地和其整體開(kāi)發(fā)流程融合的一系列的測(cè)試實(shí)踐，這些實(shí)踐具有鮮明的敏捷開(kāi)發(fā)的特征，如TDD、ATDD、結(jié)對(duì)編程、持續(xù)測(cè)試等。敏捷測(cè)試和傳統(tǒng)測(cè)試的區(qū)分，可以概括如下。

（1）傳統(tǒng)測(cè)試更強(qiáng)調(diào)測(cè)試的獨(dú)立性，將“開(kāi)發(fā)人員”和“測(cè)試人員”角色分得比較清楚。而敏捷測(cè)試可以有專(zhuān)職的測(cè)試人員，也可以是全民測(cè)試，即在敏捷測(cè)試中，可以沒(méi)有“測(cè)試人員”角色，強(qiáng)調(diào)整個(gè)團(tuán)隊(duì)對(duì)測(cè)試負(fù)責(zé)。

（2）傳統(tǒng)測(cè)試更具有階段性，從需求評(píng)審、設(shè)計(jì)評(píng)審、單元測(cè)試到集成測(cè)試、系統(tǒng)測(cè)試等，從測(cè)試計(jì)劃、測(cè)試設(shè)計(jì)再到測(cè)試執(zhí)行、測(cè)試報(bào)告等，但敏捷測(cè)試更強(qiáng)調(diào)持續(xù)測(cè)試、持續(xù)的質(zhì)量反饋，階段性比較模糊。

（3）傳統(tǒng)測(cè)試強(qiáng)調(diào)測(cè)試的計(jì)劃性，認(rèn)為沒(méi)有良好的測(cè)試計(jì)劃和不按計(jì)劃執(zhí)行，測(cè)試就難以控制和管理，而敏捷測(cè)試更強(qiáng)調(diào)測(cè)試的速度和適應(yīng)性，側(cè)重計(jì)劃的不斷調(diào)整以適應(yīng)需求的變化。

（4）傳統(tǒng)測(cè)試強(qiáng)調(diào)測(cè)試是由“驗(yàn)證”和“確認(rèn)”兩種活動(dòng)構(gòu)成的，而敏捷測(cè)試沒(méi)有這種區(qū)分，始終以用戶(hù)需求為中心，每時(shí)每刻不離開(kāi)用戶(hù)需求，將驗(yàn)證和確認(rèn)統(tǒng)一起來(lái)。

（5）傳統(tǒng)測(cè)試強(qiáng)調(diào)任何發(fā)現(xiàn)的缺陷要記錄下來(lái)，以便進(jìn)行缺陷根本原因分析，達(dá)到缺陷預(yù)防的目的，并強(qiáng)調(diào)缺陷跟蹤和處理的流程，區(qū)分測(cè)試人員和開(kāi)發(fā)人員的各自不同的責(zé)任。而敏捷測(cè)試強(qiáng)調(diào)面對(duì)面的溝通、協(xié)作，強(qiáng)調(diào)團(tuán)隊(duì)的責(zé)任，不太關(guān)注對(duì)缺陷的記錄與跟蹤。

（6）傳統(tǒng)測(cè)試更關(guān)注缺陷，圍繞缺陷開(kāi)展一系列的活動(dòng)，如缺陷跟蹤、缺陷度量、缺陷分析、缺陷報(bào)告質(zhì)量檢查等，而敏捷測(cè)試更關(guān)注產(chǎn)品本身，關(guān)注可以交付的客戶(hù)價(jià)值。在快速交付的敏捷開(kāi)發(fā)模式下，缺陷修復(fù)的成本很低。

（7）傳統(tǒng)測(cè)試鼓勵(lì)自動(dòng)化測(cè)試，但自動(dòng)化測(cè)試的成功與否對(duì)測(cè)試沒(méi)有致命的影響，但敏捷測(cè)試的基礎(chǔ)就是自動(dòng)化測(cè)試，敏捷測(cè)試是具有良好的自動(dòng)化測(cè)試框架支撐的快速測(cè)試。

0.3  軟件測(cè)試的作用

在購(gòu)買(mǎi)商品時(shí)，會(huì)發(fā)現(xiàn)商品上貼有一個(gè)“QC”標(biāo)簽，這就是產(chǎn)品經(jīng)過(guò)質(zhì)量檢驗(yàn)（Quality Control）的標(biāo)志。軟件測(cè)試就好比制造工廠的質(zhì)量檢驗(yàn)工作，是對(duì)軟件產(chǎn)品和階段性工作成果進(jìn)行質(zhì)量檢驗(yàn)，不僅驗(yàn)證產(chǎn)品是否符合事先的需求定義、設(shè)計(jì)要求和代碼規(guī)范等，完成一致性的檢查，而且要確認(rèn)所實(shí)現(xiàn)的產(chǎn)品功能特性是否滿(mǎn)足用戶(hù)需求，每個(gè)功能特性都是用戶(hù)真正所需要的。由于時(shí)間和預(yù)算的限制，我們無(wú)法證明一般的應(yīng)用系統(tǒng)軟件是沒(méi)有問(wèn)題的，而只能通過(guò)發(fā)現(xiàn)問(wèn)題并消除這些問(wèn)題來(lái)減低產(chǎn)品的質(zhì)量風(fēng)險(xiǎn)、提高產(chǎn)品的質(zhì)量。所以，軟件測(cè)試是軟件公司致力于衡量產(chǎn)品質(zhì)量、保證產(chǎn)品質(zhì)量的重要手段之一。

有人反駁說(shuō)，質(zhì)量是構(gòu)建的，不是靠測(cè)試測(cè)出來(lái)的。沒(méi)錯(cuò)，從“質(zhì)量是構(gòu)建的”角度看，開(kāi)發(fā)人員對(duì)產(chǎn)品質(zhì)量有更大貢獻(xiàn)，測(cè)試對(duì)質(zhì)量的貢獻(xiàn)要低于開(kāi)發(fā)工作，測(cè)試人員對(duì)質(zhì)量的貢獻(xiàn)要小。但這也不能否定測(cè)試的作用，測(cè)試人員幫助整個(gè)團(tuán)隊(duì)發(fā)現(xiàn)產(chǎn)品中存在的各種缺陷，然后督促開(kāi)發(fā)人員消滅這些缺陷，軟件產(chǎn)品的質(zhì)量還是有顯著的提高。如果從產(chǎn)品質(zhì)量和質(zhì)量責(zé)任來(lái)看，無(wú)論是把測(cè)試人員比作“產(chǎn)品質(zhì)量守門(mén)員”還是比作“產(chǎn)品質(zhì)量過(guò)程的監(jiān)督者”，都顯示測(cè)試人員對(duì)產(chǎn)品質(zhì)量有更大的責(zé)任，這是由“軟件測(cè)試人員”這個(gè)角色所決定的，軟件測(cè)試是質(zhì)量保證的重要手段之一，許多公司也把測(cè)試人員放在質(zhì)量保證（Quality Assurance）部門(mén)，甚至有的公司干脆就叫測(cè)試人員為QA人員。

概括起來(lái)，軟件測(cè)試有以下四個(gè)方面的作用。

（1）產(chǎn)品質(zhì)量評(píng)估：全面地評(píng)估軟件產(chǎn)品的質(zhì)量，為軟件產(chǎn)品發(fā)布（驗(yàn)收測(cè)試）、軟件系統(tǒng)部署（性能規(guī)劃測(cè)試）、軟件產(chǎn)品鑒定（第三方獨(dú)立測(cè)試）委托方和被委托方糾紛仲裁（第三方獨(dú)立測(cè)試）和其他決策提供產(chǎn)品質(zhì)量所需的各種信息，也就是能夠提供準(zhǔn)確、客觀、完整的軟件產(chǎn)品質(zhì)量報(bào)告。

（2）持續(xù)的質(zhì)量反饋：通過(guò)持續(xù)的測(cè)試（包括需求評(píng)審、設(shè)計(jì)評(píng)審、代碼評(píng)審等）可以對(duì)產(chǎn)品質(zhì)量提供持續(xù)的、快速的反饋，從而在整個(gè)開(kāi)發(fā)過(guò)程中不斷地、及時(shí)地解決存在的質(zhì)量問(wèn)題，不斷改進(jìn)產(chǎn)品的質(zhì)量，并減少各種返工，最大限度地降低軟件開(kāi)發(fā)的劣質(zhì)成本。

（3）客戶(hù)滿(mǎn)意度的提升：通過(guò)測(cè)試發(fā)現(xiàn)所要交付產(chǎn)品的缺陷，特別是盡可能地發(fā)現(xiàn)各種嚴(yán)重的缺陷，降低或消除產(chǎn)品質(zhì)量風(fēng)險(xiǎn)，提高客戶(hù)的滿(mǎn)意度，擴(kuò)大市場(chǎng)份額，提高客戶(hù)的忠誠(chéng)度。

（4）缺陷預(yù)防：通過(guò)對(duì)缺陷進(jìn)行分析，找出缺陷發(fā)生的根本原因（軟件開(kāi)發(fā)過(guò)程中所存在的流程缺失、不遵守流程、錯(cuò)誤的行為方式、不良習(xí)慣等問(wèn)題）或總結(jié)出軟件缺陷模式，采取措施糾正深層次的問(wèn)題，避免將來(lái)犯同樣的錯(cuò)誤，達(dá)到缺陷預(yù)防的效果，有效減少開(kāi)發(fā)中出現(xiàn)的問(wèn)題，提高開(kāi)發(fā)的效率。

0.4  軟件測(cè)試在SDLC中的位置

在著名的軟件瀑布模型中，軟件測(cè)試處在“編程”的下游，在“軟件維護(hù)”的上游，先有編程后有測(cè)試，測(cè)試的位置很清楚，但瀑布模型沒(méi)有反映SDLC的本質(zhì)，沒(méi)能準(zhǔn)確無(wú)誤地反映測(cè)試在SDLC的位置，瀑布模型中的軟件測(cè)試是狹義的測(cè)試，落后的測(cè)試觀念。

如前所述，軟件測(cè)試貫穿整個(gè)SDLC，從需求評(píng)審、設(shè)計(jì)評(píng)審開(kāi)始，就介入到軟件產(chǎn)品的開(kāi)發(fā)活動(dòng)或軟件項(xiàng)目實(shí)施中了。測(cè)試人員參與需求分析和需求評(píng)審，通過(guò)積極參與需求活動(dòng)，測(cè)試人員不僅能發(fā)現(xiàn)需求定義自身存在的問(wèn)題，而且能更深入理解業(yè)務(wù)需求、特定的用戶(hù)需求和產(chǎn)品的功能特性，為測(cè)試需求分析與設(shè)計(jì)等打下堅(jiān)實(shí)的基礎(chǔ)。更進(jìn)一步，這個(gè)階段可以確定產(chǎn)品測(cè)試的驗(yàn)收標(biāo)準(zhǔn)，可以制定驗(yàn)收測(cè)試的計(jì)劃和設(shè)計(jì)驗(yàn)收測(cè)試用例（test case）。同理，在軟件設(shè)計(jì)階段，測(cè)試人員要清楚地了解系統(tǒng)是如何實(shí)現(xiàn)的、采用哪些開(kāi)發(fā)技術(shù)以及構(gòu)建在什么樣的應(yīng)用平臺(tái)之上等各類(lèi)問(wèn)題，這樣可以提前準(zhǔn)備系統(tǒng)的測(cè)試環(huán)境，包括硬件和第三方軟件的采購(gòu)。更要針對(duì)一些非功能特性（如性能、安全性、兼容性、可靠性等）檢查系統(tǒng)架構(gòu)設(shè)計(jì)的合理性和有效性，發(fā)現(xiàn)設(shè)計(jì)中存在的問(wèn)題，并著手研究如何測(cè)試當(dāng)前的軟件系統(tǒng)，完成系統(tǒng)測(cè)試用例設(shè)計(jì)、測(cè)試工具的選型或啟動(dòng)測(cè)試工具的開(kāi)發(fā)，進(jìn)一步完善測(cè)試計(jì)劃等。所有這些準(zhǔn)備工作，都要花去很多時(shí)間，應(yīng)盡早開(kāi)展起來(lái)。

當(dāng)設(shè)計(jì)人員在做詳細(xì)設(shè)計(jì)時(shí)，測(cè)試人員可以直接參與具體的設(shè)計(jì)、參與設(shè)計(jì)的評(píng)審，找出設(shè)計(jì)的缺陷。同時(shí)，完成功能特性測(cè)試的用例，并基于這些測(cè)試用例開(kāi)發(fā)測(cè)試腳本。

編程階段的單元測(cè)試是很有效的，越來(lái)越得到業(yè)界的關(guān)注和實(shí)施。有數(shù)據(jù)顯示，單元測(cè)試可以發(fā)現(xiàn)代碼中60%～70%的問(wèn)題，充分的單元測(cè)試可以大幅度提高程序質(zhì)量。其次，單元測(cè)試和編程同步進(jìn)行，極其自然，可以盡早發(fā)現(xiàn)程序問(wèn)題。

軟件測(cè)試在SDLC中的位置，可以通過(guò)圖0-1充分地體現(xiàn)出來(lái)（也可參考W模型）。軟件測(cè)試和軟件開(kāi)發(fā)構(gòu)成一個(gè)全過(guò)程的交互、協(xié)作的關(guān)系，兩者自始至終一起工作，共同致力于同一個(gè)目標(biāo)——按時(shí)、高質(zhì)量地完成項(xiàng)目。

如果從團(tuán)隊(duì)來(lái)看，測(cè)試人員也是軟件研發(fā)團(tuán)隊(duì)中的主力軍。在軟件研發(fā)團(tuán)隊(duì)中，雖然有很多角色，包括項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理、用戶(hù)界面（User Interface, UI）設(shè)計(jì)人員、開(kāi)發(fā)人員、測(cè)試人員、軟件配置管理人員等，但從構(gòu)成的人數(shù)比例來(lái)看，主要以開(kāi)發(fā)人員和測(cè)試人員為主。在傳統(tǒng)的軟件開(kāi)發(fā)開(kāi)發(fā)中，特別是一些關(guān)鍵系統(tǒng)（如操作系統(tǒng)、銀行業(yè)務(wù)系統(tǒng)、交通信號(hào)控制系統(tǒng)等），測(cè)試人員占的比例就比較高，以微軟公司作為典型的例子，在其過(guò)去10～20年開(kāi)發(fā)Windows操作系統(tǒng)和Office產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)中，開(kāi)發(fā)人員和測(cè)試人員比例是1:2。相反的例子就是Google和facebook等互聯(lián)網(wǎng)軟件，如Google研發(fā)團(tuán)隊(duì)中，開(kāi)發(fā)人員和測(cè)試人員比例是10:1，而facebook沒(méi)有專(zhuān)職的測(cè)試人員。開(kāi)發(fā)人員和測(cè)試人員比例，也是經(jīng)人們討論的熱門(mén)話題，為此我還寫(xiě)過(guò)兩篇文章，在自己的博客^[28]上發(fā)表，但基本觀點(diǎn)是因?yàn)槊總€(gè)公司、公司的每個(gè)產(chǎn)品、產(chǎn)品的各個(gè)項(xiàng)目或各個(gè)階段都不同，沒(méi)法用一個(gè)比例來(lái)衡量不同的測(cè)試團(tuán)隊(duì)，因?yàn)檫@個(gè)比例受“開(kāi)發(fā)人員做哪些工作（是否包括比較多的測(cè)試工作）、開(kāi)發(fā)交付的質(zhì)量、產(chǎn)品質(zhì)量要求（不同的產(chǎn)品質(zhì)量要求不一樣）、開(kāi)發(fā)模式”等多種因素影響，例如：

 開(kāi)發(fā)人員進(jìn)行了足夠的單元測(cè)試，測(cè)試人員可以大大減少；

 非使命攸關(guān)系統(tǒng)、非生命攸關(guān)系統(tǒng)，對(duì)軟件質(zhì)量要求可以降低，測(cè)試人員可以繼續(xù)減少；

 如果是在線服務(wù)系統(tǒng)，可以隨時(shí)交付新的版本，修復(fù)缺陷的成本低、速度快，測(cè)試人員還可以繼續(xù)減少

總之，具體案例要具體分析。

0.5  傳統(tǒng)的軟件測(cè)試過(guò)程

在上節(jié)討論“軟件測(cè)試在SDLC中的位置”時(shí)，已觸及軟件測(cè)試過(guò)程，那個(gè)改進(jìn)的V模型（圖0-1）就反映了測(cè)試過(guò)程。但為了更明確測(cè)試過(guò)程，從兩條線分別展示軟件測(cè)試的基本過(guò)程，如圖0-2所示。

（1）一條線是從軟件工程過(guò)程來(lái)看，經(jīng)過(guò)需求評(píng)審、設(shè)計(jì)評(píng)審、代碼評(píng)審與單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試和驗(yàn)收測(cè)試階段。

（2）另一條線是從項(xiàng)目管理角度看，經(jīng)過(guò)測(cè)試計(jì)劃、測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行與監(jiān)控、測(cè)試結(jié)果分析與評(píng)估（報(bào)告）和項(xiàng)目總結(jié)階段。

過(guò)程的描述盡量簡(jiǎn)單，從而使讀者一目了然，基本知道各個(gè)環(huán)節(jié)主要的工作，但實(shí)際許多工作是交替進(jìn)行或同時(shí)進(jìn)行的，例如在圖0-1中所描述的，系統(tǒng)測(cè)試和驗(yàn)收測(cè)試的設(shè)計(jì)工作很早就開(kāi)始了，如圖0-1所示，系統(tǒng)測(cè)試和驗(yàn)收測(cè)試的設(shè)計(jì)工作分別在需求評(píng)審、設(shè)計(jì)評(píng)審階段就可以開(kāi)展，大部分內(nèi)容可以完成，在后續(xù)時(shí)間還可以繼續(xù)完善。

因?yàn)樘岢咳諛?gòu)建或持續(xù)集成，如果僅從軟件代碼角度看，單元測(cè)試和集成測(cè)試是同時(shí)進(jìn)行的，沒(méi)有單獨(dú)的集成測(cè)試階段。但如果考慮和其他子系統(tǒng)的集成、和第三方系統(tǒng)集成、和硬件集成等工作，集成測(cè)試的階段還是存在的。

在實(shí)際操作中，還可以定義自己所需的階段，或里程碑。這里以曾在Webex公司研發(fā)流程中所定義的測(cè)試過(guò)程作為示例，讓大家更好理解傳統(tǒng)的軟件測(cè)試過(guò)程，如圖0-3和表0-1所示。在這個(gè)示例中，主要的里程碑有：

 產(chǎn)品需求文檔（PRD）或市場(chǎng)需求文檔（MRD）的評(píng)審和簽發(fā)；

 產(chǎn)品規(guī)格說(shuō)明書(shū)（Spec）的評(píng)審和簽發(fā)；

 測(cè)試計(jì)劃、測(cè)試計(jì)劃書(shū)的評(píng)審和簽發(fā)；

 測(cè)試用例的設(shè)計(jì)、評(píng)審和簽發(fā)；

 功能測(cè)試；

 系統(tǒng)測(cè)試；

 驗(yàn)收測(cè)試。

0.6  敏捷測(cè)試過(guò)程

上面討論了傳統(tǒng)的軟件測(cè)試過(guò)程，下面就簡(jiǎn)單介紹一下敏捷測(cè)試過(guò)程，正文中還會(huì)有更多的討論。在敏捷測(cè)試流程中，參與單元測(cè)試，關(guān)注持續(xù)迭代的新功能，針對(duì)這些新功能進(jìn)行足夠的驗(yàn)收測(cè)試，而對(duì)原有功能的回歸測(cè)試則依賴(lài)于自動(dòng)化測(cè)試。由于敏捷方法中迭代周期短，測(cè)試人員盡早開(kāi)始測(cè)試，包括及時(shí)對(duì)需求、開(kāi)發(fā)設(shè)計(jì)的評(píng)審，更重要的是能夠及時(shí)、持續(xù)地對(duì)軟件產(chǎn)品質(zhì)量進(jìn)行反饋。簡(jiǎn)單地說(shuō)，在敏捷開(kāi)發(fā)流程中，階段性不夠明顯，持續(xù)測(cè)試和持續(xù)質(zhì)量反饋的特征明顯，這可以通過(guò)圖0-4來(lái)描述。

如果再具體一些，使流程更具可操作性，需要以敏捷Scrum為例，來(lái)介紹敏捷測(cè)試的流程。先看看Scrum流程，從圖0-5中可以看出，除了最后“驗(yàn)收測(cè)試”階段，其他過(guò)程似乎沒(méi)有顯著的測(cè)試特征，但隱含的測(cè)試需求和特征還是存在的。

（1）ProductBacklog （需求定義階段），在定義用戶(hù)需求時(shí)測(cè)試要做什么？測(cè)試需要考慮客戶(hù)的價(jià)值大?。▋?yōu)先級(jí)）、工作量基本估算之外，需要認(rèn)真研究與產(chǎn)品相關(guān)的用戶(hù)的行為模式（如Behavior Driven Development，BDD），產(chǎn)品的質(zhì)量需求，哪些質(zhì)量特性是我們需要考慮的？有哪些競(jìng)爭(zhēng)產(chǎn)品？這些競(jìng)爭(zhēng)產(chǎn)品有什么特點(diǎn)（優(yōu)點(diǎn)、缺點(diǎn)等）？

（2）SprintBacklog（階段性任務(wù)劃分和安排），這時(shí)候需要明確具體要實(shí)現(xiàn)的功能特性和任務(wù)，作為測(cè)試，這時(shí)候要特別關(guān)注“Definition of Done”，即每項(xiàng)任務(wù)結(jié)束的要求——即任務(wù)完成的驗(yàn)收標(biāo)準(zhǔn)，特別是功能特性的設(shè)計(jì)和代碼實(shí)現(xiàn)的驗(yàn)收標(biāo)準(zhǔn)。ATDD（使用驗(yàn)收測(cè)試驅(qū)動(dòng)開(kāi)發(fā)）的關(guān)鍵一步也體現(xiàn)在這里，在設(shè)計(jì)、寫(xiě)代碼之前，就要將驗(yàn)收標(biāo)準(zhǔn)確定下來(lái)。一方面符合測(cè)試驅(qū)動(dòng)開(kāi)發(fā)思想，最初就要把事情做對(duì)，預(yù)防缺陷；另一方面持續(xù)測(cè)試和驗(yàn)收測(cè)試的依據(jù)也清楚了，可以快速做出測(cè)試通過(guò)與否的判斷。

（3）在每個(gè)迭代（Sprint）實(shí)施階段，主要完成Sprint Backlog所定義的任務(wù)，這時(shí)除了測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（TDD）或單元測(cè)試之外，應(yīng)該進(jìn)行持續(xù)集成測(cè)試或通常所說(shuō)的BVT（Build Verification Test）。而且開(kāi)發(fā)人員在設(shè)計(jì)、寫(xiě)代碼時(shí)都會(huì)認(rèn)真考慮每一組件或每一代碼塊都具有可測(cè)試性，因?yàn)闇y(cè)試任務(wù)可能由他們自己來(lái)完成。如果有專(zhuān)職的測(cè)試人員角色，一方面可以完善單元測(cè)試、集成測(cè)試框架，協(xié)助開(kāi)發(fā)人員進(jìn)行單元測(cè)試；另一方面可以按照針對(duì)新實(shí)現(xiàn)的功能特性進(jìn)行更多的探索式測(cè)試，同時(shí)開(kāi)發(fā)驗(yàn)收測(cè)試的腳本。如果沒(méi)有專(zhuān)職的測(cè)試人員角色，這些事情也是要完成的，只是由整個(gè)團(tuán)隊(duì)共同完成。雖沒(méi)有工種的分工，但也存在任務(wù)的分工。

（4）驗(yàn)收測(cè)試可以由自動(dòng)化測(cè)試工具完成，但一般情況下，不可能做到百分之百的自動(dòng)化測(cè)試。例如易用性測(cè)試就很難由工具完成。即使對(duì)性能測(cè)試，是由工具完成，但還需要人來(lái)設(shè)計(jì)測(cè)試場(chǎng)景，包括關(guān)鍵業(yè)務(wù)選擇、負(fù)載模式等。敏捷的驗(yàn)收測(cè)試和傳統(tǒng)的驗(yàn)收測(cè)試不同，側(cè)重對(duì)“Definition of Done”的驗(yàn)證，但基本的思想和傳統(tǒng)開(kāi)發(fā)是一致的，任何沒(méi)有經(jīng)過(guò)驗(yàn)證的產(chǎn)品特性是不能直接發(fā)布出去的。

————————本文節(jié)選自《全程軟件測(cè)試（第2版）》