導語
1 接口測試
1.1 接口測試
接口：主要是子模塊或者子系統間交互並相互做用的部分。
這裏說的接口是廣義的，客戶端與後臺服務間的協議；插件間通訊的接口；模塊間的接口；再小到一個類提供的方法；均可以理解爲接口。
接口測試：是指針對模塊或系統間接口進行的測試。
1.2 接口測試發現的典型問題
接口測試常常遇到的bug和問題，以下：
（1）傳入參數處理不當，致使程序crash；
（2）類型溢出，致使數據讀出和寫入不一致；
（3）因對象權限未進行校驗，能夠訪問其餘用戶敏感信息；
（4）狀態處理不當，致使邏輯出現錯亂；
（5）邏輯校驗不完善，可利用
漏洞獲取非正當利益等。
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.5 一個完整的例子
下面舉一個完整例子，經過上述方法來分析如何對接口進行用例設計。
某模塊提供了一個接口給其餘模塊，用戶請求任務，接口定義以下：
2.5.1 針對輸入設計
dialogDetailText（dialogButtonText相似）
長度
1）正常：請安裝提示進行操做；
2）邊界：一個字：請；長度很是長：無懸浮窗權限，可能影響XX功能沒法使用，請開始懸浮窗權限，以便得到更好的用戶體驗；甚至更長；
3）特殊：空字符串。
內容
1）特定類型：中文，英文，數字等；
2）特殊字符：/n/r/t ,.><?*$&^%~"??℡?€?等；
3）敏感字符：非用戶設置，不涉及。
taskID（requestType相似）
等價類
取值範圍內：1,5,10等；
取值範圍外：0，99。
邊界法
取值範圍邊界：0,1,38,39,40
數據類型邊界：-2147483648 ,2147483648
特殊值：0,-1等。
遍歷法：1,2,3,4,5…38,39對應每種不一樣ID。
2.5.2 針對邏輯設計
（1）約束條件分析
去引導某功能須要：未完成過任務，任務有任務數據。
那麼用例能夠是：如下狀況下調requestTask：
1）未使用過有任務數據時；
2）未使用無任務數據時；
3）使用過有任務數據時；
4）使用過無任務數據時。
若是有其餘約束條件相似設計。
（2）操做對象分析
調用請求接口後，會顯根據任務數據，引導對應的任務。任務數據，任務操做方式，任務功能均可以是對象。
1）任務數據
數據類型：本地，雲端 等
數據有效性：正確數據，錯誤數據
2）操做方式
方式：安裝，下載，打開等等 。
3）任務功能
功能：用戶操做了該功能，未正常操做該功能；什麼都不操做；完成一個任務功能；完成多個任務功能；任務功能使用順序等等。
對象：還須要關注，會不會操做到不合法的對象，例如任務數據和功能不對應等問題。
（3）狀態轉換分析
功能是有4個狀態的：完成，未完成，未知。狀態圖以下：這裏是產品裏涉及的狀態轉換：
針對該狀態：
1）正常狀態轉換：未完成狀態請求並完成任務後是否可變成完成狀態；未完成狀態請求但不完成，仍是未完成狀態。
2）走不到的狀態路徑：未知和完成狀態請求任務，不能進行進行該任務。
2.4 時序分析
從時序的角度分析，調用請求接口前須要如下2步動做：
1）拉取任務數據；
2）判斷任務狀態。
從時序獲得的用例有：
正常時序：按照正常時序請求1 2 3；
缺失的時序
缺乏動做1調2 3；缺乏動做2調1 3；缺乏動做1和2直接調。
打亂的時序
打亂的時序：2 1 3，還能夠有1 3 2，2 3 1，3 1 2，3 2 1。
針對處理邏輯的設計中，可能使用某一種或某幾種方式就能夠將用例覆蓋前，故實際使用中，可能不會所有使用，只要找到最合適的方式覆蓋用例便可。
2.5.3 針對輸出分析
請求任務接口返回的數據是任務完成結果，即返回完成，未完成兩種狀態（未知都做爲完成返回）。
從結果能夠考慮遍歷：
1）未完成
2）完成
3）完成-未知
從接口處理時間分析，考慮：請求後快速返回，很長時間才返回，甚至不返回結果的狀況。
3 小結
接口用例設計方法中，針對輸入、輸出的設計是通用的，接口設計時均可用到。對於接口邏輯的設計可能會應用比較適合的一種或幾種方法，在接口用例設計時，須要選取最合適的方法去覆蓋被測邏輯。