概述
在創業公司裏，項目都比較趕，測試人員也是疲於測試功能模塊，基本沒空去寫什麼自動化測試，以提升迴歸測試的效率。但一個必須承認的事實便是，依賴測試人員去做全面迴歸測試，保證上線質量，是不可取的，因爲難度太大，成本太高。因此自動化測試還是要做一些的，具體如何着手呢，下文說一下我這邊的做法。
注意:本文主要描述一下業務接口自動化測試的方案，至於GUI自動化測試和壓力自動化測試不在本文的討論範圍內。
什麼是自動化測試
定義：把人對軟件的部分測試動作轉化爲由機器來執行。
自動化測試只能部分替代人工，不要指望所有業務場景都通過自動化case來驗證。
做自動化測試的動機
最大的動機：提升迴歸測試的效率。
爲了讓垂直拆分出去的微服務能獨立發展，不耦合太多不相關的業務邏輯，一般會有一些聚合的微服務應用，用於調用多個後端微服務，彙總數據後提供給前端。在創業公司裏，建議先做聚合服務的自動化自測，原因是：
聚合層是提供給小程序/APP/H5 等用的，聚合彙總了各種後端服務，針對其做自動化測試，可以用相對低的成本，儘量多的覆蓋業務case。至於針對後端的各個微服務接口做自動化的，實施起來代價比較大，有大量的代碼成本和維護成本，可以後續再考慮。
聚合服務也有很多業務接口，不可能都去寫對應的自動化測試代碼，建議先做主流程接口的自動化測試。比如一個電商的聚合層應用，像商詳、購物車、首頁、訂單結算頁、下單，可以先做。重要業務接口的自動化測試case，儘量做到多而全，爭取全面覆蓋。
數據創建的時機和手段
接口自動化測試中，第一個要解決的問題，就是測試數據的準備。
數據創建的時機
| 時機 | 描述 | 優點 | 缺點 |
|---|---|---|---|
| 即時創建 | 執行測試用例的時候，立刻創建測試數據，用例執行完後，刪除掉 | 不會有髒數據 | 1、會導致測試用例執行時間延長了; 2、環境不穩定的時候，無法創建數據; |
| 開箱即用 | 先提前創建好測試數據，執行測試用例的時候，直接使用，並將測試數據標記爲不可用（這個實施起來難度高）。 | 測試用例執行速度快 | 有髒數據，因爲提前創建好的數據，可能會被使用掉。 |
建議使用即時創建的方案是，原因如下：
- 自動化
case之間保證獨立性和相互不影響，實在太重要了，而即時創建數據就是保證這個的重要前提，且實施起來不難，雖然開箱即用 也能做到，但是代價太大，需要有專門的測試數據構建平臺，成本有些大； - 環境穩定性問題，可以通過時間戳開的方式，例如：晚上跑自動化測試。
- 如果後續自動化
case多了，即時創建的方式，會導致case執行時間長，可以通過並行執行的方式。對剛搞自動化測試的，需要執行的case的量也不大啦。
數據創建的手段
一般有三種：
- 調用後端服務
api創建數據； - 手寫
sql創建數據； - 組合1和2；
大部分情況下，使用第一種方式就行了，因爲造數據的後端接口，大部分都是有的。對於少部分沒有的，則手寫sql創建數據。
接口入參格式和返回值斷言
接口入參格式
測試團隊熟悉哪種就用哪種，excel或者json或者完全用代碼。
接口返回值斷言
同上，測試團隊熟悉哪種就用哪種，以excel爲例，期望的返回值也可以一併寫在excel裏，自動化case調用接口獲取到業務數據後，與excel中的期望值進行斷言操作即可。
編寫自動化case的語言
測試團隊熟悉哪個語言就用哪個，如果是Python那就最好了。
執行環境
- 將自動化測試代碼，部署到一個獨立的自動化測試機器上，使用
jenkin job執行自動化測試代碼； - 被測試的目標應用，建議重新搭建一套。
test dashboard
case跑完後，需要生成測試覆蓋率報告和列出執行成功和失敗的case。
