其實介面的設計主要用於業務資料的互動，所以一般來講都離不開業務場景。比如開發一個獲取產品資料的介面，一般與需要獲取產品列表或獲取產品詳細資訊的場景下進行使用。而測試用例則應該更側重於單介面的測試。以供其他開發人員進行相關資料呼叫做參考。

首先需要區分這裡的流程場景指的是業務流程場景，還是操作流程場景。

業務流程場景一般指的是系統業務流程，類似於辦公流程，具有強流程性。

針對業務流程場景，介面的自動化用例是需要進行場景化設計的，一般常使用關鍵字驅動的測試框架+python request模組。

借鑑關鍵字驅動測試思想，把介面請求傳送、響應校驗、響應內容返回（下一個介面依賴上一個介面返回），三部分封裝成"請求校驗"關鍵字。

同時再封裝"內容提取"關鍵字——提取介面響應體特定資料。這樣就可以獲取上一個介面返回中的特定資料作為下一個介面的輸入引數。

如此。任何業務場景都可以透過"請求校驗"關鍵字 + "內容提取"關鍵字 + "請求校驗"關鍵字 +…

操作流程場景一般指的是先使用哪個功能，再使用哪一個，沒有強制性的操作步驟規範，比如單一的查詢功能。

針對操作流程場景，則可以視情況，開展單一介面的自動化測試。現有的很多自動化框架、工具都適合此場景的自動化測試開發，在此不做介紹。

在實際的介面測試中，兩個都會有。深入來講一下，針對介面自動化測試中的一個可以提高執行效率的點。

假設有介面A, B1, B2。介面B2的入參依賴於介面B1的出參，典型場景比如B1為登入介面，登入成功以後，返回使用者的id，而介面B2需要使用該id去查詢一些資訊。介面A與B1、B2的功能無關。在實際的執行的介面測試中，我們可以按照相關程度將介面測試用例進行分組，比如例子中的A是一組，定為Group1，B1和B2為一組，定為Group2。這樣，我們可以多執行緒併發去執行介面自動化測試，同時保證Group2中B1先執行即可。