目錄
01—Why接口測試
一、提高效率
二、增加對業務的了解
三、投入産出比較高
02—How怎麼做？應用時機
一、需求測試過程中
二、需求上線後，補充用例
03—需求測試過程中
04—功能拆解
05—技術評審
06—接口用例設計
07—接口測試的實作方式
一、使用 RD 單測代碼
二、投入人力編寫自動化用例
三、自動化測試平台
二、三 對比如下：
08—APITest接口測試平台
09—測試集合示意圖
10—參數化
11—斷言
12—測試報告
13—Beetle關聯
學習資源分享
01—Why接口測試
一、提高效率
關鍵詞：QA 職責保質保量的完成需求測試工作
在保證品質的前提下提高效率，要保證品質，首先需要先弄清楚這次需求的測試範圍，針對性的使用不同的測試方法，而接口測試就是其中的一種；保證效率，降本增效是一個老生長談的話題，也是QA一直的追求，推動技術自測是一個方式，使用自動化代替人工也是一個方式，但不管哪種方式，都需要保證業務主流程的正确執行，而自動化就是解決這個問題的。
二、增加對業務的了解
關鍵詞：清楚需求的目的和技術實作方案
近期高頻詞：測試左移。在需求立項的時候，就去了解需求的目的，從QA角度給出建議；同樣的技術方案評審時，QA也需要從自身角度出發，從風險意識出發，指出技術方案上可能存在的問題，如果QA一點不了解技術，在技術評審時，就會無從下手。
關鍵詞：與 RD 建立共同語言
交流的前提是：需要有共同話題。當 RD說的細節你都不懂時，RD就會說“就這樣測就行了，你按照我說的做吧”——QA就處于一個被動的地位了。印象深刻的一件事，一個同僚指出了RD代碼上邏輯的錯誤，從此之後推進一些事情就會特别順利。
三、投入産出比較高
從自動化金字塔來看，接口測試算是投入産出比較好的一個方式.
02—How怎麼做？應用時機
一、需求測試過程中
1.1 中台本身需要對接很多業務方，有些需求業務方的開發工作量會很大，中台隻需要做一些配置或者很少的代碼開發工作。這個時候，如果中台的QA 也跟随業務側的測試排期，就會存在資源分批不合理的情況。接口測試就可以一定程度上解決這個問題。中台 RD 提測後，中台 QA 完成接口測試；業務 RD 提測時，中台QA 隻需要配合業務 QA 進行測試就可以了；
1.2 大項目的周期會很長，而這個時候，測試人員一般也會是多人參與，如果流程不通，影響的就是單個時間x人員個數。目前有些業務正在實行的就是聯調期間，QA 進行接口測試；提測後，進行功能測試。這樣可以保證主流程是通的，QA也可以更快的進入狀态。
二、需求上線後，補充用例
自動化場景用的最多的還是流程回歸和監控，隔一段時間進行業務梳理，并以文檔和自動化用例的方式沉澱下來是正常的做法。
03—需求測試過程中
以 XXX 項目為例進行介紹，XXX 業務線新增回收業務模式，于訂單側來說需要新增業務線 id、并配置狀态機等改動較少，業務方需要做大量開發工作。
04—功能拆解
UI 互動：不涉及
功能測試：業務側測試
接口測試：訂單建立，訂單狀态流轉
埋點：無
功能回歸：無，新增業務線
05—技術評審
重試補償機制
參數校驗等異常場景
06—接口用例設計
建立、流轉、重試、幂等，接口測試實際情況舉例：
07—接口測試的實作方式
一、使用 RD 單測代碼
存在以下弊端：
管理不友善
不能在其他工程複用
不能送出到 gitlab
二、投入人力編寫自動化用例
三、自動化測試平台
二、三 對比如下：
使用平台，減少了編碼之外的重複工作，用例可以自由拼裝，不會存在人員 交接後，之前的代碼就廢棄的情況。
08—APITest接口測試平台
兩個入口：需求次元、工程次元，分别解決需求測試中和服務上線後，補充用例兩種場景。
舉例：需求入口
要想做好接口測試，就不能把接口孤立起來。業務場景上，也是接口、mq、sql語句、redis等串聯起來的。單獨的接口測試，隻能覆寫孤點，不能覆寫整 個流程。要想做好接口測試，接測試平台就需要把用到的工具放在一個平面上。目前 apitest 的思路如下 為一個用例，用例聚集起來就是用例集。
09—測試集合示意圖
用例按照在用例集中的順序依次執行，目前還不支援單個用例失敗就中斷整個用例集。
10—參數化
提到自動化，就會遇到參數傳遞的問題。各個公司的 qa 因為接觸的工具不 一樣，思路也會不一樣。apitest 是使用 jsonPath 解析入參和出參的方式，讓資料可以在用例之間流動。
11—斷言
apitest也是同樣使用 jsonPath 進行結果的解析，來進行斷言的。
12—測試報告
測試報告如下，分為兩個部分：總覽和詳情。總覽展示用例集次元的資訊，詳情展示單個步驟的執行結果和斷言結果。