接口測試指導方案

https://blog.csdn.net/u011391839/article/details/80400575 1.         接口測試簡介 接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。   2.        接口測試流程   接口測試的流程和功能測試流程相似，依據的對象是需求說明書和接口需求，接口測試流程以下： 3.         接口測試範圍 1)     業務功能（包括正常、異常場景是否實現） 2)     業務規則（覆蓋度是否全面） 3)     參數驗證（邊界、業務規則是否達到要求） 4)     異常場景（重複提交、併發提交、事務中斷、多機環境、大數據量測試） 5)     性能測試（響應時間、吞吐量、併發數、資源要求） 6)     安全測試（權限驗證、SQL注入等）   4.         接口測試重點 （1）    檢查接口的功能：檢查接口的功能有沒有實現，也就是請求會不會成功，若是不成功會不會返回錯誤代號（或錯誤信息） （2）    檢查接口返回的數據：檢查接口返回的數據、數據格式、數據類型是否與預期一致（正向且傳遞的參數正常）； （3）    檢查接口的容錯性：接口是否能夠正常處理（假如傳遞的參數足夠大或者爲負、空值時） （4）    檢查接口的性能：http請求接口大多與後端執行的SQL語句性能、算法等比較相關。 （5）    檢查接口的安全性：外部調用的接口尤其重要。   5.         接口測試需求分析 首先根據接口設計的技術架構方案，瞭解清楚被測接口對應的公共入參、入參、出參及返回數據的Json結構規範，根據測試場景進行測試。 1)     理解接口參數，熟悉接口參數的輸入要求、輸入值範圍、必填項等； 2)     理解接口輸出，熟悉返回json的結構構成、返回值類別、返回值範圍、返回data的不一樣類型等。 3)     理解接口的邏輯、接口的業務關聯，熟悉技術方案中的接口相互關聯、依賴的關係，接口與接口之間的數據傳遞等。 4)     尋找測試點，根據輸入(參數名、取值範圍)、輸出(參數名、返回值範圍)、關聯關係，進行測試點分析；   6.         接口測試用例設計 接口測試的主要測試對象是接口，可是隨着系統複雜度愈來愈高，接口愈來愈多，徹底覆蓋全部接口是很難的一件事情，而且實際過程當中任意內部接口的變更均可能致使咱們的測試用例的不可用。 1）   接口用例設計優先級 n  優先級-->針對全部接口 a)     暴露在外面的接口，由於一般該接口會給第三方調用； b)     供系統內部調用的核心功能接口； c)     供系統內部調用非核心功能接口； n  優先級-->針對單個接口 a)     正向用例優先測試，逆向（異常）用例次之(一般狀況，非絕對)； b)     是否知足前提條件 > 是否攜帶默認參值參數 > 參數是否必填 > 參數之間是否存在關聯 > 參數數據類型限制 > 參數數據類型自身的數據範圍值限制 2）     接口用例設計方法   具體可參考《接口測試用例設計》     3）   測試用例編寫注意事項 是否知足前提條件 有些接口須要知足前置條件，纔可成功獲取數據。常見的，須要登錄Token。 逆向用例：針對是否知足前置條件(假設爲n個條件)，設計0~n條用例 是否攜帶默認值參數 正向用例： 帶默認值的參數都不填寫、不傳參，必填參數都填寫正確且存在的「常規」值，其它不填寫，設計1條用例； 業務規則、功能需求 這裏根據實際狀況，結合接口參數說明，可能須要設計n條正向用例和逆向用例 參數是否必填 逆向用例：針對每一個必填參數，都設計1條參數值爲空的逆向用例 參數之間是否存在關聯 有些參數彼此之間存在相互制約的關係 逆向用例：根據實際狀況，可能須要設計0~n條用例 參數數據類型限制 逆向用例：針對每一個參數都設計1條參數值類型不符的逆向用例 參數數據類型自身的數據範圍值限制 正向用例：針對全部參數，設計1條每一個參數的參數值在數據範圍內爲最大值的正向用例 逆向用例： 針對每一個參數(假設n個)，設計n條每一個參數的參數值都超出數據範圍最大值的逆向用例 針對每一個參數(假設n個)，設計n條每一個參數的參數值都小於數據範圍最小值的逆向用例   進行測試執行編寫時，有以下的原則： 1.不一樣的接口參數覆蓋不一樣的業務場景； 2.在後臺構造合適的數據來知足接口的測試用例； 3.根據接口的返回值，斷言其是否返回指望結果，並查看數據庫驗證； 4.測試用例涉及多個步驟的，應對涉及的步驟都驗證 5.刪除測試過程當中產生的結果，確保每一個用例執行前都是一個清潔的環境   7.         接口測試用例模板             8.         接口數據準備 9.         接口測試工具 1)     接口測試工具選擇 n  接口工具：Postman/Jmeter/SouapUI/python，單個接口測試時使用Postman，多個接口測試時可使用Jmeter，或者使用python腳本； ü  Jmeter：能夠測試各類類型的接口，不支持的也能夠經過網上或本身編寫的插件進行擴展。 ü  postman：功能上更簡單，組織方式也更輕量級，它主要針對的就是單個的HTTP請求。   n  抓包工具：fiddler   2)     使用Postman測試單個接口時以下,具體使用請參考《使用Postman測試接口》   3)     使用JMeter測試接口時接口組織形式規範以下，具體使用請參考《使用Jmeter盡測試接口》    10.     接口測試原則 （1）    基礎配置，如域名、環境配置等，單出文件配置，方便不一樣環境測試、腳本維護 （2）    明確接口實現什麼樣的功能，實際須要什麼樣的功能，是否一致 （3）    接口測試數據太多，用該數據驅動模式更有層次，且易於維護 （4）    要在衆多測試用例中選出冒煙測試用例及可用於性能測試的用例 （5）    先單接口測試，在多接口業務測試 （6）    測試完成之後，須要清洗髒數據     11.     接口測試執行實例 11.1  使用Jmeter測試接口實例 n  接口測試環境準備 ü  Jdk1.8或以上：http://www.oracle.com/technetwork/java/javase/downloads/index.html ü  Jmeter下載址址：http://jmeter.apache.org/download_jmeter.cgi ü  插件的下載安裝地址：http://www.jmeter-plugins.org/   n  接口測試過程 1)     新增一個測試計劃 下載好Jmeter後，雙擊bin目錄下的jmeter.bat文件   2)     　添加線程組 在「測試計劃」上點擊鼠標右鍵-->添加-->threads(Users)-->線程組，添加測試場景設置組件，接口測試中通常設置爲1個「線程數」，根據測試數據的個數設定「循環次數」。   3)     添加「Http請求默認值」 在上步的線程組上右鍵添加-->配置元件-->HTTP請求默認值。 當全部的接口測試的訪問域名和端口都同樣時，可使用該元件，一旦服務器地址變動，只須要修改請求默認值便可。     4)     在「線程組」裏添加「HTTP 請求」的Sampler 在「線程組」右鍵-->添加-->samlper-->「HTTP 請求」 在HTTP請求設置頁面，錄入被測接口的詳細信息，包括請求路徑，對應的請求方法，以及隨請求一塊兒發送的參數列表，配置以下：   注：因爲Jmeter請求線程組內的請求時從第一個開始執行，因此咱們將須要最早執行的請求放在前面  　 5)     添加斷言 在被測接口對應的「HTTP 請求」上，添加「響應斷言」。右鍵點擊HTTP請求「添加」–>「斷言」–>「響應斷言」   在設置頁面上添加對相應結果的正則表達式存在性判斷便可：   　    要測試的響應字段：響應文本、Document(text)、URL樣本、響應信息、Response Headers、Lgnore Staus等選項。雖然接口返回的是Json格式的數據，但對於Jmeter來講返回數據爲文本，因此，這裏能夠勾選「響應文本」   　　模式匹配規則：包括、匹配、Equals、Substring。這裏只須要驗證返回數據中是否包含主要的關鍵字，因此，這裏勾選「包括」。   要測試的模式：其實就是斷言的數據。點擊「添加」按鈕，輸入要斷言的數據。   6)     添加監聽器（測試報告配置） 在「線程組」右鍵-->添加-->監聽器->查看結果樹、用表格查看結果、聚合報告三種結果的報告展現  點擊運行後，便可看到運行結果，結果以下： 運行結果查看：   使用聚合報告查看：   上述步驟完成了一個簡單測試案例的建立，複雜測試案例均在此基礎上擴展完成。使用Jmeter工具開發的接口測試案例，一個子系統建議放在同一個 「測試計劃」中，流程測試能夠經過「線程組」來區分，這樣也便於設定不一樣的測試數據個數。比較獨立的接口，能夠統一放在一個線程組內，順序完成測試。　　 　流程性接口的測試：若是要測試的接口能夠組成一個流程，只須要順序添加多個「HTTP 請求」的Sampler，各請求之間能夠提取須要在上下文傳遞的數據做爲參數，以保證流程中數據的一致性。    12.      接口測試結果報告（待定）   13.     接口測試中常見問題 接口測試常常遇到以下的bug和問題： （1）    傳入參數處理不當，致使程序crash; （2）    類型溢出，致使數據讀出和寫入不一致； （3）    因對象權限爲進行校驗，能夠訪問其餘用戶敏感信息； （4）    狀態處理不當，致使邏輯出現錯亂； （5）    邏輯校驗不完善，可利用漏洞獲取非正當利益等；     14.     接口自動化適用場景及持續集成 接口自動化框架：Jmeter+Jenkins 目前設計的自動化接口測試案例有兩個運行場景： 1) 測試前置、開發自測：一個新的自動化接口測試案例開發完成後，直接發給接口對應的開發，安排在開發本地環境執行，一旦開發確認完成接口開發，就開始執行接口測試案例，基本上能夠實時拿到測試結果，方便開發快速作出判斷。【開發本地運行的方式就是打開JMeter工具，導入JMX文件，開始執行可。】 2) 迴歸測試：開發本地測試經過後，或整個需求手工測試經過後，把自動化的接口測試案例作分類整理，挑選出須要歸入到迴歸測試中的案例，在持續集成環境從新準備測試數據，並把案例歸入到持續集成的job中來，這些用於迴歸的接口測試案例須要配置到持續集成平臺自動運行。   對接口測試而言，持續集成自動化是核心內容，經過自動化的手段纔能有效下降成本，提升接口測試的價值。若是使用LR、JMeter、SoapUI工具作自動化測試，工具自己支持命令行模式運行，能夠接合Jenkins 等自動化平臺，實現項目版本更新後的自動化迴歸測試 關於持續自動化迴歸測試的建議： 一、接口腳本開發時要注意參數的取值的可用性，不由於時間或數據狀態的變化引發腳本不能正常運行，下降腳本維護成本. 二、接口迴歸功能的覆蓋度控制，須要根據腳本的實際功能和重要性判斷自動化迴歸覆蓋度，迴歸內容越多腳本維護成本越高，通常應用接口不建議全功能覆蓋（畢竟接口有變化會作詳細測試，若是沒修改其它變動可能對其產生的影響通常不會影響其邏輯判斷） 三、接口腳本須要必定的自動化校驗能力，除請求http狀態的判斷外，還須要對核心內容的正常性作判斷（判斷內容可與數據庫內容匹配等方式，不建議用寫死的內容）。 四、持續性能測試，還須要作好相關的監控、性能指標的分析自動化，減小人工操做 --------------------- 做者：紫漪 來源：CSDN 原文：https://blog.csdn.net/u011391839/article/details/80400575 版權聲明：本文爲博主原創文章，轉載請附上博文連接！