敏捷軟件開發致使很多人質疑專業測試團隊存在的價值，本文對此進行了深度的剖析，并結合技術發展現狀給出了軟件測試的未來方向。
敏捷軟件開發帶來的困惑
敏捷軟件開發強調“擁抱變化”， 認為不能將需求定義一次做到位，也沒必要一次做到位，需要不斷挖掘，才能逐漸獲得真實的需求。這就給測試帶來極大的挑戰，因為測試需要把驗證的標準作為參 照系，否則如果需求不清楚，就很難確定測試中發現的問題是不是真正的缺陷，導致測試的設計與執行困難重重。在這種情況下，我們是否只能依賴探索式測試呢？
敏捷軟件開發強調持續構建、持續測試。在構建中不僅可以完成單元測試，還可以完成集成測試。因為每天都構建軟件包，一旦單元之間（接口）存在問題，就很容易 暴露出來。每日構建和集成可被看作持續測試的一種體現。在這種情況下，是否就無需單獨的集成測試階段？測試的投入是否就可以減少呢？
敏捷軟件開發強調與用戶的溝通和協作，用戶起初并不清楚自己的需求，通過軟件產品的使用，才逐步明白自己想要什么。如果用戶真能參與開發過程，即用戶每天都能及 時使用正在開發的軟件，那么還需要測試人員嗎？如果將持續集成和用戶及時反饋結合起來，專業測試人員的測試投入是不是就可以大大降低？
敏捷軟件開發強調持續交付，即及時發布有價值功能給客戶，并盡快地滿足客戶的需求。之所以能做到持續交付，是因為軟件已從產品銷售模式轉為服務模式—軟件即服 務（Software as a Service，SaaS），不存在以前產品模式的銷售渠道，軟件版本的更新只要在自己數據中心的服務器上打個patch就可以了。這種SaaS模式使得 持續交付成為可能，軟件能夠快速上線、用戶也能及時獲得更新的服務，因此缺陷能被快速修復，缺陷修復的成本極大降低，大大提高了人們對缺陷的容忍度，降低 了對質量的要求。但這可以大大降低測試的投入嗎？
特別是像Facebook這樣耀眼的公司，其實踐似乎在支持“無需建立獨立的測試團隊”， 讓開發人員來承擔越來越多的測試工作，甚至承擔全部測試工作。還有人提議將測試團隊的一半成員拿出來做開發，這樣可以解決以前單元測試不足的問題。而測試 團隊的另一半被抽調到客戶服務（Customer Care）團隊中，負責需求前期調查和后期技術支持，在需求上加大投入，幫助建立軟件產品的客戶驗收標準，讓開發人員基于驗收標準完成軟件系統的設計和編 程，從源頭上提高質量，而且后期技術支持也得到了加強。
專業測試團隊要不要？
一系列新的實踐似乎在加劇質疑“專業測試團隊的存在意義”。但在傳統軟件測試理念中，則強調測試的獨立性和專業性，專業性越強，越需要全職人員。這些實踐在 傳統產業的質管理實踐中已得到充分的驗證。傳統產業的質檢部門是獨立的，質檢人員也是全職的。如果不管三七二十一，將測試團隊拆分掉，會不會帶來新的問題？比如：
● 究竟要不要專業的測試團隊？
● 軟件測試由誰來做更有效？
● 專業的測試團隊未來的路會是怎樣？
這一系列新的問題開始困擾業界，因此我們有必要進行充分的討論，澄清這些問題。即使不能給出令每個人都信服的答案，也要幫助測試人員獲得更客觀、更理性的認識。
從軟件測試本質來看，測試就是對軟件產品（包括階段性產品）質量進行全面地評估，以了解產品質量當前的狀態，從而為項目管理和決策提供客觀的依據。在這過程 中，發現缺陷、暴露產品質量風險等，都可以看作軟件測試的副產品。只是因為缺乏可操作的、具體的質量標準，所以目前沒有能力和手段對軟件產品做到100% 的客觀評價，也很難通過工具對軟件產品直接進行質量指標的逐項驗證而給出“質量檢驗通過”或“質量檢驗不通過”的結論。而且，軟件質量整體都比較差，人們 也很難通過一次性的測試完成軟件產品的質量評估，而是要進行持續測試或多輪的測試，其結果弱化了“全面評估軟件質量”的作用，而強調軟件測試是努力發現軟 件產品缺陷、暴露質量風險、不斷提供質量反饋的過程。
如果讓構建軟件產品的開發人員來評價自己的產品，那么測試結果具有說服力嗎？暫且不 說，王婆賣瓜，自賣自夸的嫌疑。從心理學角度分析，要發現自己的問題、否定自己的實現，需要克服心理上很大的障礙，這實際上是很不容易的。更何況人天生有 惰性，希望某一個團隊把事情從頭到尾做好，完全依賴每個成員高度的責任感和主動性，這是不現實的。監督機制不可缺失，正如建筑需要監理、警察還有督察等， 獨立測試缺失，質量難以保障。在敏捷Scrum開發模型中（如圖1所示），開發和測試在持續構建和持續測試之后，也依舊要設立一個獨立的驗收測試階段，其 實就是對獨立測試的一種訴求。
圖1 敏捷Scrum開發模型示意圖
基本上，大家已達成共識：單元測試、集成測試一般由開發人員做效率更高些，而系統測試和驗收測試由測試人員做比較好。為什么會有這樣的共識呢？
如果開發人員先實現再測試，其測試的思路一定會受到實現的影響，不能達到良好的測試效果。如果先設計測試再實現產品，即采用TDD開發軟件，讓測試在先而不 受實現的影響，效果會不錯。但問題是有多少開發團隊能夠真正做到TDD？而且TDD對需求有更高的要求，軟件產品質量的驗收標準事先需要被明確定義，然后 才能做到先開發測試腳本，后開發產品代碼。而現實的需求又很難做到這點。
軟件質量就是客戶滿意度。從這個角度看，測試工作更重要的任務是要 在系統層面驗證是否能夠全面滿足業務需求、是否真正滿足不同用戶的實際需求。而這樣的測試必須要等到系統建立起來之后才能進行，如果這時讓開發人員來做測 試，必然會受到之前實現思維慣性的影響，效果明顯降低。其次，每個開發人員通常只完成系統的很小一部分，對整體業務無法有效地把握，而且業務場景太多、繁 雜，這時很考察測試人員的專業能力。只有站得高、看得遠，完成業務端到端的測試，覆蓋各種業務場景，才能確保系統能夠正確、有效地實現整個業務流程。
如果開發人員知道某些地方很有可能存在缺陷，那么就會設法避免這些缺陷的產生。但往往開發人員并不知道自己會犯哪些錯誤。而如果讓專業的測試人員從不同的角度、不同的思路來測試軟件，測試的效果會有效得多。
更何況測試本身具有很強的專業性，包括測試建模技術、測試方法及其工具的應用，只有專業的測試人員才能很好掌握。
舉一個例子，僅僅是黑盒測試方法中一項具體的測試技術—因果分析法（cause-effect analysis），美國測試專家Richard Bender差不多用其一生的時間來研究它，才將這項技術做到極致。除系統的功能測試外，做好系統的性能測試、安全性測試等就更不容易，而且隨著軟件技術 和應用的不斷發展會不斷引發新的測試問題。因此，可以說這種專業的實踐和積累將是一項長期的任務。
互聯網的多數應用（如新浪微博、 Facebook、Google搜索）屬于文化娛樂服務，受缺陷的影響非常有限。例如，新浪微博的Beta版能在線運行長達三年，但銀行業務系統Beta 版在線運行一天都不可能。在金融、國防、航天、通信、交通控制乃至龐大的制造業生產控制等領域，無不要求零缺陷的軟件產品，其獨立的專業測試更是不可缺 少。最近幾年，各大銀行不僅建立了獨立的測試團隊，而且測試團隊還保持30%以上的發展速度。如果考慮云計算、物聯網等新技術的應用，軟件系統的復雜性會 非線性增長，軟件缺陷造成的負面影響也不能同日而語，那么在這些領域加強測試也是必然的，對專業的測試團隊的需求不但不降低，反而會增強。
軟件測試的未來
近幾年，敏捷測試、探索式測試、精益測試、基于模型的測試等越來越受到大家的關注。《軟件測試：經驗與教訓》一書的作者Bret Pettichord在2003年將軟件測試歸為四大學派（School），四年后（2007年）又增加了一個敏捷測試學派，將軟件測試分為五個學派，如 圖2所示。
圖2 軟件測試五大流派示意圖
● 分析學派（Analytic School）：認為軟件是邏輯性的，將測試看作計算機科學和數學的一部分，結構化測試、代碼覆蓋率就是其中一些典型的例子。他們認為測試工作是技術性很強的工作，側重使用類似UML工具進行分析和建模。
● 標準學派（Standard School）：從分析學派分支出來并得到IEEE的支持，把測試看作側重劣質成本控制并具有可重復標準的、旨在衡量項目進度的一項工作，測試是對產品需求的確認，每個需求都需要得到驗證。
● 質量學派（Quality School）：軟件質量需要規范，測試就是過程的質量控制、揭示項目質量風險的活動，確定開發人員是否遵守規范，測試人員扮演產品質量的守門員角色。
● 上下文驅動學派（Context-Driven School）：認為軟件是人創造的，測試所發現的每一個缺陷都和相關利益者（stakeholder）密切相關；認為測試是一種有技巧的心理活動；強調人的能動性和啟發式測試思維。探索性測試就是其典型代表。
● 敏捷學派（Agile School）：認為軟件就是持續不斷的對話，而測試就是驗證開發工作是否完成，強調自動化測試。TDD是其典型代表。
標準學派和質量學派相對比較成熟，流程、過程規范等基本已建立，包括TPI、TMMi等比較成熟，雖然未來會有一些修改。而上下文驅動是比較自然的思路，其 他學派也或多或少也會從上下文去考慮，也存在融合的可能性。雖然分析學派和上下文驅動學派、敏捷學派有一定對立關系，但它們相互之間又會有更多的交融，而 且敏捷方法主要以實踐為基礎，敏捷測試不是原發性的，而是先有敏捷開發。然后人們被動地尋求測試方法和技術來適應敏捷開發。敏捷測試缺乏自己獨立的理論根 基，更多地依賴于上下文驅動學派的支持，包括探索式測試和自動化測試。其中自動化測試是敏捷測試主打的王牌，沒有自動化測試就沒有敏捷測試，而自動化測試 和持續集成、持續測試也相當吻合。
雖然互聯網的影響越來越大，但關鍵系統（如銀行業務、交通控制等系統）還依舊存在，關鍵系統會進一步促進 軟件開發的各種建模技術的發展，其中也包括測試建模和形式化驗證。基于模型的測試也會促進自動化測試的發展，這兩者之間是相輔相成的。沒有測試建模的支 持，自動化測試靠完全模擬手工的操作方式來實現，其實現和維護代價將相當大，使之投入產出比（ROI）總是不夠理想，阻礙自動化測試的發展。當自動化測試 能夠借助基于模型的測試，那么自動化測試將事半功倍、如魚得水，ROI自然也會很高?；谀Ｐ偷臏y試，最終也需要工具的支持，例如Pairwise、因果 分析法等。如果沒有工具支持，測試人員就會感覺很累而不愿應用。
對軟件測試影響最大的因素是軟件發布模式和軟件開發技術。前面已詳細描述了 軟件發布模式，在SaaS模式中可以持續發布敏捷測試、探索式測試受到更多的關注。同時，SaaS的發展促進了各種基于云計算的服務模式誕生，軟件測試的 云服務模式應運而生、快速發展起來。測試公有云提供公共的、開放的測試服務，像UTest、SOASTA、SauceLab和Testin等，可以完成手 機應用、Web應用或其他應用的功能測試、兼容性測試、配置測試和性能測試等。而測試私有云是某個企業為自己建立的云測試服務，將測試機器資源、測試工具 等都放在云端，公司的各個團隊都可以共享所有測試資源，完成從自動分配資源、自動部署到測試結果報告生成的測試過程，而且還能將測試流程、測試管理等固化 在私有云內。
在軟件開發技術方面，軟件開發框架、工具也對測試有直接影響。例如，對分層構造軟件系統而言，軟件測試也可以采用分層的自動化 測試技術。但未來有什么革命性的軟件開發技術還難以預料，例如未來是否產生有效的開發技術能夠智能地自動完成軟件設計和實現的驗證。但可以肯定的是，未來 依靠軟件生命周期的前期努力與創新構造更高質量的產品，依靠更好的單元測試技術充分實施代碼層的測試，讓“質量是內建的”落實到位，并借助API、UI等 不同層次的自動化測試來提高測試效率。這樣，軟件測試投入可以越來越少，專業的測試團隊規?？梢圆粩嗫s小，還能保持同樣的軟件產品質量水平。這樣，對軟件 企業也是好事，企業質量保障成本越低，企業獲益就越大?？傊浖y試未來可能會形成兩個主流方向。
基于模型的自動化測試：以傳統測試的分 析學派為基礎，強調從需求分析開始，為需求或用戶行為構建模型，然后基于模型自動產生和執行測試用例，它更適用于關鍵系統的驗證。這對測試人員的技術能力 有更高的要求，專業測試人員會越來越精干。如果有一天，測試團隊的成員是從最優秀的開發人員中挑選，測試人員只占整個研發團隊的10%左右，軟件開發才到 了真正成熟的時代。
基于云服務的測試模式：非關鍵系統在前期系統架構設計和代碼實現上可借助良好的開發框架與工具、單元測試和持續集成等工 作，在沒有專職測試團隊的工作情況下，也能保證產品質量處在一個基本可用的水平。然后，利用上述的公有云服務模式來完成更深度的測試，如可用性測試、配置 測試、兼容性測試、性能測試都可以在云平臺上自動完成。剩余的功能測試（包括業務流測試、場景測試等）就可以交給大眾，通過遠程服務完成測試。這些測試人 員可能是業余志愿者，也可能是在家工作的專業測試人員，按任務領取報酬。
本文選自《程序員》雜志2012年09期：http://www.programmer.com.cn/13717/