一、接口測試測試用例

1. 某個用例的測試目的是什么

在進(jìn)行接口測試腳本的編寫前，我們應(yīng)該明確這批腳本的預(yù)期目標(biāo)在哪里，是為了驗證什么內(nèi)容。根據(jù)個人的經(jīng)驗，一般會把接口用例分成三類：

單接口驗證：以驗證接口參數(shù)、權(quán)限、返回值為主，保證接口“能用”，這類用例一般在接口設(shè)計定稿后，配合Mock服務(wù)就可以完成用例編寫；場景邏輯驗證：以用戶場景為基礎(chǔ)，驗證接口間的參數(shù)傳遞及業(yè)務(wù)流程能夠正常流轉(zhuǎn)，用例復(fù)雜度較高，需要非常熟悉業(yè)務(wù)與接口之間的關(guān)系。這是接口測試最核心的價值。異常驗證：主要驗證參數(shù)異常、邏輯異常等情況下，接口是否能處理并給出友好的錯誤信息。通常情況下，關(guān)注參數(shù)異常的場景會比較多，可以用等價類、邊界值等方式來處理。需要注意的是多關(guān)注下異常的返回信息是什么，信息是否明確，提示是否友好等等。

2. 接口信息的來源

當(dāng)我們明確好測試目標(biāo)后，再開始編寫測試用例，會有更針對性的去設(shè)計測試數(shù)據(jù)和接口組合。接下來的問題是什么呢？去哪里確認(rèn)你的接口信息是有效的？基本上有兩種路徑：

接口文檔：開發(fā)人員都不喜歡自己寫文檔，同時也很討厭別人不寫文檔。所以測試人員如何獲取一份真實有效的接口文檔是件比較麻煩的事。般團(tuán)隊內(nèi)都會有一個統(tǒng)一的接口文檔管理工具（如果沒有，就找開發(fā)多磨麿，讓他們弄個，并不難），我們需要關(guān)注接口文檔的有效性和及時性。現(xiàn)在也有很多的插件或者工具能夠幫助研發(fā)人員自動生成接口文檔，例如Swaager、apidoc等等。接口抓包：如果什么都沒有，那就自力更生，通過Fiddler之類的工具，通過抓包分析的方式來獲取接口，這類的場景如果較多的話，可以把Fiddler抓到的接口導(dǎo)出，然后寫個小程序，直接轉(zhuǎn)成接口平臺可以識別的腳本，效率會更高一些。

在獲取到接口信息后，需要與開發(fā)人員多交流，明確參數(shù)的意義及來源，以便我們針對性的做測試用例設(shè)計，這個環(huán)節(jié)不要過多的自己猜（很多測試人員經(jīng)常會自己猜想），直接找開發(fā)問就好了。在這個接段，還要梳理并區(qū)分接口的重要程度和優(yōu)先級。這樣就可以確認(rèn)哪些接口優(yōu)先設(shè)計用例，哪些接口可以先放放，在有限制的時間內(nèi)，做最大價值的事。

3. 一些基本原則

拿到接口后，明確了參數(shù)說明，結(jié)合測試目標(biāo)，我們就可以開始設(shè)計并編寫測試用例了。區(qū)別于功能測試用例，接口測試用例（腳本）一些原則需要注意：

自動化：好像是廢話，所有的用例應(yīng)該是非交互試，最常見的就是Token之類的生成，需自動處理好（我見過每次執(zhí)行用例前，需要自己手動生成Token再粘貼進(jìn)去的腳本，特別是分環(huán)境執(zhí)行的時候）。獨(dú)立性：每個用例應(yīng)該是獨(dú)立的，沒有依賴的。需要在一個用例里處理好前置條件，而不是多個用例相互依賴。可重復(fù)：用例測試可重復(fù)執(zhí)行，所以需要注意參數(shù)的生成方式。可持續(xù)性：如果代碼修改導(dǎo)致已有接口測試執(zhí)行失敗，必須修復(fù)代碼問題或者測試代碼邏輯。

延伸閱讀：

二、什么叫測試用例

測試用例（Test Case）是為某個測試目標(biāo)而編制的一組測試輸入、執(zhí)行步驟以及預(yù)期結(jié)果的集合，以便測試某 個程序的路徑或驗證軟件是否滿足某個特定需求 測試用例的概念包含以下幾個方面的特性： 1.目標(biāo)：測試用例的目的是為了達(dá)到一定目標(biāo) 2.作用：去驗證某個路徑或某個特定的需求 3.集合：表示測試用例由多個項組成：如輸入數(shù)據(jù)、步驟、預(yù)期結(jié)果等。