在介面測驗程序中，用例設計是關鍵中的關鍵，需要重點關注的一些維度

介面測驗

什么是介面

介面就是內部模塊對模塊，外部系統對其他服務提供的一種可呼叫或者連接的能力的標準，所謂的介面是模塊與模塊之間的一種連接

介面測驗

上圖為一個典型的介面，一個介面通常是有輸入輸出的，輸入就是我們常見的入參，輸出有時有，有時沒有，呼叫相關介面，介面會執行相關處理邏輯

介面測驗的用例設計，主要從輸入和介面處理兩方面考慮：

1. 針對輸入，可按照引數型別進行設計
2. 針對介面處理，可按照邏輯進行用例設計
3. 針對輸出，可根據結果進行分析設計

典型問題

介面測驗經常遇到的bug和問題，如下：

• 傳入引數處理不當，導致程式crash
• 型別溢位，導致資料讀出和寫入不一致
• 因物件權限未進行校驗，可以訪問其他用戶敏感資訊
• 狀態處理不當，導致邏輯出現錯亂
• 邏輯校驗不完善，可利用漏洞獲取非正當利益等

用例設計

前面說明什么是介面以及什么是介面測驗，接下來詳細看看如何才能更好的進行介面用例設計

一、引數校驗

對于介面來說，輸入就是入參，常見引數型別有：

1. 數值型(int、long、float、double等）
2. 字串型別
3. 陣列或鏈表
4. 結構體

1.1 數值型

數值型引數主要考慮的設計思路

1.1.1 等價類

• 取值范圍內
• 取值范圍外

1.1.2 邊界值

• 取值范圍邊界（邊界最小、最大、邊界最小-1、邊界最大+1等）
• 資料型別邊界（如int型別資料最小、最大）

1.1.3 特殊值

• 0
• 負數

1.1.4 遍歷法

• 取值范圍的所有數值遍歷

栗子

整型： 最大最小值限制、0和負數的限制
浮點型： 最大最小值限制、0和負數的限制、小數點后位數的限制

常見問題

• 特殊值處理不當導致程式例外退出
• 型別邊界溢位
• 取值范圍外值未回傳正確的錯誤資訊等

1.2 字串型

字串型的引數，主要考慮字串的長度和內容

1.2.1 字串長度

• 等價類（取值范圍內、取值范圍外）
• 邊界值（規定范圍邊界、型別邊界）
• 特殊值（0、空字串）

1.2.2 字串內容

• 特定型別（英文、中文、大小寫等）
• 特殊字符（,.><=$&^%~"*等）
• 敏感字符（"法輪功"等）

栗子

空串、空白符號、長度限制校驗、中文、全角半角、特殊字符

常見問題

• 傳入非特定型別程式例外退出
• 超長字符未進行處理，導致存盤、顯示等例外
• 其他用戶可見設定的敏感字

1.3 陣列或鏈表型別

引數型別為陣列或鏈表時，主要考慮成員個數和成員內容

1.3.1 成員個數

• 等價類（取值范圍內、取值范圍外）
• 邊界值（規定范圍邊界、個數邊界值）
• 特殊值（0等）

1.3.2 成員內容

• 等價類（合法和非法成員）
• 重復法（重復成員）

常見問題

• 0個item時程式例外退出
• 重復的item處理時未去重導致結果例外等

1.4 結構體

結構體(struct)是一些元素的結合，元素實際也是數值型，字串型，陣列或鏈表

列舉型別

需要針對列舉型別進行具體的業務資料邏輯校驗

物件型別

• 整個物件為null
• 物件不為null，里面某個成員為null
• 空集合
• 集合的最大size校驗

1.5 其他問題

• 必傳引數驗證
• 引數值為null驗證

二、功能邏輯校驗

介面核心作用在于處理業務邏輯，針對功能邏輯的用例設計分析

2.1 約束條件分析

• 2.1.1 數值限制
  等級限制、分數限制、次數限制、時間限制、數量限制、積分限制等

• 2.1.2 狀態限制
  登陸狀態、簽到狀態等

• 2.1.3 關系限制
  系結關系、好友關系、授權關系等

• 2.1.4 權限限制
  管理員、超級管理員等

約束條件用例設計的意義在于：
用戶進行操作時，在該操作前端進行了約束條件的限制，故用戶無法直接觸發請求該介面，但如果前端有bug或者通過介面請求直接呼叫，那么針對這些條件限制十分重要

常見問題

• 約束條件判斷不足，導致用戶可通過特殊手段獲取利益

2.2 操作物件分析

面向物件首先得有物件，業務處理邏輯也是針對物件的，例如用戶線上授課，課件就是操作物件，而課件的元素、屬性也是物件

常見問題

• 用戶可訪問非權限內的其他用戶資訊、敏感資訊，從而利用這些資訊謀取利益

2.3 狀態轉換分析

被測邏輯可以抽象成狀態機，各個狀態之間根據功能邏輯從一個狀態切換到另一個狀態
如果打亂對應的次序，從一個狀態切換到另一個不在它下一狀態集中的狀態，那么可能出現邏輯問題

栗子

從某狀態改變到新的狀態，依賴特定的轉換介面處理
對于某些轉換介面，其輸入狀態是確定的（比如Fun23，這個函式只能把狀態2轉換為狀態3，而不能把狀態1轉換為狀態3）
測驗點可以如下設計：

1. 狀態為狀態2，呼叫介面Fun23()，狀態切換到狀態23
2. 狀態為1,3等，呼叫介面Fun23()，狀態不能切換

常見問題

• 可通過特殊手段達到原本不能的狀態，從而謀取利益

2.4 時序分析

在一些復雜的活動中，一個活動是由一系列動作按照指定順序進行的，這些動作形成一個動作流，只有按照這個順序依次執行，才能得到預期結果

在在介面測驗時，需要考慮如果不按照時序執行，是否會出現問題

常見問題

• 非順序執行后，資料出現例外，可能還會出現程式其他例外
• 通過打亂順序獲取利益

2.5 資料精度分析

在處理業務邏輯時，有時候因為資料精度問題導致出現計算

資料精度的校驗考慮的資料

• 2.5.1 時間
  秒/毫秒、時間戳

• 2.5.2 金額
  兩位小數、元/角/分

2.6 用戶體驗

介面屬于模塊之間的呼叫，有時候前端直接展示介面回傳的資訊

• 2.6.1 介面回傳提示
  介面回傳錯誤提示是否合理&友好

三、例外校驗

例外校驗涉及服務內部例外、依賴的外部服務例外、依賴的中間件例外等等

3.1 依賴服務

依賴的下游服務呼叫例外思路

• 3.1.1 呼叫例外
  依賴服務呼叫拋例外
  回傳失敗（有明確回傳失敗資訊、回傳null、http沒有回傳body、部分成功部分失敗）
  回傳不同狀態碼的處理

• 3.1.2 呼叫超時
  下游服務呼叫超時

• 3.1.3 重試機制
  服務呼叫重試機制（重試次數、間隔時長）

• 3.1.4 呼叫校驗
  http url的正確性校驗
  入參的正確性&完整性校驗（如分頁資訊，是否查了多余資訊）

3.2 中間組件

• 3.2.1 拋例外

• 3.2.2 超時

3.3 回圈內中斷

輔助手段

需要針對服務及介面對應的依賴服務和中間件（nginx、redis、db、mq、kafka等等）進行梳理，不同情況下的模擬

1. 訪問超時和丟包可以使用linux的tc命令來設定
2. 服務掛掉可以通過改ip或埠模擬
3. 依賴第三方介面的例外回傳碼可以用mock模擬

四、資料校驗

介面業務邏輯中關于資料的處理邏輯重中之重，接下來針對資料校驗的幾個方面來說明一些校驗的維度

4.1 資料一致性

• 4.1.1 長度一致性
  DB欄位和代碼定義型別的長度一致性
  DB表欄位定義是否合理
  上下游系統相同欄位的長度一致性
  前后端長度一致性驗證
  批量介面入參的最大size限制要和需要呼叫的外部介面的最大size限制兼容

• 4.1.2 多資料源一致性
  快取和DB之間的資料一致性

4.2 冪等校驗

4.3 事務驗證

• 4.3.1 回滾操作
  驗證是不是所有寫操作都回滾
  重點驗證回滾邏輯的正確性

• 4.3.2 資料源
  驗證有沒有一個事務中出現使用兩個資料源

9.3 讀寫分析驗證

• 9.3.1 關注從庫延遲

• 9.3.2 主從配置是否正確

五、場景反推校驗

在設計功能用例時，僅限于介面檔案或了解的資訊進行用例設計，有時候需要增加一些輔助手段更好的深入測驗

5.1 批量處理

• 5.1.1 sql過濾條件
  通過sql陳述句的過濾條件去反推業務場景和開發要篩選的資料是否批量

5.2 重點關注欄位

• 5.2.1 sql表欄位狀態
  sql涉及的表中表示狀態的欄位

• 5.2.2 sql表欄位洗掉狀態
  sql涉及的表中表示洗掉狀態的欄位

檢查思路：過濾條件是否足夠及該過濾的資料有沒有被過濾，比如洗掉狀態的資料要不要過濾、禁用狀態的資料要不要過濾

六、日志檢查

在介面測驗時，不僅僅是關注功能是否能正常實作，還需要關注日志資訊是否正確

6.1 必要性

有沒有，需不需要

6.2 準確性

資訊夠不夠，有沒有多余

6.3 日志級別

日志級別對不對

6.4 日志設定

需不需要開關，開關開啟機制

6.5 日志收集

是否異步收集，性能是否有影響

6.6 敏感性

日志中有沒有包含敏感資訊、用戶資訊

七、健壯性

呼叫鏈路（下游）的介面超時時間合理性

八、并發性能校驗

在介面測驗時，性能方面主要關注并發是否導致一些功能邏輯的問題及單個介面的回應時間

8.1 并發死鎖

• 8.1.1 執行緒死鎖

• 8.1.2 db死鎖

8.2 介面回應時間

• 8.2.1 單介面回應時間

• 8.2.2 批量查詢介面回應時間

• 8.2.3 批量處理介面回應時間

九、安全性驗證

9.1 敏感資訊

• 9.1.1 敏感資訊不能暴露給用戶

• 9.1.2 url或rsp中不能包含敏感資訊

9.2 sql注入

十、sdk版本兼容性

如果依賴sdk，需要重點關注sdk新舊版本的兼容性