就按上面寫

截取一段：

測試奇譚：什麼是介面測試？這篇文章讓你明白?

zhuanlan.zhihu.com圖標

但是做介面測試，你還得考慮其他場景：

01 入參出參

你是否發現我上面貼圖中的一個細節？

插頭請求時，說了一句"我需要美標"，插孔回應"我是美標介面"。

像不像打仗的暗號——「土豆土豆，呼叫紅薯」，「我是紅薯，土豆請講」。

因此，你需要這樣設計你的用例，

步驟：A用戶（未註冊），假扮自己是已註冊用戶（修改入參），請求註銷介面。期望：失敗，給出合理提示
————————
步驟：A用戶（已註冊），請求註銷介面，系統告訴A註銷失敗（修改出參）。期望：給出合理提示

02 介面安全

即，不能像上一個場景，隨意讓用戶修改入參請求，要保障業務和系統的安全、保障數據的正確。

一般來說，使用https請求+驗簽機制（驗證碼、sign、時間戳、Token等），可以規避這個問題。

步驟：拿亂寫的入參請求註冊介面。 期望：失敗，給出合理提示
————————
步驟：拿亂寫的入參請求註銷介面。 期望：失敗，給出合理提示

03 請求超時場景

即，請求介面，一直沒有拿到介面的結果。

步驟：網路不好的情況，A用戶（未註冊），請求註冊介面。期望：超時，給出合理提示
————————
步驟：網路不好的情況，A用戶（已註冊），請求註銷介面。 期望：超時，給出合理提示

04 後端服務異常場景

即，介面後面的服務無法正常使用。

步驟：資料庫無法使用的情況，A用戶（未註冊），請求註冊介面。期望：失敗，給出合理提示
————————
步驟：資料庫無法使用的情況，A用戶（已註冊），請求註銷介面。 期望：失敗，給出合理提示

05 並發場景

類似於性能測試。

步驟：多個用戶（未註冊），同時請求註冊介面。期望：都能成功
————————
步驟：多個用戶（已註冊），同時請求註銷介面。 期望：都能成功

上面的內容，我只是做了一個引子，引導你去考慮這些場景。當然，實際工作中要考慮的，遠不止這一些，還有分散式場景下的非同步、同步任務問題，冪等問題，介面兼容問題，降級問題等等。

太多了……

但是，你也別害怕，這些場景是根據你實際工作情況來的。

比如，分散式場景下的同步、非同步等，在金融領域使用較多，需要對此精通的介面測試工程師，如果你不在這個行業，了解它即可，沒必要深究。

問同事要個模板，讓他給你講一下業務，一下就懂

謝邀，測試用例可以用來衡量一個項目的測試質量，測試工程師需要熟練掌握測試用例的編寫技巧，儘可能覆蓋任何異常的測試點。主要功能模塊測試的測試用例設計方法包括：等價類劃分、邊界值分析、錯誤推測法、因果圖和判定表、場景法、正交實驗法，這些方法的具體應用請參考下文：

行者AI：功能測試用例設計方法分享?

zhuanlan.zhihu.com圖標編輯於 01-20繼續瀏覽內容知乎發現更大的世界打開Chrome繼續測試小盒測試小盒一個喜歡動漫的小測試

入職後可以和同事要個模板，或者直接參考同事寫過的測試用例樣式，內容的話，你需要先看下公司業務和你負責的模塊需求，然後通過你學習到的一些設計測試用例的方法，然後開始編寫測試用例的方法。我最近在做總結，關於用例的設計方法在我的文章中有寫了一些，可以做下參考。

入職後可以和同事要個模板，或者直接參考同事寫過的測試用例樣式，內容的話，你需要先看下公司業務和你負責的模塊需求，然後通過你學習到的一些設計測試用例的方法，然後開始編寫測試用例的方法。我最近在做總結，關於用例的設計方法在我的文章中有寫了一些，可以做下參考。

功能測試用例編寫方法業界有以下幾類：等價類、邊界值、錯誤推斷、因果圖、判定表等。可以百度搜索一下，網上挺多案例的。剛開始可以依葫蘆畫瓢，帶著方法從模仿開始。

介面測試用例編寫重點在介面返回的斷言設置（即期望值和實際值的比對），一般返回從以下幾個點考慮：

1、返回碼斷言（必要要求、基本）

2、返回內容斷言，斷言返回業務重點代表欄位key （期望要求，最好）

3、所查即所增，如果是一個新增介面，最好從資料庫把數據查詢出來就行斷言。這樣能準確的的判斷出資料庫的處理是ok的避免介面返回處理正常實際數據落庫有問題的情況（推薦要求，更好）

最後說下，不管是功能測試用例還是介面測試用例，都免不了一個測試用例的基本結構。一個完整的用例結構包括：前置條件，測試步驟，期望結果和後置步驟。希望在寫用例的時候，保證結構完整，並應用各種用例設計方法，寫出簡潔高效高質量的用例！

實在是用語言不知道該怎麼描述，不過這張圖可以看看

推薦閱讀：
相关文章