# 路漫漫其修遠
最近接觸到了多介面串聯，介面串聯的技術會在其他帖子有說明，其核心技術點就是通過正規表示式和變數來實現介面的關聯。目前為止呢筆者用到的地方還只有乙個，就是關於session保持的時候。但是看到很多資料都說測試過程中經常遇到b介面需要用a介面的返回資料，但是筆者到目前都沒怎麼遇到過，思來想去，是筆者開啟方式不對嗎？於是專門找了一塊流程上有前後關係的地方進行實踐，以下就詳細說說這次學習成果。
在本系統中有乙個類似如下的業務場景：
業務場景：電商平台中，客戶退貨流程。客戶提出退貨申請-退貨申請傳送至商家-商家處理退貨申請-客戶確認退貨成功
待測功能：查詢該使用者進行中的退貨進度
難點1：商家回覆處理過程在商家平台
難點2：無法從上一介面的相應資訊提取有用字段，提交申請返回就乙個true，連id都沒有，等於介面沒辦法關聯，但是實際又是存在業務邏輯的前後關係
針對以上場景我設計了兩種測試方案：
自動化流程：1先手動生成各型別，處於各階段的退貨訂單
2呼叫查詢退貨進度介面查詢對應客戶的退貨訂單，並斷言與步驟1生成的資料是否一致
優點：單個工作量小，介面獨立，穩定性高。
缺點：資料維護成本高，真實性差，每個介面都需要大量資料測試
自動化流程：1 呼叫新增退貨申請介面，新增退貨申請並傳送商家
2 呼叫查詢退貨進度介面查詢步驟1生成的訂單，斷言是否查詢到步驟1生成的資料，是否處於對應進度（已提交）
3呼叫商家回覆介面回覆申請
4 呼叫查詢退貨進度介面查詢步驟1生成的訂單，斷言訂單是否正確（商家已處理）
5 呼叫使用者確認介面，確認退貨成功
6 呼叫查詢退貨進度介面查詢步驟1生成的訂單，斷言訂單是否正確（退貨完成，訂單關閉）
優點：真實性強，資料易於管理，更清晰更流程化
缺點：工作難度大，工作複雜，**維護成本高，穩定性差
總結
方案一偏向介面功能測試，測試介面對於不同資料的處理情況。方案二偏向業務流程測試，測試不同的業務流程中資料的變化及介面的處理情況，更真實模擬實際場景
筆者做完後發現，這不就有點像單元和整合的關係嘛。最終筆者選擇了方案一，因為筆者公司不止乙個人，除了待測的查詢進行中訂單狀態介面外的其他介面並不在我負責範圍，所以我只需要針對我的介面進行針對性測試即可。其實選擇哪種測試方式並不重要，自動化的目標旨在降低測試成本，提高測試效率，適合自己的方式，就是最好的了。
Jmeter介面測試
jmeter介面測試 簡單http介面測試及結果分析 介面測試主要分為兩類 層介面測試和web http介面測試，層介面測試更接近單元測試一些，而web介面主要表現為兩類 1 瀏覽器和伺服器之間的介面 2 外部介面 第三方提供的介面 1 開啟jmeter 2 新增相關元件 2.1 新建執行緒組 2....
jmeter介面測試
jmeter介面測試總結 此處的使用者定義變數作為公共的 此處有坑 如果token和http資訊頭管理器是同一級目錄，請求雖然傳送成功，但是有錯，如下圖 每個請求的token不一樣，所以token不能做成公共的 最後需要新增乙個檢視結果樹，就ok。4 最後細說請求裡面的內容 1 為請求的名稱 自己定...
jmeter介面測試
1 新建執行緒組 2 http請求頭相關 在 testplan下面進行新增，這樣的話，所有的http請求都可以共用 具體的http請求投，新增哪些，這個可以根據情況而定 3 公共變數管理 使用者自定義的變數 從指令碼中獲取的環境變數配置 4 新建http請求 把乙個介面的所有請求用例，都放到乙個 事...