前面兩篇筆記我介紹了自動化測試前期調研注意事項和前置準備階段切入點，有同學在後臺提問：
“做完前期的調研和準備工作，領導要求寫一個落地方案並評審，自動化測試的落地方案該怎麼寫”？
首先這個要求我覺得挺正常，一方面評審可以查漏補缺完善細節，另一方面也可以考察具體的落地經驗和能力。
其次，我認爲技術方案其實有個通用的模版，或者說抽象的經驗參考，這也是本篇文章我想聊的話題。
結合個人的工作實踐和思考，我認爲構成一個技術方案，有如下五點要素：
- 背景現狀：當前的業務、技術表現，遇到了什麼問題；
- 痛點挑戰：這些問題對業務和技術帶來了哪些痛點，要解決痛點面臨哪些挑戰；
- 落地方案：爲了解決上述的痛點和挑戰，打算從哪些方面用什麼手段在什麼時間來解決；
- 產出價值：產出是什麼，從哪些維度衡量產出，用哪些指標評估問題的解決程度和創造的價值；
- 總體規劃：整體規劃是什麼，短中長期里程碑是什麼，要投入哪些資源，需要誰協同配合，對業務和團隊價值；
下面的內容，我會從上述五點要素來展開說明。
闡述背景現狀
首先，在編寫技術方案的時候，第一也是最重要的一點，一定要闡述清楚項目背景或當前現狀。
我發現很多同學有所謂的技術偏執，遇到問題第一反應是解決問題，拿着錘子滿世界都是釘子。
但其實，我更建議在遇到問題時，首先應該考慮如下幾點：
- 當前問題是偶發問題還是頻發問題；
- 類似的問題在其他團隊/場景是否存在；
- 除了方案A，有沒有方案B或者方案C來解決問題；
- 如果不做該方案，當前問題造成的損失是否可以接受；
這樣思考問題的好處在於：
- 避免陷入技術陷阱，在低層次掙扎；
- 找到更高維度的解決方案，解決更大更多的問題；
- 降低重複解決低級問題而帶來的資源浪費和精力分散；
那如果要落地自動化測試，背景或者說現狀怎麼寫呢？可以參考如下例子：
- 業務範圍大，業務場景複雜，每次發版要回歸的case太多；
- 業務趨於穩定，但測試時間較少，可能無法發現更多更細節的問題；
- 迭代週期比較快，測試人力資源不足，迴歸測試無法覆蓋更多的場景；
如上例子僅供參考，闡述背景的原因在於體現當前面臨的問題，以便引出後續的解決方案，這是有的放矢。
列舉痛點挑戰
上面列舉了三條當前現狀的例子，從中可以發現，當前的現狀帶來了哪些痛點和挑戰。總結如下：
- 測試case比較多，迴歸耗時（時間）；
- 業務穩定但測試時間不足，容易漏側（質量）；
- 測試人力資源不足，會導致測試時間變長或加班趕工（成本）；
還記得之前我在軟件工程的文章中提到的質量三要素嗎？他們分別是時間+範圍+成本。
當然，日常工作中還有可能有其他痛點，比如測試用例中很多前置動作都是重複性場景，比如日常測試效率不高需要提高測試過程效率，再比如測試團隊的技術建設等原因。
列舉痛點和挑戰的目的在於，即承接了上面的現狀和問題，又可以爲後續的技術方案鋪路，整體邏輯要清晰合理。
說明落地方案
闡述了現狀背景，列舉了痛點挑戰後，接下來就是要說明通過什麼方式來解決這些問題，這就是落地方案。
一般在編寫技術方案時，我個人的經驗是如下幾點必須重點說明：
- 技術方案針對的需求或業務範圍（比如核心業務，核心服務，高頻流程）；
- 技術方案的選型、對比結果和demo效果是否適合當前的團隊（成熟穩定的工具+活躍的生態&豐富的文檔+簡單的上手難度+較低的維護和二次開發成本）；
- 方案落地所需要投入的資源（人力+時間+購買的資源）、需要哪些團隊&人協同配合（溝通協作管理成本）；
- 方案落地有哪些關鍵節點&里程碑（落地步驟1-2-3-4-5，分別在什麼時候達成什麼效果解決什麼問題）；
- 不同里程碑階段，用哪些指標度量評估問題得到了解決，項目達到了預期效果；
技術方案編寫完成後，一定要拉上領導和相關同學以及配合方進行評審。一方面是查漏補缺，另一方面也體現出自己的專業能力，當然有的時候最好能和協作團隊達成利益一致，這樣可以獲得更好的支持配合。
羅列產出價值
具體的落地方案評審結束，接下來就要重點聊聊項目產出和價值了。
產出決定了你的工作量，價值決定了你的KPI和年終績效，因此這點還是很有必要重點說明的。
當然，衡量產出和價值，一定需要具體的可量化的指標，否則無法量化的東西無法談價值。
以自動化測試爲例，我個人的觀點是基於實際的目的出發來制定度量指標。舉例：
|
自動化測試目的 |
細分類型 |
度量指標 |
如何度量 |
|
效率 |
造數據效率 |
|
和手動造數耗時對比 |
|
冒煙測試效率 |
冒煙執行耗時 |
和手動冒煙測試耗時對比 |
|
|
線上迴歸效率 |
迴歸執行耗時 |
和手動迴歸測試耗時對比 |
|
|
覆蓋率 |
接口覆蓋率 |
|
梳理核心接口，投入最多資源精力 |
|
用例覆蓋率 |
|
梳理核心case，投入最多資源精力 |
|
|
業務場景覆蓋率 |
|
根據業務場景，case by case度量 |
|
|
過程質量 |
構建執行成功率 |
自動化任務執行成功率 |
低於某個閾值判定腳本質量不通過 |
|
用例執行通過率 |
自動化case執行成功率 |
低於某個閾值判定提測質量不通過 |
制定度量指標時，建議遵循如下幾點：
- 切忌面向指標/面向KPI做度量；
- 考慮到冗餘成本，指標不宜過多；
- 制定指標是爲了提升質量，而非做數據；
- 根據做自動化測試的目的來制定度量指標；
- 度量指標對比應該以是否解決了痛點爲依據；
- 度量指標是輔助評估依據，並不是唯一正確的結果；
- 制定指標應考慮到哪些指標更實際有效，從解決問題角度出發；
- 度量指標不要單一的評估，應結合多個維度來綜合評估開展質量度量；
概括總體規劃
聊完產出和價值，方案基本就算完成了，但爲了錦上添花，大家可以考慮闡述自己對於項目的總體規劃和構思。比如：
- 當前現狀是A；
- 第一階段要達成B效果，解決C問題；
- 未來半年要達到D效果，這樣做的好處的E；
- 長期來看，遮掩做對業務和技術團隊的價值是F；
有句話我覺得說的挺對的，惠而不費的話要多說&事要多做。
關於自動化的技術筆記，到這裏就整理完了。後續我會更新關於性能測試的一些技術筆記，大家敬請期待。