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