導讀：API接口自動化測試在服務端分層測試體系中佔有重要地位，在持續追求提升研發交付效能的背景下，傳統的自動化測試工具面臨質量與效率的更高挑戰。智能化測試的本質是利用數據和算法相結合賦能質量活動的測試方法，藉助智能化測試思維，在API測試全生命週期內進行了多環節的針對性優化、形成合力賦能提升測試質效。
全文5736字，預計閱讀時間16分鐘。
一、API測試面臨的質效問題
1.1 API的自動化測試特點
API接口由於具備良好的可測性，很自然的成爲服務端程序自動化測試的首選方案：
1、API的結構化有助於程序實現請求與解析接口，當前以Json數據結構爲主要的入參、返回結構，可讀性強、程序化處理方便。
2、API的業務邏輯集成度較高，具備較高測試性價比，接口的參數組合具備直接的業務含義，主要的業務場景是可以通過不同參數組合達到覆蓋。
3、API測試執行與維護成本較低，考慮到需要書寫的case量級、調試與維護的代價，在測試分層的金字塔理念之中，是作爲腰部支撐的存在。
1.2 API自動化測試面對新的挑戰
伴隨着自動化測試的建設與積累，建成了一站式平臺化爲主要形式的測試服務，CASE全週期幾乎都是在平臺內進行的，平臺化的建設集成了豐富的測試能力、減少了重複建設、提高了測試服務的可靠性，從完全手工測試跨越到自動化平臺對質效提升有顯著意義，但同時也面臨新的問題需要解答：
1、測試全週期內，人力投入是否可完全釋放：
-
CASE書寫調試效率：API CASE由接口定義、參數數據、斷言組成，平臺建設有編輯管理能力，在自動化發展的初期， CASE自身的書寫準備仍然需要大量人工投入，多數工作集中在了從瀏覽器複製粘貼接口參數、或者從API定義文檔中手工錄入參數。在初期，CASE的全自動化生成佔比幾乎爲0%。
-
排查分析CASE失敗原因：按照歷史經驗，自動化CASE失敗的原因70~80%與被測代碼無關，而更多的是平臺、CASE、環境、數據等相關，日常排查分析此類問題浪費大量的人力。
2、自動化CASE量級急劇膨脹，測試效率開始降低、可維護性變差：
-
長尾任務增多：隨着CASE量級增長、維護跟不上導致穩定性變差，開始出現執行耗時變慢，難以達成快速測試的目的，同時也擠佔了公共執行資源。比較突出的長尾任務包含上千個case，整體耗時需要1小時。
-
CASE存在大量冗餘、無法甄別質量：當CASE積累到一定階段後，人工維護的及時性與可行性極速下降，單靠人工去篩選、清理CASE變得非常困難。使得測試執行時無法高效有效的篩選出合適的CASE來覆蓋。
3、自動化CASE測試的質量是否可信：
-
一種情況是，CASE全部PASS造成的測試通過假象：其中可能夾雜這CASE並無有效斷言來攔截問題、或者覆蓋率不足，無法有效的證明CASE測試是放心的。
-
另一種情況是CASE有頻繁的FAIL，但是誇大了問題攔截率：更多的是由於平臺、CASE、環境、數據等干擾問題導致的CASE狀態不穩定。
二、智能化測試基本思路
如何理解智能化測試：利用數據和算法相結合賦能質量活動的測試方法，使得每一次測試活動，都用較小的代價、準確判斷質量風險。
（1）智能化測試不是一種全新的測試類型；
（2）智能化測試存在傳統測試的某個或多個環節中；
（3）傳統測試是智能化測試發揮作用最重要的載體。
基於自動化測試的整個生命週期，輸入、執行、分析、定位、評估，分別有其相應的數據特徵與規律、以及對應的瓶頸問題，智能化測試以提升測試過程各階段質效爲目標，將數據與策略相結合，形成整體合力。
三、API測試全週期智能化測試實踐
在智能化測試的思維指導下，以API自動化測試平臺爲載體，結合API測試各個階段面臨的問題，分而治之。
1、準備CASE：通過自動化生成的手段快速生成CASE，智能化策略解決參數組合爆炸問題、斷言缺失問題。
2、執行CASE：通過任務編排的動態併發策略提高測試效率，通過代碼覆蓋的映射關係精準篩選CASE提高測試效益。
3、分析判斷結果：通過Diff去噪策略保障接口對比測試的調試效率與效果。
4、排查定位原因：通過結合日誌trace系統、異常錯誤規則庫建設，提高自動排查定位效率。
5、評估測試質量：通過適合的自動化CASE評估手段，評價CASE的有效性，指導CASE優化治理與披露風險。
3.1 自動化CASE的「自動化+智能化」生成
API CASE主要由接口定義結構、參數數據、斷言三部分組成，前兩部分比較好實現自動化，而斷言部分因爲包含業務邏輯的校驗需要更多考慮智能化策略。
1、接口定義+參數數據的自動導入生成：擴展多種對接渠道，建立快捷的自動化生成CASE機制。
-
基於API定義管理工具：swagger+yapi用作規範化的API定義管理工具，包含了uri、入參結構與示例、返回結構與示例。測試平臺建立對接機制，可一鍵式導入並監聽接口變更信息。
-
基於業務系統日誌：從生產環境摘取API的日誌片段，經過加工處理之後，解析出API結構與參數。測試平臺以開放API的形式提供給業務線定製化實現對接。
-
瀏覽器插件錄製請求：建設pc瀏覽器的插件，對頁面操作時的後端請求直接錄製保存到CASE，尤其是有順序要求的API請求序列。對於web手工迴歸測試、驗收的環節，可同時生成接口CASE。
-
其他API測試工具導入：postman作爲手工調試API的利器，在研發階段積累了一些API的請求，可批量導入爲CASE。另外還有一些代理工具，如fiddler、charles其接口請求的數據格式也可支持導入導出。
自動化生成的API CASE，主要用於兩類場景：
-
契約測試：在微服務系統中是比較重要的用以驗證服務之間接口契約一致性的手段，在使用中需要解決二個問題，一是接口結構隨着業務發展經常升級變化需要及時更新到CASE，二是驗證契約需要一定量級的參數組合但又要避免參數組合爆炸的問題。前者主要建設了監聽API定義變化的機制自動刷新CASE，後者是一個典型的pairwise測試組合算法應用場景，即參數倆倆正交組合達到最佳覆蓋同時又控制參數組合的量級最少。
-
迴歸測試：應用與業務邏輯迴歸面臨的重要問題有三點，一是大部分業務邏輯是一系列API組合且有依賴關係的操作序列，因此也需要CASE內保持此種關係；二是由於CASE內部API組合情況增加了複雜度，需要增加前置的規範化預處理機制；三是業務邏輯斷言不能夠依賴自動化代替，大部分仍需要人工後期修改增加斷言，但爲避免生成無斷言的無效CASE，至少生成一些基礎性的斷言，如json-schema斷言對結構做最基本的檢驗。
2、接口斷言的自動化生成：儘可能的多做一步，爲新增CASE以及存量CASE主動生成與推薦斷言。由於json爲當下API主要的數據交換格式，斷言生成的部分也主要集中在json的處理機制上。
-
Json-schema斷言：json-schema定義了一套詞彙和規則來描述Json數據，即Json數據需要遵循的規範，包括成員、結構、類型、約束等。在測試場景下（特別是契約測試），可用於驗證API返回json數據的格式、內容。
-
對於新生成的CASE，結合導入的上游渠道中描述的接口定義（包含了接口返回結構），可直接將json數據轉化爲json-schema。
-
對於存量CASE因書寫不規範有斷言空白的，起不到任何攔截問題的作用，從成本上考慮高優補充json-schema斷言。基於CASE執行的歷史結果數據，提取無異常報錯的記錄N個，轉化爲json-schema集合並計算期間的差異，按照其表現與CASE的參數、執行時間對照，經由不同規則確定適合的json-schema版本自動回填到CASE中。
-
Json key-value值斷言：json數據中的鍵值對，其value值爲主要的驗證點，常用做迴歸校驗。對於新增CASE或者存量無斷言CASE，均可以通過基於最近執行結果的N條記錄，計算key-value中value的diff比例，設定閾值區分固定的value值，並回填到CASE中作爲迴歸斷言點。
經過上述能力建設之後，當前增量CASE中，自動化手段生成的CASE佔比已經提升到了60%以上，全年爲30%。
3.2 自動化CASE執行更加高效、有效
1. 自動化CASE的「效率」問題：當CASE量級達到千級別以上，執行效率問題已經比較突出，基於 CASE 的歷史表現、可執行資源、對量級較大且耗時較長的CASE集合，實施動態預估分組併發執行。相比固定分組充分利用執行資源、有效減少了長尾的分組。
-
動態預估：基於可用線程資源、歷史性能與穩定性表現，預估可分組數量。
-
CASE分組：按歷史N次平均耗時表現動態分配到不同分組內，保持分組之間的整體耗時相對均等。
-
分佈式執行：採用分佈式執行框架，對任務分片分批處理。
-
熔斷止損：分組內監聽執行情況，異常導致的耗時明顯增長將熔斷執行，避免分組成爲長尾。
優化執行模型之後，長尾任務的數量減少40%，並且有益於資源快速釋放進而可以消化更多任務，整體測試任務的平均耗時隨之降低30%。
2. 自動化CASE的「效益」問題：CASE 量級積累到一定階段後變得龐大冗餘，帶來的另一個棘手問題是，維護不及時導致無法甄別CASE質量，全量執行 Fail 率高影響測試效果。因此，針對代碼變更篩選推薦高度相關的 CASE 集合，可減少冗餘執行、提高效率、也達到了針對代碼變更影響範圍的「精益化」測試。
-
CASE相關性計算：通過串行執行CASE的同時dump測試環境的cov文件，計算提取其中的函數信息，可獲取CASE相關的被測函數列表。
-
篩選CASE：基本做法即通過提測代碼計算diff，提取出有變更的函數列表，然後查詢上一步的對應CASE集合。進階做法是對篩選的策略進行優化，對CASE多維度的數據建立分類與排序。
CASE篩選策略可廣泛應用於CI流水線的准入測試（冒煙），以自動篩選相關CASE取代人工維護，篩選後執行效率相比全量執行可優化70%。
3.3 分析測試結果的智能化手段
在API測試中有這樣一類場景，API的數據結構比較複雜、數據比較多，不論是人工設置斷言還是自動化生成的斷言，均很難達到較好、較準的覆蓋。對於這類接口，衍生出Diff測試的方式來進行測試覆蓋。
Diff 測試常用於迴歸測試，其主要方式是採用相同的接口請求參數，分別發往A/B兩個版本的接口服務，其中一個版本是已交付上線版本並認爲是可信的。Diff測試的優點在於可全流程自動生成、無需編寫斷言。但 diff 結果情況複雜，一般存在較多隨機值、變化值並非驗證重點，導致case往復調試成本高。
針對Diff結果有「噪點」的問題，設定去噪算法消除 diff 結果的不確定性，減少人工調試 case 成本，自適應提高 case 穩定性。當前在接口CASE應用到diff測試場景時，大部分無需關注斷言，可100%自動化完成自適應修正，無需人工介入。
3.4 CASE FAIL原因的智能化分析定位
自動化CASE FAIL比較常見，在建設初期、或者維護case量級比較大的業務，70%～80%以上的FAIL問題基本屬於非代碼bug原因。這部分排查牽扯的人力成本也是比較高的。通過自動化平臺建立自身+業務邏輯的排查服務，通過自動定位排查手段能有效的減少這部分人力投入。
1、一級定位：首先排除掉自動化測試工具平臺、環境、CASE規範這類非常明顯、且容易出現的問題。這部分的工作依賴的是自動化測試工具自身的日誌建設，建立完整的異常錯誤碼機制，對各個環境容易出現的異常進行細緻的分類。比如接口請求不通的異常，就需要分爲被測服務異常無法訪問、或者是CASE中的URL填寫錯誤等。對於工具而言要解決的一個策略機制問題是，當一次測試出現的異常太多，如何選擇1個root cause作爲主要根因反饋到測試結果中。此處的過濾策略，先對CASEID+ERROR爲Key存儲到緩存，過濾掉同一個CASE重複的報錯；根據執行測試流程對ERROR發生的時機建立優先級順序，同一個CASE有不同的ERROR報錯信息時，按照先後順序高優推薦首條錯誤原因；當批量CASE均有多個ERROR報錯信息時，對ERROR計數再區分，選擇比重最高的作爲錯誤原因。如此一來可自動化的排除掉CASE FAIL問題的20%無需介入排查。
2、二級定位：相對於一級定位，其他FAIL原因則更多的是與測試環境、測試數據緊密相關。比如被測系統調用第三方的API超時無返回，體現在CASE結果上是斷言不通過，那麼希望是能定位到這個原因上，也可以大大縮短定位的路徑。做到這個層面的自動定位分析，需要解決二個問題。第一是將自動化CASE與業務系統的日誌串聯起來，業務系統首先建立起日誌的trace機制，可通過唯一ID串聯起一次API請求的過程。第二是針對業務日誌常見邏輯異常的報錯，建立錯誤信息規則庫，FAIL的CASE透傳關聯ID到日誌這邊時，根據已有的錯誤信息規則庫去檢測日誌範圍內的匹配結果。這樣可繼續自動化排除掉60~70%左右的FAIL問題。
3.5 自動化CASE的有效性評估
在測試工作中對於測試交付的質量經常會有如下困擾：自動化 CASE的測試攔截效果如何？每次測試都 Pass 是否可以高枕無憂？需要證明自動化 CASE 能有效發現 bug，才能使得測試行爲有信心，此即爲測試有效性的含義。
如上爲典型的一個有效性不足的CASE，即驗證點覆蓋不足，會遺漏對業務邏輯的校驗。在業界用以做有效性評估的手段多數爲變異測試，學術界也有對比分析語句覆蓋率、分支覆蓋率與變異測試評估的效果。
結合實際測試工作經驗，可劃分爲四個評估的方向：
1、靜態分析評估：根據自動化case自身的書寫特點進行的設計合理性的檢查評估，是最爲基礎的手段之一。
2、動態分析評估：根據case運行之後的結果評估執行效果。
3、變異測試評估：是一個研究非常多且有一定難度的評估手段，通過源代碼生成變異體之後，檢測case是否能發現變異，多用於白盒測試。
4、揭錯能力評估：實際工作中，case存在特殊的問題，即存有較多同質化的case帶來額外的執行開銷，同時也有脆弱不穩定的case干擾測試結果，進而有需要評估治理。
對於API測試而言，測試覆蓋流程較長而不便於做代碼程度的變異與檢測。但可以先從基礎的體現CASE本質的幾大因素來評估，即綜合了上述靜態+動態的分析手段：
1、CASE規範性：基礎的因素即斷言，斷言體現的是測試驗證的覆蓋，否則將出現只有代碼覆蓋率數據但沒有檢驗點覆蓋率。
2、代碼覆蓋率：代碼覆蓋率雖然不能作爲檢驗測試質量的唯一標準，但它是基礎，代碼覆蓋率低必然CASE覆蓋程度薄弱。
3、CASE穩定性：CASE設計考慮不周全導致錯誤頻發、性能波動較大意味着不可靠，穩定性差將非常打擊測試結果的可信度。
4、CASE活躍度：被運行的頻度、被暫停擱置的週期、被更新編輯的次數等等，表明了某個CASE是否已經不再活躍，變成了閒置CASE。
5、CASE複雜度：CASE組成內容過於複雜時，維護的代價、運行的穩定性風險都比較高。
綜合上述數據特徵，按不同權重對每一項進行評分，加總後給出CASE的評分。用於兩個方面，一是CASE數據評估供後期維護CASE參考，二是測試報告實時披露CASE的質量風險。
四、總結
回顧API 自動化測試的智能化改造實踐歷程：由痛點問題出發、從點到線、全面覆蓋，全方位優化 API 測試流程的效率與質量，爲 API 測試作爲主流的功能迴歸測試能力形成有力保障。
經過智能化測試的改造，API 的測試全流程更加精益求精，各個環節形成合理，全方位提升測試過程效率、測試質量。
---------- END ----------