介面測試求助

1、介面需求描述

查詢現金獎品記錄，透過引數條件組合獲取資料庫對應的資料記錄,介面文件如下：
url: g####e/query####ist
引數：

 {
    b**d (Array[string], optional)對應活動id, 
    cr**n (string, optional): 建立開始時間,yyyy-MM-dd HH:mm:ss, 
    c**d (string, optional): 建立結束時間,yyyy-MM-dd HH:mm:ss, 
    pageIndex (integer, optional): 第幾頁，從1開始，預設為1, 
    pageSize (integer, optional): 每頁行數，預設為10, 
    s**No (Array[string], optional): 請求流水號, 
    s***Begin (string, optional): 定時傳送開始時間,yyyy-MM-dd HH:mm:ss, ,
    s***End (string, optional): 定時傳送截止時間,yyyy-MM-dd HH:mm:ss,
}

返回格式

PagedResponseOfListOfCashPrizeLogDTO {
code (integer, optional): 狀態碼, ,
message (string, optional): 響應訊息, ,
pageIndex (integer, optional): 第幾頁, ,
pageSize (integer, optional): 每頁行數, ,
p***d (Array[CashPrizeLogDTO], optional): 結果資料, ,
total (integer, optional): 總記錄數,
}CashPrizeLogDTO {
a***nt (number, optional): 總價值, ,
b***d (string, optional): 業務ID, ,
c***Type (integer, optional): 贈金型別, ,
c***d (integer, optional): 業務系統ID ,
createTime (string, optional): 建立時間, ,
c***d (integer, optional): 使用者ID, ,
g***d (integer, optional): g***表id, ,
id (integer, optional): ID, ,
p***s (integer, optional): 狀態, ,
reason (string, optional): 理由, ,
s***o (string, optional): 請求流水號, ,
s***Date (string, optional): 定時時間,
}

2、需求理解

1. 帶有分頁功能的介面，對首頁，中間頁和尾頁的測試驗證
2. 引數中 pageSize 和 pageIndex 兩個帶有預設值，驗證其正確性
3. 除了 pageSize 和 pageIndex 以外其它引數會按照並集的形式返回（前端會展示多個輸入搜尋條件）
4. 除了 pageSize 和 pageIndex 以外，其它引數如果不傳遞，就不校驗該引數
5. 介面返回的 code 和 message 為必須返回欄位，其他欄位可能會不返回

3、測試用例設計

我先按照非常理想的狀態設計測試用例

3.1、業務正常測試
在傳遞合理的引數前提下，介面必須保證業務的正常，即返回正常和理想資料，可以把這部分的用例抽取一部分作為冒煙測試用例
例如：在管理系統中我們在首次進入一個模組頁面的時候，會不傳遞引數，直接以預設的分頁方式展示全部資料
介面入參只有一個分頁引數（{"pageIndex":1,"pageSize":10}），或者直接連分頁引數也沒有（{}）,校驗點，分頁邏輯，total 結果總數，返回結果數量，和裡面欄位和資料庫欄位是否一一對應，並且按照指定格式返回（時間格式和浮點數格式等）

3.2、單一欄位校驗
根據介面的特性，在不傳遞其他引數的情況下，可以保證對單個引數的校驗（pageSize 和 pageIndex 除外），對每一個引數的輸入都進行相關的校驗，主要有這幾點：正確欄位（合理輸入），空欄位，格式問題，數值長度等，這些校驗我個人覺得是必要的，但是這些測試用例應該

3.3、組合邏輯判斷
這些用例說白了，就是模擬多條件組合查詢，驗證返回結果是否和預期是一致的，本質上除了就是驗證開發在資料庫查詢上面的邏輯是否正確。個人理解的最直接的驗證方法，根據條件組合，形成傳參呼叫介面。案例介面有 6 個引數（分頁引數先不理她），在每個引數都合理正確的前提下，也就是說測試用例數目應該是：6 的全部組合=63,what? 63？單單這個需要 63 個測試用例？小盆友是不是滿臉問號，一個簡單的不能再簡單的查詢介面，還是一個不怎麼帶有其他業務邏輯的單一資料庫查詢介面，這麼多用例？在實際業務中是這些組合發生可能性是完全會發生的，有沒有必要完全校驗一遍這些邏輯呢？我個人認為是有必要的，為了不當背鍋俠，我忍了。

3.3、分頁功能和拍序
分頁功能，我就不多說了，基本上是大多數查詢列表這類介面必備的，分頁功能測測試無非就是首頁，預設頁，中間頁，尾頁和溢位頁（最後頁面 +n,n!=0）對這些頁面驗證是否返回正確的頁面資料。排序的話，當前這個沒有排序要求

3.4、 總結
在理想狀態下按照上述規劃設計測試用例，去掉幾個模組的重複用例，這個簡單介面測試用例數量應該有 100+，不慌，我們慢慢來。

4、測試執行規劃對比

4.1、手動介面測試方案 1
採用工具 postman 執行測試用例，按照 3 分鐘執行完一個的平均速度，理想狀態下 8*60/3 = 160 一天工作下來，可以完成 160 個測試用例（摸魚時間自己在扣除哈，畢竟每個人摸魚時間不一樣），這還只是冒煙之後的第一輪測試，內心毫無波瀾。畢竟開發修改完程式碼，在理想狀態下我們還需要繼續跑跑一遍用例。

4.2、手工執行＋錄製回放
採用工具 post+fiddler+jmeter,很多人都會說，你一個介面測試，怎麼用上了 fiddler？fiddler 的主要作用就是抓包，記錄測試用例的執行（有了這些記錄，證明我沒有偷懶，要不然一個簡單介面測試測試一天，領導要找你談心的），fiddler 的作用當然不止這些，匯出 jmeter 程式碼然後在每個請求後面加上自己的斷言，就可以輕鬆回放介面測試了，優點就是第後面的迴歸測試絕對舒服，和自動化掛鉤了，逼格上升，缺點就是每個介面都需要加上斷言，工作量也不小啊，

上面兩個方案我都有過實踐經驗，我的第一份工作是在一家小型的創業公司實習，公司從事的是虛擬雲桌面系統的二次開發和對虛擬雲系統的體系完成（運營系統和運維繫統開發），在我工作過程中最主要的問題就是時間問題，公司當時的政策是先完成所有功能模組後迭代細化問題，快速的版本迭代和線上問題，讓測試小組應接不暇，完全沒有時間編寫方案二的斷言，漸漸加入深度加班大軍，無限惡性迴圈。

有沒有好用一點的介面異常自動化測試技術可以推薦？

求助各位大佬