專業(yè)測(cè)試團(tuán)隊(duì)的重要性和未來(lái)的發(fā)展

敏捷軟件開發(fā)致使很多人質(zhì)疑專業(yè)測(cè)試團(tuán)隊(duì)存在的價(jià)值，本文對(duì)此進(jìn)行了深度的剖析，并結(jié)合技術(shù)發(fā)展現(xiàn)狀給出了軟件測(cè)試的未來(lái)方向。

敏捷軟件開發(fā)帶來(lái)的困惑

敏捷軟件開發(fā)強(qiáng)調(diào)“擁抱變化”，認(rèn)為不能將需求定義一次做到位，也沒必要一次做到位，需要不斷挖掘，才能逐漸獲得真實(shí)的需求。這就給測(cè)試帶來(lái)極大的挑戰(zhàn)，因?yàn)闇y(cè)試需要把驗(yàn)證的標(biāo)準(zhǔn)作為參照系，否則如果需求不清楚，就很難確定測(cè)試中發(fā)現(xiàn)的問題是不是真正的缺陷，導(dǎo)致測(cè)試的設(shè)計(jì)與執(zhí)行困難重重。在這種情況下，我們是否只能依賴探索式測(cè)試呢？

敏捷軟件開發(fā)強(qiáng)調(diào)持續(xù)構(gòu)建、持續(xù)測(cè)試。在構(gòu)建中不僅可以完成單元測(cè)試，還可以完成集成測(cè)試。因?yàn)槊刻於紭?gòu)建軟件包，一旦單元之間（接口）存在問題，就很容易暴露出來(lái)。每日構(gòu)建和集成可被看作持續(xù)測(cè)試的一種體現(xiàn)。在這種情況下，是否就無(wú)需單獨(dú)的集成測(cè)試階段？測(cè)試的投入是否就可以減少呢？

敏捷軟件開發(fā)強(qiáng)調(diào)與用戶的溝通和協(xié)作，用戶起初并不清楚自己的需求，通過軟件產(chǎn)品的使用，才逐步明白自己想要什么。如果用戶真能參與開發(fā)過程，即用戶每天都能及時(shí)使用正在開發(fā)的軟件，那么還需要測(cè)試人員嗎？如果將持續(xù)集成和用戶及時(shí)反饋結(jié)合起來(lái)，專業(yè)測(cè)試人員的測(cè)試投入是不是就可以大大降低？

敏捷軟件開發(fā)強(qiáng)調(diào)持續(xù)交付，即及時(shí)發(fā)布有價(jià)值功能給客戶，并盡快地滿足客戶的需求。之所以能做到持續(xù)交付，是因?yàn)檐浖褟漠a(chǎn)品銷售模式轉(zhuǎn)為服務(wù)模式—軟件即服務(wù)（Software as a Service，SaaS），不存在以前產(chǎn)品模式的銷售渠道，軟件版本的更新只要在自己數(shù)據(jù)中心的服務(wù)器上打個(gè)patch就可以了。這種SaaS模式使得持續(xù)交付成為可能，軟件能夠快速上線、用戶也能及時(shí)獲得更新的服務(wù)，因此缺陷能被快速修復(fù)，缺陷修復(fù)的成本極大降低，大大提高了人們對(duì)缺陷的容忍度，降低了對(duì)質(zhì)量的要求。但這可以大大降低測(cè)試的投入嗎？

特別是像Facebook這樣耀眼的公司，其實(shí)踐似乎在支持“無(wú)需建立獨(dú)立的測(cè)試團(tuán)隊(duì)”，讓開發(fā)人員來(lái)承擔(dān)越來(lái)越多的測(cè)試工作，甚至承擔(dān)全部測(cè)試工作。還有人提議將測(cè)試團(tuán)隊(duì)的一半成員拿出來(lái)做開發(fā)，這樣可以解決以前單元測(cè)試不足的問題。而測(cè)試團(tuán)隊(duì)的另一半被抽調(diào)到客戶服務(wù)（Customer Care）團(tuán)隊(duì)中，負(fù)責(zé)需求前期調(diào)查和后期技術(shù)支持，在需求上加大投入，幫助建立軟件產(chǎn)品的客戶驗(yàn)收標(biāo)準(zhǔn)，讓開發(fā)人員基于驗(yàn)收標(biāo)準(zhǔn)完成軟件系統(tǒng)的設(shè)計(jì)和編程，從源頭上提高質(zhì)量，而且后期技術(shù)支持也得到了加強(qiáng)。

專業(yè)測(cè)試團(tuán)隊(duì)要不要？

一系列新的實(shí)踐似乎在加劇質(zhì)疑“專業(yè)測(cè)試團(tuán)隊(duì)的存在意義”。但在傳統(tǒng)軟件測(cè)試?yán)砟钪校瑒t強(qiáng)調(diào)測(cè)試的獨(dú)立性和專業(yè)性，專業(yè)性越強(qiáng)，越需要全職人員。這些實(shí)踐在傳統(tǒng)產(chǎn)業(yè)的質(zhì)管理實(shí)踐中已得到充分的驗(yàn)證。傳統(tǒng)產(chǎn)業(yè)的質(zhì)檢部門是獨(dú)立的，質(zhì)檢人員也是全職的。如果不管三七二十一，將測(cè)試團(tuán)隊(duì)拆分掉，會(huì)不會(huì)帶來(lái)新的問題？比如：

究竟要不要專業(yè)的測(cè)試團(tuán)隊(duì)？
軟件測(cè)試由誰(shuí)來(lái)做更有效？
專業(yè)的測(cè)試團(tuán)隊(duì)未來(lái)的路會(huì)是怎樣？

這一系列新的問題開始困擾業(yè)界，因此我們有必要進(jìn)行充分的討論，澄清這些問題。即使不能給出令每個(gè)人都信服的答案，也要幫助測(cè)試人員獲得更客觀、更理性的認(rèn)識(shí)。

從軟件測(cè)試本質(zhì)來(lái)看，測(cè)試就是對(duì)軟件產(chǎn)品（包括階段性產(chǎn)品）質(zhì)量進(jìn)行全面地評(píng)估，以了解產(chǎn)品質(zhì)量當(dāng)前的狀態(tài)，從而為項(xiàng)目管理和決策提供客觀的依據(jù)。在這過程中，發(fā)現(xiàn)缺陷、暴露產(chǎn)品質(zhì)量風(fēng)險(xiǎn)等，都可以看作軟件測(cè)試的副產(chǎn)品。只是因?yàn)槿狈刹僮鞯�、具體的質(zhì)量標(biāo)準(zhǔn)，所以目前沒有能力和手段對(duì)軟件產(chǎn)品做到100%的客觀評(píng)價(jià)，也很難通過工具對(duì)軟件產(chǎn)品直接進(jìn)行質(zhì)量指標(biāo)的逐項(xiàng)驗(yàn)證而給出“質(zhì)量檢驗(yàn)通過”或“質(zhì)量檢驗(yàn)不通過”的結(jié)論。而且，軟件質(zhì)量整體都比較差，人們也很難通過一次性的測(cè)試完成軟件產(chǎn)品的質(zhì)量評(píng)估，而是要進(jìn)行持續(xù)測(cè)試或多輪的測(cè)試，其結(jié)果弱化了“全面評(píng)估軟件質(zhì)量”的作用，而強(qiáng)調(diào)軟件測(cè)試是努力發(fā)現(xiàn)軟件產(chǎn)品缺陷、暴露質(zhì)量風(fēng)險(xiǎn)、不斷提供質(zhì)量反饋的過程。

如果讓構(gòu)建軟件產(chǎn)品的開發(fā)人員來(lái)評(píng)價(jià)自己的產(chǎn)品，那么測(cè)試結(jié)果具有說服力嗎？暫且不說，王婆賣瓜，自賣自夸的嫌疑。從心理學(xué)角度分析，要發(fā)現(xiàn)自己的問題、否定自己的實(shí)現(xiàn)，需要克服心理上很大的障礙，這實(shí)際上是很不容易的。更何況人天生有惰性，希望某一個(gè)團(tuán)隊(duì)把事情從頭到尾做好，完全依賴每個(gè)成員高度的責(zé)任感和主動(dòng)性，這是不現(xiàn)實(shí)的。監(jiān)督機(jī)制不可缺失，正如建筑需要監(jiān)理、警察還有督察等，獨(dú)立測(cè)試缺失，質(zhì)量難以保障。在敏捷Scrum開發(fā)模型中（如圖1所示），開發(fā)和測(cè)試在持續(xù)構(gòu)建和持續(xù)測(cè)試之后，也依舊要設(shè)立一個(gè)獨(dú)立的驗(yàn)收測(cè)試階段，其實(shí)就是對(duì)獨(dú)立測(cè)試的一種訴求。

圖1 敏捷Scrum開發(fā)模型示意圖

基本上，大家已達(dá)成共識(shí)：?jiǎn)卧獪y(cè)試、集成測(cè)試一般由開發(fā)人員做效率更高些，而系統(tǒng)測(cè)試和驗(yàn)收測(cè)試由測(cè)試人員做比較好。為什么會(huì)有這樣的共識(shí)呢？

如果開發(fā)人員先實(shí)現(xiàn)再測(cè)試，其測(cè)試的思路一定會(huì)受到實(shí)現(xiàn)的影響，不能達(dá)到良好的測(cè)試效果。如果先設(shè)計(jì)測(cè)試再實(shí)現(xiàn)產(chǎn)品，即采用TDD開發(fā)軟件，讓測(cè)試在先而不受實(shí)現(xiàn)的影響，效果會(huì)不錯(cuò)。但問題是有多少開發(fā)團(tuán)隊(duì)能夠真正做到TDD？而且TDD對(duì)需求有更高的要求，軟件產(chǎn)品質(zhì)量的驗(yàn)收標(biāo)準(zhǔn)事先需要被明確定義，然后才能做到先開發(fā)測(cè)試腳本，后開發(fā)產(chǎn)品代碼。而現(xiàn)實(shí)的需求又很難做到這點(diǎn)。

軟件質(zhì)量就是客戶滿意度。從這個(gè)角度看，測(cè)試工作更重要的任務(wù)是要在系統(tǒng)層面驗(yàn)證是否能夠全面滿足業(yè)務(wù)需求、是否真正滿足不同用戶的實(shí)際需求。而這樣的測(cè)試必須要等到系統(tǒng)建立起來(lái)之后才能進(jìn)行，如果這時(shí)讓開發(fā)人員來(lái)做測(cè)試，必然會(huì)受到之前實(shí)現(xiàn)思維慣性的影響，效果明顯降低。其次，每個(gè)開發(fā)人員通常只完成系統(tǒng)的很小一部分，對(duì)整體業(yè)務(wù)無(wú)法有效地把握，而且業(yè)務(wù)場(chǎng)景太多、繁雜，這時(shí)很考察測(cè)試人員的專業(yè)能力。只有站得高、看得遠(yuǎn)，完成業(yè)務(wù)端到端的測(cè)試，覆蓋各種業(yè)務(wù)場(chǎng)景，才能確保系統(tǒng)能夠正確、有效地實(shí)現(xiàn)整個(gè)業(yè)務(wù)流程。

如果開發(fā)人員知道某些地方很有可能存在缺陷，那么就會(huì)設(shè)法避免這些缺陷的產(chǎn)生。但往往開發(fā)人員并不知道自己會(huì)犯哪些錯(cuò)誤。而如果讓專業(yè)的測(cè)試人員從不同的角度、不同的思路來(lái)測(cè)試軟件，測(cè)試的效果會(huì)有效得多。

更何況測(cè)試本身具有很強(qiáng)的專業(yè)性，包括測(cè)試建模技術(shù)、測(cè)試方法及其工具的應(yīng)用，只有專業(yè)的測(cè)試人員才能很好掌握。

舉一個(gè)例子，僅僅是黑盒測(cè)試方法中一項(xiàng)具體的測(cè)試技術(shù)—因果分析法（cause-effect analysis），美國(guó)測(cè)試專家Richard Bender差不多用其一生的時(shí)間來(lái)研究它，才將這項(xiàng)技術(shù)做到極致。除系統(tǒng)的功能測(cè)試外，做好系統(tǒng)的性能測(cè)試、安全性測(cè)試等就更不容易，而且隨著軟件技術(shù)和應(yīng)用的不斷發(fā)展會(huì)不斷引發(fā)新的測(cè)試問題。因此，可以說這種專業(yè)的實(shí)踐和積累將是一項(xiàng)長(zhǎng)期的任務(wù)。

互聯(lián)網(wǎng)的多數(shù)應(yīng)用（如新浪微博、Facebook、Google搜索）屬于文化娛樂服務(wù)，受缺陷的影響非常有限。例如，新浪微博的Beta版能在線運(yùn)行長(zhǎng)達(dá)三年，但銀行業(yè)務(wù)系統(tǒng)Beta版在線運(yùn)行一天都不可能。在金融、國(guó)防、航天、通信、交通控制乃至龐大的制造業(yè)生產(chǎn)控制等領(lǐng)域，無(wú)不要求零缺陷的軟件產(chǎn)品，其獨(dú)立的專業(yè)測(cè)試更是不可缺少。最近幾年，各大銀行不僅建立了獨(dú)立的測(cè)試團(tuán)隊(duì)，而且測(cè)試團(tuán)隊(duì)還保持30%以上的發(fā)展速度。如果考慮云計(jì)算、物聯(lián)網(wǎng)等新技術(shù)的應(yīng)用，軟件系統(tǒng)的復(fù)雜性會(huì)非線性增長(zhǎng)，軟件缺陷造成的負(fù)面影響也不能同日而語(yǔ)，那么在這些領(lǐng)域加強(qiáng)測(cè)試也是必然的，對(duì)專業(yè)的測(cè)試團(tuán)隊(duì)的需求不但不降低，反而會(huì)增強(qiáng)。

軟件測(cè)試的未來(lái)

近幾年，敏捷測(cè)試、探索式測(cè)試、精益測(cè)試、基于模型的測(cè)試等越來(lái)越受到大家的關(guān)注�！盾浖䴗y(cè)試：經(jīng)驗(yàn)與教訓(xùn)》一書的作者Bret Pettichord在2003年將軟件測(cè)試歸為四大學(xué)派（School），四年后（2007年）又增加了一個(gè)敏捷測(cè)試學(xué)派，將軟件測(cè)試分為五個(gè)學(xué)派，如圖2所示。

圖2 軟件測(cè)試五大流派示意圖

分析學(xué)派（Analytic School）：認(rèn)為軟件是邏輯性的，將測(cè)試看作計(jì)算機(jī)科學(xué)和數(shù)學(xué)的一部分，結(jié)構(gòu)化測(cè)試、代碼覆蓋率就是其中一些典型的例子。他們認(rèn)為測(cè)試工作是技術(shù)性很強(qiáng)的工作，側(cè)重使用類似UML工具進(jìn)行分析和建模。
標(biāo)準(zhǔn)學(xué)派（Standard School）：從分析學(xué)派分支出來(lái)并得到IEEE的支持，把測(cè)試看作側(cè)重劣質(zhì)成本控制并具有可重復(fù)標(biāo)準(zhǔn)的、旨在衡量項(xiàng)目進(jìn)度的一項(xiàng)工作，測(cè)試是對(duì)產(chǎn)品需求的確認(rèn)，每個(gè)需求都需要得到驗(yàn)證。
質(zhì)量學(xué)派（Quality School）：軟件質(zhì)量需要規(guī)范，測(cè)試就是過程的質(zhì)量控制、揭示項(xiàng)目質(zhì)量風(fēng)險(xiǎn)的活動(dòng)，確定開發(fā)人員是否遵守規(guī)范，測(cè)試人員扮演產(chǎn)品質(zhì)量的守門員角色。
上下文驅(qū)動(dòng)學(xué)派（Context-Driven School）：認(rèn)為軟件是人創(chuàng)造的，測(cè)試所發(fā)現(xiàn)的每一個(gè)缺陷都和相關(guān)利益者（stakeholder）密切相關(guān)；認(rèn)為測(cè)試是一種有技巧的心理活動(dòng)；強(qiáng)調(diào)人的能動(dòng)性和啟發(fā)式測(cè)試思維。探索性測(cè)試就是其典型代表。
敏捷學(xué)派（Agile School）：認(rèn)為軟件就是持續(xù)不斷的對(duì)話，而測(cè)試就是驗(yàn)證開發(fā)工作是否完成，強(qiáng)調(diào)自動(dòng)化測(cè)試。TDD是其典型代表。
標(biāo)準(zhǔn)學(xué)派和質(zhì)量學(xué)派相對(duì)比較成熟，流程、過程規(guī)范等基本已建立，包括TPI、TMMi等比較成熟，雖然未來(lái)會(huì)有一些修改。而上下文驅(qū)動(dòng)是比較自然的思路，其他學(xué)派也或多或少也會(huì)從上下文去考慮，也存在融合的可能性。雖然分析學(xué)派和上下文驅(qū)動(dòng)學(xué)派、敏捷學(xué)派有一定對(duì)立關(guān)系，但它們相互之間又會(huì)有更多的交融，而且敏捷方法主要以實(shí)踐為基礎(chǔ)，敏捷測(cè)試不是原發(fā)性的，而是先有敏捷開發(fā)。然后人們被動(dòng)地尋求測(cè)試方法和技術(shù)來(lái)適應(yīng)敏捷開發(fā)。敏捷測(cè)試缺乏自己獨(dú)立的理論根基，更多地依賴于上下文驅(qū)動(dòng)學(xué)派的支持，包括探索式測(cè)試和自動(dòng)化測(cè)試。其中自動(dòng)化測(cè)試是敏捷測(cè)試主打的王牌，沒有自動(dòng)化測(cè)試就沒有敏捷測(cè)試，而自動(dòng)化測(cè)試和持續(xù)集成、持續(xù)測(cè)試也相當(dāng)吻合。

雖然互聯(lián)網(wǎng)的影響越來(lái)越大，但關(guān)鍵系統(tǒng)（如銀行業(yè)務(wù)、交通控制等系統(tǒng)）還依舊存在，關(guān)鍵系統(tǒng)會(huì)進(jìn)一步促進(jìn)軟件開發(fā)的各種建模技術(shù)的發(fā)展，其中也包括測(cè)試建模和形式化驗(yàn)證�；谀Ｐ偷臏y(cè)試也會(huì)促進(jìn)自動(dòng)化測(cè)試的發(fā)展，這兩者之間是相輔相成的。沒有測(cè)試建模的支持，自動(dòng)化測(cè)試靠完全模擬手工的操作方式來(lái)實(shí)現(xiàn)，其實(shí)現(xiàn)和維護(hù)代價(jià)將相當(dāng)大，使之投入產(chǎn)出比（ROI）總是不夠理想，阻礙自動(dòng)化測(cè)試的發(fā)展。當(dāng)自動(dòng)化測(cè)試能夠借助基于模型的測(cè)試，那么自動(dòng)化測(cè)試將事半功倍、如魚得水，ROI自然也會(huì)很高�；谀Ｐ偷臏y(cè)試，最終也需要工具的支持，例如Pairwise、因果分析法等。如果沒有工具支持，測(cè)試人員就會(huì)感覺很累而不愿應(yīng)用。

對(duì)軟件測(cè)試影響最大的因素是軟件發(fā)布模式和軟件開發(fā)技術(shù)。前面已詳細(xì)描述了軟件發(fā)布模式，在SaaS模式中可以持續(xù)發(fā)布敏捷測(cè)試、探索式測(cè)試受到更多的關(guān)注。同時(shí)，SaaS的發(fā)展促進(jìn)了各種基于云計(jì)算的服務(wù)模式誕生，軟件測(cè)試的云服務(wù)模式應(yīng)運(yùn)而生、快速發(fā)展起來(lái)。測(cè)試公有云提供公共的、開放的測(cè)試服務(wù)，像UTest、SOASTA、SauceLab和Testin等，可以完成手機(jī)應(yīng)用、Web應(yīng)用或其他應(yīng)用的功能測(cè)試、兼容性測(cè)試、配置測(cè)試和性能測(cè)試等。而測(cè)試私有云是某個(gè)企業(yè)為自己建立的云測(cè)試服務(wù)，將測(cè)試機(jī)器資源、測(cè)試工具等都放在云端，公司的各個(gè)團(tuán)隊(duì)都可以共享所有測(cè)試資源，完成從自動(dòng)分配資源、自動(dòng)部署到測(cè)試結(jié)果報(bào)告生成的測(cè)試過程，而且還能將測(cè)試流程、測(cè)試管理等固化在私有云內(nèi)。

在軟件開發(fā)技術(shù)方面，軟件開發(fā)框架、工具也對(duì)測(cè)試有直接影響。例如，對(duì)分層構(gòu)造軟件系統(tǒng)而言，軟件測(cè)試也可以采用分層的自動(dòng)化測(cè)試技術(shù)。但未來(lái)有什么革命性的軟件開發(fā)技術(shù)還難以預(yù)料，例如未來(lái)是否產(chǎn)生有效的開發(fā)技術(shù)能夠智能地自動(dòng)完成軟件設(shè)計(jì)和實(shí)現(xiàn)的驗(yàn)證。但可以肯定的是，未來(lái)依靠軟件生命周期的前期努力與創(chuàng)新構(gòu)造更高質(zhì)量的產(chǎn)品，依靠更好的單元測(cè)試技術(shù)充分實(shí)施代碼層的測(cè)試，讓“質(zhì)量是內(nèi)建的”落實(shí)到位，并借助API、UI等不同層次的自動(dòng)化測(cè)試來(lái)提高測(cè)試效率。這樣，軟件測(cè)試投入可以越來(lái)越少，專業(yè)的測(cè)試團(tuán)隊(duì)規(guī)�？梢圆粩嗫s小，還能保持同樣的軟件產(chǎn)品質(zhì)量水平。這樣，對(duì)軟件企業(yè)也是好事，企業(yè)質(zhì)量保障成本越低，企業(yè)獲益就越大。總之，軟件測(cè)試未來(lái)可能會(huì)形成兩個(gè)主流方向。

基于模型的自動(dòng)化測(cè)試：以傳統(tǒng)測(cè)試的分析學(xué)派為基礎(chǔ)，強(qiáng)調(diào)從需求分析開始，為需求或用戶行為構(gòu)建模型，然后基于模型自動(dòng)產(chǎn)生和執(zhí)行測(cè)試用例，它更適用于關(guān)鍵系統(tǒng)的驗(yàn)證。這對(duì)測(cè)試人員的技術(shù)能力有更高的要求，專業(yè)測(cè)試人員會(huì)越來(lái)越精干。如果有一天，測(cè)試團(tuán)隊(duì)的成員是從最優(yōu)秀的開發(fā)人員中挑選，測(cè)試人員只占整個(gè)研發(fā)團(tuán)隊(duì)的10%左右，軟件開發(fā)才到了真正成熟的時(shí)代。

基于云服務(wù)的測(cè)試模式：非關(guān)鍵系統(tǒng)在前期系統(tǒng)架構(gòu)設(shè)計(jì)和代碼實(shí)現(xiàn)上可借助良好的開發(fā)框架與工具、單元測(cè)試和持續(xù)集成等工作，在沒有專職測(cè)試團(tuán)隊(duì)的工作情況下，也能保證產(chǎn)品質(zhì)量處在一個(gè)基本可用的水平。然后，利用上述的公有云服務(wù)模式來(lái)完成更深度的測(cè)試，如可用性測(cè)試、配置測(cè)試、兼容性測(cè)試、性能測(cè)試都可以在云平臺(tái)上自動(dòng)完成。剩余的功能測(cè)試（包括業(yè)務(wù)流測(cè)試、場(chǎng)景測(cè)試等）就可以交給大眾，通過遠(yuǎn)程服務(wù)完成測(cè)試。這些測(cè)試人員可能是業(yè)余志愿者，也可能是在家工作的專業(yè)測(cè)試人員，按任務(wù)領(lǐng)取報(bào)酬。