用soapui功能测试-使用断言

让我们来看看使用采样器的TestSteps(包括request的TestStep)的Assertion功能如何验证TestStep收到传入的响应或请求。在我们深入了解可用的断言之前,让我们快速概述一下。

断言用于在执行期间验证TestStep接收的消息,通常通过将消息(或整个消息)的部分与某些预期值进行比较。任何数量的断言都可以添加到采样器TestStep中,每个断言都会验证响应内容的一些不同方面。在采样器TestStep执行后,其所有断言将应用于接收到的响应,如果任何一个断言TestStep在TestCase视图中被标记为失败,并且相应的FAILED条目显示在测试执行日志中。

这里我们可以看到“测试请求 - 登录”TestStep已经失败,在底部的TestCase运行日志中还会显示有关实际断言失败的详细信息; “took 1023 ms”表示“SLA”断言失败,即响应太慢。

1. 管理断言

断言始终显示在包含TestSteps编辑器窗口底部的选项卡中。

在上面的截图中,您可以看到添加到SOAP Request TestStep中的3个断言,并且它们都failed。

在断言之上的工具栏允许您根据需要添加,配置,删除,移动和克隆断言,并且用于断言的右键单击弹出菜单包含类似的操作(可以在屏幕截图中看到)。双击断言会弹出其配置对话框(如果可用)。

该对话框将包含可用于当前类型采样器的断言映射(见下文),按OK将添加断言并打开其配置对话框。

2. 断言类别

断言分为几个类别,以便于管理。

2.1. Property Content

  • Contains - 在属性值中搜索字符串是否存在,支持正则表达式。适用于任何。
  • Message Content Assertion - 允许XML消息的复杂内容验证。适用于包含XML的任何属性。
  • Not Contains - 不包含 - 搜索属性值中不存在字符串,支持正则表达式。适用于任何。
  • XPath Match - 使用XPath表达式从目标属性中选择内容,并将结果与??期望值进行比较。适用于包含XML的任何属性。
  • XQuery Math - 使用XQuery表达式从目标属性中选择内容,并将结果与??期望值进行比较。适用于包含XML的任何属性。

2.1.1. Compliance, Status and Standards

  • HTTP Download all resource - 下载所有资源称为HTML文档(图像,脚本等),并验证它们是否可用。适用于包含HTML的任何属性。
  • Invalid HTTP Status Codes - 检查目标TestStep是否收到HTTP结果,状态码不在定义的代码列表中。适用于接收HTTP消息的任何TestStep
  • Not SOAP Fault - validates that the last received message is not a SOAP Fault. Applicable to SOAP TestSteps.
  • Schema Compliance - validates that the last received message is compliant with the associated WSDL or WADL schema definition. Applicable to SOAP and REST TestSteps. The schema definition URL supports Property Expansions (e.g. ${#System#my.wsdl.endpoint}/services/PortType?wsdl ).
  • SOAP Fault - validates that the last received message is a SOAP Fault. Applicable to SOAP TestSteps SOAP Request - validates that the last received request is a valid SOAP Request. Applicable to MockResponse TestSteps only.
  • SOAP Response - validates that the last received response is a valid SOAP Response. Applicable to SOAP TestRequest Steps only.
  • Valid HTTP Status Codes - 检查目标TestStep是否在定义的代码列表中收到带有状态代码的HTTP结果。适用于接收HTTP消息的任何TestStep。
  • WS-Addressing Request - validates that the last received request contains valid WS-Addressing Headers. Applicable to MockResponse TestSteps only.
  • WS-Addressing Response - validates that the last received response contains valid WS-Addressing Headers. Applicable to SOAP TestRequest Steps only.
  • WS-Security Status - 验证最后收到的消息是否包含有效的WS-Security标头。适用于SOAP TestSteps。

2.1.1.1. Script

  • Script Assertion - 运行自定义脚本来执行任意验证。仅适用于测试步骤(不能用到属性)。

2.1.1.2. SLA

  • Response SLA - 验证最后收到的响应时间是否在定义的限制内。适用于发送请求和接收响应的脚本TestSteps和TestSteps。

2.1.1.3. JMS

  • JMS Status - 验证该目标步步测试的JMS请求成功执行。适用于要求TestSteps与JMS端点。

2.1.1.4. JDBC

  • JDBC Status - 验证目标TestStep的JDBC语句是否成功执行。仅适用于JDBC TestSteps。
  • JDBC Timeout - 验证目标TestStep的JDBC语句是否不会超过指定的持续时间。仅适用于JDBC TestSteps。

2.1.1.5. Security

  • Sensitive Information Exposure - 检查上一次接收到的消息是否不会公开有关目标系统的敏感信息。适用于REST,SOAP和HTTP TestSteps。

3. Common Assertions

常见的teststep断言是:

  • Contains
  • Not Contains
  • Reponse SLA
  • XPath Match
  • XQuery match
  • Script

3.1. The Contains Assertion

该断言检查接收到的响应或请求消息中是否存在某些文本,其配置对话框如下:

截图中显示的示例指定了要验证的消息的整个内容中的字符串“SessionID”的正则表达式检查。 内容支持属性扩展。

3.2. The Not Contains Assertion

包含断言的对应物;这个检查在断言的消息中不存在指定的内容。配置对话框与上述相同:

这里的截图中的例子只是检查整个响应中“Error”不存在。

3.3. The Response SLA Assertion

此声明验证响应时间在指定的值内,否则断言将失败。配置对话框是一个简单的对话框:

属性扩展支持在指定的值中,允许您通过某些外部机制(如果需要)来控制断言限制。

时间: 2024-08-25 00:43:10

用soapui功能测试-使用断言的相关文章

soapUI学习笔记---断言的小使用

转自:http://www.cnblogs.com/duimianyoushan/p/4274791.html 以下示例在soapUI 4.5中进行.刚开始学soapUI的使用,记录下以免忘记 1.创建project 2.找到要测试的Request,先请求一遍,可以请求成功.返回的结果中,有一个字段值为X 3.选中Request,右键→Add to TestCase,创建了一个test case 4.然后对该request添加断点,断点的内容为X→运行,检查返回的结果是否正确 5.下次就可以直接

SoapUI接口测试——添加断言(检查点)——Assertion

断言(检查点):即请求运行之后,增加一个检查判断,用来检查判断这个请求是否运行成功,以及结果是否和预期的一样 原文地址:https://www.cnblogs.com/xiaobaibailongma/p/12268928.html

soapui接口性能测试(三)---- 验证性能

背景:如何表现性能? 在SoapUI中,断言性能和底层功能(通过步骤状态断言)的可能性很多.找到正确的组合并不容易,因为LoadTest结果非常依赖于外部因素(特别是在高负载时); 网络,磁盘活动,数据库备份等.因此,我们建议您为LoadTest创建一个"safety net"的断言,以检测某些事情真的错误,而不是在所有情况下都期待相同的吞吐量.例如,如果您有一个步骤通常需要大约300ms,并且您想要自动执行LoadTest,则可以在大约900ms处创建一个"TestStep

WebService测试方案

1.WebService简介 WebService是一种革命性的分布式计算技术,本质上就是网络上可用的API,可以直接在网络环境调用的方法. WebService常用的框架有axis.xfire.cxf等. WebService发布后,其服务是封装在一个wsdl(Web Services Description Language,Web服务描述语言)文件中,客户端发请求主要是向发布好的wsdl地址以SOAP方式发请求,调用过程如下: Ø  服务端: n  生成服务描述文件,以供客户端获取. n 

用soapui进行功能测试-TestSteps的使用

如前所述,TestSteps是soapUI中功能测试的核心构件;每个TestStep都执行一些步骤来验证要测试的功能. TestSteps默认是依次执行的,但是分支,循环甚至调用其他TestCases有几种可能性,在需要时可以进行复杂的测试.任何数量的TestSteps都可以添加到TestCase中;通过右键单击TestStep列表并选择添加/插入或按TestCase窗口中相应的按钮添加它们: 当选择TestStep时,其右键单击菜单会显示相应的操作,左下角的属性表显示可设置的相关属性,例如下面

soapui中文操作手册(八)----Web服务的功能测试案例

现在,让我们来看看在一个TestCase的功能测试. 展开 Simple TestSuite并双击Simple Login and Logout w. Properties Steps. 正如你所看到的TestCase包括五个TestSteps. 您也可以点击才能看到的测试文档的描述标签. 该步骤包括三个不同类型的TestSteps的; 一PropertyStep,TestRequests和PropertyTransfer.他们做了什么: PropertySteps:存储属性以备后用.在我们的例

SOAPUI使用脚本进行断言

Script-Assertion允许对消息进行任意验证,包括消息内容,HTTP头等.Script-Assertion使用脚本语言(Groovy或JavaScript)编写.使用标准的"Add Assertion"按钮将Script-Assertion添加到TestStep中; 这将显示以下配置对话框 顶部区域是标准的soapUI脚本编辑器,具有相应的弹出菜单和操作.运行按钮针对上次接收到的响应执行断言脚本,并将结果显示在弹出窗口中.底部显示脚本中可用的日志变量的输出. 脚本中的mess

用soapui进行功能测试(1)-结构

1. 测试结构 SoapUI将功能测试分为三个层次; TestSuites,TestCases和TestSteps. TestSuite是TestCase的集合,可用于将功能测试分组为逻辑单元.可以在soapUI项目中创建任何数量的TestSuits,以支持大量测试场景. TestCase是TestStep的集合,用于测试服务的某些特定方面.您可以添加任何数量的TestCase到一个TestSuite. TestSteps是soapUI中功能测试的"构建块".它们被添加到TestCas

SOAPUI用测试步骤进行断言

soapUI提供两种断言方法:TestSteps中添加断言和Assertion TestStep(仅限PRO版本). Assertion TestStep扩展了断言处理和管理的想法.此功能允许创建简单到复杂的的灵活性断言,可以在测试用例中请求/响应,JMS,JDBC或安全相关活动中断言从项目级别到单个测试阶段的任何属性.此外,断言可以分组并利用布尔逻辑. 1. 添加步骤 右键单击TestCase,然后选择Add Step - > Assertion TestStep打开Assertion Tes