在大部分研發(fā)項目經(jīng)理心中，進度通常往往會放在第一位，其次是成本，最后是質(zhì)量，當然人員隊伍也最好要穩(wěn)定。天下武功，唯快不破：進度 > 成本 > 質(zhì)量 > 人。

這個說法并不是絕對，當然今天我們并不是討論他們之間的優(yōu)先順序。而是圍繞效率提升，測試可以做什么？

相信大部分測試人員腦海里首先會跳出來：“自動化測試”或者“敏捷測試”，沒錯，自動化和敏捷都可以幫助提升研發(fā)效率，但是并不是只要做了就都有這個提升作用。

測試效率提升有以下幾個不同段位：

1、提升測試效率

提升測試的效率，最有效的手段是制定測試策略。對，你沒有看錯，是測試策略而不是自動化！

測試策略提升測試效率的邏輯是：減少不必要的測試，重要的問題早發(fā)現(xiàn)早解決。

測試策略的基礎(chǔ)是風(fēng)險評估，首先從失效概率、失效影響這兩個維度，區(qū)分高、中、低風(fēng)險的特性，失效概率是發(fā)生錯誤的可能性，評分一般是依據(jù)：同類特性的歷史表現(xiàn)，設(shè)計中需要考慮的要素多寡，需求變更的頻繁程度，是否采用新方法等。失效影響是錯誤發(fā)生造成的影響，評分的一般是參考：錯誤失效對主要業(yè)務(wù)流程的影響范圍，給研發(fā)團隊以及客戶帶來的直接經(jīng)濟損失，修復(fù)成本，信譽影響等。這兩個風(fēng)險維度的評分雖然有一些參考維度，但主要是依賴經(jīng)驗。

風(fēng)險評估完成后，根據(jù)每個測試內(nèi)容的風(fēng)險評分，確定測試的時間和強度（測試強度通常是用千行代碼用例數(shù)來衡量）。原則上高風(fēng)險的內(nèi)容要盡可能早測試，低風(fēng)險的內(nèi)容在計劃安排上靈活性可以大一些。高風(fēng)險的內(nèi)容要多測試，比如考慮多種測試設(shè)計方法同時使用，安排探索式測試等。測試的過程中，需要持續(xù)的分析缺陷數(shù)據(jù)、指標數(shù)據(jù)，以確定風(fēng)險是降低還是升高了，如果發(fā)現(xiàn)風(fēng)險升高，甚至已經(jīng)成為會阻礙產(chǎn)品發(fā)布的問題，則必須進行例外報告，調(diào)整開發(fā)和測試策略。

提升測試的效率，基于需求的測試也是有效手段之一，基于需求進行測試設(shè)計的目的，是減少不必要的參數(shù)組合和虛構(gòu)的應(yīng)用場景的測試用例。當然，只基于需求進行測試，往往不那么讓人放心，因為總會有意外的情況發(fā)生，一般還需要再基于經(jīng)驗、基于錯誤猜測，或者基于在線應(yīng)用采集的應(yīng)用場景進行一些補充。對于特別重要的測試內(nèi)容，可能還需要基于設(shè)計進行更高強度的測試。

那么，為什么不是自動化？大多數(shù)時候，我們是將原本手工執(zhí)行的功能用自動化的方式來執(zhí)行，這種情況下自動化測試更多的是服務(wù)于質(zhì)量，其目的是發(fā)現(xiàn)新特性對老特性產(chǎn)生的，不為人知的影響。如果新特性每次發(fā)布，都導(dǎo)致老特性發(fā)生意外的變化，進而導(dǎo)致測試不得不在每個版本都全面測試老特性，那么這種自動化就是提升測試效率的。不過，這種情況比較少見，而且，如果真的發(fā)生這種情況，一定是產(chǎn)品架構(gòu)設(shè)計出了問題，優(yōu)化架構(gòu)比實現(xiàn)自動化測試的優(yōu)先級要高。

2、提升開發(fā)效率

測試活動不再局限于測試活本身，測試幫助提升研發(fā)效率，最有效的手段是自動化和工具化，這兩個手段是實現(xiàn)TDD和缺陷快速定位的關(guān)鍵措施。

TDD的作用，是用測試用例的形式表述需求或設(shè)計目標，從而確保codeing過程中，始終在做正確的事，在向主干中加入各種分支處理邏輯、或者進行各種修改時，不會破壞已經(jīng)正確的功能，讓開發(fā)可以放心的修改缺陷或者重構(gòu)代碼。在TDD實施中，測試的主要價值是提供趁手的工具，這個工具不僅要能夠驅(qū)動測試用例執(zhí)行，還要讓開發(fā)很方便的構(gòu)建測試用例及其執(zhí)行所需的條件。我們有些團隊在TDD實施的早期，把TDD用例編寫和調(diào)試的工作也交給測試完成，這種方式無法讓開發(fā)及時驗證自己的每一次改動，做不到及時的質(zhì)量反饋，也起不到TDD宣稱的那些作用，不建議采用。

缺陷快速定位為什么要拿出來講呢？因為，我們曾經(jīng)統(tǒng)計過開發(fā)的工作量，在實現(xiàn)階段，大概有1/3~1/2的開發(fā)工作量是耗費在缺陷的確認、重現(xiàn)、定位、修改、驗證，如果能加快這個過程，則開發(fā)效率會有大幅提升。

通過缺陷輔助定位工具，可以提高這部分工作的效率。在一個用例執(zhí)行不通過的時候，工具自動采集缺陷定位所需的信息，如：系統(tǒng)產(chǎn)生的日志和其他過程與結(jié)果記錄，產(chǎn)生變化的數(shù)據(jù)庫記錄，此用例執(zhí)行覆蓋到的代碼。通過這些信息，可以在無需重現(xiàn)、無需跟蹤執(zhí)行的情況下定位大部分的問題。當然，要實現(xiàn)這個目的，僅僅有工具是不夠的，還需要產(chǎn)品做一些日志上的增強，例如在函數(shù)的入口和出口記錄函數(shù)的輸入、輸出參數(shù)。缺陷修改完成后，再用自動化用例進行驗證，就能夠?qū)﹂_發(fā)的缺陷定位產(chǎn)生積極影響。

很多團隊中，開發(fā)會把測試提交的缺陷集中在某個時間去修改，也是為了壓縮處理缺陷的時間，但是這樣會導(dǎo)致質(zhì)量風(fēng)險在開發(fā)后期集中爆發(fā)，是不值得借鑒的方式。

提升代碼質(zhì)量，除了TDD和缺陷定位，還可以在環(huán)境準備、測試結(jié)果采集上，使用工具和自動化提升效率。

3、提升版本發(fā)布效率

測試服務(wù)于研發(fā)整體而不是某個環(huán)節(jié)的效率提升。

測試幫助提升版本發(fā)布的效率，主要方法是自動化和CI（持續(xù)集成）、持續(xù)交付。

自動化是CI的基礎(chǔ)，而自動化及CI是持續(xù)交付的基礎(chǔ)。

CI對自動化的要求，除了用測試用例進行自動化的產(chǎn)品驗證，還包括自動化的編譯、打包、部署、環(huán)境檢查等。

持續(xù)交付在一般CI的基礎(chǔ)上，通常還需要做到應(yīng)用場景的自動化驗證（通常是基于UI的自動化測試，用于冒煙測試）、常規(guī)性能的自動化驗證，不同環(huán)境的統(tǒng)一部署，以及按不同的策略發(fā)布。一般的組織中，持續(xù)交付主要還是用于向?qū)ｉT的測試團隊交付產(chǎn)品版本。某些互聯(lián)網(wǎng)公司能夠做到將持續(xù)交付用于生產(chǎn)環(huán)境，這種場景下，除了上述能力，還需要在產(chǎn)品上線初期進行自動化的異常偵測，看護系統(tǒng)和業(yè)務(wù)的正常運行，此外，還應(yīng)該有比較可靠的系統(tǒng)和數(shù)據(jù)回滾機制。在生產(chǎn)環(huán)境中，要使這個過程安全的走下來，驗證用例最好能比較完整的覆蓋基本功能和新增需求，也需要根據(jù)歷史問題不斷完善看護、偵測規(guī)則。

發(fā)布時對基本功能的覆蓋，除了傳統(tǒng)的人工編寫自動化用例的方式，利用在線運行抓取實際場景是更能讓測試適配產(chǎn)品更新節(jié)奏的方式。

理想情況下，CI可以做到每天（也可能是每周或者其他的周期）都能夠有一個質(zhì)量過關(guān)的版本為上線做好了準備。這是比較理想的情況，我沒有見到過真正這樣實施的團隊，在我們團隊中，CI更多的還是在開發(fā)過程中，檢查程序員的代碼質(zhì)量，起到的是質(zhì)量門檻的作用。

持續(xù)發(fā)布是研發(fā)整體的工程能力提升，需要的不僅是研發(fā)團隊的工具開發(fā)能力，還需要在過程管理、配置管理，甚至產(chǎn)品架構(gòu)、質(zhì)量文化等方面進行匹配。持續(xù)發(fā)布的實施，有專門的書籍做了詳細介紹。

4、提升特性交付效率

測試不是依賴工具和自動化，而是依賴分析設(shè)計服務(wù)于效率提升。

測試幫助提升特性 交付的效率，需要做到基于需求的測試，此外，敏捷也可以提升特性的交付效率。

基于需求的測試中，測試幫助研發(fā)團隊在需求實現(xiàn)方面少一次試錯。很多團隊認為自己是基于需求進行測試的，但實際上是基于“需求規(guī)格說明書”進行測試，后者依賴一份質(zhì)量優(yōu)良的文檔（標準是，內(nèi)容完整且正確，研發(fā)各個環(huán)節(jié)都可以完全依據(jù)這份文檔開展工作，并最終得到正確的特性），但通常這個依賴條件不存在。

基于需求測試需要做到：

改善需求質(zhì)量。利用需求內(nèi)容模型（5W1H）促進需求內(nèi)容完整性的提升，利用測試對產(chǎn)品、業(yè)務(wù)的理解，通過靜態(tài)測試發(fā)現(xiàn)需求中的遺漏、矛盾、錯誤，從而改善需求，即測試設(shè)計輸入的質(zhì)量。

基于需求測試。根據(jù)需求進行單個操作、業(yè)務(wù)場景和端到端應(yīng)用場景的測試。并在測試執(zhí)行時，通過研發(fā)測試、邀請客戶和需求工程師參與體驗和演示等方式，在產(chǎn)品特性半成品上，利用形象的操作過程對抽象的分析進行驗證和糾錯。

基于需求的測試除了要會使用上述方法，也比較依賴測試工程師的經(jīng)驗，因為實際應(yīng)用過程中，我們通常都是參照已經(jīng)成熟的特性，曾經(jīng)犯過的錯誤來進行查缺補漏。

敏捷提升交付效率的基本邏輯是實現(xiàn)按特性開發(fā)和交付。首先，應(yīng)對這種小步快跑的方式，測試需要及時實現(xiàn)對少量的新增和修改內(nèi)容進行測試，在最短的時間內(nèi)進行質(zhì)量反饋，這要求測試設(shè)計、測試執(zhí)行（自動化測試），甚至發(fā)布、部署都要能夠在迭代周期的時間窗內(nèi)完成。其次，按特性發(fā)布可以讓客戶盡可能快的看到和使用特性，以便更快的進行產(chǎn)品應(yīng)用層面的質(zhì)量反饋，因此，如果團隊按特性開發(fā)了，但是并不能按特性 交付，那么對于交付效率的提升還是只完成了一半。

敏捷是建立在研發(fā)的質(zhì)量文化、產(chǎn)品的架構(gòu)優(yōu)化、測試的自動化水平之上的研發(fā)模式的演進，如果沒有這些基礎(chǔ)，僅僅依靠模式的改變是無法既提升效率，又維持質(zhì)量穩(wěn)定的。

圍繞效率提升，測試可以開展的工作遠不止上面提到的這些，這些都有待我們持續(xù)地研究、探索和討論。。。