断言 SoapUI脚本、XQuery、XPath 类型

⚡ 智能摘要

断言 SoapUI 这些检查点决定了 Web 服务响应是否正确,将仅仅执行的请求变成对真实、可验证内容的实际通过或失败的测试。

  • 🔘 分类: 物业内容、合规性/状态/标准、脚本、服务水平协议、JMS 和安全性。
  • ☑️ 包含: 支持正则表达式,确认响应中是否存在指定字符串。
  • 不包含: 确认字符串不存在,对错误标记和泄露字段很有用。
  • 🧪 XPath 匹配: 先声明命名空间,然后选择一个节点并比较其值。
  • 🛠️ XQuery 匹配: 验证重复节点集,否则需要数百次 XPath 检查。
  • 📊 脚本: Groovy 断言处理动态响应以及设置或拆卸逻辑。
  • 🔍 故障排除: 大多数错误都是由命名空间错误和使用点号代替冒号语法造成的。

断言 SoapUI

什么是断言?

断言是指肯定或陈述某事的行为。它也可以解释为检查点或验证点。

当请求发送到 Web 服务器后,会收到响应。我们需要验证响应是否包含预期的数据。为了验证响应,我们需要使用断言。如果没有断言,测试步骤只能证明服务已响应,而不能证明响应正确,这就是为什么每个测试都需要断言的原因。 API 测试 至少应该携带一个。

断言类型

表达回应的方式有很多种;但是,我们将重点关注常用的方式。 SoapUI 在验证响应时,可以使用断言类型。以下是开源版本中可用的类别: SoapUI.

  1. 物业内容
  2. 合规状况 标准
  3. 脚本
  4. SLA
  5. JMS
  6. 安保防护

对话框会将所有断言归入这些类别,如下面的屏幕截图所示。

列出的断言类别 SoapUI 添加断言对话框
断言的类型 SoapUI

除了上面列出的功能外,Pro 版本还内置了 JDBC 断言,我们可以使用该断言来判断 Web 服务是否已正确更新数据库。

版本说明: 当前 SoapUI 文档中还列出了 数据库连接 除了上述类别之外,还有类别(JDBC 状态和 JDBC 超时),以及一个 留言内容 在属性内容中添加断言,以便进行更丰富的 XML 比较。此处提及的商业版本“Pro”现已作为……出售。 ReadyAPI 由于 SmartBear 的缘故,新版本中的菜单标签可能会有所不同,但断言行为保持不变。

包含断言

搜索指定字符串是否存在。它也支持正则表达式。

我们将继续使用上一个教程中的相同示例,使用 WSDL 请求作为 http://www.dneonline.com/calculator.asmx如果你还没有构建该项目,请按以下步骤进行。 创建项目、测试套件和测试用例 隐形价值。

步骤 1:默认情况下没有断言。

  1. 断言的数量显示在断言选项卡中。
  2. 要添加新的断言,请单击“添加新断言”按钮。

SoapUI “断言”选项卡中未显示任何断言,并且显示“添加新断言”按钮。

步骤2:现在,

  1. 选择断言类别。
  2. 选择断言类型。
  3. 点击“添加”

在“添加断言”对话框中,选择断言类别和类型。

步骤 3:让我们验证响应中是否存在字符串“46”。单击“确定”。

注意:我们也可以忽略大小写并添加正则表达式。

包含断言配置对话框,其中已输入值 46

步骤 4:添加后,立即执行断言,并显示是否有效或无效。

“断言”选项卡报告“包含”断言为有效

步骤 5:现在假设我们更改“包含断言”的内容 SoapUI把“'”改成“'47”,看看会发生什么。

将“包含断言”的内容从 46 编辑到 47

步骤 6:断言执行,并将结果返回给用户。由于响应中没有字符串“47”,因此断言失败。

“断言”选项卡报告“包含”断言失败

不包含断言

它的对应函数则相反,用于查找指定字符串是否存在。它也支持正则表达式。

步骤 1:点击“添加新断言”按钮后,

  1. 选择断言类别。
  2. 选择断言类型——本例中为“不包含”
  3. 点击“添加”

添加“不包含”断言对话框(已选)

步骤 2:让我们验证响应中是否存在字符串“intA”。输入字符串“FromCurrency”,然后单击“确定”。

在“不包含”断言对话框中输入了字符串“FromCurrency”。

步骤 3:断言添加后,会立即执行并显示结果。目前我们添加了两个断言,因此这两个断言都会被执行并显示结果。

“断言”选项卡列出了“包含”和“不包含”的结果。

步骤 4:现在让我们更改“不包含断言”的内容,看看会发生什么。我们将检查字符串“AddResult”是否存在。

不包含断言对话框检查标记 AddResult

步骤 5:字符串“AddResult”实际上存在于响应中,因此“NOT Contains”断言将失败,如下所示。

“不包含”断言失败,因为 AddResult 已存在。

XPath 匹配断言

字符串匹配是粗略的,因此下一个断言将针对单个节点。它使用 XPath 表达式来选择目标节点及其值。 XPath的是一种 XML 查询语言,用于从 XML 文档中选择节点。

步骤 1:点击“添加新断言”按钮后,

  1. 选择断言类别。
  2. 选择断言类型——在本例中为“XPath Match”
  3. 点击“添加”

添加断言对话框,并选中“XPath 匹配”选项

步骤 2:添加 XPath 窗口打开。

在添加 SoapUI 在 XPath 中,我们需要声明命名空间。XML 命名空间是一组名称的集合,这些名称由统一资源标识符 (URI) 引用标识,并在 XML 文档中用作元素和属性名称。同样的方法也用于…… SoapUI XPath 断言。

要声明 XML 命名空间,我们只需点击“声明”按钮即可,或者我们也可以手动声明命名空间。

声明命名空间后,我们需要使用创建的命名空间来引用 XPath。

点击“声明”按钮后,会弹出两个命名空间,因为我们有两个 URI。其中一个是模式。 URL 另一个则对应于实际的 Web 服务。 URL在使用 XPath 时,我们需要使用 Web 服务所在的实际命名空间,而不是模式命名空间。声明的行会显示在 XPath 框的顶部,如下所示。

在 XPath 断言窗口中声明了 soap 和 ns1 命名空间

声明命名空间 soap='http://schemas.xmlsoap.org/soap/envelope/';

声明命名空间 ns1='http://tempuri.org/';

点击“声明”后,XPath断言窗口立即弹出。

步骤 3:现在我们需要输入要验证的 XML 节点的 XPath。

//ns1:AddResult 给出了包含在以下节点之间的值& ns1 对应于指向“http://tempuri.org/”的声明命名空间

输入 XML 后,我们需要点击“从当前选择”,这样就可以选取当前响应中的值来进行进一步的比较。

输入了 XPath 表达式,并从当前高亮显示的位置进行选择。

第四步:到目前为止,

  1. 声明命名空间后,我们输入了需要验证的 XML 节点的 XPath。
  2. 我们需要点击‘从当前选择’以使当前值成为预期值。
  3. 当前值显示给用户,如果需要我们可以修改。
  4. 点击“保存”。

XPath 匹配配置显示预期值和“保存”按钮

步骤 5:添加断言 SoapUI 将显示如下。

“断言”选项卡显示了已添加的 XPath 匹配断言。

脚本断言

这种断言技术是最广泛使用的技术,因为管理和维护数百个断言极其困难。

SoapUI 使用任一 Groovy 脚本或 JavaScript 用于脚本断言。脚本技术被采用用于开发。ping 用于测试 SOAP 的框架。脚本断言在以下情况下使用。

  • 脚本允许用户在执行测试用例之前和之后分别使用设置(setup)和清理(teardown)方法执行一些操作。设置(setup)是在执行特定方法之前执行的过程(例如,创建和初始化对象),而清理(teardown)是在执行方法之后执行的过程(例如,销毁对象和清理工作)。其他断言类型不具备此功能,只能通过编写代码来实现。
  • 它允许用户执行打开/关闭项目的操作,以便初始化或清理项目相关设置,还可以处理环境变量,这在编写脚本时非常有用。
  • 它帮助我们断言动态的响应内容。
  • 脚本断言用于创建用户自定义的、非预定义的断言。 SoapUI.

为了演示脚本断言 SoapUI我们将使用计算器 WSDL,以及我们之前创建的测试用例“Add”。

步骤 1:添加 Groovy 脚本的步骤与其他断言相同,不同之处在于该断言并非预定义断言,而是用户自定义断言,因此比内置断言更灵活。

选择需要添加断言的测试步骤。

在测试步骤中选择 SoapUI 在添加断言之前导航

单击“添加断言”按钮,如下所示。

测试步骤断言工具栏上的“添加断言”按钮

步骤 2:现在选择断言类别。

  1. 在这种情况下,它是脚本。
  2. 选择 SoapUI 脚本断言,没有与之关联的子类型。
  3. 单击“添加”。

在“添加断言”对话框中选择“脚本”类别

步骤 3:打开脚本对话框,用户可以在其中编写用户定义的脚本来验证响应 XML。

空的 SoapUI 脚本断言编辑器对话框

步骤 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"}
  1. 单击“执行”按钮即可触发执行。
  2. 脚本的输出显示在“输出”窗格中。它打印了转换值以及最终结果(通过或失败)
  3. 显示信息“脚本断言已通过”。单击“确定”。

注意:只要脚本语法正确,最终的信息弹出窗口将始终显示“脚本断言已通过”消息。它与脚本中的断言没有任何关联。

脚本断言输出窗格打印结果值并显示“通过”字样。

单击确定

步骤 5:现在“断言”选项卡显示了我们为此测试套件添加的所有断言,以及每个断言的状态。

“断言”选项卡列出了添加到测试套件中的每个断言。

步骤6:现在

  1. 从导航器树中选择测试套件
  2. 点击“运行”按钮
  3. 将显示整个测试套件的结果。

执行所有断言后的测试套件运行结果

XQuery 匹配断言

它使用 XQuery 表达式从目标属性中选择内容。我们需要一个更大的响应 XML,以便更好地理解其中的 XQuery 断言。 SoapUI让我们导入另一个 WSDL 文件,如下所示:http://www.webservicex.net/medicareSupplier.asmx?WSDL

注意: 本演练中使用的公共 webservicex.net 演示端点已无法可靠访问,因此以下请求和响应屏幕截图仅作为参考示例保留。任何返回重复节点集的 WSDL 都将以完全相同的方式执行 XQuery 断言。

步骤 1:右键单击现有项目,然后选择“添加 WSDL”。

点击右键菜单 SoapUI 项目显示添加 WSDL

步骤二:打开“添加 WSDL”对话框。其他选项保持默认设置,然后单击“确定”按钮。

添加带有默认导入选项的 WSDL 对话框

步骤 3:所有操作如下所示。

导航树中列出的 Medicare 供应商 WSDL 运营情况

步骤 4:现在让我们添加一个 测试用例 在我们为 测试与验证 货币转换器。

现有测试套件新增测试用例选项

步骤 5:输入测试用例名称,然后单击“确定”按钮

在“新建测试用例”对话框中输入测试用例名称

步骤 6:测试用例创建如下。

新创建的测试用例 SoapUI 导航树

步骤 7:添加一个类型为“Soap 测试请求”的新测试步骤,如下所示。

“添加步骤”菜单,并选中“SOAP 测试请求”。

步骤 8:输入测试步骤的名称。例如,输入“按城市划分的供应商”,这样更有意义。点击“确定”。

将新的测试步骤命名为 Supplier_by_City

步骤9:选择 Opera我们希望验证的 tion。在本例中为 'MedicareSupplierSoap -> GetSupplierByCity'。单击“OK”。

在测试步骤中选择 GetSupplierByCity 操作

步骤 10:输入测试用例的名称,然后单击“确定”。

确认 SOAP 测试请求名称

步骤 11:请求 XML 大纲将显示如下。

生成的 GetSupplierByCity 请求 XML 概要

第 12 步:现在让我们查找纽约市的所有供应商信息。

为此,请将以下几行添加到您的代码中。

<GetSupplierByCity xmlns="http://www.webservicex.net/">

<City>New York</City>

</GetSupplierByCity>

下面列出的是 WSDL。 URL – http://www.webservicex.net/medicareSupplier.asmx?op=GetSupplierByCity

请求 XML 已编辑,城市值为 New York

步骤 13:执行测试后,我们收到以下响应

GetSupplierByCity 响应包含重复的供应商记录

步骤 14:假设我们需要验证所有供应商编号。由于需要数百个 XPath 断言,因此我们不能使用 XPath 断言。在这种情况下,使用 XQuery 是不可避免的。

XQuery 断言帮助我们验证一组本质上重复的 XML 响应。

XQuery 将遍历的重复 SupplierData 节点

第15步:现在点击“添加断言”,

  1. 在这种情况下,选择“断言类别” - 属性内容。
  2. 选择断言类型为“XQuery 断言”
  3. 单击“添加”。

在“属性内容”类别中选择了 XQuery 断言

步骤 16:与 XPath 断言类似,我们需要声明命名空间。

  1. 点击“声明”按钮即可自动允许 SoapUI 要声明命名空间,点击“声明”按钮后,会弹出一个窗口,提示“改为从模式中声明命名空间”。点击“是”继续,如下所示。
  2. 为了检索所有供应商编号,我们需要编写一个 XPath 查询,并将其放在 <SupplierNumber> 中,然后标签。
  3. 单击“从当前选择”将从当前响应执行。
  4. 点击“从当前供应商中选择”后,将列出所有供应商编号。
  5. 点击“保存”。

从架构确认弹出窗口中声明命名空间

注意:点击“声明”按钮后,您可能会得到不同的结果。 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)}
}

XQuery表达式窗口列出了所有供应商编号

步骤 17:执行 XQuery 断言,并在“断言”面板中显示最终结果,如下所示。现在,我们已成功添加 XQuery 断言,并使用该断言验证了所有供应商编号信息。每次向 Web 服务器发送请求时,都会将验证结果与实际值进行比较。

注意:不会显示实际值。如果所有实际值与预期值相同,则显示“VALID”,否则将显示“Failed”。

断言面板显示 XQuery 断言结果

何时使用内置断言?

既然已经涵盖了点击式操作和脚本式操作两种选项,那么实际的问题是应该选择哪一种。

  • 当响应很短时,可以使用其中一个内置断言进行验证。
  • 如果 Web 服务器发送的响应本质上始终是静态的,我们也可以使用内置断言。如果它是动态的,我们将无法使用内置断言对其进行断言。
  • 当使用内置断言(如超时断言和安全断言)变得不可避免时。
  • 内置断言非常适合一次性使用且不需要重复测试的情况。

断言选项

在下面突出显示的控制面板的帮助下可以最好地控制创建的断言。

断言工具箱控制面板 SoapUI

创建的断言允许测试人员从断言工具箱中配置以下内容。

附加选项 描述
向上移动断言图标 选定的断言将向上移动。
向下移动断言图标 选定的断言将按顺序向下移动。
移除断言图标 删除选定的断言
配置或编辑断言图标 重新配置/编辑所选的断言。

以下是专业版独有的功能 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 测试步骤。

下载包含上述断言的 SOAPUI 项目

常见错误及故障排除

大多数断言失败 trac又回到了一小堆错误,所以在重写表达式之前请检查这些错误。

  • 使用正确的命名空间。命名空间应该是…… URL 网络服务所在的位置。
  • 如果在开发过程中抛出错误ping 脚本断言,使用“log.info”打印变量的内容。
  • 如果您没有得到所需的输出,请验证请求中是否传递了有效的输入。

例如,在货币转换器中,如果您将“intA”输入为非整数“x”,则输出会抛出错误代码“SOAP-Client”,这意味着问题出在客户端传递的参数上。首先会显示包含无效值的请求。

SoapUI 请求传递了无效的非整数值作为 intA。

响应返回的是故障代码而不是结果,如下所示。

SOAP客户端返回的错误代码 SoapUI 回复编辑

在使用 XPath 和 XQuery 断言时,请确保使用正确的语法。切勿使用点号 (.) 代替冒号 (:)。正确的语法是 `//namespace:Tagname`,而不是 `//namespace.tagname`。否则,即使标签名称正确,您也可能会收到“当前响应中未找到匹配项”的错误信息。

当前响应中未找到匹配项,错误原因是 XPath 语法不正确。

常见问题

任意数字。 SoapUI 在采样器测试步骤执行后,应用附加到该步骤的每个断言;如果其中任何一个断言失败,则该步骤在测试用例视图中被标记为失败。

它将 XML 消息与预期文档节点逐个比较,因此可以忽略选定的字段或进行宽松匹配,而不是将整个有效负载视为一个纯字符串。

开源 SoapUI 涵盖物业内容、合规性、脚本、服务水平协议、JMS 和安全。 ReadyAPI 增加组ping克隆、JDBC 检查以及启用或禁用控件。

AI 模型读取示例响应并建议 XPath 或 XQuery 表达式,提出边界值,并标记每次运行时都会更改的字段——大大减少了手动编写命名空间和表达式的工作量。

是的。 副驾驶 自动补全 GroovyUtils 和 XmlHolder 样板代码。务必先执行脚本,因为无论比较结果如何,语法有效的脚本都会报告“脚本断言通过”。

是的。断言内容字段支持属性扩展,因此可以从项目或测试用例属性中提取预期值,而不是从字面值中提取,这使得一个断言可以在不同环境中重复使用。

失败的断言会在测试用例视图中将其测试步骤标记为失败,并在窗口底部的测试执行日志中写入匹配的 FAILED 条目,其中包含失败的详细信息。

包含、不包含、XPath 匹配、XQuery 匹配、响应 SLA​​、脚本、有效和无效的 HTTP 状态代码、敏感信息泄露以及针对 WADL 或推断模式的模式合规性。

总结一下这篇文章: