@@@@@@@@@@@@@@@
# 路漫漫其修遠
最近接觸到了多接口串聯，接口串聯的技術會在其他帖子有說明，其核心技術點就是通過正則表達式和變量來實現接口的關聯。目前為止呢筆者用到的地方還只有一個，就是關於session保持的時候。但是看到很多資料都說測試過程中經常遇到b接口需要用a接口的返回數據，但是筆者到目前都沒怎么遇到過，思來想去，是筆者打開方式不對嗎？於是專門找了一塊流程上有前后關系的地方進行實踐，以下就詳細說說這次學習成果。
在本系統中有一個類似如下的業務場景：
業務場景：電商平台中，客戶退貨流程。客戶提出退貨申請-退貨申請發送至商家-商家處理退貨申請-客戶確認退貨成功
待測功能：查詢該用戶進行中的退貨進度
難點1：商家回復處理過程在商家平台
難點2：無法從上一接口的相應信息提取有用字段，提交申請返回就一個true，連id都沒有，等於接口沒辦法關聯，但是實際又是存在業務邏輯的前后關系
針對以上場景我設計了兩種測試方案：
- 方案1：單接口測試，數據寫死，固定測試數據，針對性設計不同的訂單數據，對基礎數據要求比較高
自動化流程：1先手動生成各類型，處於各階段的退貨訂單
2調用查詢退貨進度接口查詢對應客戶的退貨訂單，並斷言與步驟1生成的數據是否一致
優點：單個工作量小，接口獨立，穩定性高。
缺點：數據維護成本高，真實性差，每個接口都需要大量數據測試
- 方案2：接口關聯，模擬業務流程，通過接口控制數據的傳遞，只需要給出初始訂單數據，即可模擬出業務流程中的動態數據流。
自動化流程：1 調用新增退貨申請接口，新增退貨申請並發送商家
2 調用查詢退貨進度接口查詢步驟1生成的訂單，斷言是否查詢到步驟1生成的數據，是否處於對應進度（已提交）
3調用商家回復接口回復申請
4 調用查詢退貨進度接口查詢步驟1生成的訂單，斷言訂單是否正確（商家已處理）
5 調用用戶確認接口，確認退貨成功
6 調用查詢退貨進度接口查詢步驟1生成的訂單，斷言訂單是否正確（退貨完成，訂單關閉）
優點：真實性強，數據易於管理，更清晰更流程化
缺點：工作難度大，工作復雜，代碼維護成本高，穩定性差
總結
方案一偏向接口功能測試，測試接口對於不同數據的處理情況。方案二偏向業務流程測試，測試不同的業務流程中數據的變化及接口的處理情況，更真實模擬實際場景
筆者做完后發現，這不就有點像單元和集成的關系嘛。最終筆者選擇了方案一，因為筆者公司不止一個人，除了待測的查詢進行中訂單狀態接口外的其他接口並不在我負責范圍，所以我只需要針對我的接口進行針對性測試即可。其實選擇哪種測試方式並不重要，自動化的目標旨在降低測試成本，提高測試效率，適合自己的方式，就是最好的了。
--以上內容均為筆者原創，轉載請注明出處，如有不當歡迎指正