如何設計介面測試
優秀的後端測試開發最基礎的素養就是懂得如何設計介面測試用例。下圖簡述了如何做好介面測試。本文不做展開
介面測試痛點
測試資料難準備 – - 定製資料複雜且龐大，測試場景更是千變萬化，測試場景難以窮舉
測試資料難維護 - - 同樣是因為定製資料的複雜性，新功能迭代會導致原有case預期不正確，且輸入資料需要同期更新。可能某乙個欄位的小改動，會導致80%以上的介面失敗。這就表明這些測試資料的生命週期可能就只有乙個禮拜，但是測試卻需要花上可能一天的時間更新用例。case越多，時間成本越高。投入產出比不成正比
測試結果校驗不精準 – - 一般簡單的資料校驗 ，可能是針對測試場景中的測試結果資料中的某個字段進行比較，或者測試資料全量校驗，但是定製結果相同請求很可能每次的請求結果都不一致。這就要求我們去做json降噪處理，從而達到正確比對測試結果。
測試結果同開發溝通不方便 - - 介面測試資料展現會是某個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層資料進行全量校驗，保證拆分前後各物件的一致性。
測試結果：
當然還有面試，面試一般分為技術面和hr面，形式的話很少有群面，少部分企業可能會有乙個交叉面，不過總的來說，技術面基本就是考察你的專業技術水平的，hr面的話主要是看這個人的綜合素質以及家庭情況符不符合公司要求，一般來講，技術的話只要通過了技術面hr面基本上是沒有問題（也有少數企業hr面會刷很多人）
我們主要來說技術面，技術面的話主要是考察專業技術知識和水平，上面也是我整理好的精選面試題。
加油吧，測試人！如果你需要提公升規劃，那就行動吧，在路上總比在起點觀望的要好。事必有法，然後有成。
資源不錯就給個推薦吧~
怎樣提高測試效率
問題 怎麼樣可以提高測試效率，在人力有限的情況下怎麼把控軟體質量？有時因為專案優先順序的問題，測試到一半的專案停了去測試其他專案 其他的專案是後面把優先順序提上來的 每次這樣都感覺到時間緊張，人力緊張，版本更新後客戶也會提很多問題 思考 1 優先順序調整正常都有會，無法避免，重點是調整優先順序後，先...
原創 如何提高軟體測試效率
原創 如何提高軟體測試效率 1 盡早測試，從軟體生命週期開始測試就參與其中，覆蓋到從需求，架構設計，編碼等各環節，測試不在是乙個獨立體 2 不斷測試，這裡的不斷是遵循軟體生命週期原理，且在每個生命週期，進行不同層級的測試 3 充分利用各種測試方法和技術 黑，灰，白盒，自動化測試，靜態測試，效能測試，...
怎樣提高開發效率
給你乙個任務,限定5天內完成,如果你實際用了6天,可以說是開發效率不高,或者同樣的乙個任務,你花了6天,而你的同事卻只用了4天,也可以說是你的開發效率不高,影響開發效率的因素有很多,下面就我個人的理解來談談怎樣提高開發效率.俗話說，工欲善其事必先利其器，使用得心應手的工具必然會提高開發效率，做微軟平...