這篇文章用來對自己做介面自動化用例過程中遇到的經驗作以總結，主要是用例編寫和執行過程中的難點：
用例編寫要考慮穩定性，解決用例耦合
導致此類問題的原因有：
① 用例編寫問題：
a.大部分業務介面對引數比如name有唯一性校驗，所以引數需要進行隨機生成；
b.對結果校驗不通用，指定陣列序列：返回體是jsonarray，校驗陣列中有乙個元素的name為abc，校驗中直接制定元素位置：array[0].name==』abc』，這種校驗當用例一直到b環境執行時會有可能時array[1].name為abc,校驗會不通過，需要修改校驗為contains
②不同環境對引數規則要求不
一、返回屬性不一致：如果使用同乙份用例，遷移至b環境，會導致此類用例不通用，當前我們的機制是：規範不一致的用例用不同標籤標識，選擇用例時選擇對應環境標籤執行
執行時間
自動化要求能較快時間完成用例的執行，現我們專案要求30min內完成全量用例執行。
所以用例要考慮用例間是否能併發，不能併發執行的用例耗時情況。有的依賴驗證碼的介面，兩次獲取驗證碼的時間有30s時間間隔，所以對此類場景，能預置的資料提前預置，能合併驗證的合併乙個用例驗證，減少驗證環節前面的資料構造過程。
介面的引數合法性校驗可以合併乙個用例寫，減少用例前面的執行時間，減少過多的非關鍵用例。
當前我們專案介面自動化用例數多達3000多條，其中正常場景的用例可能不到1/3，其餘都是異常場景，有些單介面引數驗證是可以合併的，但是到後期意識到這個問題整改成本很大
執行策略
我們可以按照測試目的選擇用例執行，而不是每次都全量執行，這樣有效提公升大家的驗證時間效率
驗證db讀寫一致性情況，可以勾選部分讀寫用例執行
用例按照微服務介面新增微服務標籤，對應服務公升級流水線可掛在對應服務標籤的用例，同時搭配用例優先順序，雙重層級選擇用例
新需求用例增加新需求用例標籤，驗證時單獨執行，不新增至日常任務中，保證日常任務執行穩定性，待需求上線後更新標籤為微服務標籤、設定優先順序
預置變數的規範性和必要性
用例中我們不可避免的要預置變數，變數不能設定id值，且對變數的預置要知會全組告知變數用途，要有乙個變數維護**，不能任意增加預置變數，預置變數要精簡
制定統一的編碼和用例編寫規範
考慮到自動化工程的維護性，要統一規定自動化**規範，細化到元模型的命名、**結構
對於返回值首先要將介面原生返回的內容返回出去，保證在外部能看到介面原生返回的東西，這樣斷言出錯我們能明確知道介面返回的資料是啥，而不用檢視自動化日誌。對於需要進行處理的內容在做單獨處理返回。
殘留資料的清理
要做好建立資料的清理
問題定位日誌
在呼叫界面前將介面名、請求方法、元模型函式名、請求資料、（用例名）進行日誌列印
介面呼叫後將介面返回結果進行日誌列印，將資料處理結果也進行列印
用於後續用例出錯的問題定位
後續日漸更新，希望自己通過不斷地總結思考提公升自己的測試領悟
Excel介面自動化（8）介面測試自動化指令碼
介面測試自動化指令碼 整個流程的邏輯基本都是在這裡面實現，所需要的資料都是通過呼叫前面的封裝來獲取 第一步 新建乙個解析excel工具類的例項物件並且獲取 api 的sheet物件 parsee parseexcel parsee.loadworkbook filepath sheetobj par...
介面自動化（二） 介面聯調
今天寫一下存在關係的介面，怎麼呼叫上乙個介面返回來的東西，以註冊 登入，忘記密碼 修改密碼為例，其中修改密碼會用到上乙個介面的token，直接上 都是上期的 重複的我就不解釋了，沒解釋過的我會加到注釋中 usr bin env python conding utf 8 import requests...
介面自動化測試（一） 介面測試
介面測試是測試系統元件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。其中介面協議分為http,webservice,dubbo,thrift,socket等型別，測試型別又主要...