編寫目的
1、為什么要寫這這塊內容
①記錄實踐過程，組內討論學習
②另外希望有朋友一起來討論，怎么可以針對不同的項目達到最佳實踐
談到接口自動化測試，印象里網上的教程，一般都是工具介紹、入門級介紹（有API文檔，入參個位數，出參完善易懂），給人的感覺都是泡杯茶，它就自己唰唰唰的測試完了，還有完善的測試報告，節省了好多人力。
以前也有做過簡單的項目，emmmmm，確實容易。這次負責的是大型的ERP項目，人手少，業務復雜，一開始真的無從入手。
先說明下項目業務，業務中業務鏈很長（長的一條鏈路中走的接口上百），業務鏈分支多。
下圖為其中一個業務鏈的部分內容：
手工測試中有兩個主要痛點：
1、前置數據構造繁瑣：如上圖，假如需要測試收款單，則需要准備前置數據訂單->計划->賬單，花費14分鍾（這里的時間指的是無腦構造，實際中一般都會大於）准備，然后才開始正式測試。
2、業務表單復雜，分支多：如訂單，字段數超過150+，其中的一些字段是嵌套的json（服務明細）；然后訂單的類別超過120+，還有各種不同的計費方式等，即case數極多，修改其中一個場景，需要回歸的case量很大。
因此自動化的方案上考慮分成兩塊，1、2兩塊互相補充：
1、自動化測試：這塊主要在自動化測試環境執行，做回歸測試，執行前獲取mysqlbinlog的節點，執行后還原至該節點；
2、自動構造數據：這塊主要用於手工測試環境准備各個節點數據，減少前置數據構造時間，每個節點都會不停構造可用數據，設置闕值為10，小於10時自動新增該節點數據。
其中的難點在於
數據：
接口用數據：每個接口case量很多，每個case的data構造耗時都很多，工作量極大極大。這里考慮與手工測試相結合，各個接口封裝對應的從DB獲取數據，生成api用data（可跨環境獲取）的方法：其中數據分成sourcedata（來源數據，一般來源於手工測試后存儲在DB的數據）+prefixdata（前置數據，比如訂單提交審批，會用到草稿的訂單的ID等）-->處理后的數據processeddata-->映射成apidata。每次同一場景新增case，只需要添加用例名+數據主鍵。
前置數據：
①常見方案一：在用例prepare部分，調用前置的接口來新增數據，這種方案在業務鏈較短的業務中適用，長業務鏈的話會導致用例執行速度很慢，且穩定性較低。
②常見方案二：先人工准備好各個用例的前置數據（也可以用前置接口的腳本來生成），每次執行完自動化腳本后，回滾數據庫，則可以反復使用。如果只是做自動化測試，那么這種方案就可以了。
③方案三：因為考慮要減少手工測試構造數據時間，因此在手工測試環境，不能還原數據庫，數據每次被使用就消耗了。這里考慮每個節點的腳本執行完，把場景+數據主鍵+其他信息存入數據池，狀態為可用。手工測試通過數據平台查詢數據，被查詢的數據狀態置為不可用。每個節點的可用數據小於設定的闕值時，腳本自動執行新增該節點數據。
項目里方案二、三結合使用。