Time will tell.
1、什么是介面測驗？為什么要做介面測驗？
介面測驗是測驗系統組件間介面的一種測驗，
介面測驗主要用于檢測外部系統與系統之間以及內部各個子系統之間的互動點，測驗的重點是要檢查資料的交換，傳遞和控制管理程序，以及系統間的相互邏輯依賴關系等，
由于如今的系統復雜度不斷上升，傳統的測驗方法成本急劇增加且測驗效率大幅下降，所以就要做介面測驗，同時，介面測驗相對容易實作自動化持續集成，且相對UI自動化也比較穩定，可以減少人工回歸測驗人力成本與時間，縮短測驗周期，支持后端快速發版需求，介面持續集成是為什么能低成本高收益的根源，
現在很多系統前后端架構是分離的，從安全層面來說，只依賴前端進行限制已經完全不能滿足系統的安全要求， 需要后端同樣進行控制，在這種情況下就需要從介面層面進行驗證，前后端傳輸、日志列印等資訊是否加密傳輸也是需要驗證的，特別是涉及到用戶的隱私資訊，如身份證，銀行卡等，
2、怎么做介面測驗？
一般情況下，由于我們專案前后呼叫主要是基于http協議的介面，所以測驗介面時主要是通過工具或代碼模擬http請求的發送和接收，所以我們下面整理了一下使用Jmeter工具進行http介面測驗，
開發介面測驗案例的整體方案：
第一步： 分析出測驗需求，并拿到開發提供的介面說明檔案；
第二步： 從介面說明檔案中整理出介面測驗案例，里面要包括詳細的入參和出參資料以及明確的格式和檢查點；
第三步： 和開發一起對介面測驗案例進行評審；
第四步： 結合開發庫，準備介面測驗案例中的入參和出參資料，并整理成csv格式的檔案；
第五步： 結合介面測驗案例檔案和csv格式的資料檔案，做介面測驗案例的自動化案例開發，
介面自動化適用場景
目前設計的自動化介面測驗案例有兩個運行場景：
（1）測驗前置、開發自測：一個新的自動化介面測驗案例開發完成后，直接發給介面對應的開發，安排在開發本地環境執行，一旦開發確認完成介面開發，就開始執行介面測驗案例，基本上可以實時拿到測驗結果，方便開發快速做出判斷，（開發本地運行的方式就是打開JMeter工具，匯入JMX檔案，開始執行可）
（2）回歸測驗：開發本地測驗通過后，或整個需求手工測驗通過后，把自動化的介面測驗案例做分類整理，挑選出需要納入到回歸測驗中的案例，在持續集成環境重新準備測驗資料，并把案例納入到持續集成的job中來，這些用于回歸的介面測驗案例需要配置到持續集成平臺自動運行，
介面測驗環境準備
Jdk1.6或以上：http://www.oracle.com/technetwork/java/javase/downloads/index.html
Jmeter, 下載地址：http://jmeter.apache.org/download_jmeter.cgi
插件的下載安裝地址： http://www.jmeter-plugins.org/
創建工程
1.打開Jmeter：下載好Jmeter后，雙擊bin目錄下的jmeter.bat檔案：
2.添加執行緒組：在“測驗計劃”上點擊滑鼠右鍵–>添加–>threads(Users)–>執行緒組，添加測驗場景設定組件，介面測驗中一般設定為1個“執行緒數”，根據測驗資料的個數設定“回圈次數”，
3.添加“HTTP Cookie管理器”：
4.添加“Http請求默認值”組件，當被測系統有唯一的訪問域名和埠時，這個組件很好用：
5.在“HTTP 請求默認值”組件配置頁面，填寫被測系統的域名和埠，http請求的實作包版本以及具體協議型別，執行緒組里的所有“HTTP Sampler”可默認使用此設定，
6.在“執行緒組”里添加“HTTP 請求”的Sampler
7.在HTTP請求設定頁面，錄入被測介面的詳細資訊，包括請求路徑，對應的請求方法，以及隨請求一起發送的引數串列：
8.設定檢查點：在被測介面對應的“HTTP 請求”上，添加“回應斷言”：
9.在設定頁面上添加對相應結果的正則運算式存在性判斷即可：
10.添加監聽器：方便查看運行后的結果
??上述步驟完成了一個簡單測驗案例的創建，復雜測驗案例均在此基礎上擴展完成，使用Jmeter工具開發的介面測驗案例，一個子系統建議放在同一個 “測驗計劃”中，流程測驗可以通過“執行緒組”來區分，這樣也便于設定不同的測驗資料個數，比較獨立的介面，可以統一放在一個執行緒組內，順序完成測驗，
??流程性介面的測驗：如果要測驗的介面可以組成一個流程，只需要順序添加多個“HTTP 請求”的Sampler，各請求之間可以提取需要在背景關系傳遞的資料作為引數，以保證流程中資料的一致性，
3、介面測驗持續集成
對介面測驗而言，持續集成自動化是核心內容，通過持自動化的手段我們才能做到低成本高收益，目前我們已經實作了介面自動化，主要應用于回歸階段，后續還需要加強自動化的程度，包括但不限于下面的內容：
a) 流程方面：在回歸階段加強介面例外場景的覆寫度，并逐步向系統測驗，冒煙測驗階段延伸，最終達到全流程自動化，
b) 結果展示：更加豐富的結果展示、趨勢分析，質量統計和分析等
c) 問題定位：報錯資訊、日志更精準，方便問題復現與定位，
d) 結果校驗：加強自動化校驗能力，如資料庫資訊校驗，
e) 代碼覆寫率：不斷嘗試由目前的黑盒向白盒下探，提高代碼覆寫率，
f) 性能需求：完善性能測驗體系，通過自動化的手段監控介面性能指標是否正常，
4、介面測驗質量評估標準
a) 業務功能覆寫是否完整
b) 業務規則覆寫是否完整
c) 引數驗證是否達到要求（邊界、業務規則）
d) 介面例外場景覆寫是否完整
e) 介面覆寫率是否達到要求
f) 代碼覆寫率是否達到要求
g) 性能指標是否滿足要求
h) 安全指標是否滿足要求
絮叨
對介面、自動化、軟體測驗零基礎入門、python全堆疊、面試題感興趣可以加入我們175317069一起學習，群內會有不定期測驗資料鏈接發放喔，
喜歡的話，歡迎【評論】、【點贊】、【關注】禮貌三連，
Time will tell.（時間會證明一切）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/115047.html
標籤：其他