版權聲明：本文為原創文章，轉載請先聯系並標明出處
在正式介紹檢查點之前，我們先思考一個問題：在性能測試的過程中，如何才能算是腳本正確執行？
我們說，一個性能測試負載模型建立的再好，一個性能測試方案設計的再完美，如果在實際落地的時候，腳本實現或者執行卻有問題，那么前面的一切也都是白搭。所以，問題來了，到底怎么樣才能算是一個腳本正確的執行呢？
我認為這個正確應該分為兩點：一是腳本正確；二是執行正確；
腳本正確很容易理解，就是你的腳本完全實現了你對應的用例，使用用戶、操作步驟、輸入數據都與你的用例一般無二；
而執行正確，我認為至少要分三點：
1、最基本的一點是腳本執行沒有報錯；
2、再者，即便測試腳本沒有報錯並不代表測試腳本是正確的按照預期輸出，不僅是HyperPacer，對於任何一種測試工具來說，都是根據HTTP狀態碼來判斷返回成功還是失敗的。也就是說只要HTTP的狀態碼是200它就認為這個請求通過了，而我們系統在設計的時候為了用戶體驗，一般不會直接報錯，而是設計相應的錯誤頁面或者異常提示頁面，這樣在執行過程中，我們的操作或者數據出現異常了，然后返回有一個異常提示的頁面。這時候，對於工具來說也是有響應返回，而且狀態碼為200，所以測試工具認為是正確的，但是對於我們的測試用例中預期輸出來說，實際上這是失敗了，所以這樣也不算是執行正確；
3、最后一點就是腳本跑並發的時候是按照測試方案設計的模型運行的，即並發用戶數、每個模擬用戶使用的參數化數據、處理數據都是按照方案設計運行的。譬如，我們性能測試方案中設計的是要並發的每個用戶都使用不同的用戶名，錄入不同的數據，如果我們運行的時候所有並發用戶都是使用一個用戶名，錄入的數據也都一樣，那么就跟我們方案預期的運行模式不一樣，這樣也不算是執行正確。
滿足以上三點，我認為才是一個腳本正確的執行了。
基於以上的理解，我們再來看，第一點很容易驗證，執行一下看有沒有報錯就可以了。第二點和第三點該如何保證和確認呢，這就說到我們這次要介紹的另一種技巧了——檢查點。
檢查點，顧名思義就是用來進行檢查，一般是通過預期的文本內容或者大小等特征來與實際返回進行比對，與比對規則能匹配上，則檢查通過，反之則不通過。
在HyperPacer中提供5種不同的檢查類型，分別為：
- Response：響應內容檢查
- Duration：響應時間檢查
- Size：響應文件大小檢查
- Variables：響應內容中變量檢查
- Function：自定義功能檢查
下面我們來逐個說明。
1、RESPONSE：響應內容檢查
響應內容檢查一般應用在響應的結果驗證，即我們上文中所提到的第二點，響應需要是成功的。
取值范圍：設置進行檢查點校驗的取樣器范圍
- 父節點：檢查點僅應用於父節點
- 兄弟節點：檢查點應用於所有平行節點
- 所有節點：檢查點應用於所有節點
檢查范圍：此選項可以設定測試的響應域。
- TextResponse：來自服務器的響應文本，即主體，不包括任何HTTP頭
- Document(text)：從不同類型的文檔中提取的文本
- URLSampled
- ResponseCode：例如200
- ResponseMessage：例如OK
- ResponseHeaders：包括設置的Cookie頭(如果有的話)
忽略響應狀態：將響應的初始狀態設置為成功。
HTTP響應狀態在4xx和5xx范圍內，通常被認定為失敗。"忽略響應狀態"設置為true，可以在進行進一步檢查之前將響應狀態強制設置為成功。請注意，這種設置將會導致清除之前任何失敗的檢查點，所以請確保這只是設置在第一個檢查點上。
匹配規則：設定使用哪種模式測試文本。
- 包含：文本中包含正則表達式
- 完全匹配：整個文本能夠完全匹配正則表達式
- 相等：整個文本等於匹配字符串（區分大小寫）
- 包含子字符串：文本中包含匹配字符串（區分大小寫）
- 不包含：文本中不包含正則表達式
- 不完全匹配：文本不能夠完全匹配正則表達式
- 不相等：文本不等於匹配字符串（區分大小寫）
- 不包含子字符串：文本中不包含匹配字符串（區分大小寫）
注意！相等和子字符串模式使用的是純字符串，不是正則表達式。
匹配項列表：被測試的匹配項列表。
分別測試每個匹配項。如果一個匹配項失敗，那么不會繼續檢查下面的匹配項。添加一個設置多種匹配項的檢查點和添加多個只設置一種匹配項的檢查點，效果是一樣的（假設其他的選項是一樣的）。
2、DURATION：響應時間檢查
持續時間（ms）： 檢查的持續時間，如果為0，那么此檢查點將被忽略。
3、SIZE：響應文件大小檢查
取值范圍： 進行取值判斷的范圍，包括Full、Head、Body、Code、Message。
比較規則：檢查時使用的運算規則。包括：相等、不相等、大於、小於、大於等於、小於等於。
比較大小：要檢查的字節數。需配合比較規則使用。
4、VARIABLES：響應內容中變量檢查
名稱： 要檢查的變量名稱
類型： 選擇要檢查的變量類型：數值、字符串、對象。
匹配規則： 根據選擇的類型，選擇執行的匹配規則。
值： 輸入要對變量進行檢查的值。
5、FUNCTION：自定義功能檢查
函數： 在其他檢查類型均不滿足時，可通過自動義編寫的函數進行檢查。編寫的語法可參考HyperPacer幫助手冊中的計算表達式語法手冊，如果有疑問，可以QQ用戶服務群（237936872）咨詢。
介紹完了原理，我們以“用戶登錄業務系統”為例來說明一下檢查點在實際的性能測試工作中是怎么使用的。
首先，我們需要創建一個檢查點，在HyperPacer中，支持對測試場景、事務、具體的請求等設置檢查點。此例中，我們要驗證用戶登錄成功，所以將檢查點創建在用戶登錄的取樣器下，命名為Check：
我們要驗證登錄是成功的而非登錄異常，即需要檢查響應代碼為200或者響應消息為OK，則Check檢查點選擇Response響應內容檢查，檢查范圍選擇Response Code，匹配規則為完全等於，設置完成后保存檢查點設置：
檢查點設置成功后，需要調試運行，校驗檢查點是否設置正確：
在快照瀏覽器中選擇登錄取樣器，查看“檢查結果”頁簽，Check檢查點沒有出現異常，狀態為ture，表明該檢查點被執行通過。
當檢查點執行失敗時，快照瀏覽器中該取樣器快照標紅顯示，且檢查結果頁簽，狀態為false，並給出錯誤的詳細信息，如下圖：
以上這個檢查點設置，很好的解決了“腳本執行通過但數據執行失敗”的問題。那么，為了保證我們的腳本完全正確，是不是可以在每個請求下面都添加這樣一個檢查點呢？可以。但是我們強烈建議您不要這么做。因為每個檢查點的對比校驗都是一次性能損耗，盡管這種損耗非常小，但是量變引起質變，做的太多的話，腳本本身的性能損耗可能導致性能測試結果的嚴重失真。所以，只要在每個事務中選擇最關鍵的一個請求進行檢查就可以了。
參考文章： LoadRunner技巧之檢查點
原文出處