1 接口測試常見問題
（1）傳入參數處理不當，導致程序crash；
（2）類型溢出，導致數據讀出和寫入不一致；
（3）因對象權限未進行校驗，可以訪問其他用戶敏感信息；
（4）狀態處理不當，導致邏輯出現錯亂；
（5）邏輯校驗不完善，可利用漏洞獲取非正當利益等。
1、接口測試從狀態級別做起，做到最基本的覆蓋
1、1xx: 信息
100 Continue 服務器僅接收到部分請求，但是一旦服務器並沒有拒絕該請求，客戶端應該繼續發送其余的請求。
101 Switching Protocols 服務器轉換協議：服務器將遵從客戶的請求轉換到另外一種協議
2、2xx: 成功
200 OK 請求成功（其后是對GET和POST請求的應答文檔。）
201 Created 請求被創建完成，同時新的資源被創建。
202 Accepted 供處理的請求已被接受，但是處理未完成。
203 Non-authoritative Information 文檔已經正常地返回，但一些應答頭可能不正確，因為使用的是文檔的拷貝。
204 No Content 沒有新文檔。瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面，而Servlet可以確定用戶文檔足夠新，這個狀態代碼是很有用的。
205 Reset Content 沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。
206 Partial Content 客戶發送了一個帶有Range頭的GET請求，服務器完成了它。
3、3xx: 重定向
300 Multiple Choices 多重選擇。鏈接列表。用戶可以選擇某鏈接到達目的地。最多允許五個地址。
301 Moved Permanently 所請求的頁面已經轉移至新的url。
302 Found 所請求的頁面已經臨時轉移至新的url。
303 See Other 所請求的頁面可在別的url下被找到。
304 Not Modified 未按預期修改文檔。客戶端有緩沖的文檔並發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩沖的文檔還可以繼續使用。
305 Use Proxy 客戶請求的文檔應該通過Location頭所指明的代理服務器提取。
306 Unused 此代碼被用於前一版本。目前已不再使用，但是代碼依然被保留。
307 Temporary Redirect 被請求的頁面已經臨時移至新的url
4、4xx: 客戶端錯誤
400 Bad Request 服務器未能理解請求。
401 Unauthorized 被請求的頁面需要用戶名和密碼。
402 Payment Required 此代碼尚無法使用。
403 Forbidden 對被請求頁面的訪問被禁止。
404 Not Found 服務器無法找到被請求的頁面。
405 Method Not Allowed 請求中指定的方法不被允許。
406 Not Acceptable 服務器生成的響應無法被客戶端所接受。
407 Proxy Authentication Required 用戶必須首先使用代理服務器進行驗證，這樣請求才會被處理。
408 Request Timeout 請求超出了服務器的等待時間。
409 Conflict 由於沖突，請求無法被完成。
410 Gone 被請求的頁面不可用。
411 Length Required "Content-Length" 未被定義。如果無此內容，服務器不會接受請求。
412 Precondition Failed 請求中的前提條件被服務器評估為失敗。
413 Request Entity Too Large 由於所請求的實體的太大，服務器不會接受請求。
414 Request-url Too Long 由於url太長，服務器不會接受請求。當post請求被轉換為帶有很長的查詢信息的get請求時，就會發生這種情況。
415 Unsupported Media Type 由於媒介類型不被支持，服務器不會接受請求。
416 服務器不能滿足客戶在請求中指定的Range頭。
417 Expectation Failed
5、5xx: 服務器錯誤
500 Internal Server Error 請求未完成。服務器遇到不可預知的情況。
501 Not Implemented 請求未完成。服務器不支持所請求的功能。
502 Bad Gateway 請求未完成。服務器從上游服務器收到一個無效的響應。
503 Service Unavailable 請求未完成。服務器臨時過載或當機。
504 Gateway Timeout 網關超時。
505 HTTP Version Not Supported 服務器不支持請求中指明的HTTP協議版本。
500 Internal Server Error 請求未完成。服務器遇到不可預知的情況。
501 Not Implemented 請求未完成。服務器不支持所請求的功能。
502 Bad Gateway 請求未完成。服務器從上游服務器收到一個無效的響應。
503 Service Unavailable 請求未完成。服務器臨時過載或當機。
504 Gateway Timeout 網關超時。
505 HTTP Version Not Supported 服務器不支持請求中指明的HTTP協議版本。
2、參數級驗證，入參及出參的驗證
1、入參和出參的類型、范圍、是否必填、默認值、參數間的關聯性，參數格式等進行驗證
2、與接口文檔一致
3、安全級驗證
1、篡改參數的校驗，如面值、規格、價格等重要數據的篡改，是否校驗不讓提交數據
2、接口請求限制校驗，如某活動限參與一次，重復請求接口校驗
3、並發請求是否寫入多條數據，數據庫是否唯一索引
2 接口測試用例設計
一個接口通常是有輸入輸出的，輸入就是我們常見的入參，輸出有時有，有時沒有。調用相關接口，接口會執行相關處理邏輯。
接口測試的用例設計，主要從輸入和接口處理兩方面考慮：
1）針對輸入，可按照參數類型進行設計；
2）針對接口處理，可按照邏輯進行用例設計；
3）針對輸出，可根據結果進行分析設計。
2.1 針對輸入設計
對於接口來說，輸入就是入參。常見參數類型有:
（1）數值型(int,long,float,double等）
（2）字符串類型
（3）數組或鏈表
（4）結構體
結構體(struct)是一些元素的結合，元素實際也是數值型，字符串型，數組或鏈表。
下面詳細說明數值型、字符串型、數組或鏈表三種參數類型用例設計。
2.1.1 數值型
數值型的參數主要考慮以下幾個方面設計：
如果參數規定了值的范圍，則需要考慮等價類取值范圍內、取值范圍外，取值的邊界，如有需要，可能會遍歷取值范圍內的各個值。
例如檢查權限的接口：TaskChecker.checkTask(int taskID) taskID的取值范圍是1-35，那么設計時考慮：
-
1-35范圍內和范圍外的值；
-
1-35的邊界：0，1,35,36；
-
類型的特殊值：-1,0
-
數據類型的邊界值：int的最小值最大值；
-
因為1-35代碼的權限ID不同，可能需要遍歷1-35的每個值。
常見問題和風險：
-
特殊值處理不當導致程序異常退出；
-
類型邊界溢出
-
取值范圍外值未返回正確的錯誤信息等
2.1.2 字符串型
字符串型的參數，主要考慮字符串的長度和內容：
例如接口轉換設置鬧鍾的接口DateUtil.getDayOfDDHH(String ddhh)，用例可以考慮：
-
長度為4位，比4位少，比4位多；
-
邊界值：String的最大長度；
-
特殊值：空字符；
-
字符串內容可考慮類型：數字，非數字；
-
特殊字符。
-
如果是輸入用戶輸入且其他用戶可見的內容，則還需要考慮敏感字是否被正常過濾。
可能出現的問題和風險：
-
傳入非特定類型程序異常退出
-
超長字符未進行處理，導致存儲、顯示等異常
-
其他用戶可見設置的敏感字
2.1.3 數組或鏈表類型
參數類型為數組或鏈表時，用例可以考慮：
例如批量提交任務的接口submitTask(int[] taskID)，參數用例設計考慮：
-
正常取值：1-5個權限，范圍外：6個權限；
-
邊界值：1-35的邊界值，請求允許最大最小值；
-
特殊值：0個；
-
合法ID和不合法的；
-
重復的ID等。
可能存在的問題和風險：
-
0個item時程序異常退出；
-
重復的item處理時未去重導致結果異常等。
2.2 針對邏輯設計
接口需要進行一些邏輯處理的，那么按邏輯設計用例可以從以下幾個角度分析。
2.2.1 約束條件分析
（1）數值限制：分數限制、金幣限制、等級限制等等。
例如：兌換Q幣活動要求積分>50才可參與。
（2）狀態限制：登錄狀態等。
例如：同步用戶信息需要先登錄賬號。
（3）關系限制：綁定的關系，好友關系等。
例如：幫家人防騙功能只能查詢綁定家人的來電信息。
（4）權限限制：管理員等。
約束條件的測試在功能測試中經常遇到，在接口測試中更為重要。它的意義在於：用戶進行操作時，在該操作的前端可以已經進行了約束條件的限制，故用戶無法直接觸發請求該接口。但是實際上，如果有其他手段：例如UI有bug或者通過技術手段直接調用接口，那么接口是否針對這些條件進行了限制就尤為重要。
例如常見的例子：要兌換5Q幣需要200積分，但是我積分不足，所以兌換按鈕是灰色無法點擊的狀態：
正常用戶是無法操作的，但是兌換其實是調后台的一個接口，如果繞過頁面按鈕的限制，直接調用后台接口兌換呢？是否可以兌換？預期當然是不能兌換的。因此積分這個數值限制就需要針對接口進行測試，並且非常重要。
其他約束條件類似：
-
時間約束：22：00之前；
-
數值約束：積分200；限量5個；
-
狀態約束：登錄手機管家；
-
等等約束條件類似。
常見的問題和風險：
-
約束條件判斷不足，導致用戶可通過特殊手段獲取利益
2.2.2 操作對象分析
操作通常是針對對象的，例如用戶綁定電話號碼，電話號碼就是操作對象，而這個電話號碼的話費、流量也是對象。
對象分析主要是針對合法和不合法對象進行操作。例如下述用例子:
-
用戶A查詢電話P1話費：
-
用戶A查詢電話P1流量；
-
用戶A查詢電話P2話費；
-
用戶A查詢電話P2流量。
后台的邏輯處理，如果一個電話已經被綁定過，從后台的角度是可以查詢到該電話的話費和流量的。但是在用戶側，應該是A綁定了的電話，才能讓A查詢到該電話的話費。故類似對象的測試也必不可少。
常見的問題和風險：
-
用戶可訪問非權限內的其他用戶信息、敏感信息，從而利用這些信息謀取利益。
2.2.3 狀態轉換分析
被測邏輯可以抽象成狀態機，各個狀態之間根據功能邏輯從一個狀態切換到另一個狀態。如果我們打亂了這個次序，從一個狀態切換到另一個不在它下一狀態集中的狀態，那么邏輯將會打亂，就會出現邏輯問題。
如上圖所示，從某狀態改變到新的狀態，依賴於轉換接口。而對於某轉換接口，其輸入狀態是確定的，比如Fun23, 這個函數只能把狀態2轉換為狀態3，而不能把狀態1轉換為狀態3。那么測試點就可以是：
（1）狀態為狀態2，調用接口Fun23（），狀態切換到狀態23；
（2） 狀態為1,3等，調用接口Fun23（），狀態不能切換。
例如在做任務的時候，任務有三種狀態：未領取，已領取未提交，已完成三種狀態。
那么可以這樣設計：
（1）正常的狀態切換：未領取狀態，領取任務后變為已領取狀態；已領取滿足任務條件提交后，變成已完成狀態；完成后可以再次領取任務。
（2） 非正常的狀態切換：未領取任務滿足任務條件直接提交任務；已領取時再次領取任務等等。
常見的問題和風險：
可通過特殊手段達到原本不能的狀態，從而謀取利益。
2.2.4 時序分析
在一些復雜的活動中，一個活動是由一系列動作按照指定順序進行的，這些動作形成一個動作流，只有按照這個順序依次執行，才能得到預期結果。
在正常的流程里，這些動作是根據程序調用依次進行的，並不會打亂，在接口測試時，需要考慮如果不安裝時序執行，是否會出現問題。
例如，客戶端數據同步是由客戶端觸發進行的，期間的同步用戶無法干預。功能測試的時候可見的就是是否能正常進行同步，而進一步分析，同步流程實際涉及了一組動作：
從時序圖可以看出，后台有3個接口：登陸獲取用戶ID，上報本地數據，上報本地沖突。三個接口需要依次調用執行，才能完成同步。那么在接口測試就可以考慮打亂上述接口的執行順序去執行，會有怎樣的結果，是否會出現異常。例如：獲取用戶ID后不上報本地數據而直接上報本地沖突。
常見的問題和風險：
-
非順序執行后，數據出現異常，可能還會出現程序其他異常
-
通過打亂順序獲取利益
2.3 針對輸出設計
2.3.1 針對輸出結果
接口處理正確的結果可能只有一個，但是錯誤異常返回結果有很多情況很多值。如果知道返回結果有很多種，就可以針對不同結果設計用例。例如提交積分任務的時候我們通常能想到的是返回正確和錯誤，錯誤可能想到：無效任務，無效登錄態，但是不一定能否完全覆蓋所有錯誤碼，而接口返回定義的返回碼可以設計更多用例：
覆蓋返回碼也是用例設計的一種思路。
常見問題和風險：
（1）錯誤前端處理不足，導致前端異常；
（2）錯誤提示處理不當，導致用戶看到晦澀的錯誤碼；
（3）錯誤提示不當，導致用戶不知道哪里出了問題，如何解決。
2.3.2 接口超時
接口正常情況下是有返回的，那么如果接口不返回呢？也就是說接口超時后的處理也是測試需要考慮的部分。如果超時處理不當，可能會引起以下問題：
（1）未進行超時處理，導致整個流程阻塞
（2）超時后又收到接口返回，導致邏輯出現錯亂
2.4 其他測試設計
2.4.1 已廢棄接口測試
已廢棄協議，是指之前有定義，但是因為需求變更或其他原因，目前版本不用。這些接口雖然不再使用，但有可能代碼並沒有及時刪除。如果利用技術手段調用這些接口，可能獲取額外利益。
例如，任務之前有個清理任務，在一個版本需求里將清理任務替換為下載任務。在新版本客戶端已不再調用完成清理任務的接口；但是如果該接口未關閉，用戶就可以繼續請求submitTask(int taskID)接口完成清理任務獲得積分。
因此新版本在考慮兼容舊版本的同時，還應做好相關廢棄接口的檢查，避免用戶獲得額外利益。
2.4.2 接口設計合理性分析
接口定義是否合理可以從以下幾個方面分析：
（1）接口字段是否冗余；
（2）接口是否冗余；
（3）接口是否返回了調用方期望得到的信息；
（4）接口定義是否可滿足所有調用需求；
（5）接口定義調用是否方便。
----------------------------------------標准接口測試的理由--------------------------------------------
2、為什么要做接口測試
a)互聯網的快速發展，公司內部系統或與外部系統的關聯越來越多，一個業務流程關聯多個后端系統，它們的關聯都是基於接口來實現，接口測試可以將復雜的系統關聯進行簡化，只要做好每個接口的測試就能夠較好的保證系統質量。
b)單個系統的變更，是否會影響到關聯業務系統，比較難用常規的測試方面來覆蓋相關的應用系統（例如使用此接口的外部 系統有N個，不可能每個做功能兼容性測試），但可以通過對接口功能的覆蓋來驗證是否影響它人對接口的調用。
c)接口功能比較單一，能夠比較好的進行測試覆蓋，也相對容易實現自動化持續集成，，可以減少人工回歸成本與時間，縮短測試周期。
d)接口相對於界面功能，會更底層一些，測試覆蓋會更容易（如業務在調用接口時做了判斷，當不滿足條件時鏈接就不顯示，此時從界面無法測試相關功能是否做好判斷，通過接口就比較容易）
3、接口測試范圍
a)業務功能（包括正常、異常場景是否實現）
b)業務規則（覆蓋度是否全面）
c)參數驗證（邊界、業務規則是否達到要求）
d)異常場景（重復提交、並發提交、事務中斷、多機環境、大數據量測試）
e)性能測試（響應時間、吞吐量、並發數、資源要求）
f)安全測試（權限驗證、SQL注入等）
4、接口測試的重點
1、檢查接口返回的數據是否與預期結果一致。
2、檢查接口的容錯性，假如傳遞數據的類型錯誤時是否可以處理。
3、接口參數的邊界值。例如，傳遞的參數足夠大或為負數時，接口是否可以正常處理。
4、接口的性能，http請求接口大多與后端執行的SQL語句性能、算法等比較相關。
5、接口的安全性，外部調用的接口尤為重要。
二、做好接口測試的前提
1、系統化的接口文檔
傳統的接口文檔，一般采用word或wiki等系統來記錄，從單次使用上似乎比較簡單，因為大家會更習慣這樣的操作，但這種形式存在比較大的問題：
a、接口文檔非標准化，無法直接與接口測試工具接口使用
b、接口維護困難，接口有變化時比較難標識清楚，溝通成本很高
系統化接口文檔，例如rap（淘寶分源的一個系統），具備接口維護標准化、版本化管理、MOCK測試等功能；對標准化的接口內容做二次開發，可以直接導出Soapui等工具使用的格式，直接導入工具中使用，有以下好處：
A、接口測試時不再需要手工輸入相關字段，節省時間成本
B、版本化管理，能夠清晰的知道哪些接口有變化
2、標准化的接口規范
接口管理是做好接口測試很重要的前提，如果一個系統有哪些接口都不太清楚，測試就很難覆蓋到，接口管理建議采用以下方式：
A、按接口提供方為單位進行首次划分，按接口使用方進行二次划分，再按業務模塊進行細分，分類原則根據內容多少進行優化，不需要固定，如本身接口較少就沒有必要分得過細，較多時就需要多划分模塊
如：系統A，提供有 1、2、3、4、5、6、7、8、9 這9個接口，接口分別給B系統、C系統使用，其中1、2為公用接口，3、4、5為B專用，6、7、8、9為C系統專用
B、按接口鏈接URL做為唯一，不同的接口參數做為接口變量，接口有參數變更時在原來接口上進行維護，而不是新增加接口
C、為接口增加版本號，方便清楚哪些接口本次有變更，易於維護用例