圍繞效率提升，測試可以做什麽？你腦海裏跳出來的，應該是“自動化”或者“敏捷”吧，沒錯，自動化和敏捷都可以幫助提升研發效率，但是並不是只要做了都有這個作用。

下面來看看測試支持效率提升的不同段位。

一段：提升測試效率。

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

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

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

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

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

那麽，為什麽不是自動化？大多數時候，我們是將原本手工執行的功能和DFX測試自動化執行，這種情況下自動化測試更多的是服務於質量，其目的是發現新特性對老特性產生的，不為人知的影響。如果新特性每次發布，都導致老特性發生意外的變化，進而導致測試不得不在每個版本都全面測試老特性，那麽這種自動化就是提升測試效率的。不過，這種情況比較少見，而且，如果真的發生這種情況，一定是產品架構設計出了問題，優化架構比實現自動化測試的優先級要高。

二段：提升開發效率，測試不再局限於測試活動本身。

測試幫助提升研發效率，最有效的手段是自動化和工具化，這兩個手段是實現TDD和缺陷快速定位的關鍵措施。

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

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

通過缺陷輔助定位工具，可以提高這部分工作的效率。在一個用例執行不通過的時候，工具自動采集缺陷定位所需的信息，如：系統產生的日誌和其他過程與結果記錄，產生變化的數據庫記錄，此用例執行覆蓋到的代碼。通過這些信息，可以在無需重現、無需跟蹤執行的情況下定位大部分的問題。當然，要實現這個目的，僅僅有工具是不夠的，還需要產品做一些日誌上的增強，例如在函數的入口和出口記錄函數的輸入、輸出參數。缺陷修改完成後，再用自動化用例進行驗證，就能夠對開發的缺陷定位產生積極影響。

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

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

三段：提升版本發布效率，測試服務於研發整體而不是某個環節的效率提升。

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

自動化是CI的基礎，而自動化及CI是持續交付的基礎。

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

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

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

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

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

四段：提升特×××付效率，測試不是依賴工具和自動化，而是依賴分析設計服務於效率提升。

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

基於需求的測試中，測試幫助研發團隊在需求實現方面少一次試錯。很多團隊認為自己是基於需求進行測試的，但實際上是基於“需求規格說明書”進行測試，後者依賴一份質量優良的文檔（標準是，內容完整且正確，研發各個環節都可以完全依據這份文檔開展工作，並最終得到正確的特性），但通常這個依賴條件不存在。

基於需求測試需要做到：

■改善需求質量。利用需求內容模型（5W1H）促進需求內容完整性的提升，利用測試對產品、業務的理解，通過靜態測試發現需求中的遺漏、矛盾、錯誤，從而改善需求，即測試設計輸入的質量。

■基於需求測試。根據需求進行單個操作、業務場景和端到端應用場景的測試。並在測試執行時，通過研發測試、邀請客戶和需求工程師參與體驗和演示等方式，在產品特性半成品上，利用形象的操作過程對抽象的分析進行驗證和糾錯。

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

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

敏捷是建立在研發的質量文化、產品的架構優化、測試的自動化水平之上的研發模式的演進，如果沒有這些基礎，僅僅依靠模式的改變是無法既提升效率，又維持質量穩定的。

圍繞效率提升，測試可以開展的工作遠不止上面提到的這些，也一定還有做到更高段位的團隊實踐（提升產品交付效率的DevOps），期待……

圍繞效率提升，測試可以做什麽？