全程軟件測試之引子

在本書的開頭，有必要先澄清對軟件測試的理解，包括軟件測試的核心價值和作用，以及軟件測試和軟件開發的關系等，幫助讀者建立起軟件測試的正確理念，這樣對閱讀和理解以后各章的內容會有很大幫助。

如何理解軟件測試和建立起軟件測試的正確理念呢？還是從軟件測試的基本概念出發，回答下列幾個問題，逐步揭示軟件測試的內涵，深入到軟件測試的核心價值觀。這個過程，通過回答下列一系列問題來完成。

 究竟什么是軟件測試？

 究竟什么是敏捷測試？

 軟件測試的作用是什么？

 軟件測試在軟件開發生命周期（SDLC）中處在什么樣的地位？

 傳統的軟件測試過程是怎樣的？

 敏捷測試的過程又有什么不同？

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

0.1  究竟什么是軟件測試？

什么是軟件測試？人們常常回答：軟件測試就是發現軟件產品中的Bug（缺陷）。也有人說，不對，軟件測試是驗證軟件產品特性是否滿足用戶的需求。實際上，上述回答都沒錯，是對軟件測試的正反兩個方面的解釋。

（1）軟件測試就是發現軟件產品中的Bug，強調測試人員以逆向思維方式，不斷思考開發人員可能存在的誤區、不良的習慣、系統的邊界條件、異常輸入和操作、系統弱點和漏洞等，更快地發現軟件系統的問題。畢竟開發人員力求構造軟件，以正向思維方式為主，所以測試人員從逆向思維出發，可以獲得更高的測試效率。

（2）軟件測試是驗證軟件產品特性是否滿足用戶的需求，是以正向思維方式針對軟件系統的所有功能點，逐個驗證其正確性，這是傳統工業的質檢工作在軟件業的自然延伸。

但僅僅這樣理解軟件測試還不夠，需要更全面的理解軟件測試，就可以更好地做好工作，也可以適應不同的軟件開發過程所帶來的挑戰，包括敏捷方法帶給軟件測試的極大挑戰。

將近30年前，G.J.Myers在其經典著作《軟件測試之藝術》（The Art of Software Testing）一書中，給出了測試的定義：“程序測試是為了發現錯誤而執行程序的過程”。那時對軟件測試的認識還非常具有局限性，這也是受軟件開發瀑布模型的影響，認為軟件測試是編程之后的一個階段。只有等待代碼開發出來之后，通過執行程序，像用戶那樣操作軟件發現問題，這就是“動態測試”。

如果在此時發現功能設計不合理或性能不好，就需要修改需求或修改設計，那就不得不返工到需求定義或系統設計階段，造成很大的代價。所以，有必要將軟件測試延伸到需求、設計階段，即對階段性成果——需求定義文檔、設計技術文檔進行驗證，從而將動態測試延伸到靜態測試，盡早地發現問題，把問題消滅在萌芽之中，將每個階段產生的缺陷及時清除，極大地提高產品的質量，有效地降低企業的成本。靜態測試就是在不運行軟件系統時對軟件或階段性成果進行評審，包括需求評審、設計評審、代碼掃描、代碼評審等。

軟件測試從“動態測試”延伸到“靜態測試”，是從狹義的軟件測試發展到廣義的軟件測試，也使“軟件測試”不再停留在編程之后的某個階段上，而是貫穿整個軟件開發生命周期（Software Development Life Cycle，SDLC）的質量保證活動。有了廣義軟件測試的概念，在敏捷開發中，軟件測試就能被解釋為對軟件產品質量的持續評估。在敏捷方法中，不僅提倡持續集成，而且提倡持續測試,持續集成實際上也是為了持續測試。

從國際標準對軟件測試的定義來看，軟件測試被看做是“驗證（Verification）”和“有效性確認（Validation）”這兩類活動構成的整體，缺一不可。如果只做到其中一項，測試是不完整的。

（1）“驗證”是檢驗軟件是否已正確地實現了產品規格書所定義的系統功能和特性。驗證過程提供證據表明軟件相關產品與所有生命周期活動的要求相一致，即驗證軟件實現（即交付給客戶的產品）是否達到了軟件需求定義和設計目標。

（2）“有效性確認”是確認所開發的軟件是否滿足用戶實際需求的活動。因為軟件需求定義和設計可能就不對，上述一致性不能保證軟件產品符合客戶的實際需求，而且客戶的需求也是在變化的，當需求定義是半年前確定的，這種變化的可能性就比較大。

軟件不同于硬件，軟件一般都是應用系統，常常和人們的娛樂、事務處理、商業活動、社區交流等緊密聯系在一起，所以軟件具有很強的社會性，所以有測試專家把測試和社會性、人類學等聯系起來，認為軟件測試是跨學科的（interdisciplinary）活動，以系統為焦點（systems-focused），通過不斷調查（investigative）和講故事（storytelling）方式完成軟件質量的評估。通過其社會性，強調測試人員的思維能力和探索能力，強調測試的有效性和可靠性，在測試中要理解用戶的行為、人們活動的背景和目的（上下文關系），不斷觀察，不斷學習，發現和質量相關的信息（差異或質疑），從客戶利益出發來守護產品的價值。

概括起來，究竟什么是軟件測試呢？可以這樣說，軟件測試是貫穿整個軟件開發生命周期、對軟件產品（包括階段性產品）進行驗證和確認的活動過程，也是對軟件產品質量持續的評估過程，其目的是盡快盡早地發現在軟件產品（包括階段性產品）中所存在的各種問題，盡最大可能地消除軟件開發過程中所存在的產品質量風險。

0.2  究竟什么是敏捷測試？

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

（1）我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。

（2）欣然面對需求變化，即使在開發后期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。

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

（4）業務人員和開發人員必須相互合作，項目中的每一天都不例外。

（5）激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。

（6）不論團隊內外，傳遞信息效果最好、效率也最高的方式是面對面的交談。

（7）可工作的軟件是進度的首要度量標準。

（8）敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。

（9）堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。

（10）以簡潔為本，它是極力減少不必要工作量的藝術。

（11）最好的架構、需求和設計出自自組織團隊。

（12）團隊定期地反思如何能提高成效，并依此調整自身的舉止表現。

這12條原則中沒有一條直接談到測試，那是否說明沒有敏捷測試呢？有開發就有測試，只是原來參加敏捷宣言的17人，基本是清一色的程序員，沒有在原則中單獨闡述一下測試的原則。但如下的一些原則和測試的關聯性很強。

（1）軟件測試如何支撐或協助“持續不斷地及早交付有價值的軟件”？如何在非常有限的時間內進行充分的測試？這就是我們經常在敏捷測試中強調的“自動化測試”，如果沒有自動化測試，就沒有敏捷，就不能持續不斷地及早交付有價值的軟件，而且還要“使客戶滿意”。

（2）“欣然面對需求變化，即使在開發后期也一樣”和傳統的開發原則是不同的，傳統的開發希望有嚴格的需求變更控制，越到后期控制越嚴。而敏捷開發擁抱變化，那么測試如何適應這種變化？如何快速地完成回歸測試？這可能要依賴于開發做好單元測試，或全員參與測試，以及全面支持系統級的、端到端的回歸測試的自動化測試執行。

（3）傳統的開發也要求“業務人員和開發人員必須相互合作”，但存在一定的階段性，例如前期需求評審、期間產品走查（product walk-through）、后期驗收測試等要求有緊密的溝通與協作。但敏捷開發更強調“項目中的每一天都不例外”，在這樣的原則下，如何去做敏捷測試？這樣可以減少測試文檔，剛開始也沒必要把測試計劃寫得很詳細，而是寫一頁紙測試計劃就可以，將來再持續地加以完善和調整。

（4）“可工作的軟件是進度的首要度量標準”，不再是測試計劃完成情況、完成的測試用例數目、測試腳本量等，而是如何及時驗證每天完成的功能特性。開發的工作量也不能按代碼行來衡量，而是看多少個具體的用戶故事（功能特性）被實現了（done）。某個開發說已完成了某個用戶故事，要么是通過他自己的驗證，要么是通過測試人員的驗證，誰做的測試不重要，關鍵是要有準備好的測試，隨時驗證已完成的工作。

（5）“堅持不懈地追求技術卓越和良好設計”，一方面要求測試的技術要不斷提高，在處理每個測試任務時，都應該找到最有效的辦法；另一方面，在前期要更多地參與設計評審，及時發現設計的問題。只有良好的設計，才能更好地支持系統的功能擴充和不斷的重構。

基于這些原則，我們就可以概括敏捷測試的下列一些特點。

（1）敏捷測試一定是敏捷開發方法的一部分，應符合敏捷測試宣言的思想，也遵守上面所列的敏捷開發的原則，強調測試人員的個人技能，始終保持與客戶/用戶、其他成員（特別是業務人員、產品設計人員等）的緊密協作，建立良好的測試框架（特別是持續集成測試和自動化回歸測試的基礎設施）以適應需求的變化，更關注被測系統的本身而不是測試文檔（如測試計劃、測試用例等）。

（2）敏捷測試具有鮮明的敏捷開發的特征，如測試驅動開發（TDD）、驗收測試驅動開發（ATDD），可以見我的另一篇文章《敏捷測試的思考和新發展》所討論的。測試驅動開發的思想是敏捷測試的核心，或者說，單元測試是敏捷測試的基礎，如果沒有足夠的單元測試就無法應付將來需求的快速變化、也無法實現持續的交付。這也說明，在敏捷測試中，開發人員承擔更多的測試，這也就是我們說的，在敏捷測試中，是整個團隊的共同努力。在敏捷測試中，可以沒有專職的測試人員，每個人都可以主動去取設計任務和代碼任務做，也可以去拿測試任務來做。在敏捷測試中，也可以像開發人員的結對編程那樣，實踐結對測試——一個測試人員對應一個開發人員、或一個測試人員對應另一個測試人員。

（3）敏捷測試無處不在、無時不在。在傳統測試中也提倡盡早測試，包括需求和設計的評審；在傳統測試里也提倡全過程測試。但在傳統測試里階段性特征相對突出一些，例如，需求評審，意味著先讓產品人員去寫需求，但需求文檔寫好之后，測試人員再參加評審。而在敏捷測試里，團隊每一天都在一起工作，一起討論需求、一起評審需求。在敏捷測試中，這種持續性更為顯著一些。

（4）敏捷測試是基于自動化測試的，自動化測試在敏捷測試中占有絕對的主導地位。在傳統測試中也提倡自動化測試，但由于傳統開發的周期比較長（幾個月到幾年），即使沒有自動化測試也是可以應付的，一般來說，回歸測試能夠獲得幾周時間，甚至1～2個月的時間。而敏捷測試的持續性迫切要求測試的高度自動化，在1～3天內就能完成整個的驗收測試（包括回歸測試）。沒有自動化，就沒有敏捷。

敏捷測試就是符合敏捷宣言思想，遵守敏捷開發原則，在敏捷開發環境下能夠很好地和其整體開發流程融合的一系列的測試實踐，這些實踐具有鮮明的敏捷開發的特征，如TDD、ATDD、結對編程、持續測試等。敏捷測試和傳統測試的區分，可以概括如下。

（1）傳統測試更強調測試的獨立性，將“開發人員”和“測試人員”角色分得比較清楚。而敏捷測試可以有專職的測試人員，也可以是全民測試，即在敏捷測試中，可以沒有“測試人員”角色，強調整個團隊對測試負責。

（2）傳統測試更具有階段性，從需求評審、設計評審、單元測試到集成測試、系統測試等，從測試計劃、測試設計再到測試執行、測試報告等，但敏捷測試更強調持續測試、持續的質量反饋，階段性比較模糊。

（3）傳統測試強調測試的計劃性，認為沒有良好的測試計劃和不按計劃執行，測試就難以控制和管理，而敏捷測試更強調測試的速度和適應性，側重計劃的不斷調整以適應需求的變化。

（4）傳統測試強調測試是由“驗證”和“確認”兩種活動構成的，而敏捷測試沒有這種區分，始終以用戶需求為中心，每時每刻不離開用戶需求，將驗證和確認統一起來。

（5）傳統測試強調任何發現的缺陷要記錄下來，以便進行缺陷根本原因分析，達到缺陷預防的目的，并強調缺陷跟蹤和處理的流程，區分測試人員和開發人員的各自不同的責任。而敏捷測試強調面對面的溝通、協作，強調團隊的責任，不太關注對缺陷的記錄與跟蹤。

（6）傳統測試更關注缺陷，圍繞缺陷開展一系列的活動，如缺陷跟蹤、缺陷度量、缺陷分析、缺陷報告質量檢查等，而敏捷測試更關注產品本身，關注可以交付的客戶價值。在快速交付的敏捷開發模式下，缺陷修復的成本很低。

（7）傳統測試鼓勵自動化測試，但自動化測試的成功與否對測試沒有致命的影響，但敏捷測試的基礎就是自動化測試，敏捷測試是具有良好的自動化測試框架支撐的快速測試。

0.3  軟件測試的作用

在購買商品時，會發現商品上貼有一個“QC”標簽，這就是產品經過質量檢驗（Quality Control）的標志。軟件測試就好比制造工廠的質量檢驗工作，是對軟件產品和階段性工作成果進行質量檢驗，不僅驗證產品是否符合事先的需求定義、設計要求和代碼規范等，完成一致性的檢查，而且要確認所實現的產品功能特性是否滿足用戶需求，每個功能特性都是用戶真正所需要的。由于時間和預算的限制，我們無法證明一般的應用系統軟件是沒有問題的，而只能通過發現問題并消除這些問題來減低產品的質量風險、提高產品的質量。所以，軟件測試是軟件公司致力于衡量產品質量、保證產品質量的重要手段之一。

有人反駁說，質量是構建的，不是靠測試測出來的。沒錯，從“質量是構建的”角度看，開發人員對產品質量有更大貢獻，測試對質量的貢獻要低于開發工作，測試人員對質量的貢獻要小。但這也不能否定測試的作用，測試人員幫助整個團隊發現產品中存在的各種缺陷，然后督促開發人員消滅這些缺陷，軟件產品的質量還是有顯著的提高。如果從產品質量和質量責任來看，無論是把測試人員比作“產品質量守門員”還是比作“產品質量過程的監督者”，都顯示測試人員對產品質量有更大的責任，這是由“軟件測試人員”這個角色所決定的，軟件測試是質量保證的重要手段之一，許多公司也把測試人員放在質量保證（Quality Assurance）部門，甚至有的公司干脆就叫測試人員為QA人員。

概括起來，軟件測試有以下四個方面的作用。

（1）產品質量評估：全面地評估軟件產品的質量，為軟件產品發布（驗收測試）、軟件系統部署（性能規劃測試）、軟件產品鑒定（第三方獨立測試）委托方和被委托方糾紛仲裁（第三方獨立測試）和其他決策提供產品質量所需的各種信息，也就是能夠提供準確、客觀、完整的軟件產品質量報告。

（2）持續的質量反饋：通過持續的測試（包括需求評審、設計評審、代碼評審等）可以對產品質量提供持續的、快速的反饋，從而在整個開發過程中不斷地、及時地解決存在的質量問題，不斷改進產品的質量，并減少各種返工，最大限度地降低軟件開發的劣質成本。

（3）客戶滿意度的提升：通過測試發現所要交付產品的缺陷，特別是盡可能地發現各種嚴重的缺陷，降低或消除產品質量風險，提高客戶的滿意度，擴大市場份額，提高客戶的忠誠度。

（4）缺陷預防：通過對缺陷進行分析，找出缺陷發生的根本原因（軟件開發過程中所存在的流程缺失、不遵守流程、錯誤的行為方式、不良習慣等問題）或總結出軟件缺陷模式，采取措施糾正深層次的問題，避免將來犯同樣的錯誤，達到缺陷預防的效果，有效減少開發中出現的問題，提高開發的效率。

0.4  軟件測試在SDLC中的位置

在著名的軟件瀑布模型中，軟件測試處在“編程”的下游，在“軟件維護”的上游，先有編程后有測試，測試的位置很清楚，但瀑布模型沒有反映SDLC的本質，沒能準確無誤地反映測試在SDLC的位置，瀑布模型中的軟件測試是狹義的測試，落后的測試觀念。

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

當設計人員在做詳細設計時，測試人員可以直接參與具體的設計、參與設計的評審，找出設計的缺陷。同時，完成功能特性測試的用例，并基于這些測試用例開發測試腳本。

編程階段的單元測試是很有效的，越來越得到業界的關注和實施。有數據顯示，單元測試可以發現代碼中60%～70%的問題，充分的單元測試可以大幅度提高程序質量。其次，單元測試和編程同步進行，極其自然，可以盡早發現程序問題。

軟件測試在SDLC中的位置，可以通過圖0-1充分地體現出來（也可參考W模型）。軟件測試和軟件開發構成一個全過程的交互、協作的關系，兩者自始至終一起工作，共同致力于同一個目標——按時、高質量地完成項目。

如果從團隊來看，測試人員也是軟件研發團隊中的主力軍。在軟件研發團隊中，雖然有很多角色，包括項目經理、產品經理、用戶界面（User Interface, UI）設計人員、開發人員、測試人員、軟件配置管理人員等，但從構成的人數比例來看，主要以開發人員和測試人員為主。在傳統的軟件開發開發中，特別是一些關鍵系統（如操作系統、銀行業務系統、交通信號控制系統等），測試人員占的比例就比較高，以微軟公司作為典型的例子，在其過去10～20年開發Windows操作系統和Office產品開發團隊中，開發人員和測試人員比例是1:2。相反的例子就是Google和facebook等互聯網軟件，如Google研發團隊中，開發人員和測試人員比例是10:1，而facebook沒有專職的測試人員。開發人員和測試人員比例，也是經人們討論的熱門話題，為此我還寫過兩篇文章，在自己的博客^[28]上發表，但基本觀點是因為每個公司、公司的每個產品、產品的各個項目或各個階段都不同，沒法用一個比例來衡量不同的測試團隊，因為這個比例受“開發人員做哪些工作（是否包括比較多的測試工作）、開發交付的質量、產品質量要求（不同的產品質量要求不一樣）、開發模式”等多種因素影響，例如：

 開發人員進行了足夠的單元測試，測試人員可以大大減少；

 非使命攸關系統、非生命攸關系統，對軟件質量要求可以降低，測試人員可以繼續減少；

 如果是在線服務系統，可以隨時交付新的版本，修復缺陷的成本低、速度快，測試人員還可以繼續減少

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

0.5  傳統的軟件測試過程

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

（1）一條線是從軟件工程過程來看，經過需求評審、設計評審、代碼評審與單元測試、集成測試、系統測試和驗收測試階段。

（2）另一條線是從項目管理角度看，經過測試計劃、測試設計、測試執行與監控、測試結果分析與評估（報告）和項目總結階段。

過程的描述盡量簡單，從而使讀者一目了然，基本知道各個環節主要的工作，但實際許多工作是交替進行或同時進行的，例如在圖0-1中所描述的，系統測試和驗收測試的設計工作很早就開始了，如圖0-1所示，系統測試和驗收測試的設計工作分別在需求評審、設計評審階段就可以開展，大部分內容可以完成，在后續時間還可以繼續完善。

因為提倡每日構建或持續集成，如果僅從軟件代碼角度看，單元測試和集成測試是同時進行的，沒有單獨的集成測試階段。但如果考慮和其他子系統的集成、和第三方系統集成、和硬件集成等工作，集成測試的階段還是存在的。

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

 產品需求文檔（PRD）或市場需求文檔（MRD）的評審和簽發；

 產品規格說明書（Spec）的評審和簽發；

 測試計劃、測試計劃書的評審和簽發；

 測試用例的設計、評審和簽發；

 功能測試；

 系統測試；

 驗收測試。

0.6  敏捷測試過程

上面討論了傳統的軟件測試過程，下面就簡單介紹一下敏捷測試過程，正文中還會有更多的討論。在敏捷測試流程中，參與單元測試，關注持續迭代的新功能，針對這些新功能進行足夠的驗收測試，而對原有功能的回歸測試則依賴于自動化測試。由于敏捷方法中迭代周期短，測試人員盡早開始測試，包括及時對需求、開發設計的評審，更重要的是能夠及時、持續地對軟件產品質量進行反饋。簡單地說，在敏捷開發流程中，階段性不夠明顯，持續測試和持續質量反饋的特征明顯，這可以通過圖0-4來描述。

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

（1）ProductBacklog （需求定義階段），在定義用戶需求時測試要做什么？測試需要考慮客戶的價值大小（優先級）、工作量基本估算之外，需要認真研究與產品相關的用戶的行為模式（如Behavior Driven Development，BDD），產品的質量需求，哪些質量特性是我們需要考慮的？有哪些競爭產品？這些競爭產品有什么特點（優點、缺點等）？

（2）SprintBacklog（階段性任務劃分和安排），這時候需要明確具體要實現的功能特性和任務，作為測試，這時候要特別關注“Definition of Done”，即每項任務結束的要求——即任務完成的驗收標準，特別是功能特性的設計和代碼實現的驗收標準。ATDD（使用驗收測試驅動開發）的關鍵一步也體現在這里，在設計、寫代碼之前，就要將驗收標準確定下來。一方面符合測試驅動開發思想，最初就要把事情做對，預防缺陷；另一方面持續測試和驗收測試的依據也清楚了，可以快速做出測試通過與否的判斷。

（3）在每個迭代（Sprint）實施階段，主要完成Sprint Backlog所定義的任務，這時除了測試驅動開發（TDD）或單元測試之外，應該進行持續集成測試或通常所說的BVT（Build Verification Test）。而且開發人員在設計、寫代碼時都會認真考慮每一組件或每一代碼塊都具有可測試性，因為測試任務可能由他們自己來完成。如果有專職的測試人員角色，一方面可以完善單元測試、集成測試框架，協助開發人員進行單元測試；另一方面可以按照針對新實現的功能特性進行更多的探索式測試，同時開發驗收測試的腳本。如果沒有專職的測試人員角色，這些事情也是要完成的，只是由整個團隊共同完成。雖沒有工種的分工，但也存在任務的分工。

（4）驗收測試可以由自動化測試工具完成，但一般情況下，不可能做到百分之百的自動化測試。例如易用性測試就很難由工具完成。即使對性能測試，是由工具完成，但還需要人來設計測試場景，包括關鍵業務選擇、負載模式等。敏捷的驗收測試和傳統的驗收測試不同，側重對“Definition of Done”的驗證，但基本的思想和傳統開發是一致的，任何沒有經過驗證的產品特性是不能直接發布出去的。

————————本文節選自《全程軟件測試（第2版）》