Jmeter接口測試

1. 接口測試是什麼
   1.1接口
    API（Application Program Interface）接口屬於操做系統的程序接口。
    GUI （Graphic User Interface）接口，屬於一種圖形接口。
    2者都是用戶接口。有時候公司將API做爲爲公共接口，對外開放。
   1.2接口測試
   接口測試是測試系統組件間的一種測試
   接口測試主要用於檢查外部系統和系統之間以及內部各個子系統之間的交互點。
   1.3接口測試目的
    提供測試效率，提供用戶體驗度，減小研發成本
    對系統接口進行全面（功能，安全，性能）高效的持續的測試；
    接口測試是一個完整的系統，包括了功能測試，部分的安全測試，性能測試。
    能夠發現不少頁面上發現不了的bug
    檢查系統的異常處理能力
    前端隨意變，接口測好了，後端不用變
   1.4接口測試工具
   HTTPWatch，Fildder，瀏覽器自帶F12，BurpSuit、LoadRunner，Soapui、jmeter，postman
   1.4.1客戶端請求消息
   請求消息包括如下格式：請求消息包括如下格式：請求行（request line）、請求頭部(header)、空行和請求數據4個部分組成。如圖1所示：
   
   1.4.2服務端響應消息：
   HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。如圖2所示：
   
   1.4.3請求方法
   請求方法如圖3所示：
   
   以GET請求爲例：
   login.action?name=hyddd&password=idontknow&verifly=%E4%BD%E5%A5%BD
   以？來分隔URL和數據；以&來分隔參數；若是數據是英文或數字，原樣發送；若是數據是中文或其餘字符，則進行BASE64編碼。
   1.4.4常見狀態碼
    200 請求成功
    301 資源（網頁等）被永久轉移到其餘URL
    404 請求的資源（網頁等）不存在
    500 內部服務器錯誤
2. 怎麼作接口測試
   
   2.1接口用例設計
   接口測試用例設計的重點，在於功能性的業務邏輯檢查和參數檢查。
   (1). 功能：檢查接口基礎功能，是否完成了業務邏輯要求。此處的用例設計方法，和普通的測試用例設計方法同樣。能夠把接口看成一個待測模塊，分析接口功能需求，利用常規用例方法設計測試用例。
    等價類劃分法
    邊界值分析法
    錯誤推測法
    因果圖法
    斷定表驅動法
    正交試驗法
    場景圖法
   (2). 數據：分析接口的輸入參數，覆蓋各類可能的場景。
    檢查接口的輸入，數據格式、數據類型、數據範圍等
    檢查接口的參數邊界（傳遞的參數足夠大或者爲負、空值時）
    檢查接口的參數的組合，可選、必選等
    檢查接口的約束條件，是否符合約束條件的，是否須要設計用例
   (3). 性能：接口是否形成性能瓶頸，能承受的壓力範圍
   (4). 安全：接口是否涉及安全性
   
   2.2什麼樣的腳本，是一個好的腳本
   自動化腳本規範：
   (1）.一個腳本是一個完整的場景，覆蓋到正常異常業務場景（L0，L1，L2）。
   (2).一個腳本只驗證一個功能點，不要試圖用戶登錄系統後把全部的功能都進行驗證，再退出系統。
   (3).腳本之間不要產生關聯性，也就是說編寫的每個腳本都是獨立的，不能依賴或影響其餘腳本。
   (4). 若是對數據進行了修改，須要對數據進行還原。【後置步驟】
   (5). 測試用例的上下文必須有必定的順序性，要可以互相鏈接起來；而且前置條件要清楚。
   (6). 每一個測試用例粒度必須儘量小，短小簡單的測試用例易於調試。若是測試用例不得不長而複雜，則把它分紅兩個或更多的私有方法，並單獨調用這些方法。
   (7). 儘可能把重複任務放入一個方法中，這樣它能夠被多個測試用例調用。
   (8). 測試用例要有合適的驗證點，符合測試用例的期待結果。驗證：如文件存在，數據庫的表字段，接口返回的消息。
   3.jmeter基本使用
   3.1安裝與配置
    配置Jdk1.8或以上
    Jmeter下載址址：http://jmeter.apache.org/download_jmeter.cgi
    Jmeter啓動：解壓，bin目錄下運行ApacheJMeter.jar進行啓動。
    Jmeter 文件目錄介紹
    bin：可執行文件目錄
   Bin目錄文件
    jmeter.bat：windows的啓動文件
    jmeter.log：日誌文件
    jmeter.sh：linux的啓動文件
    jmeter.properties：系統配置文件
    docs：接口文檔目錄
    extras：擴展插件目錄
    lib：所用到的插件目錄，裏面全是jar包，JMeter 會自動在 JMETER_HOME/lib 和 ext 目錄下尋找須要的類
    Licenses jmeter證書目錄
    printable_docs用戶使用手冊
   3.2接口測試過程
   3.2.1Jmeter頁面
   Jmeter頁面如圖6所示：
   
   3.2.1.1測試計劃
   新建測試計劃過程如圖7所示：
   
   做用：
   • 本次測試所須要的【組件】都是基於測試計劃添加；
   • 本次測試全部組件的設置與執行都基於測試計劃；
   • 組件：完成指定功能代碼段的封裝；
   3.2.1.2線程組
   Threads (Users)線程 用戶
    setup thread group
   一種特殊類型的ThreadGroup的，可用於執行預測試操做。這些線程的行爲徹底像一個正常的線程組元件。不一樣的是，這些類型的線程執行測試前進行按期線程組的執行。
    teardown thread group.
   一種特殊類型的ThreadGroup的，可用於執行測試後動做。這些線程的行爲徹底像一個正常的線程組元件。不一樣的是，這些類型的線程執行測試結束後執行按期的線程組。
    thread group(線程組)
   這個就是咱們一般添加運行的線程。能夠看作一個虛擬用戶組，線程組中的每一個線程均可以理解爲一個虛擬用戶。線程組中包含的線程數量在測試執行過程當中是不會發生改變的。右鍵點擊「測試計劃」 -> 「添加」-> 「Threads(Users)」 -> 「線程組」 分別如圖8和圖9所示。
   
   
   • 線程數：虛擬用戶數。一個虛擬用戶佔用一個進程或線程。設置多少虛擬用戶數在這裏也就是設置多少個線程數。
   • Ramp-Up Period(in seconds)準備時長：設置的虛擬用戶數須要多長時間所有啓動。若是線程數爲10，準備時長爲2，那麼須要2秒鐘啓動10個線程，也就是每秒鐘啓動5個線程。
   • 循環次數：每一個線程發送請求的次數。若是線程數爲10，循環次數爲100，那麼每一個線程發送100次請求。總請求數爲10*100=1000 。若是勾選了「永遠」，那麼全部線程會一直髮送請求，一到選擇中止運行腳本。
   • Delay Thread creation until needed：直到須要時延遲線程的建立。
   • 調度器：設置線程組啓動的開始時間和結束時間(配置調度器時，須要勾選循環次數爲永遠)
   • 持續時間（秒）：測試持續時間，會覆蓋結束時間
   • 啓動延遲（秒）：測試延遲啓動時間，會覆蓋啓動時間
   3.2.1.3添加http請求
   右鍵點擊「線程組」 -> 「添加」 -> 「Sampler」 -> 「HTTP請求」
   接口地址：http://www.baidu.com/s?ie=utf-8&wd=jmeter接口測試
   圖10和圖11所示：
   
   
   一個HTTP請求有着許多的配置參數，下面將詳細介紹：
    名稱：本屬性用於標識一個取樣器，建議使用一個有意義的名稱。
    註釋：對於測試沒有任何做用，僅用戶記錄用戶可讀的註釋信息。
    服務器名稱或IP ：HTTP請求發送的目標服務器名稱或IP地址。
    端口號：目標服務器的端口號，默認值爲80 。
    協議：向目標服務器發送HTTP請求時的協議，能夠是http或者是https ，默認值爲http 。
    方法：發送HTTP請求的方法，可用方法包括GET、POST、HEAD、PUT、OPTIONS、TRACE、DELETE等。
    Content encoding ：內容的編碼方式，默認值爲iso8859
    路徑：目標URL路徑（不包括服務器地址和端口）
    自動重定向：若是選中該選項，當發送HTTP請求後獲得的響應是302/301時，JMeter 自動重定向到新的頁面。
    Use keep Alive ： 當該選項被選中時，jmeter 和目標服務器之間使用 Keep-Alive方式(又稱持久鏈接、鏈接重用)進行HTTP通訊，默認選中。
    Use multipart/from-data for HTTP POST ：當發送HTTP POST 請求時，使用Use multipart/from-data方法發送，默認不選中。
   3.2.1.4Jmeter參數化
   方式一：
   添加用戶自定義變量
   咱們能夠添加用戶自定義變量用以Http請求參數化，右鍵點擊「線程組」 -> 「添加」 -> 「配置元件」 -> 「用戶定義的變量」。圖12所示：
   
   新增一個參數wd，存放搜索詞"自動化測試"，如圖13所示：
   
   並在Http請求中使用該參數，格式爲：${wd} ，如圖14所示：
   
   方式二："CSV 數據文件設置"
   1.新建一個csv文件，保存以下數據：注意使用notepad編輯，將其轉換爲utf-8編碼方式，不然中文在jmeter中顯示亂碼
   2.右鍵點擊「線程組」 -> 「添加」 -> 「配置元件」 -> 「CSV 數據文件設置」：如圖15和圖16所示：
   
   
   在Http請求中使用該參數，格式爲：${keyword} ，並運行能夠在結果樹中查看到以下結果，則表示已從csv文件中讀取對應的參數。如圖17所示：
   
   3.2.1.5響應斷言
   右鍵點擊「HTTP請求」 -> 「添加」-> 「斷言」 -> 「響應斷言」 ，如圖18所示：
   
   校驗返回的文本中是否包含搜索詞，添加參數${keyword}到要測試的模式中：如圖19所示
   
   模式匹配規則
   • 包括：支持純文本和正則，驗證返回包括指定的內容
   • 匹配：支持純文本和正則，正則需全匹配（正則必須匹配所有返回，而非部分返回）
   • Equals：字符串相等，純文本匹配，驗證返回結果和指定結果徹底一致
   • SubString：字符串包含，純文本匹配，驗證返回結果包含指定結果
   • 否：結合上述條件取反，若上述斷言結果爲false，取否後，最終斷言結果爲true
   3.2.1.6Json斷言
   Json斷言是針對Json報文的斷言方式，通Json Path提取出Json響應報文中的字段，再採用純文本或者正則去驗證Json Path的提取結果，Json結合了Json Path和正則表達式，有以下選項：
   • Additionally assert value：文本驗證，此處是徹底匹配，勾選上此選項後再勾選Match as regular expression，能夠觸發正則匹配。
   • Match as regular expression：支持正則表達式匹配
   • Expect null：斷定返回爲null
   • Invert assertion：倒置斷言結果
   如圖20所示:
   
   3.2.1.7正則表達式提取器
   正則表達式部分配置說明
   （1）引用名稱：下一個請求要引用的參數名稱，如填寫uuid，則可用${uuid}引用它。
   （2）正則表達式：
   ()括起來的部分就是要提取的。
   .匹配任何字符串。
   +：一次或屢次。
   ?：在找到第一個匹配項後中止。
   （3）模板：用$$引用起來，若是在正則表達式中有多個正則表達式（多個括號括起來的東東），則能夠是$2$$3$等等，表示解析到的第幾個值給title。如：$1$表示解析到的第1個值
   （4）匹配數字：0表明隨機取值，1表明所有取值，
   （5）缺省值：若是參數沒有取獲得值，那默認給一個值讓它取。
   3.2.1.8Json提取器
   詳見圖21所示：
   
   3.2.1.9添加察看結果樹
   右鍵點擊「線程組」 -> 「添加」 -> 「監聽器」 -> 「察看結果樹」
   詳見圖22所示
   
   這時，咱們運行Http請求，修改響應數據格式爲「HTML Source Formatted」，能夠看到本次搜索返回結果頁面標題爲」jmeter接口測試_百度搜索。如圖23所示：
   4.jmeter數據驅動定義：一、從數據文件中讀取測試數據，驅動測試過程的一種測試方法。二、數據驅動能夠理解爲更高級的參數化。特色：一、測試數據與測試代碼分離。二、數據控制過程。好處：一、減小測試代碼量。二、下降腳本開發和維護的成本。三、便於用例的修改和維護（不用修改代碼）。