Jmeter(十九)-響應斷言

應斷言

作用：根據(jù)響應內(nèi)容進行判斷，判定請求是否成功

詳細說明

響應斷言界面如下：

Name: 斷言元件的名字，可以隨便命名，最好是有標識意義

Comments：元件的說明或注釋

Apply to:作用范圍

1)Main sample and sub-samples:作用于主節(jié)點的取樣器及對應子節(jié)點的取樣器

2)Main sample only：僅作用于主節(jié)點的取樣器

3)Sub-samples only: 僅作用于子節(jié)點的取樣器

4)JMeter Variable: 作用于jmeter變量(輸入框內(nèi)可輸入jmeter的變量名稱)，從指定變量值中提取需要的值。

Field to Test：需要斷言測試請求或響應中的哪個域

1）Text Response：響應文本，來自服務器的響應文本，即正文，不包括任何 HTTP 頭，相當于結果樹的 Response Body；最常用及默認值

2）Response Code：響應碼，在結果樹的取樣器結果中可看到

3）Response Message：響應信息，在結果樹的取樣器結果中可看到

4）Response Headers：響應頭，相當于結果樹的 Response headers

5）Request Headers：請求頭，相當于結果樹的 Request headers

6）URL Sampler：請求 URL

7）Request Data：請求數(shù)據(jù)，發(fā)送到服務器（即正文）的請求文本，不包括任何 HTTP 頭，相當于結果樹的 Request Body

8)Document(text): 匹配文檔內(nèi)容

9)Ignore status: 1個請求多項響應斷言時，忽略之前斷言失敗狀態(tài)，繼續(xù)下一項斷言

Pattern Matching Rules ：匹配規(guī)則

1）Contains：響應的結果中包含指定的文本或者字段值，支持正則表達式

2）Match：完全匹配，期望值與實際結果必須完全一致，一般結合正則表達式使用

3）Equals：響應結果與指定的內(nèi)容完全一致，不支持正則表達式，區(qū)分大小寫

4）Substring：返回結果，包含指定的字符串，不支持正則表達式，區(qū)分大小寫

5）Not

勾選 Not ，表示預期斷言結果不應存在，如果實際結果與預期值不一致，則結果樹標紅

不勾選 Not，表示預期斷言結果應該存在

6）OR

勾選OR時，當有多個斷言模式時，斷言模式之間就是OR的關系

不勾選OR時，當有多個斷言模式時，斷言模式之間就是AND的關系

Patterns to Test：斷言的模式

輸入要匹配的內(nèi)容，可以是字符串或正則表達式。可以添加1個或多個，每一個分別驗證。

Custom failure message:自定義斷言失敗時的輸出信息

自定義失敗可以是斷言失敗時的參數(shù)化變量取值等

參考資料：

https://jmeter.apache.org/usermanual/component_reference.html#Response_Assertion

樣例

常用斷言樣例

OR斷言樣例

勾選OR時

勾選OR時

不勾選OR時

不勾選OR時

NOT斷言樣例

正式表達式斷言樣例

自定義失敗信息樣例

. Http在瀏覽器端的14個響應頭信息

（1）響應的簡介

當一個web服務器響應一個http請求時，響應通常包括一個狀態(tài)行、一些響應報頭、一個空行和文檔。一個典型的響應如下所示：

HTTP/1.1 200 OK

Content-Type: text/html

Header2: ...

...

HeaderN: ...

(Blank Line)

<!doctype ...>

<html>

<body>

...

</body>

</html>

（2）補充：

狀態(tài)行包括：http版本、一個狀態(tài)碼和一個對應于狀態(tài)碼的短消息。

（3）下表總結了從web服務器端返回到瀏覽器的最有用的http1.1響應報頭：

2. servlet設置http響應報頭的方法：

下面的方法可用于servlet程序中設置http響應報頭。這些方法通過HttpServletResponse對象可用。

3. servlet設置http header響應的代碼實例

（1）在webtest工程下的com.web.test包下創(chuàng)建類ResponseInfo

補充：通過用 setIntHeader() 方法來設置 Refresh 頭，達到自動刷新的目的。

（2）啟動tomcat訪問，訪問鏈接如下：

http://localhost:8080/webtest/responseinfo

（3）效果如下

此頭條號每天都會分享非常實用的技術文章和筆試題講解，歡迎大家關注此頭條號！

文以HTTP請求和響應的過程來講解涉及到的相關知識點。

一、 HTTP請求和響應步驟

圖片來自：理解Http請求與響應以上完整表示了HTTP請求和響應的7個步驟，下面從TCP/IP協(xié)議模型的角度來理解HTTP請求和響應如何傳遞的。

二、TCP/IP協(xié)議

TCP/IP協(xié)議模型（Transmission Control Protocol/Internet Protocol），包含了一系列構成互聯(lián)網(wǎng)基礎的網(wǎng)絡協(xié)議，是Internet的核心協(xié)議，通過20多年的發(fā)展已日漸成熟，并被廣泛應用于局域網(wǎng)和廣域網(wǎng)中，目前已成為事實上的國際標準。TCP/IP協(xié)議簇是一組不同層次上的多個協(xié)議的組合，通常被認為是一個四層協(xié)議系統(tǒng)，與OSI的七層模型相對應。

HTTP協(xié)議就是基于TCP/IP協(xié)議模型來傳輸信息的。

(1). 鏈路層

也稱作數(shù)據(jù)鏈路層或網(wǎng)絡接口層（在第一個圖中為網(wǎng)絡接口層和硬件層），通常包括操作系統(tǒng)中的設備驅(qū)動程序和計算機中對應的網(wǎng)絡接口卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理接口細節(jié)。ARP（地址解析協(xié)議）和RARP（逆地址解析協(xié)議）是某些網(wǎng)絡接口（如以太網(wǎng)和令牌環(huán)網(wǎng)）使用的特殊協(xié)議，用來轉(zhuǎn)換IP層和網(wǎng)絡接口層使用的地址。

(2). 網(wǎng)絡層

也稱作互聯(lián)網(wǎng)層（在第一個圖中為網(wǎng)際層），處理分組在網(wǎng)絡中的活動，例如分組的選路。在TCP/IP協(xié)議族中，網(wǎng)絡層協(xié)議包括IP協(xié)議（網(wǎng)際協(xié)議），ICMP協(xié)議（Internet互聯(lián)網(wǎng)控制報文協(xié)議），以及IGMP協(xié)議（Internet組管理協(xié)議）。

IP是一種網(wǎng)絡層協(xié)議，提供的是一種不可靠的服務，它只是盡可能快地把分組從源結點送到目的結點，但是并不提供任何可靠性保證。同時被TCP和UDP使用。TCP和UDP的每組數(shù)據(jù)都通過端系統(tǒng)和每個中間路由器中的IP層在互聯(lián)網(wǎng)中進行傳輸。

ICMP是IP協(xié)議的附屬協(xié)議。IP層用它來與其他主機或路由器交換錯誤報文和其他重要信息。

IGMP是Internet組管理協(xié)議。它用來把一個UDP數(shù)據(jù)報多播到多個主機。

(3). 傳輸層

主要為兩臺主機上的應用程序提供端到端的通信。在TCP/IP協(xié)議族中，有兩個互不相同的傳輸協(xié)議：TCP（傳輸控制協(xié)議）和UDP（用戶數(shù)據(jù)報協(xié)議）。

TCP為兩臺主機提供高可靠性的數(shù)據(jù)通信。它所做的工作包括把應用程序交給它的數(shù)據(jù)分成合適的小塊交給下面的網(wǎng)絡層，確認接收到的分組，設置發(fā)送最后確認分組的超時時鐘等。由于運輸層提供了高可靠性的端到端的通信，因此應用層可以忽略所有這些細節(jié)。為了提供可靠的服務，TCP采用了超時重傳、發(fā)送和接收端到端的確認分組等機制。

UDP則為應用層提供一種非常簡單的服務。它只是把稱作數(shù)據(jù)報的分組從一臺主機發(fā)送到另一臺主機，但并不保證該數(shù)據(jù)報能到達另一端。一個數(shù)據(jù)報是指從發(fā)送方傳輸?shù)浇邮辗降囊粋€信息單元（例如，發(fā)送方指定的一定字節(jié)數(shù)的信息）。UDP協(xié)議任何必需的可靠性必須由應用層來提供。

(4). 應用層

應用層決定了向用戶提供應用服務時通信的活動。TCP/IP 協(xié)議族內(nèi)預存了各類通用的應用服務。包括 HTTP，F(xiàn)TP（File Transfer Protocol，文件傳輸協(xié)議），DNS（Domain Name System，域名系統(tǒng)）服務。

當應用程序用TCP傳送數(shù)據(jù)時，數(shù)據(jù)被送入?yún)f(xié)議棧中，然后逐個通過每一層直到被當作一串比特流送入網(wǎng)絡。其中每一層對收到的數(shù)據(jù)都要增加一些首部信息（有時還要增加尾部信息），該過程如圖所示。

當目的主機收到一個以太網(wǎng)數(shù)據(jù)幀時，數(shù)據(jù)就開始從協(xié)議棧中由底向上升，同時去掉各層協(xié)議加上的報文首部。每層協(xié)議盒都要去檢查報文首部中的協(xié)議標識，以確定接收數(shù)據(jù)的上層協(xié)議。這個過程稱作分用（Demultiplexing）。協(xié)議是通過目的端口號、源I P地址和源端口號進行解包的。

通過以上步驟我們從TCP/IP模型的角度來理解了一次HTTP請求與響應的過程。

下面這張圖更清楚明白：

下面具體來看如何進行一步步操作的。

三、TCP三次握手

TCP是面向連接的，無論哪一方向另一方發(fā)送數(shù)據(jù)之前，都必須先在雙方之間建立一條連接。在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務，連接是通過三次握手進行初始化的。三次握手的目的是同步連接雙方的序列號和確認號并交換 TCP窗口大小信息。

第一次握手：建立連接。客戶端發(fā)送連接請求報文段，將SYN位置為1，Sequence Number為x；然后，客戶端進入SYN_SEND狀態(tài)，等待服務器的確認；

第二次握手：服務器收到SYN報文段。服務器收到客戶端的SYN報文段，需要對這個SYN報文段進行確認，設置Acknowledgment Number為x+1(Sequence Number+1)；同時，自己自己還要發(fā)送SYN請求信息，將SYN位置為1，Sequence Number為y；服務器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中，一并發(fā)送給客戶端，此時服務器進入SYN_RECV狀態(tài)；

第三次握手：客戶端收到服務器的SYN+ACK報文段。然后將Acknowledgment Number設置為y+1，向服務器發(fā)送ACK報文段，這個報文段發(fā)送完畢以后，客戶端和服務器端都進入ESTABLISHED狀態(tài)，完成TCP三次握手。

為什么要三次握手

為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產(chǎn)生錯誤。

具體例子：“已失效的連接請求報文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發(fā)出的一個新的連接請求。于是就向client發(fā)出確認報文段，同意建立連接。假設不采用“三次握手”，那么只要server發(fā)出確認，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會理睬server的確認，也不會向server發(fā)送數(shù)據(jù)。但server卻以為新的運輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會向server的確認發(fā)出確認。server由于收不到確認，就知道client并沒有要求建立連接。”

四、HTTP協(xié)議

Http是什么？

通俗來講，他就是計算機通過網(wǎng)絡進行通信的規(guī)則，是一個基于請求與響應，無狀態(tài)的，應用層的協(xié)議，常基于TCP/IP協(xié)議傳輸數(shù)據(jù)。目前任何終端（手機，筆記本電腦。。）之間進行任何一種通信都必須按照Http協(xié)議進行，否則無法連接。

四個基于：

請求與響應：客戶端發(fā)送請求，服務器端響應數(shù)據(jù)

無狀態(tài)的：協(xié)議對于事務處理沒有記憶能力，客戶端第一次與服務器建立連接發(fā)送請求時需要進行一系列的安全認證匹配等，因此增加頁面等待時間，當客戶端向服務器端發(fā)送請求，服務器端響應完畢后，兩者斷開連接，也不保存連接狀態(tài)，一刀兩斷！恩斷義絕！從此路人！下一次客戶端向同樣的服務器發(fā)送請求時，由于他們之前已經(jīng)遺忘了彼此，所以需要重新建立連接。

應用層：Http是屬于應用層的協(xié)議，配合TCP/IP使用。

TCP/IP：Http使用TCP作為它的支撐運輸協(xié)議。HTTP客戶機發(fā)起一個與服務器的TCP連接，一旦連接建立，瀏覽器（客戶機）和服務器進程就可以通過套接字接口訪問TCP。

針對無狀態(tài)的一些解決策略：

有時需要對用戶之前的HTTP通信狀態(tài)進行保存，比如執(zhí)行一次登陸操作，在30分鐘內(nèi)所有的請求都不需要再次登陸。于是引入了Cookie技術。

HTTP/1.1想出了持久連接（HTTP keep-alive）方法。其特點是，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態(tài)，在請求首部字段中的Connection: keep-alive即為表明使用了持久連接。

等等還有很多。。。。。。

下面開始講解重頭戲：HTTP請求報文，響應報文，對應于上述步驟的2，3，4，5，6。

HTTP報文是面向文本的，報文中的每一個字段都是一些ASCII碼串，各個字段的長度是不確定的。HTTP有兩類報文：請求報文和響應報文。

五、HTTP請求報文

一個HTTP請求報文由請求行（request line）、請求頭部（header）、空行和請求數(shù)據(jù)4個部分組成，下圖給出了請求報文的一般格式。

1.請求行

請求行分為三個部分：請求方法、請求地址和協(xié)議版本

請求方法

HTTP/1.1 定義的請求方法有8種：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。

最常的兩種GET和POST，如果是RESTful接口的話一般會用到GET、POST、DELETE、PUT。

請求地址

URL:統(tǒng)一資源定位符，是一種自愿位置的抽象唯一識別方法。

組成：<協(xié)議>：//<主機>：<端口>/<路徑>

端口和路徑有時可以省略（HTTP默認端口號是80）

如下例：

有時會帶參數(shù)，GET請求

協(xié)議版本

協(xié)議版本的格式為：HTTP/主版本號.次版本號，常用的有HTTP/1.0和HTTP/1.1

2.請求頭部

請求頭部為請求報文添加了一些附加信息，由“名/值”對組成，每行一對，名和值之間使用冒號分隔。

常見請求頭如下：

請求頭部的最后會有一個空行，表示請求頭部結束，接下來為請求數(shù)據(jù)，這一行非常重要，必不可少。

3.請求數(shù)據(jù)

可選部分，比如GET請求就沒有請求數(shù)據(jù)。

下面是一個POST方法的請求報文：

POST /index.php　HTTP/1.1 請求行
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 請求頭
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://localhost/
Content-Length：25
Content-Type：application/x-www-form-urlencoded
空行
username=aa&password=1234 請求數(shù)據(jù)

六、HTTP響應報文

HTTP響應報文主要由狀態(tài)行、響應頭部、空行以及響應數(shù)據(jù)組成。

1.狀態(tài)行

由3部分組成，分別為：協(xié)議版本，狀態(tài)碼，狀態(tài)碼描述。

其中協(xié)議版本與請求報文一致，狀態(tài)碼描述是對狀態(tài)碼的簡單描述，所以這里就只介紹狀態(tài)碼。

狀態(tài)碼

狀態(tài)代碼為3位數(shù)字。

1xx：指示信息--表示請求已接收，繼續(xù)處理。

2xx：成功--表示請求已被成功接收、理解、接受。

3xx：重定向--要完成請求必須進行更進一步的操作。

4xx：客戶端錯誤--請求有語法錯誤或請求無法實現(xiàn)。

5xx：服務器端錯誤--服務器未能實現(xiàn)合法的請求。

下面列舉幾個常見的：

2.響應頭部

與請求頭部類似，為響應報文添加了一些附加信息

常見響應頭部如下：

3.響應數(shù)據(jù)

用于存放需要返回給客戶端的數(shù)據(jù)信息。

下面是一個響應報文的實例：

HTTP/1.1 200 OK 狀態(tài)行

Date: Sun, 17 Mar 2013 08:12:54 GMT 響應頭部

Server: Apache/2.2.8 (Win32) PHP/5.2.5

X-Powered-By: PHP/5.2.5

Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

Content-Length: 4393

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive

Content-Type: text/html; charset=utf-8

空行
<html> 響應數(shù)據(jù)
<head>
<title>HTTP響應示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>

關于請求頭部和響應頭部的知識點很多，這里只是簡單介紹。

通過以上步驟，數(shù)據(jù)已經(jīng)傳遞完畢，HTTP/1.1會維持持久連接，但持續(xù)一段時間總會有關閉連接的時候，這時候據(jù)需要斷開TCP連接。

七、TCP四次揮手

當客戶端和服務器通過三次握手建立了TCP連接以后，當數(shù)據(jù)傳送完畢，肯定是要斷開TCP連接的啊。那對于TCP的斷開連接，這里就有了神秘的“四次分手”。

第一次分手：主機1（可以使客戶端，也可以是服務器端），設置Sequence Number，向主機2發(fā)送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態(tài)；這表示主機1沒有數(shù)據(jù)要發(fā)送給主機2了；

第二次分手：主機2收到了主機1發(fā)送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進入FIN_WAIT_2狀態(tài)；主機2告訴主機1，我“同意”你的關閉請求；

第三次分手：主機2向主機1發(fā)送FIN報文段，請求關閉連接，同時主機2進入LAST_ACK狀態(tài)；

第四次分手：主機1收到主機2發(fā)送的FIN報文段，向主機2發(fā)送ACK報文段，然后主機1進入TIME_WAIT狀態(tài)；主機2收到主機1的ACK報文段以后，就關閉連接；此時，主機1等待2MSL后依然沒有收到回復，則證明Server端已正常關閉，那好，主機1也可以關閉連接了。

為什么要四次分手

TCP協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的運輸層通信協(xié)議。TCP是全雙工模式，這就意味著，當主機1發(fā)出FIN報文段時，只是表示主機1已經(jīng)沒有數(shù)據(jù)要發(fā)送了，主機1告訴主機2，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了；但是，這個時候主機1還是可以接受來自主機2的數(shù)據(jù)；當主機2返回ACK報文段時，表示它已經(jīng)知道主機1沒有數(shù)據(jù)發(fā)送了，但是主機2還是可以發(fā)送數(shù)據(jù)到主機1的；當主機2也發(fā)送了FIN報文段時，這個時候就表示主機2也沒有數(shù)據(jù)要發(fā)送了，就會告訴主機1，我也沒有數(shù)據(jù)要發(fā)送了，之后彼此就會愉快的中斷這次TCP連接。

通過以上步驟便完成了HTTP的請求和響應，進行了數(shù)據(jù)傳遞，這其中涉及到需要知識點，都進行了逐一了解。

在線咨詢

上一篇：CSS clear 屬性
下一篇：最少的代碼實現(xiàn)樹形菜單（Jquery+CSS）

您的項目需求

*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。

整合營銷服務商