如何提高介面測試的效率

酷家樂質量效能發表於2020-08-11

背景

酷家樂是一家面向未來的大家居全案設計平臺及生態解決方案提供商，致力於為數字化升級提供一站式的解決方案。平臺以設計為入口，連結大家居行業生態，為家居企業提供設計、營銷、生產、管理、供應鏈等場景的解決方案和服務，助力全行業實現“所見即所得”的願景。其背後都離不開茁壯的技術架構和穩定的基礎設施。定製設計工具作為酷家樂工具中幫助使用者實現其定製化服務的工具，其能完成定製櫃體從建模到設計到圖紙再到生產輸出，都離不開資料二字，這也就意味著，定製資料的複雜性及多變性在測試過程中會成為一大難點。介面測試作為測試過程中必不可少且極其重要的一環，其資料的正確性在這裡會極大地得到保障。介面測試通過率也被加入到釋出過程中卡點資料，其重要性顯而易見。

如何設計介面測試

優秀的後端測試開發最基礎的素養就是懂得如何設計介面測試用例。下圖簡述瞭如何做好介面測試。本文不做展開

介面測試痛點

1. 測試資料難準備 – - 定製資料複雜且龐大，測試場景更是千變萬化，測試場景難以窮舉
2. 測試資料難維護 - - 同樣是因為定製資料的複雜性，新功能迭代會導致原有case預期不正確，且輸入資料需要同期更新。可能某一個欄位的小改動，會導致80%以上的介面失敗。這就表明這些測試資料的生命週期可能就只有一個禮拜，但是測試卻需要花上可能一天的時間更新用例。case越多，時間成本越高。投入產出比不成正比
3. 測試結果校驗不精準 – - 一般簡單的資料校驗，可能是針對測試場景中的測試結果資料中的某個欄位進行比較，或者測試資料全量校驗，但是定製結果相同請求很可能每次的請求結果都不一致。這就要求我們去做json降噪處理，從而達到正確比對測試結果。
4. 測試結果同開發溝通不方便 - - 介面測試資料展現會是某個body，body內容是純json文字。很難通過body去全面的認識該case的測試場景。只是單純的將比對結果告知開發，復現問題會比較麻煩。

介面測試不同階段的表現

測試資料準備

測試資料維護

測試結果校驗

測試結果同開發溝通不方便

讓開發下載介面測試程式碼測試？---- 不太現實，繁瑣且效率低
對比結果截圖甩給開發？---- 可能比較懵逼，不知道如何復現問題
將對應介面，請求引數，以及測試結果和預期結果，通通發給開發？---- 資料都有了，就是自己累得慌。CV太多次也是體力活

Tips：
1、使用一些小的工具，自動上傳測試結果至oss
2、將測試資料作為存在模型或者方案中，甩個模型&方案連結
3、維護一個公共區域，記錄介面測試變更。溝通可在該文件反饋

定製介面測試是如何做的

案例：

1、如編輯器modeleditor服務3D介面改造

3D介面作為定製編輯器modeleditor服務中預覽介面，其承載了編輯器中幾乎所有資料，該介面若存在問題，其模型將無法構建。保障該介面的正確性即保證了建模過程中80%以上操作的正確性。
改造前：通過從編輯器前端直接獲取3D請求的資料，存入到介面測試的post body資料中，每次資料（新增減少欄位，修改資料結構）的變動都會造成body資料不可用，或者資料不夠新，測試結果也不可完全信任
改造後：通過維護模型去維護介面資料，將所需要的場景資料直接儲存到模型中，再通過開啟模型，獲取3D介面中的Editordata獲取所需要的body資料，改造後可直接作為3d介面的傳送資料。再將獲取到的結構同上一次穩定版本比較，得到變動內容，看是否符合預期。

2、parameter-model包拆分測試

parameter-model包拆分包含底層資料的變更和改動，定製服務一半以上都依賴該包，其涉及相關服務廣，範圍大，牽一髮而動全身。要做到前端無感知拆分，這就必須保證後端提供給前端的資料結構的一致性。簡單的API返回資料的校驗無法滿足測試需求。因而採用物件層級的校驗、在記憶體中對model層資料進行全量校驗，保證拆分前後各物件的一致性。