什么是EP英文簡稱“Engine Productivity”直譯：工程生產力，通俗點：提升研發生產力。我在第一篇中提到百度QA職責中有一部分是提升研發效率，而不僅是提升測試效率。這項職責不是一個日常工作中測試管理者刻意去強調的工作內容，而是因為QA角色的特點，在自己的日常工作中會參與產品的全流程研發環節，因此當發現流程中有可以提升效率的地方或是通過外部交流知道了可提升效率的技術后自發地去做的事。當然做好了自然會得到組織的認可，于是QA都有這個習慣會自發主動地去思考如何提升研發效率，除了幫QA提升工作效率，也幫產品開發者提升工作效率，幫產品經理提升工作效率，從而可以全流程的優化加快產品發布上市的速度。總體而言，QA主要通過各類自動化工程手段、研發流程的工程化改造、產品代碼可測試性改造、測試環境工程化改造等實現從開發階段、測試階段、版本發布階段三個領域同時進行研發效率提升的目標。
作為QA要提升研發效率最早也最容易想到的就是自動化一切提升測試效率，不僅是自動化回歸功能測試，自動化性能測試，自動化測試框架、還演進出自動化找代碼缺陷，自動化找出算法效果缺陷的數據集、自動化Code Review過程、自動化進行代碼級的掃描準入（valgrind、vitamin、errhunter）、自動化定位Crash位置新的自動化工程手段。例如：在我目前服務的某產品線，有個QA每周都會分析一些bug的缺陷根因，然后抽取出Code Review規則給另一個QA來自動化實現后再提供給開發同學使用，減少開發同學Code Review的時間提升工作效率。當我們在測試過程中觸發了crash，會有一個平臺自動在1-3分鐘內給出這個crash發生的代碼行，這個crash之前的代碼調用序列，大大減少了開發同學和QA分析原始log定位crash的時間成本，幫助開發同學快速定位和修復crash代碼。除了本地運行的回歸測試用例，質量部還提供了分布式并行測試平臺幫助各產品加快大量其他功能回歸測試任務執行的速度，縮短整體回歸測試時間，自動化功能回歸測試執行時間縮短為原來的幾十分之一，為產品更快發布又節省了研發周期。
QA對公司研發效率的提升不只是自動化一切，還有其他的工程手段諸如：進行可測試性改造、單元測試效率提升、測試環境搭建與仿真。
可測試性改造的目的既有減少產品缺陷的產生的效果也有減少測試實現成本、發現問題可快速定位的效果。因此一些百度的高階QA會和開發配合合作進行產品的可測試性改造以提升后期測試執行和開發定位問題的效率。首先：QA會給RD提供代碼可測試性的方法論和設計準備，降低代碼的圈復雜度，不但減少復雜邏輯引起的代碼問題、還更有利于降低單元測試開展的復雜度從而提升單元測試覆蓋率，預防軟件缺陷的產生，就減少了后期定位和修復bug的成本，提升產品整體生產效率。其次：為了幫助后續RD更好的定位問題，以及QA更容易開展系統測試，QA還會提出一些可測試性設計理念給RD，希望能融入到產品設計中。例如我今年搞的一個可測試性框架，不但實現了測試代碼不駐留產品代碼，QA通過在測試階段一鍵自動注入測試代碼到產品代碼中進行專項crash風險挖掘工作，而且挖掘出來的每個crash都是必現的，都能在1到5分鐘內復現，都能直接給出是哪一行代碼的發生的crash，是什么原因觸發的crash。這樣的可測試性改造不但大大提升了測試人員發現crash的效率和crash復現的效率，結合我們的crash自動分析平臺還提升了開發定位和修復crash的效率，開發人員定位的時間可以縮小到分鐘級。因此提升研發測試效率除了自動化一切，產品進行可測試性改造和設計也是減少bug定位和復現成本的重要EP手段之一。
在QA的EP支撐過程中，除了通過可測試性設計預防缺陷減少后期的研發成本消耗，在缺陷預防領域還大力支持RD更簡單更高效地開展單元測試降低單元測試實施的成本和難度，提升單元測試開展的效率。支持的主要手段有：提供更簡化使用的單元測試框架、單元測試的教練式輔導。
在日常的開發和測試工作中，無論開發人員還是測試人員都會相當比例的時間用在測試環境搭建、調試和環境問題的定位中，直接影響了研發工作效率。因此QA必須進行測試環境的EP工程改造，諸如：測試環境自動部署、測試環境仿真、開發測試模擬器的來降低相關的研發成本、加快測試工作速度和開發定位的效率。據我了解，幾乎所有產品測試團隊都實現了測試環境自動部署來提高研發工作效率，減少測試環境搭建和調試的成本。同時還通過測試環境仿真，讓產品實際運行環境中的變量成為可控的因子來減少環境問題的定位成本，提升QA和開發在環境問題上的定位效率。在移動APP的測試中有成本很低的測試仿真環境來模擬低質量的移動網絡，不但可仿真低質量網絡的丟包率、時延和低速這些特征，還能仿真真實移動網絡中手機被迫頻繁退出和接入網絡的效果（如坐地鐵或走動的場景）。通過仿真的移動網絡，我們不但可為用戶提供更高可用性的產品而且還大大縮短了戶外真正網絡環境引起的產品問題效果的定位時間。以前認為是環境問題無法復現的問題都可以實現分鐘級為單位快速復現，并根據仿真環境設置的參數快速定位產品問題根源。
在測試階段除了自動化測試、可測試性工具、測試環境搭建和仿真外。各測試團隊還積極結合產品特點開發一些測試輔助工具、進行測試設計模式和測試模式的改進，力求在不增加測試周期的條件下甚至減少測試周期的條件下可以盡早發現更多產品中存在的質量風險，提升測試效率。例如：2012年時很多產品組都積極應用探索測試方法，有些產品組在未增加測試時間和測試人力的情況下，通過應用探索測試方法新發現的bug數量占據總bug數量的30%以上，相比過去直接提升了40%以上的測試生產力。還有一些團隊在回歸測試范圍領域進行測試技術探索精準回歸測試，縮短回歸測試工作量，提升了測試團隊的工作效率。
以上內容是我在百度看到的比較普適性的在開發階段和測試階段提升工程效率的QA工程實踐，代表了百度成熟的應用，不代表全部。
下一篇文章計劃給大家分享百度QA在版本發布階段進行的EP工作實踐。
版權聲明：本文出自 架構師Jack 的51Testing軟件測試博客：http://www.51testing.com/?293557
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
相關鏈接：
《我眼中的百度QA》第一篇：百度QA的特點與核心價值
《我眼中的百度QA》第一篇：百度QA的特點與核心價值（下半部分）
《我眼中的百度QA》第二篇：百度用戶體驗提升的產品評測