星球裏有同學問了這樣一個問題：自動化測試開展了一段時間，現在需要給領導彙報成果，該怎麼彙報？表面看起來這是一個技術問題，實際上這是一個向上管理問題。
那麼該如何向領導彙報自動化測試創造的成果呢？我們不妨從它的源頭出發，思考這幾個問題：
- 爲什麼做自動化測試？
- 預期的目標和結果是什麼？
- 過程中解決了哪些問題和痛點？
想清楚做自動化測試的原因，能明確做自動化測試的預期目標和評估標準，解決了團隊面臨的實際問題，且最終的成果沒有偏離預期目標，也拿到了預期甚至超過預期的結果，那就是好的成果。
首先，爲什麼要做自動化測試？這個問題相信各位技術同學特別是測試同學心裏都很清楚：將人力從重複性工作中解放出來，提高單位的人效比。
一般來說一個長期迭代的項目，核心業務流程和關鍵分支，整體不會有太大的變化，如果每次版本迭代或更新都去手動執行相關的測試用例，從性價比來說肯定是不高的。
因此採用自動化執行的方式，將這些測試用例轉化爲機器執行，既可以提升測試用例的執行效率，也可以釋放測試同學的精力在更重要的事情上面，一舉兩得。
至於是選擇UI自動化測試還是接口自動化測試抑或單元自動化測試，就是具體問題具體分析的範疇。
其次，自動化測試好歹是一個軟件工程實踐，在落地之前肯定要明確預期的目標和度量評估標準，以便於在落地執行過程中不偏離目標，可以有效掌握工程整體的進度和實施效果。
預期目標其實很簡單，提升效率，怎麼算提升效率呢？要選擇一個對比對象，比如相比於做自動化測試之前，測試用例執行耗時縮小了多少。以一週一個版本迭代爲例，大體的研發測試節奏如下圖所示：
其中測試驗證(執行用例)大約佔整個測試過程的50%時間，且每個版本除了執行新增的測試用例，原有的主流程和核心分支用測試用佔比也不小。
以我的經驗來說，功能測試一般一天驗證120條左右的測試用例，強度就已經不低了。如果能將重複性的測試用例用機器執行，在一個版本迭代中，測試就可以節省幾個小時的執行用例時間，將精力放在用例設計、風險評估、工具開發和基礎設施優化方面。
當然，自動化測試落地實施自然不可能這麼簡單，要編寫和維護腳本，要解決測試數據有效性和測試環境穩定性等方面的問題，這是第三個問題要回答的內容。
第三個問題：自動化測試實施過程中解決了哪些問題和痛點？這個問題不僅是很現實的工程實踐要解決的問題，也是高頻的面試題。在自動化測試落地實踐過程中，一般要重點解決這幾個問題：
- 測試數據維護管理：用Excel、配置文件還是數據庫？造測試數據的能力能否爲研發聯調和自測賦能？
- 測試環境的穩定性：環境的穩定性極大的影響整體的測試效率和測試結果的準確性，但這是長期基礎設施建設範疇。
- 測試用例精準匹配：隨着業務的不斷迭代，測試用例沉澱了一大堆，但也會有失效的，可以通過測試用例集來解決。
解決了這些問題，纔算是自動化測試真的落地實踐，達到了預期目標並拿到了好的結果。
最後，回到最初的問題，該如何向領導彙報。
首先要明白的一點是，給領導彙報的內容，最終會由領導向更高層彙報，因此抓住重點內容，適度包裝很重要。其次自動化測試的內核還是提升效率，需要找到對比對象並且有明確的數據支撐成果。
最後，落地過程中解決了哪些影響效率和質量的問題，是否能爲團隊發展提供賦能也是需要考量的因素。
如果是我來做自動化測試成果的彙報，我會從這幾個維度來介紹：
1、相比於實施自動化測試之前，實施後的測試執行效率提升了X%；
2、測試用例有效覆蓋了P0/P1/P2場景佔X%，每版本人效提升了X%；
3、落地過程中識別了N個潛在風險，解決了X個影響質量和效率的問題；
4、實踐過程採用了新技術，提升了環境穩定性，爲後續X項目積累了經驗；
5、預期結果是X，在1-2-3階段各自達成的效果是Y，符合或者超過預期N%；
6、後續打算從XYN不同角度去優化，解決X問題，擴大覆蓋範圍，爲D團隊賦能；
其中1和2代表了提升效率，3和4代表了風險預防和技術視野以及技術體系建設，5是彙報給領導的成果和結論，6是未來規劃和賦能協作。