整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
作用：根據響應內容進行判斷，判定請求是否成功
響應斷言界面如下：
Name: 斷言元件的名字，可以隨便命名，最好是有標識意義
Comments：元件的說明或注釋
1)Main sample and sub-samples:作用于主節點的取樣器及對應子節點的取樣器
2)Main sample only：僅作用于主節點的取樣器
3)Sub-samples only: 僅作用于子節點的取樣器
4)JMeter Variable: 作用于jmeter變量(輸入框內可輸入jmeter的變量名稱)，從指定變量值中提取需要的值。
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：請求數據，發送到服務器（即正文）的請求文本，不包括任何 HTTP 頭，相當于結果樹的 Request Body
8)Document(text): 匹配文檔內容
9)Ignore status: 1個請求多項響應斷言時，忽略之前斷言失敗狀態，繼續下一項斷言
1）Contains：響應的結果中包含指定的文本或者字段值，支持正則表達式
2）Match：完全匹配，期望值與實際結果必須完全一致，一般結合正則表達式使用
3）Equals：響應結果與指定的內容完全一致，不支持正則表達式，區分大小寫
4）Substring：返回結果，包含指定的字符串，不支持正則表達式，區分大小寫
5）Not
勾選 Not ，表示預期斷言結果不應存在，如果實際結果與預期值不一致，則結果樹標紅
不勾選 Not，表示預期斷言結果應該存在
6）OR
勾選OR時，當有多個斷言模式時，斷言模式之間就是OR的關系
不勾選OR時，當有多個斷言模式時，斷言模式之間就是AND的關系
輸入要匹配的內容，可以是字符串或正則表達式。可以添加1個或多個，每一個分別驗證。
自定義失敗可以是斷言失敗時的參數化變量取值等
參考資料：
https://jmeter.apache.org/usermanual/component_reference.html#Response_Assertion
勾選OR時
勾選OR時
不勾選OR時
不勾選OR時
（1）響應的簡介
當一個web服務器響應一個http請求時，響應通常包括一個狀態行、一些響應報頭、一個空行和文檔。一個典型的響應如下所示：
HTTP/1.1 200 OK
Content-Type: text/html
Header2: ...
...
HeaderN: ...
(Blank Line)
<!doctype ...>
<html>
<head>...</head>
<body>
...
</body>
</html>
（2）補充：
狀態行包括：http版本、一個狀態碼和一個對應于狀態碼的短消息。
（3）下表總結了從web服務器端返回到瀏覽器的最有用的http1.1響應報頭：
下面的方法可用于servlet程序中設置http響應報頭。這些方法通過HttpServletResponse對象可用。
（1）在webtest工程下的com.web.test包下創建類ResponseInfo
補充：通過用 setIntHeader() 方法來設置 Refresh 頭，達到自動刷新的目的。
（2）啟動tomcat訪問，訪問鏈接如下：
http://localhost:8080/webtest/responseinfo
（3）效果如下
文以HTTP請求和響應的過程來講解涉及到的相關知識點。
圖片來自：理解Http請求與響應以上完整表示了HTTP請求和響應的7個步驟，下面從TCP/IP協議模型的角度來理解HTTP請求和響應如何傳遞的。
TCP/IP協議模型（Transmission Control Protocol/Internet Protocol），包含了一系列構成互聯網基礎的網絡協議，是Internet的核心協議，通過20多年的發展已日漸成熟，并被廣泛應用于局域網和廣域網中，目前已成為事實上的國際標準。TCP/IP協議簇是一組不同層次上的多個協議的組合，通常被認為是一個四層協議系統，與OSI的七層模型相對應。
HTTP協議就是基于TCP/IP協議模型來傳輸信息的。
(1). 鏈路層
也稱作數據鏈路層或網絡接口層（在第一個圖中為網絡接口層和硬件層），通常包括操作系統中的設備驅動程序和計算機中對應的網絡接口卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理接口細節。ARP（地址解析協議）和RARP（逆地址解析協議）是某些網絡接口（如以太網和令牌環網）使用的特殊協議，用來轉換IP層和網絡接口層使用的地址。
(2). 網絡層
也稱作互聯網層（在第一個圖中為網際層），處理分組在網絡中的活動，例如分組的選路。在TCP/IP協議族中，網絡層協議包括IP協議（網際協議），ICMP協議（Internet互聯網控制報文協議），以及IGMP協議（Internet組管理協議）。
IP是一種網絡層協議，提供的是一種不可靠的服務，它只是盡可能快地把分組從源結點送到目的結點，但是并不提供任何可靠性保證。同時被TCP和UDP使用。TCP和UDP的每組數據都通過端系統和每個中間路由器中的IP層在互聯網中進行傳輸。
ICMP是IP協議的附屬協議。IP層用它來與其他主機或路由器交換錯誤報文和其他重要信息。
IGMP是Internet組管理協議。它用來把一個UDP數據報多播到多個主機。
(3). 傳輸層
主要為兩臺主機上的應用程序提供端到端的通信。在TCP/IP協議族中，有兩個互不相同的傳輸協議：TCP（傳輸控制協議）和UDP（用戶數據報協議）。
TCP為兩臺主機提供高可靠性的數據通信。它所做的工作包括把應用程序交給它的數據分成合適的小塊交給下面的網絡層，確認接收到的分組，設置發送最后確認分組的超時時鐘等。由于運輸層提供了高可靠性的端到端的通信，因此應用層可以忽略所有這些細節。為了提供可靠的服務，TCP采用了超時重傳、發送和接收端到端的確認分組等機制。
UDP則為應用層提供一種非常簡單的服務。它只是把稱作數據報的分組從一臺主機發送到另一臺主機，但并不保證該數據報能到達另一端。一個數據報是指從發送方傳輸到接收方的一個信息單元（例如，發送方指定的一定字節數的信息）。UDP協議任何必需的可靠性必須由應用層來提供。
(4). 應用層
應用層決定了向用戶提供應用服務時通信的活動。TCP/IP 協議族內預存了各類通用的應用服務。包括 HTTP，FTP（File Transfer Protocol，文件傳輸協議），DNS（Domain Name System，域名系統）服務。
當應用程序用TCP傳送數據時，數據被送入協議棧中，然后逐個通過每一層直到被當作一串比特流送入網絡。其中每一層對收到的數據都要增加一些首部信息（有時還要增加尾部信息），該過程如圖所示。
當目的主機收到一個以太網數據幀時，數據就開始從協議棧中由底向上升，同時去掉各層協議加上的報文首部。每層協議盒都要去檢查報文首部中的協議標識，以確定接收數據的上層協議。這個過程稱作分用（Demultiplexing）。協議是通過目的端口號、源I P地址和源端口號進行解包的。
通過以上步驟我們從TCP/IP模型的角度來理解了一次HTTP請求與響應的過程。
下面這張圖更清楚明白：
下面具體來看如何進行一步步操作的。
TCP是面向連接的，無論哪一方向另一方發送數據之前，都必須先在雙方之間建立一條連接。在TCP/IP協議中，TCP協議提供可靠的連接服務，連接是通過三次握手進行初始化的。三次握手的目的是同步連接雙方的序列號和確認號并交換 TCP窗口大小信息。
第一次握手：建立連接。客戶端發送連接請求報文段，將SYN位置為1，Sequence Number為x；然后，客戶端進入SYN_SEND狀態，等待服務器的確認；
第二次握手：服務器收到SYN報文段。服務器收到客戶端的SYN報文段，需要對這個SYN報文段進行確認，設置Acknowledgment Number為x+1(Sequence Number+1)；同時，自己自己還要發送SYN請求信息，將SYN位置為1，Sequence Number為y；服務器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中，一并發送給客戶端，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN+ACK報文段。然后將Acknowledgment Number設置為y+1，向服務器發送ACK報文段，這個報文段發送完畢以后，客戶端和服務器端都進入ESTABLISHED狀態，完成TCP三次握手。
為什么要三次握手
為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。
具體例子：“已失效的連接請求報文段”的產生在這樣一種情況下：client發出的第一個連接請求報文段并沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發出的一個新的連接請求。于是就向client發出確認報文段，同意建立連接。假設不采用“三次握手”，那么只要server發出確認，新的連接就建立了。由于現在client并沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以為新的運輸連接已經建立，并一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由于收不到確認，就知道client并沒有要求建立連接。”
Http是什么？
通俗來講，他就是計算機通過網絡進行通信的規則，是一個基于請求與響應，無狀態的，應用層的協議，常基于TCP/IP協議傳輸數據。目前任何終端（手機，筆記本電腦。。）之間進行任何一種通信都必須按照Http協議進行，否則無法連接。
四個基于：
請求與響應：客戶端發送請求，服務器端響應數據
無狀態的：協議對于事務處理沒有記憶能力，客戶端第一次與服務器建立連接發送請求時需要進行一系列的安全認證匹配等，因此增加頁面等待時間，當客戶端向服務器端發送請求，服務器端響應完畢后，兩者斷開連接，也不保存連接狀態，一刀兩斷！恩斷義絕！從此路人！下一次客戶端向同樣的服務器發送請求時，由于他們之前已經遺忘了彼此，所以需要重新建立連接。
應用層：Http是屬于應用層的協議，配合TCP/IP使用。
TCP/IP：Http使用TCP作為它的支撐運輸協議。HTTP客戶機發起一個與服務器的TCP連接，一旦連接建立，瀏覽器（客戶機）和服務器進程就可以通過套接字接口訪問TCP。
針對無狀態的一些解決策略：
有時需要對用戶之前的HTTP通信狀態進行保存，比如執行一次登陸操作，在30分鐘內所有的請求都不需要再次登陸。于是引入了Cookie技術。
HTTP/1.1想出了持久連接（HTTP keep-alive）方法。其特點是，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態，在請求首部字段中的Connection: keep-alive即為表明使用了持久連接。
等等還有很多。。。。。。
下面開始講解重頭戲：HTTP請求報文，響應報文，對應于上述步驟的2，3，4，5，6。
HTTP報文是面向文本的，報文中的每一個字段都是一些ASCII碼串，各個字段的長度是不確定的。HTTP有兩類報文：請求報文和響應報文。
一個HTTP請求報文由請求行（request line）、請求頭部（header）、空行和請求數據4個部分組成，下圖給出了請求報文的一般格式。
1.請求行
請求行分為三個部分：請求方法、請求地址和協議版本
請求方法
HTTP/1.1 定義的請求方法有8種：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。
最常的兩種GET和POST，如果是RESTful接口的話一般會用到GET、POST、DELETE、PUT。
請求地址
URL:統一資源定位符，是一種自愿位置的抽象唯一識別方法。
組成：<協議>：//<主機>：<端口>/<路徑>
端口和路徑有時可以省略（HTTP默認端口號是80）
如下例：
有時會帶參數，GET請求
協議版本
協議版本的格式為：HTTP/主版本號.次版本號，常用的有HTTP/1.0和HTTP/1.1
2.請求頭部
請求頭部為請求報文添加了一些附加信息，由“名/值”對組成，每行一對，名和值之間使用冒號分隔。
常見請求頭如下：
請求頭部的最后會有一個空行，表示請求頭部結束，接下來為請求數據，這一行非常重要，必不可少。
3.請求數據
可選部分，比如GET請求就沒有請求數據。
下面是一個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 請求數據
HTTP響應報文主要由狀態行、響應頭部、空行以及響應數據組成。
1.狀態行
由3部分組成，分別為：協議版本，狀態碼，狀態碼描述。
其中協議版本與請求報文一致，狀態碼描述是對狀態碼的簡單描述，所以這里就只介紹狀態碼。
狀態碼
狀態代碼為3位數字。
1xx：指示信息--表示請求已接收，繼續處理。
2xx：成功--表示請求已被成功接收、理解、接受。
3xx：重定向--要完成請求必須進行更進一步的操作。
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現。
5xx：服務器端錯誤--服務器未能實現合法的請求。
下面列舉幾個常見的：
2.響應頭部
與請求頭部類似，為響應報文添加了一些附加信息
常見響應頭部如下：
3.響應數據
用于存放需要返回給客戶端的數據信息。
下面是一個響應報文的實例：
HTTP/1.1 200 OK 狀態行
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> 響應數據
<head>
<title>HTTP響應示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>
關于請求頭部和響應頭部的知識點很多，這里只是簡單介紹。
通過以上步驟，數據已經傳遞完畢，HTTP/1.1會維持持久連接，但持續一段時間總會有關閉連接的時候，這時候據需要斷開TCP連接。
當客戶端和服務器通過三次握手建立了TCP連接以后，當數據傳送完畢，肯定是要斷開TCP連接的啊。那對于TCP的斷開連接，這里就有了神秘的“四次分手”。
第一次分手：主機1（可以使客戶端，也可以是服務器端），設置Sequence Number，向主機2發送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有數據要發送給主機2了；
第二次分手：主機2收到了主機1發送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我“同意”你的關閉請求；
第三次分手：主機2向主機1發送FIN報文段，請求關閉連接，同時主機2進入LAST_ACK狀態；
第四次分手：主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，然后主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段以后，就關閉連接；此時，主機1等待2MSL后依然沒有收到回復，則證明Server端已正常關閉，那好，主機1也可以關閉連接了。
為什么要四次分手
TCP協議是一種面向連接的、可靠的、基于字節流的運輸層通信協議。TCP是全雙工模式，這就意味著，當主機1發出FIN報文段時，只是表示主機1已經沒有數據要發送了，主機1告訴主機2，它的數據已經全部發送完畢了；但是，這個時候主機1還是可以接受來自主機2的數據；當主機2返回ACK報文段時，表示它已經知道主機1沒有數據發送了，但是主機2還是可以發送數據到主機1的；當主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告訴主機1，我也沒有數據要發送了，之后彼此就會愉快的中斷這次TCP連接。
通過以上步驟便完成了HTTP的請求和響應，進行了數據傳遞，這其中涉及到需要知識點，都進行了逐一了解。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
