JMETER断言：终极指南

你想要：

检查服务器响应是否包含特定字符串，
或验证服务器返回了HTTP 200 OK，
或者检查json字段的值（使用类似JsonPath$.store..price）。

断言是要走的路。

问题是：你不知道如何开始。并且可用断言的数量是压倒性的。别担心！

这个关于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陷阱。