SOAPUI接口测试使用手册

1、SoapUI接口测试使用手册（V1.0）1. SoapUI的介绍SoapUI是专门针对Webservice接口的测试工具，功能强大且界面易用。它是直接利用Web Service的WSDL文件测试Web服务的接口，利用SOAPUI测试不需要了解底层的接口、调用关系及详细协议，也不需要使用编程来实现测试用例，而是基于WSDL自动产生测试消息。SOAPUI还支持接口的负载测试。在对同一 Web Service接口进行测试时，SOAPUI比Loadrunner表现的性能会更加优越、真实，更接近反映接口的性能指标。并且SoapUI支持多种语言，java、c+，且wcf 这种形式的接口也可支持。2. So

2、apUI的安装SoapUI基于JAVA开发，支持多个平台，需要设置 JAVA_HOME 变量指向到相应的JRE 目录，同时修改 PATH 变量，将JRE1.6 的 bin 目录添加到 PATH里面。3. SoapUI接口测试3.1 创建/导入工程启动SoapUI程序，双击目录bin下的soapui.bat，即可启动程序。程序第一次打开后，在左侧导航面板上，自动有一个空的Projects 工程。鼠标右键点击Projects，选择第一项 “New SoapUI Project”，新建一个工程。（如果本地有现成的工程，也可直接选择第二项导入工程“Import Project”，选择本地的xml文件导

3、入即可）如下图页面弹出“New SoapUI Project”框，输入Project Name，“Initial WSDL/WADL” 可填入URL 地址或直接导入WSDL 文件，（在这一步骤中，也可不导入WSDL文件，等到工程创建好后，右键点击工程名，选择“Add WSDL”也可导入）如下图所示：默认选上：Create Requests：Create sample requests for all operations?（为每个接口创建一个请求）Create TestSuite：Creates a TestSuite for the imported WSDL or WADL（为WSDL 或

4、WADL 创建一个测试包）点击OK按钮，弹出创建测试包的对话框“Generate TestSuite”：用来进行接口的性能测试，如果有需要可以勾选此处显示的都是WSDL文件中的所有方法，只须选择要测试的方法即可说明：Single TestCase with one Request for each Operation（为每个接口的请求都创建一个测试用例）Create new empty requests（创建一个空的请求）Generates a default LoadTest for each created TestCase（为每个创建好的测试用例生成一个默认的负载测试）点击OK按钮，在弹

5、出框中填入测试包的名称，点击确定按钮后，工程便创建成功。测试步骤 Test Step测试用例 TestCase测试包 TestSuite工程名Project请求Request由此图可以看到，SoapUI提供的测试用例管理的映射关系是这样的：项目Project测试包 TestSuite测试用例 TestCase测试步骤 TestStep3.2 执行测试上面步骤我们已经为WSDL文件的每个操作创建了请求和测试用例以Login TestCase为例，展开测试包下的“Login TestCase”，双击 “Test Steps”下的“Login”。双击login后，在SoapUI 的右侧会出现请求编辑

6、器：响应区域请求区域端口地址工具栏请求编辑器分为三部分：_ 顶部的工具栏，包含一组请求相关的动作、操作_ 左边是请求区域_ 右边是响应区域报文中“？”是需要被替换的内容，输入请求的参数，点击运行按钮（绿色图标），soapui会将我们填写后的soap报文发送给服务接口进行调用，返回的结果报文会显示在右侧区域。见下图：根据响应的结果报文可查看接口是否被正确调用。3.3 测试用例双击多个测试用例就组成一个测试包(TestSuite)，双击测试包，弹出下图：点击运行按钮时，可将此测试包中的所有测试用例按顺序从上到下执行测试，可以随意更改测试用例的顺利，只需右键点击某测试用例，选择“move Test

7、UP”或“Move Test Down”即可。运行按钮 点击运行按钮，可将这四条测试用例一次执行完，显示为绿色表示四条用例全部执行成功，如果其中有一条用例执行失败，则显示为红色。见下图：执行结果如果想单独执行某条测试用例，可双击测试用例名称，直接点击运行按钮即可。比如单独测试login，双击Login TestCase双击 弹出下图：直接点击运行按钮，即可将Login测试用例完成测试。日志部分3.4 测试步骤3.4.1 添加测试步骤一条测试用例中可以包含多个测试步骤，测试步骤是按顺序执行的，也可以调用其它的测试用例。n 添加测试步骤时，可有3种方法：(1)右键点击测试用例名称，在弹出菜单中选择

8、“Add Step”；(2) 右键点击测试步骤名称，在弹出菜单中选择“Insert Step”；(3)下图为双击测试用例名称打开的测试用例信息框，红色方框内为各种测试步骤，点击相应图标可以进行测试步骤的添加。点击测试步骤，左下方会显示该步骤的相关属性，可以在此进行属性的编辑，右击测试步骤，会弹出一些相关操作。n 添加测试请求注意点：点击上图红色圆圈即可添加一个请求，上图红色方框要勾选上，代表将请求中的option操作步骤元素也添加进来，否则添加的请求不完整。3.4.2 修改测试步骤点击某测试请求，右键选择Change Operation，见下图Recreate Request: 重新创建一个新

9、的Request.Create Optional: 重新创建Request时也同时会创建optional.Keep Existing：重新创建Request时会保存之前填写的Value值。3.4.2 属性Properteisn 测试用例里都会有一些主要的测试步骤来验证接口的功能，可以组合一条测试用例的所有步骤，通过属性的设置和传递在这些测试步骤间共享数据。测试步骤主要有：Properties：允许你定义任意数量的属性值，可以用来参数化请求等。Property Transfer：属性传递，允许你在测试步骤间传递属性值，它可以将各个测试步骤联系起来。可以将一个Properties的步骤将属性传给一

10、个TestRequest的步骤，也可以是将属性从一个请求的出参传递给另一个请求的入参。允许你定义任意数量的属性值，可以用来参数化请求等n 下面就建立一个属性（Properties）的操作。按照上面添加测试步骤的方法，添加一个Properties，也可点击下图中第3个按钮完成属性的添加。添加Properties 输入好属性名后，会弹出下图，点击工具栏第一个按钮，添加属性名称Name双击Value一列的框，可以添加属性值。这样包含2个属性username和password的测试步骤就添加完成了。另外，Value值也可以写成函数的形式，比如username的Value值可以写成函数：$=(int)(

11、Math.random()*100)或$=new Random().nextInt(100)-返回0100之间的随机整数。n SoapUI也可以导入txt和Properties文件，达到批量参数化的设置，但文件中不能有中文显示。下面以txt文件举例说明:Txt中的数据可以Name和Values以空格隔开，也可以写成Name=Value的形式，见以下两图：将此txt文件的数据批量导入到SoapUI Properties中的方法为：点击属性弹出框中Load from后的浏览图标，选择txt文件，即可成功导入。弹出“Create missing Properties?”提示框，选择“是” ， 就可以

12、将txt文件中的数据批量导入到Properties中，见下图：n 点击属性弹出框中Save to后的图标，可以进行数据的保存，默认保存为Properties格式，也可以自定义保存的格式（包括xls格式）。3.4.3 属性传递 Property TransferSoapUI为我们提供了两种属性传递的方法，一种是Property Transfer，另一种是Property Expansion。下面先介绍第一种方法Property Transfer。属性传递给请求参数n 添加一个Property Transfer（属性传递），先要双击某测试步骤，然后点击TestSteps的第四个按钮，

13、添加Property Transfer，如下图。添加Property Transfer输入好属性传递名后，会弹出下图，点击下图左侧第一个按钮，可添加一个传递的属性。点击此按钮添加Propery transfer添加的传递属性会在左侧显示出来，如下图，添加了1个属性传递 “move user”Xpath表达式Source表示来源是你使用了哪个测试步骤，Target表示目标是传递给哪个测试步骤，比如上图中move user表示将右边栏上半部分Source中返回的值传递给Target中指定的元素。即将属性（Properties）为username的值传递给login中的请求：Request，并且下面

14、的方框中明确了传递的元素username。通过以上步骤就完成了属性传递的添加。上图中传递给Login请求的元素username的Xpath表达式写法如下：要传递的目标是Login,双击Login测试步骤（或请求），打开login的请求报文，为如下代码：固定模式，不做改动declare namespace sam=/sample/;/sam:login/username ?传递的元素为username 12345 n 双击Login TestCase，执行包含3个测试步骤的测试用例，点击运行按钮。双击Login请求，可看到属性为username的值Log

15、in被自动传递到代码中。请求参数传递给请求参数同上面同样步骤，只是Xpath表达式不同。比如我们要将A接口的请求参数QueryType传递给B接口的请求参数QueryValue。Xpath表达式填写规则如下：A接口的请求代码：B接口的请求代码：按照上面两幅图中的红色框中方式输入传递的参数属性：点击上方绿色箭头，可查看参数是否被成功传递。如下图：响应结果传递给请求同上面同样步骤，只是Xpath表达式不同。比如我们要将A接口的响应参数Result传递给B接口的请求参数QueryValue。Xpath表达式填写规则如下：A接口的响应代码：B接口的请求代码：按照上面两幅图中的红色框中方式输入传递的参数

16、属性：点击上方绿色箭头，可查看参数是否被成功传递。如下图： Property Expansion属性传递给请求参数双击某个测试请求。1 在需要填入的请求参数（标有？）中点击鼠标右键，选择Get Data选择测试步骤的某个属性值。如下图，为 参数选择了属性Properties中的QueryType1的值。2 完成上面操作后，参数自动被赋值为“ $Properties#QueryType1 ”，这样属性QueryType1的值就被成功的传递给SystemID了。当然也可以将某个步骤响应结果中的某个参数值或请求的参数值进行传递。请求参数传递给请求参数比如：我们要将A接口中的Reques

17、t参数值 传递给B接口的请求参数。利用Property Expansion方法操作步骤如下：1. 在B接口的请求参数（标有？）中点击鼠标右键，选择Get Data A 接口Property Request ，如下图：2. 然后会弹出“Select Xpath”框，需要在框中输入传递参数的相应Xpath表达式。Xpath表达式的输入规则同上面介绍的Property Transfer方法相同。比如此例：我们要将A接口中的Request参数值 传递给B接口的请求参数。A接口的请求代码为：我们要传递的是A接口的QueryType值，同上面介绍的Property Transfer方法相同只要将对应的XP

18、ath路径输入“Select Xpath”弹出框即可：/bus:CustAuthenticateRequest/QueryType ， 如下图：3. 点击确定按钮后，在B接口的请求参数处自动显示了传递代码：这样就成功地利用Property Expansion方法将A接口的请求参数传递给了B接口。同样的原理，也可以将A接口的响应参数传递给B接口的请求参数。响应结果传递给请求利用上面的例子：将A接口中的Response参数值 传递给B接口的请求参数。利用Property Expansion方法操作步骤如下：1. 在B接口的请求参数（标有？）中点击鼠标右键，选择Get Data A 接口Proper

19、tyResponse，如下图：2. 同样会弹出“Select Xpath”框，需要在框中输入传递参数的相应Xpath表达式。原理和上面介绍的方法相同：A接口的响应代码为：我们要传递的是A接口的Result值0，同上面介绍的Property Transfer方法相同只要将对应的XPath路径输入“Select Xpath”弹出框即可：/ns1:CustAuthenticateResponse/Result ， 如下图：3. 点击确定按钮后，在B接口的请求参数处自动显示了传递代码：这样就成功地利用Property Expansion方法将A接口的响应参数传递给了B接口。3.4.4 串联测试n 测试

20、步骤中也可以创建多个测试请求，来串联进行测试。比如在测试步骤中添加2个请求，一个为login，一个为buy ，通过点击下图第一个按钮，添加Request，如下图：此处选择需要添加的请求点击OK按钮后，添加请求buy成功。为login请求添加一个断言，双击Login,点击工具栏第2个按钮添加Contains断言，填入内容1（前面已经介绍过，result为0则表示接口响应成功，此处填写1，结果肯定失败）测试步骤中请求的顺序默认是按从上往下执行的，如果第一个测试请求执行失败，则不能进入第二个请求进行测试，我们将请求buy的顺序放在login后面，点击运行按钮。可以看到login请求测试失败，就不能测

21、试buy请求，只能Login测试成功后，才会执行buy请求的测试。如果想要从测试步骤中某一步开始执行测试，也可以右击测试步骤，选择“Run from here”。n SoapUI测试步骤中还可以添加其它测试用例中的请求，以此来实现接口串联的测试。n 串联测试的结果，可以在下方Log处查看每个接口的请求/响应情况，见下图：双击某个步骤，比如双击Step2，就进入此接口的详细执行情况，请求/响应参数都会详细的显示出来，方便我们查看数据，见下图：3.5 断言SoapUI工具还提供了“断言”的功能。为了在测试中不用人为地去判断接口的响应结果是否正确，可由程序自动对返回结果进行判断。因此需要加入断言As

22、sertions，SoapUI提供了大量验证响应报文的断言，主要有：Contains ：检查指定的文本内容是否存在响应报文中。Not Contains：与Contains断言相反，检查指定的文本内容是否不包含在响应报文中。Response SLA：检查响应时间是否在指定的时间内，需要填入时间数字，单位是毫秒。Schema compliance：根据WSDL所定义内容验证响应报文和包含的XML模式。SOAP Response：验证响应报文是一个有效的SOAP响应。SOAP Fault：检查响应报文包含SOAP异常。Not SOAP Fault：检查响应报文没有包含SOAP异常。Xpath Mat

23、ch：比较通过Xpath表达式提取的结果是否与预期值相符合。3.5.1 Contains检查指定的文本内容是否存在响应报文中，下面就创建一个Contains断言。创建一个断言，可以先打开测试用例中的请求编辑器，如下图，点击左上角的第2个按钮，可增加一个断言：（只有测试用例中的请求才能添加断言，一般的接口请求不能添加）点击添加断言按钮后，会弹出“Select Assertion”对话框，通过下拉框选择“Contains”的断言，点击确定按钮后会弹出如下对话框，在Content 中填入表示返回的结果报文里应该包含的字段，比如上方Login操作根据接口协议，当返回为0时，即代表接口响应成功，所以填写

24、如下，注意最后不能有回车和空格点击“OK”，插入断言完毕，程序会在运行用例时，自动帮我们校验是否响应结果含有“0”内容，如果含有，则表示接口响应成功，断言处Contain会变为绿色，如图：断言显示为绿色，表示接口响应成功，点击此处刚刚设置的断言Contains，双击可以进行查看或编辑如果设置的断言显示为红色，则表示接口响应失败，见下图：3.5.2 Xpath Match比较通过Xpath表达式提取的结果是否与预期值相符合。以登录（Login）为例，它返回的响应结果是一个变化的。下面是Login的响应报文：实际上，我们只需要验证loginResponse中的结果sessionId这个元素的值即可

25、。点击添加断言的按钮，选择Xpath Match类型的断言。点击确定按钮后，打开一个空白Xpath Match配置框，见下图：点击“Declare”按钮，自动显示出namespace地址，对照响应结果将Xpath 表达式填写为：declare namespace sam=/sample/;declare namespace soapenv=/soap/envelope/;此行可去掉/ sam:loginResponse然后点击预期结果的“Select from current”,它可以按照Xpath表达

26、式的指定位置把最后一次响应报文中的值自动取出来这样，在执行测试时，此断言就会将Xpath表达式指定位置的值与预期结果处的值进行匹配，如果值不匹配，断言就会失败。这个例子中，由于每次取得的sessionid值都会发生变化，按照上面的设置，断言必定会失败，所以需要勾选“Allow Wildcard”允许通配符的模式进行设置，并将sessionid改为* 号显示。这样就可以匹配任何元素，只要设置的Xpath路径正确即可。3.6 接口变化3.6.1 接口地址变化测试过程中有可能我们使用的接口地址会发送变化，如果没有较好的接口地址管理方法，就需要人工一个一个去改变接口URL，效率很低。针对接口地址会发生

27、变化，soapui也为我们提供了解决方案，具体方法如下：1. 点击某项目名称，soapui左下方会显示出两个属性：Custom Properties和Project Properties。点击Custom Properties，切换到Custom标签下。新建一个Name为Endpoint（名字自定义）的属性，用来存放服务器的地址（最好在开始编写用例时，就设置好地址），该地址Value输入要连接的接口服务器URL，比如：90:8080/soap/services如下图：2. 双击项目接口名称，切换到“Service Endpoints”标签页，使用proper

28、ty Expansion方式配置端口属性，如下图：配置地址方法：比如：上图crm_custInfo项目连接服务器的接口地址为：90:8080/soap/services/crm_custInfo按照步骤1中我们定义好的Custom 属性Endpoint ：90:8080/soap/services，利用property Expansion方式将地址配置为：$#Project#Endpoint /crm_custInfo3. 地址配置好后，点击Assign，弹出Assign Endpoint框，选择All Request一项

29、，表示此项目下的所有接口请求都配置$#Project#Endpoint /crm_custInfo地址。4. 这样，当接口地址发生变化，可以在步骤1中的Custom 属性Endpoint中修改Value值，此处修改后，该工程下的接口地址都会随之改变。也可打开Request，通过“edit current”进行接口地址的编辑，只要编辑一个地址，其它所有接口的地址都会发生变化。3.6.2 参数（入参）变化1. 右键点击接口名称，选择“Update Definition”。如下图：2. 弹出下框，最好将下列选项一并勾选：Recreate Requests：重新创建接口。Recreate Option

30、al：创建接口的同时加载Optional参数。Keep Existing：保存原来的参数值，但被更新的参数，其值不会被保存，仍显示?。Create Backups：为修改前的Request创建备份，备份名称默认显示为“Backup of Request 1”。Update TestRequests：同时更新测试用例。Open Request List：打开更新的requests。此选项根据情况选择，如果接口中的request更新较多，测试用例用到的相应request也比较杂乱，可以勾选此项，随后会显示出哪些请求被更新，供方便查看。3. 点击OK按钮后，弹出下面确认框，表示共有多个Request

31、操作被更新成功。4. 点击确定按钮后，接口被更新成功。更新后的左侧菜单树如下图：5. 打开“Backup of Request 1”和“Request 1”可以对比查看哪些参数被修改。3.6.3 参数（出参）变化为每个测试用例的请求加入“Schema Compliance”断言，这样当返回的响应结果与之前定义的不一致时，这个断言就会报错，我们就可以知道这个接口的出参发生了变化。Schema：The set of statements, expressed in data definition language, that Completely describe the structure of

32、 a data base.简单的理解为：Schema定义了文档的结构，设置此断言的作用是检查response的格式是否符合之前定义的WSDL文件的要求。 当“Schema Compliance”断言报错时，只需要右键单击接口名称，选择“Update Definition”更新一下WSDL即可，然后再次运行一下请求，断言即可通过。（自己测试时，WSDL文件和Eclipse中模拟的响应代码都要相应修改，才可生效）见下图：3.7 MokeService当接口没有完成或因为某些原因导致接口服务暂时不能使用时，可以通过SoapUI提供的MokeService功能人为地模拟接口服务，去完成测试，这样就可以

33、使测试人员能够在早期进行接口测试用例的调试，这意味着，当真正的Web Service服务接口可以开始测试时，你的用例设计工作可能早已完成，可以直接开始测试。n 添加一个MokeService。 右键单击接口集合的名称，选择Generate MokeService。见下图：弹出下图，可以使用默认设置的值，点击OK按钮，输入MokeService名称，点击确定按钮后，便创建成功。运行用例时所用的端口地址路径要和此处相一致经过上面的操作，一个MokeService便成功生成，接下来就可以去设置响应操作了。双击某个操作的响应Response，比如双击search的Response 1 , 出现下图响应

34、报文。？处代表需要填入的响应结果右侧代码“？”处说明需要你填入响应参数，填入的这些参数也许不是真实的数据信息，只是人为地去模拟响应结果，比如填入1，成功,100。将这些填好后，打开测试用例search的测试步骤，点击运行，显示的响应结果就显示为在MokeService中填入的响应参数，注意端口地址URL一定要和新建MockService时的Path和Port相一致。如下图：n 注意：使用MokeService功能，在执行测试前，必须将MokeService服务启动。双击MokeService，弹出下图。点击运行按钮，MokeService就启动成功了，可以看到MokeService运行在808

35、8端口。6. SoapUI对Web Service服务进行负载测试创建完测试用例后，SoapUI可以快速地创建对应的负载测试用例，这个是非常实用的功能，越早进行负载测试，越早暴露性能问题。而且可以在功能测试完成的情况下，快速地、方便地、随意地检验Web Service接口是否能够承载指定的负载量。在测试用例名称上右键选择“New LoadTest”，弹出对话框需要用户输入负载测试用例名称。 输入负载测试用例名称后点击“确定”按钮，新建的负载测试用例显示在左侧导航树中，右侧展示新建的负载测试用例详细信息。可以对一个测试用例创建多个负载测试用例，共有四种负载策略Burst、Simple、Varia

36、nce、Thread，可以根据需要进行设置，双击某一个负载用例，可以配置里面的配置项。Limit：表示负载测试要持续执行的时间，秒为单位；Threads：配置负载测试所用的线程数，即一般性能测试中所说的并发数；Test Delay：设置测试时线程的休眠时间，即在完成一次完整的用例执行后，开始下一次执行时，线程的休眠时间，以毫秒为单位；Random：该值的设置是与“Test Delay”的设置结合在一起的，表示休眠时间会在Test Delay的Random范围内波动。如果Test Delay的值设为1000，Random的值为0.5，表示线程的休眠时间会在1000*（1-0.5）=500毫秒和1

37、000*（1+0.5）=1500毫秒之间波动。同功能测试一样，也可以设置负载测试用例断言，点击负载测试用例窗口下方“LoadTest Assertions” 出现增加断言的窗口，点击增加断言窗口左侧的小图标，弹出增加断言类型窗口，最大错误数（Max Errors）、步骤平均响应时间（Step Average）、步骤TPS（Step TPS）、步骤最大响应时间（Step Maximum）和步骤状态（Step Status）。一般会选择最大错误数，可以对单一步骤设置断言，直接选择步骤名称即可；也可以对所有步骤设置断言（Any），当出现的错误数达到Max errors值时，负载测试会停止。所有配置项

38、和断言设置完毕后，点击运行按钮，就开始执行了，监测的指标会实时的发生变化。也可以通过点击下图的图标查看测试整体趋势图。点击右侧的图标可以将监测结果导出到文件，方便分析。7. 接口调用失败常见例子4.1 连接被拒绝点击运行按钮后，编辑器右侧无任何响应内容，最下方显示“Error getting response:Connect Exception: Connection refused: connet ”，说明服务端口连接失败，需要更改端口地址。需要更改此地址如果用到MokeService功能，可以点击MokeService，在工具左下侧属性中查看Path路径和端口号，再进行相应的端口地址更改。

39、见下图：比如本地IP地址：计算机名称：ibm-ffd15c1MokeService Path路径：/mockLogin 端口号：8080则运行用例的端口地址可以写为：31:8080/mockLogin或http:/ ibm-ffd15c1:8080/ mockLogin4.2 响应结果不正常如果响应结果为以下代码：There are currently 0 running soapUI MockServices则表示MockServices没有启动，需要先运行MockServices，在执行测试。4.3 Contains断言总是失败设置的Contains断言

40、内容明明在响应报文中存在，但执行测试时，仍显示失败状态，这种情况下需要查看你设置的断言末尾是否有回车和空格，如果有，应去掉。8. xpath路径表达式学习网站：简单说，xpath就是选择XML文件中节点的方法。所谓节点（node），就是XML文件的最小构成单位，一共分成7种。- element（元素节点）- attribute（属性节点）- text （文本节点）- namespace （名称空间节点）- processing-instruction （处理命令节点）- comment （注释节点）- root （根节点）xpath可以用来选择这7种节点。不过，下面的笔记只涉及最常用的第一种element（元素节点），因此可以将下文中的节点和元素视为同义词。 一、 xpat