断言 SoapUI脚本、XQuery、XPath 类型

什么是断言?
断言是指肯定或陈述某事的行为。它也可以解释为检查点或验证点。
当请求发送到 Web 服务器后,会收到响应。我们需要验证响应是否包含预期的数据。为了验证响应,我们需要使用断言。如果没有断言,测试步骤只能证明服务已响应,而不能证明响应正确,这就是为什么每个测试都需要断言的原因。 API 测试 至少应该携带一个。
断言类型
表达回应的方式有很多种;但是,我们将重点关注常用的方式。 SoapUI 在验证响应时,可以使用断言类型。以下是开源版本中可用的类别: SoapUI.
- 物业内容
- 合规状况 标准
- 脚本
- SLA
- JMS
- 安保防护
对话框会将所有断言归入这些类别,如下面的屏幕截图所示。

除了上面列出的功能外,Pro 版本还内置了 JDBC 断言,我们可以使用该断言来判断 Web 服务是否已正确更新数据库。
版本说明: 当前 SoapUI 文档中还列出了 数据库连接 除了上述类别之外,还有类别(JDBC 状态和 JDBC 超时),以及一个 留言内容 在属性内容中添加断言,以便进行更丰富的 XML 比较。此处提及的商业版本“Pro”现已作为……出售。 ReadyAPI 由于 SmartBear 的缘故,新版本中的菜单标签可能会有所不同,但断言行为保持不变。
包含断言
搜索指定字符串是否存在。它也支持正则表达式。
我们将继续使用上一个教程中的相同示例,使用 WSDL 请求作为 http://www.dneonline.com/calculator.asmx如果你还没有构建该项目,请按以下步骤进行。 创建项目、测试套件和测试用例 隐形价值。
步骤 1:默认情况下没有断言。
- 断言的数量显示在断言选项卡中。
- 要添加新的断言,请单击“添加新断言”按钮。
步骤2:现在,
- 选择断言类别。
- 选择断言类型。
- 点击“添加”
步骤 3:让我们验证响应中是否存在字符串“46”。单击“确定”。
注意:我们也可以忽略大小写并添加正则表达式。
步骤 4:添加后,立即执行断言,并显示是否有效或无效。
步骤 5:现在假设我们更改“包含断言”的内容 SoapUI把“'”改成“'47”,看看会发生什么。
步骤 6:断言执行,并将结果返回给用户。由于响应中没有字符串“47”,因此断言失败。
不包含断言
它的对应函数则相反,用于查找指定字符串是否存在。它也支持正则表达式。
步骤 1:点击“添加新断言”按钮后,
- 选择断言类别。
- 选择断言类型——本例中为“不包含”
- 点击“添加”
步骤 2:让我们验证响应中是否存在字符串“intA”。输入字符串“FromCurrency”,然后单击“确定”。
步骤 3:断言添加后,会立即执行并显示结果。目前我们添加了两个断言,因此这两个断言都会被执行并显示结果。
步骤 4:现在让我们更改“不包含断言”的内容,看看会发生什么。我们将检查字符串“AddResult”是否存在。
步骤 5:字符串“AddResult”实际上存在于响应中,因此“NOT Contains”断言将失败,如下所示。
XPath 匹配断言
字符串匹配是粗略的,因此下一个断言将针对单个节点。它使用 XPath 表达式来选择目标节点及其值。 XPath的是一种 XML 查询语言,用于从 XML 文档中选择节点。
步骤 1:点击“添加新断言”按钮后,
- 选择断言类别。
- 选择断言类型——在本例中为“XPath Match”
- 点击“添加”
步骤 2:添加 XPath 窗口打开。
在添加 SoapUI 在 XPath 中,我们需要声明命名空间。XML 命名空间是一组名称的集合,这些名称由统一资源标识符 (URI) 引用标识,并在 XML 文档中用作元素和属性名称。同样的方法也用于…… SoapUI XPath 断言。
要声明 XML 命名空间,我们只需点击“声明”按钮即可,或者我们也可以手动声明命名空间。
声明命名空间后,我们需要使用创建的命名空间来引用 XPath。
点击“声明”按钮后,会弹出两个命名空间,因为我们有两个 URI。其中一个是模式。 URL 另一个则对应于实际的 Web 服务。 URL在使用 XPath 时,我们需要使用 Web 服务所在的实际命名空间,而不是模式命名空间。声明的行会显示在 XPath 框的顶部,如下所示。
声明命名空间 soap='http://schemas.xmlsoap.org/soap/envelope/';
声明命名空间 ns1='http://tempuri.org/';
步骤 3:现在我们需要输入要验证的 XML 节点的 XPath。
//ns1:AddResult 给出了包含在以下节点之间的值& ns1 对应于指向“http://tempuri.org/”的声明命名空间
输入 XML 后,我们需要点击“从当前选择”,这样就可以选取当前响应中的值来进行进一步的比较。
第四步:到目前为止,
- 声明命名空间后,我们输入了需要验证的 XML 节点的 XPath。
- 我们需要点击‘从当前选择’以使当前值成为预期值。
- 当前值显示给用户,如果需要我们可以修改。
- 点击“保存”。
步骤 5:添加断言 SoapUI 将显示如下。
脚本断言
这种断言技术是最广泛使用的技术,因为管理和维护数百个断言极其困难。
SoapUI 使用任一 Groovy 脚本或 JavaScript 用于脚本断言。脚本技术被采用用于开发。ping 用于测试 SOAP 的框架。脚本断言在以下情况下使用。
- 脚本允许用户在执行测试用例之前和之后分别使用设置(setup)和清理(teardown)方法执行一些操作。设置(setup)是在执行特定方法之前执行的过程(例如,创建和初始化对象),而清理(teardown)是在执行方法之后执行的过程(例如,销毁对象和清理工作)。其他断言类型不具备此功能,只能通过编写代码来实现。
- 它允许用户执行打开/关闭项目的操作,以便初始化或清理项目相关设置,还可以处理环境变量,这在编写脚本时非常有用。
- 它帮助我们断言动态的响应内容。
- 脚本断言用于创建用户自定义的、非预定义的断言。 SoapUI.
为了演示脚本断言 SoapUI我们将使用计算器 WSDL,以及我们之前创建的测试用例“Add”。
步骤 1:添加 Groovy 脚本的步骤与其他断言相同,不同之处在于该断言并非预定义断言,而是用户自定义断言,因此比内置断言更灵活。
选择需要添加断言的测试步骤。
单击“添加断言”按钮,如下所示。
步骤 2:现在选择断言类别。
- 在这种情况下,它是脚本。
- 选择 SoapUI 脚本断言,没有与之关联的子类型。
- 单击“添加”。
步骤 3:打开脚本对话框,用户可以在其中编写用户定义的脚本来验证响应 XML。
步骤 4:现在让我们编写一个 Groovy 脚本来验证转化率。脚本附在下方,并嵌入了注释。建议您具备一定的 Groovy 知识。 Java 脚本或 Groovy 在尝试编写自己的脚本之前,请先编写脚本。
//Define Groovy Utils and holder for validating the XML reponse content def groovyUtils = new com.eviware.soapui.support.GroovyUtils(context) def holder = groovyUtils.getXmlHolder(messageExchange.responseContent) //Define the NameSpace holder.namespaces["ns1"] = "http://tempuri.org/" //Get the Value of the Node 'AddResult' and assign to a variable def addResult = holder.getNodeValue("//ns1:AddResult") //print the value of the result in the Output panel log.info "The result value for integers is " + addResult //Comparing the value to print 'Pass' or 'Fail' if(addResult=="46") { log.info "Pass" } else { log.info "fail"}
- 单击“执行”按钮即可触发执行。
- 脚本的输出显示在“输出”窗格中。它打印了转换值以及最终结果(通过或失败)
- 显示信息“脚本断言已通过”。单击“确定”。
注意:只要脚本语法正确,最终的信息弹出窗口将始终显示“脚本断言已通过”消息。它与脚本中的断言没有任何关联。
单击确定
步骤 5:现在“断言”选项卡显示了我们为此测试套件添加的所有断言,以及每个断言的状态。
步骤6:现在
- 从导航器树中选择测试套件
- 点击“运行”按钮
- 将显示整个测试套件的结果。
XQuery 匹配断言
它使用 XQuery 表达式从目标属性中选择内容。我们需要一个更大的响应 XML,以便更好地理解其中的 XQuery 断言。 SoapUI让我们导入另一个 WSDL 文件,如下所示:http://www.webservicex.net/medicareSupplier.asmx?WSDL
注意: 本演练中使用的公共 webservicex.net 演示端点已无法可靠访问,因此以下请求和响应屏幕截图仅作为参考示例保留。任何返回重复节点集的 WSDL 都将以完全相同的方式执行 XQuery 断言。
步骤 1:右键单击现有项目,然后选择“添加 WSDL”。
步骤二:打开“添加 WSDL”对话框。其他选项保持默认设置,然后单击“确定”按钮。
步骤 3:所有操作如下所示。
步骤 4:现在让我们添加一个 测试用例 在我们为 测试与验证 货币转换器。
步骤 5:输入测试用例名称,然后单击“确定”按钮
步骤 6:测试用例创建如下。
步骤 7:添加一个类型为“Soap 测试请求”的新测试步骤,如下所示。
步骤 8:输入测试步骤的名称。例如,输入“按城市划分的供应商”,这样更有意义。点击“确定”。
步骤9:选择 Opera我们希望验证的 tion。在本例中为 'MedicareSupplierSoap -> GetSupplierByCity'。单击“OK”。
步骤 10:输入测试用例的名称,然后单击“确定”。
步骤 11:请求 XML 大纲将显示如下。
第 12 步:现在让我们查找纽约市的所有供应商信息。
为此,请将以下几行添加到您的代码中。
<GetSupplierByCity xmlns="http://www.webservicex.net/"> <City>New York</City> </GetSupplierByCity>
下面列出的是 WSDL。 URL – http://www.webservicex.net/medicareSupplier.asmx?op=GetSupplierByCity
步骤 13:执行测试后,我们收到以下响应
步骤 14:假设我们需要验证所有供应商编号。由于需要数百个 XPath 断言,因此我们不能使用 XPath 断言。在这种情况下,使用 XQuery 是不可避免的。
XQuery 断言帮助我们验证一组本质上重复的 XML 响应。
第15步:现在点击“添加断言”,
- 在这种情况下,选择“断言类别” - 属性内容。
- 选择断言类型为“XQuery 断言”
- 单击“添加”。
步骤 16:与 XPath 断言类似,我们需要声明命名空间。
- 点击“声明”按钮即可自动允许 SoapUI 要声明命名空间,点击“声明”按钮后,会弹出一个窗口,提示“改为从模式中声明命名空间”。点击“是”继续,如下所示。
- 为了检索所有供应商编号,我们需要编写一个 XPath 查询,并将其放在 <SupplierNumber> 中,然后标签。
- 单击“从当前选择”将从当前响应执行。
- 点击“从当前供应商中选择”后,将列出所有供应商编号。
- 点击“保存”。
注意:点击“声明”按钮后,您可能会得到不同的结果。 URL虽然使用了命名空间声明,但实际的 Web 服务位置命名空间才是编码时需要考虑的。
包含命名空间声明的完整 XQuery 表达式如下所示。
// Namespace declaration declare namespace soap='http://schemas.xmlsoap.org/soap/envelope/'; declare namespace ns1='http://www.webservicex.net/'; declare namespace x = ''; // Placing the result in Myresult Tags{ // Iterating through all the supplier number for $x in //ns1:GetSupplierByCityResponse/ns1:SupplierDataLists/ns1:SupplierDatas/ns1:SupplierData //Return all the Supplier number within ‘SupplierNumber’ Tags. return {data($x/ns1:SupplierNumber)} }
步骤 17:执行 XQuery 断言,并在“断言”面板中显示最终结果,如下所示。现在,我们已成功添加 XQuery 断言,并使用该断言验证了所有供应商编号信息。每次向 Web 服务器发送请求时,都会将验证结果与实际值进行比较。
注意:不会显示实际值。如果所有实际值与预期值相同,则显示“VALID”,否则将显示“Failed”。
何时使用内置断言?
既然已经涵盖了点击式操作和脚本式操作两种选项,那么实际的问题是应该选择哪一种。
- 当响应很短时,可以使用其中一个内置断言进行验证。
- 如果 Web 服务器发送的响应本质上始终是静态的,我们也可以使用内置断言。如果它是动态的,我们将无法使用内置断言对其进行断言。
- 当使用内置断言(如超时断言和安全断言)变得不可避免时。
- 内置断言非常适合一次性使用且不需要重复测试的情况。
断言选项
在下面突出显示的控制面板的帮助下可以最好地控制创建的断言。
创建的断言允许测试人员从断言工具箱中配置以下内容。
| 附加选项 | 描述 |
| 选定的断言将向上移动。 | |
| 选定的断言将按顺序向下移动。 | |
| 删除选定的断言 | |
| 重新配置/编辑所选的断言。 |
以下是专业版独有的功能 SoapUI现已作为 ReadyAPI专业版还有助于我们对断言进行分组,以便我们可以为创建的断言添加另一层验证。
- 和: 所有断言均被评估为有效断言,这将导致组条件通过。
- 要么: 要断言组 PASSED 条件成立,组内至少要有一个断言为 VALID。
- 专业版还允许 断言的克隆此选项允许测试人员将断言复制到同一项目或不同项目中的不同测试步骤。
- 禁用/启用断言:此选项允许禁用或启用任何分组或未分组的断言。如果断言被禁用,则会显示为灰色;执行测试用例时,禁用的断言将不会被执行。
- 取消分组断言:任何分组的断言都可以在测试人员决定时取消分组。
各种断言类型中可用的方法的完整列表
下表汇总了上面讨论的所有断言,并按其在“添加断言”对话框中出现的类别进行分组。
| 断言机制 | 描述 |
| 物业内容 | |
| 包含 | 搜索指定字符串是否存在。它也支持正则表达式。 |
| 不包含 | 搜索指定字符串是否存在。它也支持正则表达式。 |
| XPath 匹配 | 使用 XPath 表达式选择目标节点及其值。 |
| XQuery 匹配 | 使用 XQuery 表达式从目标属性中选择内容。 |
| 合规性、状态、标准 | |
| HTTP 下载所有资源 | 下载后验证 HTML 文档,并且它适用于任何包含 HTML 的属性。 |
| 无效的 HTTP 状态 Codes | 验证 HTML 响应是否包含定义代码列表中未包含的状态代码。 |
| 非 SOAP 错误 | 验证最后收到的消息是否不是 SOAP 错误。很明显,它仅适用于 SOAP 测试步骤。 |
| 架构合规性 | 验证最后收到的消息是否符合 WSDL 或 WADL 标准架构定义。适用于 SOAP 和 REST 测试步骤。 |
| SOAP 故障 | 验证最后收到的消息是否为 SOAP 错误。它与“非 SOAP”错误断言相反。 |
| SOAP 响应 | 验证最后收到的响应是否是有效的 SOAP 响应,并且仅适用于 SOAP 测试请求步骤。 |
| 有效的 HTTP 状态 Codes | 验证 HTML 响应是否包含已定义状态码列表中的状态码。它与“无效 HTTP 状态码”相反。 Codes 的断言。 |
| WS-Addressing 请求 | 验证最后收到的请求是否包含适当的 WS-Addressing Headers。 |
| WS-Addressing 响应 | 验证最后收到的响应是否包含适当的 WS-Addressing Headers。 |
| WS-安全状态 | 验证最后收到的消息是否包含有效的 WS-Security 标头,并且仅适用于 SOAP 请求。 |
| 脚本 | |
| 脚本断言 | 允许用户执行自定义脚本来执行用户定义的验证。 |
| SLA | |
| 响应 SLA | 验证最后收到的响应的响应时间是否在定义的限制内。 |
| JMS | |
| JMS 状态 | 验证测试步骤的 JMS 请求是否已成功执行,并且对于具有 JMS 端点的测试步骤是否有效。 |
| JMS 超时 | 验证测试步骤的 JMS 响应所用时间是否未超过指定的持续时间。 |
| 安保防护 | |
| 敏感信息暴露 | 验证响应消息是否不暴露有关目标系统的敏感信息。我们可以将此断言用于 REST、SOAP 和 HTTP 测试步骤。 |
常见错误及故障排除
大多数断言失败 trac又回到了一小堆错误,所以在重写表达式之前请检查这些错误。
- 使用正确的命名空间。命名空间应该是…… URL 网络服务所在的位置。
- 如果在开发过程中抛出错误ping 脚本断言,使用“log.info”打印变量的内容。
- 如果您没有得到所需的输出,请验证请求中是否传递了有效的输入。
例如,在货币转换器中,如果您将“intA”输入为非整数“x”,则输出会抛出错误代码“SOAP-Client”,这意味着问题出在客户端传递的参数上。首先会显示包含无效值的请求。
响应返回的是故障代码而不是结果,如下所示。
在使用 XPath 和 XQuery 断言时,请确保使用正确的语法。切勿使用点号 (.) 代替冒号 (:)。正确的语法是 `//namespace:Tagname`,而不是 `//namespace.tagname`。否则,即使标签名称正确,您也可能会收到“当前响应中未找到匹配项”的错误信息。














































