你想要：
断言是要走的路。
问题是：你不知道如何开始。并且可用断言的数量是压倒性的。别担心！
这个关于JMeter Assertion的终极指南通过综合例子探讨了每一个断言类型。你会明白何时以及如何明智地使用各种断言。一旦你阅读了本指南，断言将不再对你有任何秘密！我们走吧。
一般概念
在本节中，我们将介绍适用于所有断言的概念。它们都不取决于您要使用的断言类型。
支持的断言
JMeter断言必须对采样器的结果执行额外的检查。断言是后处理器元素系列的一部分。
JMeter提供了各种各样的断言，可以在许多不同的场景中使用：
| 类型 | 用法 |
|---|---|
| 响应断言 | 应用字符串模式以验证服务器响应 |
| 持续时间断言 | 检查在给定的经过时间内收到的响应 |
| 大小断言 | 检查服务器响应的大小是否包含所需的字节数 |
| XML断言 | 检查响应是否是有效的XML文档 |
| Beanshell断言 | 使用Beanshell脚本执行您自己的逻辑 |
| MD5Hex断言 | 允许检查响应数据的MD5哈希值（非常适合静态文件） |
| HTML断言 | 使用JTidy检查html响应语法 |
| XPath断言 | 测试文档是否格式正确，可能进行DTD验证，或者将文档放在JTidy中并使用XPath进行测试 |
| XML Shema断言 | 根据XML模式验证XML响应 |
| JSR223断言 | 使用JSR223脚本运行您自己的代码逻辑 |
| 比较断言 | 比较他们自己之间的结果 |
| SMIME断言 | 评估Mail Reader Sampler的样本结果 |
| JSON断言 | 执行JsonPath表达式并验证Json文档 |
你应该使用哪种断言？它归结为你必须检查的那种反应。
断言范围
你应该使用哪个范围？
断言范围定义断言适用于哪个样本结果：
- 仅限主样本：仅适用于采样器的结果（在大多数情况下是HTTP请求），
- 主样本和子样本：一些采样器可以生成子样本。例如，
Retrieve All Embedded Resources在HTTP请求采样器上启用时会发生这种情况。每个资源（CSS，图像，Javascript等...）生成子样本结果， - 仅限子样本：仅适用于子样本结果，
- JMeter变量：对变量的值应用断言（如
${foo}）。
在大多数情况下，您将需要使用“ 仅主样本”选项。断言很少应用于主要结果和子结果。
断言位置
正如我们之前所说，断言是一种特殊的后处理器。
断言适用于在相同级别或以下定义的采样器。如果不是，则仅适用于父采样器。
让我们用一些例子来理解这个概念：
采样器A下的断言
- 在上面的例子中，断言仅适用于采样器A，
控制器A之后的断言
- 在这种情况下，断言适用于采样器A和采样器B，
控制器B后断言
- 在这种情况下，断言适用于取样器和采样乙和采样Ç。
我能给出的最好建议是：保持简单和愚蠢。将断言定义为采样器的子项，避免尝试过于聪明。越容易理解脚本的可维护性越强。
此外，当断言失败时，故障将扩散到采样器周围的逻辑控制器。这意味着失败的断言会导致关联的控制器也失败。
性能
您必须意识到大多数断言都是CPU和内存耗尽。下表定义了每种类型的断言需要多少资源：
| 断言 | CPU /内存使用情况 | 笔记 |
|---|---|---|
| 响应断言 | 中等 | 常用表达 |
| 持续时间断言 | 低 | |
| 大小断言 | 低 | |
| XML断言 | 高 | 构建XML DOM文档 |
| Beanshell断言 | 变量 | 取决于脚本逻辑 |
| MD5Hex断言 | 低 | |
| HTML断言 | 高 | 解析HTML响应 |
| XPath断言 | 高 | 构建XML DOM文档 |
| XML Schema断言 | 高 | 构建XML DOM文档 |
| JSR223断言 | 变量 | 取决于脚本逻辑 |
| 比较断言 | 高 | 解析响应并进行比较 |
| SMIME断言 | 中等 | |
| Json Assertion | 高 | 解析Json文档 |
每种颜色都有自己的含义：
- 低：可以自由使用，性能开销很低，
- 中等：特别是在大服务器响应上使用它们（如数百KB，几MB），
- 高：主要仅适用于功能测试或非常轻负载（少于10个并发用户）。
优化断言用法只是优化JMeter进行大规模测试的一小部分。如果您在负载测试期间看到CPU /内存使用情况通过屋顶并有断言，请尝试禁用/删除不需要的内容。
像Beanshell或JSR223断言这样的脚本断言具有可变的性能：它实际上取决于脚本检查的内容。此外，由于这些设置没有任何范围UI设置，因此您必须手动通过脚本定义脚本应用的样本结果。
断言结果
查看断言失败的最佳方法是使用“ 查看结果树”侦听器。当然，还有许多其他方法可以分析JMeter结果。
断言失败说明
在上面的屏幕截图中，我们可以看到断言失败。通过单击断言，我们可以看到详细的错误消息：
Assertion error: false
Assertion failure: true
...
在这种情况下，响应包含John Smith但是断言检查它包含John Doe。
现在让我们更详细地了解每个断言是如何工作的！
虚拟采样器
以下所有示例均使用虚拟采样器进行模拟。
具有JSON响应的JMeter虚拟采样器
它可以轻松地尝试各种断言，而无需使用正确的响应设置远程端点。亲自尝试一下！
常见断言
以下断言是Performance Engineers最常使用的断言。这些断言涵盖了广泛的用例。了解如何使用它们是正确断言服务器响应的关键。
响应断言
JMeter响应断言
JMeter响应断言文档
JMeter响应断言可能是最常用的JMeter断言之一。它包括以下设置：
- 要测试的字段：可以是文本响应，响应代码，文档（文本）等。告诉应该应用断言的服务器响应的哪一部分，
- 模式匹配规则：包含，匹配，的Equals，子串用
Not和Or选项。默认情况下，它会检查是否验证了要测试的所有模式。通过检查Or选项，只有一个要测试的模式必须为true， - 要测试的模式：必须针对要测试的字段测试的字符串值。
JMeter响应断言失败
通常，您希望确保响应包含特定文本。在上面的示例中，我们检查响应是否包含John Doe。
Assertion error: false
Assertion failure: true
Assertion failure message: Test failed: text expected to contain /John Doe/
这是最常用的断言，原因如下：
- 合理的性能影响，
- 使用方便。
就个人而言，Contains 模式匹配规则满足了我95％的需求。我猜其他选项也很有用，但主要是在非常狭窄的用例中。
定制错误消息的能力肯定是一个加号。这样，您可以在结果（如JTL文件）中拥有自己的消息，并更好地了解错误。由于适度的 CPU和内存占用，可以谨慎使用此断言。
持续时间断言
JMeter持续时间断言
该期限断言是非常有用的验证应用程序满足一定的性能水平。通常，我会用它来检查服务器在合理的时间内做出的响应。在以毫秒为单位持续时间字段，您可以输入超过该限制的预期服务器响应time.Any响应时间会触发断言错误。
它可以被视为实施SLA（服务水平协议）的一种方式。因此，它更多的是性能警报而不是断言。
JMeter持续时间断言文档
由于不存在性能开销，这也是我首选的断言之一。由于响应时间已由JMeter计算，它只是根据指定值检查响应时间。性能成本几乎为零！
JMeter持续时间断言失败
以下是此断言失败时的示例错误消息：
Assertion error: false
Assertion failure: true
Assertion failure message: The operation lasted too long: It took 323 milliseconds, but should not have lasted longer than 1 milliseconds.
由于低 CPU和内存占用，这个断言可以广泛使用。
大小断言
JMeter尺寸断言
当您需要确保服务器响应始终具有特定大小时，大小断言很漂亮：
- 大小（字节）：预期大小（字节），
- 比较类型：许多可用的运营商，包括
=，!=，>，<，>=和<=。
JMeter大小断言文档
它使用起来非常简单。我个人用它来检查下载文件的大小，如视频或音乐。我想确保JMeter已经完全下载了该文件。
JMeter大小断言失败
如果失败，您应该看到预期的和实际的响应大小（以字节为单位）：
Assertion error: false
Assertion failure: true
Assertion failure message: The result was the wrong size: It was 17 bytes, but should have been equal to 50 bytes.
由于低 CPU和内存占用，应该广泛使用此断言。
JSON断言
JSON Assertion允许您验证JSON响应。让我们以json响应为例：
{
"firstName": "John",
"lastName" : "doe",
"age" : 26,
"address" : {
"streetAddress": "naist street",
"city" : "Nara",
"postalCode" : "630-0192"
},
"phoneNumbers": [
{
"type" : "iPhone",
"number": "0123-4567-8888"
},
{
"type" : "home",
"number": "0123-4567-8910"
}
]
}
假设我们要检查第phoneNumbers一种类型是什么iPhone。我们将使用$.phoneNumbers[:1].type JsonPath Expression。
JMeter JSON断言
然后我们将在JMeter中将其配置为以下内容：
- 断言JsonPath存在：
$.phoneNumbers[:1].type， - 附加断言值：如果选中，则断言该值等于预期值，
- 预期价值：
iPhone。
现在假设我们把Samsung Galaxy在期望值来代替。
JMeter JSON断言失败
正如所料，断言失败，因为第phoneNumbers一种类型是iPhone。
Assertion error: false
Assertion failure: true
Assertion failure message: Value expected to be 'Samsung Galaxy', but found '["iPhone"]'
有关如何使用JsonPath的更多信息，请参阅有关JMeter Json Path Extractor的文章。它涉及这个主题的更多细节。
此断言具有高 CPU和内存占用，因为它解析Json响应并将它们转换为对象表示。
XPath断言
JMeter XPath断言
XPath是一种用于从XML文档中选择节点的查询语言。我们能做些什么呢？它相当于JsonPath，但是对于XML响应。如果您想了解XPath的工作原理，请查看我们出色的XPath Extractor Guide。
此断言主要适用于SOAP Web服务。
JMeter XPath断言文档
与XPath Extractor一样，它有几个高级设置，如：
- 使用Tidy：如果XML格式不正确，则启用它，
- 使用命名空间：必须启用以验证节点
foo:singer，如下例所示， - 验证XML：确保XML格式正确，否则失败，
- 获取外部DTD：下载引用的XML 文档类型定义。
大多数情况下，您可以保留这些设置（全部未选中）。除非断言的XML无效，否则默认解析器就可以了。
让我们采用相同的XML文档作为示例响应：
<root xmlns:foo="http://www.foo.org/" xmlns:bar="http://www.bar.org">
<actors>
<actor id="1">Christian Bale</actor>
<actor id="2">Liam Neeson</actor>
<actor id="3">Michael Caine</actor>
</actors>
<foo:singers>
<foo:singer id="4">Tom Waits</foo:singer>
<foo:singer id="5">B.B. King</foo:singer>
<foo:singer id="6">Ray Charles</foo:singer>
</foo:singers>
</root>
现在让我们用XPath Assertion配置XPath断言：//actor[@id='4']。已知此表达式失败，因为没有id = 4的actor。
JMeter XPath断言失败
运行断言应失败，并显示以下消息：
Assertion error: false
Assertion failure: true
Assertion failure message: No Nodes Matched //actor[@id='4']
此断言具有高 CPU和内存使用率（特别是对于大型XML响应），因为它解析XML响应并将它们转换为对象表示。在负载测试期间避免使用它。
JSR223断言
JMeter JSR223断言
该JSR223断言是继任者的BeanShell断言。它为脚本语言提供了更大的灵活性（它支持beanshell，groovy，java，jexl和Javascript），并且比beanshell更快。（在使用条件下groovy）
JMeter JSR223断言文档
在大多数情况下，您将单独留下额外的设置（例如Parameters和Script File）。当您需要在多个JMX项目中共享脚本功能时，通常会使用这些功能。在这种情况下，您需要共享脚本，从而通过将公共脚本放在单独的文件中使它们可重用。
例如，如果我们想用JSR223脚本检查以前的结果响应时间，我们将执行以下操作：
def response_time = prev.getTime().toInteger();
def expected_response_time = 0;
if (response_time > expected_response_time) {
AssertionResult.setFailure(true);
AssertionResult.setFailureMessage("The expected response time is : " + expected_response_time + "ms but it took: " + response_time + "ms");
}
当然，它会失败，因为我们想要一个响应时间0ms。
JMeter JSR223断言失败
此断言具有变量，这意味着CPU和内存使用量取决于脚本内部实现的逻辑。一般来说，避免在断言中进行大量计算。
较少使用的断言
XML断言
JMeter XML断言
XML断言非常适合检查响应是否是有效的XML文档。但是，这是这个断言的唯一用例。当您需要检查服务器响应是否格式正确时，它在功能测试中非常有用。
JMeter XML断言失败
如果出现错误（如无效的XML响应），您应该看到如下错误消息：
Assertion error: true
Assertion failure: true
Assertion failure message: Content is not allowed in prolog.
由于高 CPU和内存占用，在负载测试期间应该避免这种断言。
XML Schema断言
JMeter XML Schema断言
此断言允许检查XML响应是否符合某个XML Schema DTD。我猜这个用法是有趣的，我个人从来没用过它。
它可能最适合SOAP Web服务，其中响应必须遵循严格的模式。
由于高 CPU和内存占用，它适用于功能测试，但不适用于负载测试。
Beanshell断言
JMeter Beanshell断言
BeanShell是Java的轻量级脚本引擎。但是，性能比JSR223脚本差很多。强烈建议使用JSR223脚本。
JMeter BeanShell断言文档
例如，您可以使用以下脚本:(非常类似于Java）
Failure = true;
FailureMessage = "This is an Error Message";
结果应该是配置的错误消息。
JMeter BeanShell断言失败
由于您需要学习脚本语言（与Java非常相似），因此不能直接使用。但是，它比任何其他断言都更具可定制性。
脚本中可以直接使用各种变量：
- log - 记录器对象。示例：
log.warn("Message"[,Throwable])， SampleResult, prev：SampleResult对象; 读写，Response：响应对象; 读写，Failure：布尔值; 读写; 用于设置断言状态，FailureMessage：字符串; 读写; 用于设置断言消息，ResponseData：响应体（byte []），ResponseCode：喜欢200，404等等，ResponseMessage：例如OK，ResponseHeaders- 包含HTTP响应标头，RequestHeaders：包含HTTP请求标头，SampleLabel：采样器的名称，SamplerData：发送到服务器的数据，ctx- 使用各种方法访问当前线程，前一个采样器等的JMeterContext，vars：JMeterVariables从脚本中获取/设置变量。
需要一些例子吗？请参阅我们的可重用示例脚本博客文章。
由于高 CPU和内存占用，更喜欢JSR223断言。它非常相似，但执行起来要快得多。
MD5Hex断言
JMeter MD5Hex断言
执行服务器响应的MD5哈希并将其与给定的Md5哈希进行比较。它非常适合您要检查下载文件是否完整的情况。
它只有一个设置：
- MD5Hex：输入预期的响应MD5哈希值。
就像在维基百科上解释：
MD5算法是广泛使用的散列函数，产生128位散列值。尽管MD5最初设计用作加密哈希函数，但它已被发现存在广泛的漏洞。
让我们尝试使用提供的随机md5哈希对我们的虚拟采样器运行它。
JMeter MD5Hex断言失败
正如预期的那样，断言失败是因为MD5哈希值不同。
Assertion error: false
Assertion failure: true
Assertion failure message: Error asserting MD5 sum : got c9ed4e51d70d5fb374d12e63db2e42d4 but should have been c05f1d607f5f8a72c9a58652b845e98e
由于服务器响应在每次检查时必须完全相同，因此它仅适用于静态资源检查。任何动态网页都可能产生断言错误，因为内容不同。
由于中等 CPU使用率，它可用于在小负载测试期间检查文件完整性。
HTML断言
JMeter HTML断言
这个断言检查HTML响应是一个结构良好的HTML文档。可以通过设置Error Threshold和Warning Threshold更高级别（除了0）来配置严格性级别。它主要适用于功能测试。
显然，您不希望在服务器上每秒投入数千次点击时检查HTML响应的有效性。
可以使用以下设置进行配置：
- 的DocType：
omit，auto，strict或loose。无论何时考虑HTML DocType，都要定义， - 格式：
HTML，XHTML或XML。取决于要验证的响应类型， - 仅错误：忽略警告（如果有）
- 错误和警告阈值：设置容忍错误和警告的数量，
- 文件名：在那里输出一个JTidy报告。
以下是JTidy报告的示例：
line 1 column 1 - Error: <root> is not recognized!
line 1 column 1 - Warning: missing <!DOCTYPE> declaration
line 1 column 1 - Warning: discarding unexpected <root>
line 2 column 3 - Error: <actors> is not recognized!
InputStream: Document content looks like HTML 3.2
2 warnings, 2 errors were found!
This document has errors that must be fixed before
using HTML Tidy to generate a tidied up version.
JMeter HTML断言失败
通常，失败看起来像：
Assertion error: false
Assertion failure: true
Assertion failure message: Tidy Parser errors: 9 (allowed 0) Tidy Parser warnings: 21 (allowed 0)
由于高 CPU和内存使用，请避免在负载测试期间使用HTML断言。它解析消耗大量资源的 HTML响应。
最后的话
虽然断言提供了一种方便的方法来验证服务器响应是否符合预期，但您应该知道它有成本。大多数花哨的断言如断言JSON或XPath断言只应用于轻负载测试（少数并发用户）或功能测试（通常是单个用户）。
明智地使用脚本断言，Beanshell或者JSR223可以解决其他断言甚至不会触及的问题。但是，请再次注意性能缺陷：脚本应该尽可能少地进行计算。
负载测试是一门需要强烈关注性能的学科。请务必阅读我们的指南，解释如何大规模优化JMeter以避免常见的JMeter陷阱。