如何評價接口自動化項目

我理想中的接口自動化項目，是有一套腳本，能夠100%覆蓋核心業(yè)務場景，能夠回歸線上頻繁出現(xiàn)的問題，能夠支持手工無法驗證的場景，能夠拋出偶現(xiàn)問題，能夠包含容易遺漏的邊界場景、異常場景，每天都能定時運行，出具報告，給予反饋。用實際的「指標量化」下：

• 功能測試自動化率 = 自動化測試用例數(shù)/總測試用例數(shù)。
• 自動化發(fā)現(xiàn)bug占比 = 自動化發(fā)現(xiàn)的bug/總bug數(shù)。
• 自動化發(fā)現(xiàn)bug有效性 = 自動化發(fā)現(xiàn)的有效bug/自動化提交的bug總數(shù)。
• 自動化執(zhí)行成功率 = 自動化執(zhí)行成功的次數(shù)/自動化執(zhí)行總次數(shù)。
• 周活躍自動化用例占比 = (∑每周執(zhí)行過的自動化測試用例)/(∑周維度自動化測試用例)。
• 應用維度自動化代碼覆蓋率 = 自動化用例覆蓋代碼行數(shù)/應用維度代碼總行數(shù)。

現(xiàn)狀是什么(Situation)

我負責的業(yè)務是發(fā)票中臺，數(shù)據流簡化后如下圖所示：

發(fā)票中臺對調用方提供RPC服務，底層有讀寫MySQL、同步ES、消息隊列、異步任務等服務，上游是用戶和訂單，需要賬號、增票資質、訂單等物料；下游是財務，推送申請單給財務開具發(fā)票等。發(fā)票的接口自動化在多年前是寫了的，用Java+TestNG+RPC本地化了一套框架來實現(xiàn)，因為人員離職和業(yè)務變更，這套自動化到我手上的時候，已經不能用了，本地化的接口自動化項目也無法做數(shù)據度量，只有接口測試平臺寫的自動化用例才會被統(tǒng)計到。

任務是什么(Task)

我給自己定的績效是在Q2完成95條自動化用例，按照一個標準化的自動化項目來實現(xiàn)發(fā)票的接口自動化，結合測試環(huán)境、測試物料、流水線、精準分析，打造一個個人的穩(wěn)定的沉淀物，無論是晉升還是求職，都能拿來講點故事。

行動是什么(Action)

「編寫自動化用例的方式」

• 最理想的方式，是能夠錄制線上流量直接轉換為自動化用例，修修改改即可。雖然我們有流量錄制回放平臺，但是它跟接口自動化平臺并沒有打通，很可惜不能采取這種方式。
• 參考線上流量日志，抓取接口、入參，人工轉化為自動化用例。
• 參考接口的代碼設計，比如controller/provider/sdk都定義了應用接口，能知道哪些覆蓋到了，哪些還需要補充。
• 根據入參模板自行構造參數(shù)。參數(shù)個數(shù)太多的話造起來很麻煩。我主要采用第2種和第3種方式結合來編寫自動化用例。

「典型自動化用例」

前置步驟：初始化數(shù)據，將訂單發(fā)票類型更新為3。預設變量：提供參數(shù)化數(shù)據。執(zhí)行步驟：調用修改訂單發(fā)票類型接口，將發(fā)票類型3改為2，入參引用預設變量。財務接口：依賴測試物料無法滿足，通過Mock來返回模板數(shù)據，讓接口繼續(xù)往下走?；A斷言：接口響應狀態(tài)碼200。業(yè)務斷言：調用訂單列表查詢接口，用JSONPath提取響應中的發(fā)票類型，斷言已經改成了2。

場景用例

數(shù)據準備：通過物料工具造訂單數(shù)據，寫入MySQL數(shù)據庫中。

更新MySQL數(shù)據：更新訂單的部分字段數(shù)據，觸發(fā)binlake，將數(shù)據同步至ES，因為提交開票申請是讀取的ES數(shù)據；從預設變量獲取orderId。

提交開票申請：從ES讀取訂單數(shù)據，提交開票申請；從預設變量獲取orderId和userId。

查詢申請單號：根據訂單號查詢申請單號；從預設變量獲取orderId和userId。用JSONPath提取申請單號，存入動態(tài)變量中。推送財務：把申請單號推送給財務；從動態(tài)變量獲取applyId。

覆蓋更多代碼

①看代碼：

在Java工程里面的Controller/Provider找到所有接口，分析可以用來做自動化的接口，設計自動化用例進行覆蓋。

②代碼覆蓋率：

借助于jacoco，在執(zhí)行自動化用例后，把代碼覆蓋率跑出來，分析沒覆蓋的代碼，補充更多「正常/異常/邊界」的自動化用例。也就是精準測試。

自動化巡檢

每天早上8點，定時任務執(zhí)行用例集；發(fā)送郵件，抄送測試組、開發(fā)組、領導，讓測試、開發(fā)和領導都知道自動化建設情況；如果出現(xiàn)問題，一定要在當天解決，并郵件回復問題原因；確保當天的自動化用例結果都是正確的；第二天接著繼續(xù)巡檢。

流水線

在持續(xù)集成中，引入自動化用例環(huán)節(jié)，把自動化用例跑通作為提測卡點，不通過可以駁回。

產出是什么(Result)

定性來看：「結合測試環(huán)境、測試物料、自動化、流水線、精準測試，完成了一個能對環(huán)境和業(yè)務進行穩(wěn)定性巡檢，能對研發(fā)提測進行質量門禁，能對應用進行代碼覆蓋率分析的接口自動化項目?！苟縼砜矗?/p>

• 功能測試自動化率 = 自動化測試用例數(shù)/總測試用例數(shù)「95/100=95%」。
• 自動化發(fā)現(xiàn)bug占比 = 自動化發(fā)現(xiàn)的bug/總bug數(shù)「2/53=3.7%」。
• 自動化發(fā)現(xiàn)bug有效性 = 自動化發(fā)現(xiàn)的有效bug/自動化提交的bug總數(shù)「2/2=100%」。
• 自動化執(zhí)行成功率 = 自動化執(zhí)行成功的次數(shù)/自動化執(zhí)行總次數(shù)「5396/5621=96%」。
• 周活躍自動化用例占比 = (∑每周執(zhí)行過的自動化測試用例)/(∑周維度自動化測試用例)「77%」。
• 應用維度自動化代碼覆蓋率 = 自動化用例覆蓋代碼行數(shù)/應用維度代碼總行數(shù)「39%」。

這個Q主要完成了核心流程和重要接口的自動化用例，還需要持續(xù)補充場景用例和異常/邊界的自動化用例。