SoapUI 5.3免安装版：WebService调试、断言Mock与CI回归

简介：这份 SoapUI 5.3 免安装包面向 Web 服务接口测试初学者、后端开发人员与功能测试工程师，适合快速验证 SOAP 与 REST 接口功能、复现服务调用异常、开展接口回归检查，以及在联调阶段核对请求与响应。它省去安装与注册配置环节，解压后即可在 Windows 环境启动，便于在临时项目、演示机器和不同测试环境之间迁移使用。压缩包共 203 个文件，整体约 46.82MB，包含 99 个 jar 运行库、49 个 txt 说明与配置文件、24 个 xml 配置、13 个 bat 启动脚本，并有 xsl、wsdl、wadl 等接口描述与转换文件，可支撑图形界面调试、命令行执行、模拟服务、负载测试和安全测试等入口。功能上支持导入 WSDL 自动生成测试用例，编辑 SOAP 消息并查看响应，也能为 REST 请求设置方法、请求头与路径，再通过断言校验返回结果；LoadTest 可模拟并发用户并观察响应时间与吞吐量，数据驱动测试则可从 CSV 或数据库读取参数。已有 399 人学习，读者可借助它熟悉 Groovy 脚本自动化、WS-Security 扫描、测试报告查看和日志排查流程，也能理解测试套件组织、属性传递与持续集成调用的基本思路。对接口字段较多或需要反复回归的项目，可直接复用已有工程与测试步骤，减少重复录入和环境搭建时间；整体轻便，适合随身携带与离线演示。

1. 解压就能跑的 SOAP 调试台：SoapUI 5.3 免安装版省掉的到底是什么

对接一个第三方 WebService，对方只丢过来一个 WSDL 地址，要求一天内把十几个接口全部调通。装 IDE、建工程、引依赖、写客户端骨架，光样板代码就能耗掉半天，而真正要看的是报文长什么样、哪些字段必填、失败时返回的 SOAP Fault 是什么结构。SoapUI 5.3 免安装版针对的就是这个场景：解压出一整个目录，双击脚本起界面，把 WSDL 导进去，请求模板自动生成，改几个字段就能发。它解决的不是业务代码，而是写代码之前把接口摸清楚这件事。适合做联调的后端、做接口回归的测试，以及偶尔被拉去验证 WebService 是否存活的运维。下面按跑起来、会断言、能 Mock、避坑、上命令行的顺序，把这套 SoapUI 5.3 免安装包拆成能照着复现的步骤。

2. 从 WSDL 到第一条能发的请求：免安装包落地三步

免安装版最大的误解是“解压完双击就能用”。多数人卡住不是不会用 SOAP，而是启动阶段的环境没对齐。这一章先把目录和 JDK 掰开看，再走 WSDL 导入，最后把端点、认证、SOAPAction 这三个真正决定请求能不能通的东西配好。整条链路走完，你会拿到一个能反复重放的请求步骤，后面做断言、做 Mock、上命令行都建立在这上面。

2.1 先看目录结构和 JDK，别急着双击

解压之后的根目录通常是bin、lib、hermesJMS这几种，启动入口全在bin里。soapui.bat和soapui.sh是图形界面，testrunner.bat和testrunner.sh是无界面跑用例的，后者才是后面做批量回归的关键。lib下是一堆 jar，界面上所有的功能模块、Groovy 引擎、XML 处理库全在里面，所以这份包体积不小，但也正因为依赖都自带，才不需要额外装什么。

不少绿色包会在根目录带一个jre或者jdk文件夹，那是打包人塞进去的内置运行时。判断方法很简单，开一个命令行窗口，进到bin目录，手动执行一次启动脚本，看报错信息，而不是双击：

:: Windows 下先进 bin 目录，手动调用，报错才留在窗口里 cd /d D:\tools\SoapUI-5.3\bin set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_202 soapui.bat

# Linux / macOS 下先确认运行时，再起图形界面 cd /opt/SoapUI-5.3/bin export JAVA_HOME=/usr/lib/jvm/java-8-openjdk java -version ./soapui.sh

这里有两个参数要盯紧。JAVA_HOME指向的应当是 JDK 而不是精简过的 JRE，因为部分脚本断言和证书工具会去摸tools.jar一类的东西，只给 JRE 时表现为“界面能开，个别功能点到就抛异常”。版本上，常见做法是钉在 JDK 8；SoapUI 5.3 距今有些年头，配高版本 JDK 时偶发类加载和 HTTPS 协议协商问题，新人排查这类问题性价比极低。另外路径里尽量别带空格和中文，带空格的路径在.bat里不加引号会被截断，表现就是闪一下就没了。

如果目录里确实自带运行时，也可以用脚本自带的探测逻辑，但建议还是显式设一次JAVA_HOME，免得到换机器时忘了这份包是靠内置运行时跑起来的，挪到没网的内网机才发现对不上。

提示：装完先跑一次“新建空工程 → 保存 → 关闭 → 再打开”，确认工作空间目录可写。工作空间默认落在用户目录下，受限账号或漫游配置环境下会写失败，表现为保存后重启工程不见了。

2.2 导入 WSDL：URL 和本地文件怎么选

WSDL 导入的入口是File → New SOAP Project。弹窗里填三项：Project Name 随便起但要能看出业务；Initial WSDL 填地址或者本地文件路径；下面一排勾选框决定生成多少东西，Create Requests生成请求模板，Create TestSuite顺手把用例骨架建好，Create MockService直接生成一个对应接口的 Mock，Cache WSDL把 WSDL 内容复制进工程文件。

对方服务在内网可达、WSDL 地址稳定时，直接填 URL 最省事。但我一般的习惯是先curl或浏览器把 WSDL 拉下来存成本地文件再导入，理由有三个：对方接口一旦下线，工程里所有引用都会变成红叉；URL 形式的 WSDL 每次打开工程都可能重新拉一遍，慢且不稳定；本地文件便于进版本库，谁改了什么一目了然。

# 先把 WSDL 和它 import 的 XSD 一起落到本地，保证离线也能打开工程 mkdir -p wsdl/order curl -s -o wsdl/order/order.wsdl http://127.0.0.1:8080/ws/order?wsdl # WSDL 里如果还有 <xsd:import schemaLocation="...">，同样抓下来放到相对路径 grep -o 'schemaLocation="[^"]*"' wsdl/order/order.wsdl

导入成功后，左侧树是Projects → 你的工程 → interfaces → 具体接口 → Binding → 操作名。一个 WSDL 里如果声明了多个 service 或多个 portType，就会展开成多个 interface，别看到一堆节点就以为导错了。真正要核对的是 WSDL 里的三处信息：targetNamespace决定后面 XPath 断言里的命名空间，soap:address location是默认端点，每个 operation 对应的soapAction在请求窗口底部能改。

<!-- 导入后重点看 targetNamespace 和 address location 这两处 --> <wsdl:definitions targetNamespace="urn:demo:order" xmlns:tns="urn:demo:order"> <wsdl:service name="OrderService"> <wsdl:port name="OrderPort" binding="tns:OrderBinding"> <!-- 默认端点，联调时经常要改成测试环境地址 --> <soap:address location="http://127.0.0.1:8080/ws/order"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

targetNamespace是新手最容易忽略的参数。它不会影响请求能不能发出去，但会让 XPath 断言永远匹配不到，因为报文里每个元素都挂在这个命名空间下，XPath 不声明前缀就只能按无命名空间匹配，结果恒为空。这一点在第 3 章的断言里还会再提一次。

如果 WSDL 里有xsd:import或wsdl:import且schemaLocation写的是相对路径，导入时必须保证被引用的文件在旁边，否则界面会给一个“无法解析”的提示，生成的请求模板里字段全是?。碰到这种情况，把引用文件按原相对路径摆好再重新导入，比手工补字段快得多。

2.3 把请求发出去：端点、认证、SOAPAction 三件事

请求模板生成后长这样，?是 WSDL 里没给默认值的占位符，发之前必须换掉，否则服务端会当成字符串?处理，返回的参数校验错误往往让人以为是报文结构错了：

<!-- 请求体：命名空间要和 WSDL 的 targetNamespace 一致 --> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ord="urn:demo:order"> <soapenv:Header/> <soapenv:Body> <ord:queryOrder> <ord:orderNo>202401010001</ord:orderNo> </ord:queryOrder> </soapenv:Body> </soapenv:Envelope>

soapenv:Envelope的命名空间是 SOAP 1.1 的固定值，SOAP 1.2 是另一套，两者不能混。soapenv:Header为空时也别顺手删，有些服务端做 schema 校验时会因为缺 Header 节点报错。端点地址在请求窗口左上角的输入框里改，改完只对当前请求生效；想让整个 interface 下的所有请求都指向新地址，双击 interface 节点改Service Endpoint，这样后面新建的请求也继承。

认证分两条路。HTTP 基本认证在请求窗口左下角的Auth页签里填用户名密码，勾上Preemptive可以避免第一次 401 往返，某些网关对未预认证的请求直接断开。WS-Security 则是另一套东西，要点Auth旁边的WS-Security Configurations新建一个配置，加 Username Token，再回到请求的Outgoing WS-Security Configurations里挂上。

SOAPAction在 SOAP 1.1 里是 HTTP 头的一部分，服务端路由经常靠它。WSDL 里每个 operation 都会声明soapAction，SoapUI 导入时会自动填进请求属性，但如果对方网关改了路由规则，就得手工在请求窗口底部覆盖。一个常见的翻车现场是：报文完全正确，返回却是Unsupported Media Type或者一个空响应，最后发现是SOAPAction带着引号、或者和 WSDL 声明的值差了个斜杠。

请求发出去后，右侧窗口能看到原始请求报文、原始响应报文、XML 树视图和 HTTP 头。第一次调通时建议把HTTP Log打开，头信息里的Content-Type（是否为text/xml; charset=utf-8）、状态码、响应时长，都是后面断言和排查的依据。

3. 断言与数据驱动：把手工点变成每次都能重跑的回归

请求跑通一次只证明当下这一次是通的。接口回归的价值在于，改动之后能一键知道有没有坏。这一步靠断言和数据驱动完成，前者决定“什么叫对”，后者决定“用多少组数据去证明它对”。

3.1 断言别只勾 Contains：三层组合最稳

新建 TestCase 时会自动带一个Contains断言，很多人就靠它看返回里有没有某个字符串。这个断言在报文短的时候够用，但它对结构变化毫无感知：字段顺序、命名空间、节点位置全变了，只要那个字符串还在，照样通过。

我的习惯是三层组合。第一层Valid HTTP Status Codes填200，先把网络层和网关层的异常挡掉，否则后面所有断言都会因为响应体是错误页而误判。第二层Schema Compliance，指定 WSDL 或 XSD，校验响应的结构合法性，这一层能抓住“字段类型改了”“必填节点没了”这类问题。第三层才是业务断言，XPath Match精确取值，或者用 Groovy 脚本做计算判断。

XPath Match的配置里有个Namespaces按钮，点开把 WSDL 里的前缀和 URI 加进去，XPath 才能匹配到节点。写 XPath 时用//ord:queryOrderResponse/ord:status这种形式，前缀名可以自己起，但必须和命名空间表里登记的一致。如果对方返回的前缀和 WSDL 不一致（很常见，不同框架序列化出来的前缀五花八门），XPath 匹配的是命名空间 URI 而不是前缀本身，所以只要 URI 对上就没问题。

schema断了的情况要单独说一句：Schema Compliance报错时，界面上给的信息往往只告诉你哪一行不符合，不告诉你为什么。把响应报文复制出来，丢给任意一个 XML 校验工具对着同一个 XSD 跑一遍，能更快定位是字段缺失还是类型不匹配。

3.2 Properties 加 Data Source：参数化的最小闭环

把订单号写死在请求体里，做过一次之后基本不会再想第二次。参数化的第一步是在 TestCase 上右键Add → Properties，建一个属性表，里面放orderNo、expectStatus这类键值对。请求体里用${#TestCase#orderNo}引用，注意作用域前缀不能省，只写${orderNo}在复杂工程里很容易被同名属性覆盖。

<!-- 请求体改成引用属性，值在 TestCase 的 Properties 里维护 --> <ord:queryOrder> <ord:orderNo>${#TestCase#orderNo}</ord:orderNo> </ord:queryOrder>

这套引用语法在 SoapUI 里是通用的：#Project#挂整个工程的公共配置（比如环境地址），#TestSuite#放一组用例共享的数据，#TestCase#放单条用例的，#MockService#只在 Mock 里可用，#Global#是全局的。层级越低优先级越高，覆盖关系是自下而上。实际项目里我一般把端点地址放#Project#，把账号密码放#TestSuite#，业务数据放#TestCase#，这样换环境只改一处。

数据量大了就用Data Source步骤。右键 TestCase →Add Step → Data Source，类型选 Excel、CSV、XML 或 JDBC，指定文件或连接，界面会把列名读出来作为属性名。后面接请求步骤，再接一个Data Source Loop指回 Data Source，就能逐行跑完整个文件。

// Data Source 步骤之后的 Groovy 步骤：把当前行的值打到日志里，方便核对取数是否正确 // context 由 SoapUI 注入，currentRow 是 Data Source 暴露的行对象 def ds = context.testCase.getTestStepByName("DataSource") def row = ds.getPropertyValue("orderNo") log.info "当前行 orderNo = ${row}"

这段脚本的作用是在数据驱动链路里加一个可观测点。参数说明：getTestStepByName用的是步骤显示名，改过名字要同步改脚本；getPropertyValue取的是数据源里那一列的当前行值。真跑起来发现所有行取到的都是第一行，八成是Data Source Loop的Target Step没指回数据源开头，循环没推进。

数据源文件的编码也是个坑。CSV 存成带 BOM 的 UTF-8，某些版本的解析器会把 BOM 当成第一列的第一个字符，导致列名匹配不上，表现为“属性值为空但文件里明明有”。遇到就往无 BOM 的 UTF-8 或 GBK 存一份试试。

3.3 Groovy 脚本断言：处理“必须算一下”的场合

XPath 能取单值，但“返回的明细条数等于表头声明的条数”“总金额等于明细金额之和”这类跨字段校验，只能写脚本。SoapUI 内置 Groovy，脚本断言里可以直接用messageExchange和context两个注入对象。

// Script Assertion：校验返回明细条数与表头自洽、金额为正 // context.expand 里的 queryOrder 是请求步骤名，Response 是固定后缀 def resp = context.expand('${queryOrder#Response}') def holder = new com.eviware.soapui.support.XmlHolder(resp) holder.namespaceAware = true holder.declareNamespace('o', 'urn:demo:order') def status = holder.getNodeValue("//o:queryOrderResponse/o:status") def total = holder.getNodeValue("//o:queryOrderResponse/o:totalAmount") as BigDecimal def items = holder.getNodeList("//o:queryOrderResponse/o:items/o:item") assert status == 'PAID' : "状态不符，实际=${status}" assert total > 0 : "金额异常：${total}" assert items.size() >= 1 : "明细为空，条数=${items.size()}"

逻辑和参数逐条说。context.expand('${步骤名#Response}')是把上一步的响应文本取出来，括号里的语法和属性引用同源，步骤名改了脚本必须跟着改。XmlHolder是全类名调用，脚本环境里不自动导入这个类。namespaceAware = true必须显式打开，否则 XPath 会忽略命名空间，取出来的值全是 null——这是脚本断言里出现频率最高的一个坑，且报错信息不明显。declareNamespace声明的前缀要和 XPath 里用的完全一致。最后as BigDecimal是强制类型转换，直接对字符串做>比较在 Groovy 里会按字典序走，"9" > "10"为真，这种错误在金额校验上足够致命。

断言失败时，消息会显示在 TestCase 的断言面板里，冒号后面那句自定义文案就是给人看的。写自定义文案时把实际值拼进去，排查时能省一次复现。

4. Mock Service 与异常注入：对方接口没好时怎么先开工

真实项目里，甲方接口往往比你的排期晚。等接口再开发等于把风险堆到最后一天。Mock Service 的作用就是按 WSDL 起一个假服务，返回体由你控制，前端和调用方可以立刻开始联调。

4.1 从 interface 生成 MockService 的三步

在导入好的 interface 上右键 →Generate MockService，弹窗里填端口和路径，端口建议避开 8080、8000 这类常用端口，防止和本机其他服务撞车。生成后左侧树会多出一个MockServices节点，里面有 MockService、MockOperation、MockResponse 三层，双击 MockService 点绿色三角启动。

启动之后有个容易漏的动作：MockService 的访问地址是http://本机IP:端口/路径，而请求步骤里的端点仍然是 WSDL 里的原地址，两边对不上，表现出来的现象是“Mock 明明启动了，请求还是报连接失败”。解决办法是在请求里把端点改成 Mock 地址，或者更优雅一点，用#Project#属性管理端点，切换环境只改一处。

Mock 默认只监听本机回环地址，局域网里另一台机器访问不到。需要让别人调的时候，在 MockService 设置里把Host改成0.0.0.0，然后确认本机防火墙放行该端口。这一步在内网联调时几乎必踩。

4.2 Dispatch 用 Script 按入参分支返回

MockOperation 默认的 Dispatch 是SEQUENCE，按顺序循环返回预设的响应。要按入参返回不同结果，得改成SCRIPT。

// MockOperation 的 Dispatch 选 SCRIPT // mockRequest / mockResponse 由 SoapUI 在运行时注入 def req = new com.eviware.soapui.support.XmlHolder(mockRequest.requestContent) req.namespaceAware = true req.declareNamespace('o', 'urn:demo:order') def orderNo = req.getNodeValue("//o:queryOrder/o:orderNo") if (orderNo == '0000') { // 模拟业务异常：SOAP Fault，客户端应当能解析 faultstring mockResponse.setResponseContent(""" <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <soapenv:Fault> <faultcode>soapenv:Server</faultcode> <faultstring>order not found</faultstring> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope>""") } else { // 正常返回，注意根元素带着命名空间 mockResponse.setResponseContent(""" <o:queryOrderResponse xmlns:o="urn:demo:order"> <o:status>PAID</o:status> <o:totalAmount>128.00</o:totalAmount> </o:queryOrderResponse>""") }

mockRequest.requestContent是客户端发来的原始报文，用XmlHolder解析后按 XPath 取字段。mockResponse.setResponseContent直接覆盖返回体，覆盖之后不再走预设响应。Fault 报文的faultcode前缀必须和 Envelope 上声明的命名空间前缀一致，写成soap:Server而 Envelope 声明的是soapenv时，某些客户端解析会直接抛异常。

这个脚本的价值在于，一份 Mock 能覆盖正常、异常、边界三类返回，调用方在对方接口上线前就能把容错逻辑写完。

4.3 异常注入：超时、5xx、脏数据

// 模拟慢响应：让调用方验证超时与重试逻辑 Thread.sleep(5000) // 模拟网关错误 mockResponse.setResponseHttpStatus(500) // 模拟脏数据：返回结构不完整的报文，测客户端容错 mockResponse.setResponseContent("<o:queryOrderResponse xmlns:o=\"urn:demo:order\"><o:status>PAID")

Thread.sleep的单位是毫秒，5 秒足够触发大多数客户端的默认超时。setResponseHttpStatus(500)设置的是 HTTP 状态码，业务层可能还会正常解析报文，所以调用方要同时处理状态码和报文两种失败形态。截断的报文用来测客户端是不是做了严格的 XML 解析——如果调用方拿到半截 XML 直接崩，说明容错没做。

异常注入做一轮，往往能提前发现对方接口设计里没写清楚的边界，也能发现自己代码里那堆“只考虑成功路径”的分支。

5. 免安装版的避坑排查：五个把人卡住的现场

绿色包省了安装，也省掉了安装程序帮你处理的那部分环境适配。下面五个场景是我在不同机器上反复遇到的，每条按现象、原因、解决讲，遇到同类问题可以直接对号入座。

5.1 双击启动一闪而过，命令行能看到报错

现象：双击soapui.bat，黑框闪一下就没了，什么提示都没有。

原因：脚本里引用的JAVA_HOME不存在、路径带空格没加引号、或者 JDK 位数和系统不匹配。双击运行时窗口是执行完立刻关闭的，错误信息来不及看。

解决：开一个 CMD 窗口手动进bin目录执行脚本，报错会留在屏幕上。看到JAVA_HOME is not set就补环境变量；看到Unsupported major.minor version说明 JDK 版本不对，换 JDK 8；路径带空格时在脚本里给变量加双引号。改完先跑java -version确认能起来，再启动 SoapUI。

5.2 返回中文乱码，或请求体里的中文被转成问号

现象：响应里中文显示为乱码；或者发出去的请求里中文变成?。

原因：两层编码不一致。JVM 默认编码、工程文件编码、HTTP 响应的charset声明，这三者只要有一处不同就会出问题。免安装环境的默认编码跟随系统区域设置，在英文系统或容器里经常不是 UTF-8。

解决：给启动脚本加 JVM 参数-Dfile.encoding=UTF-8，改完重启界面。请求体的 XML 声明里写<?xml version="1.0" encoding="UTF-8"?>，确保声明和实际字节一致。响应乱码如果是对方服务端造成的，把响应原始字节抓出来用十六进制看，确认是服务端编码问题还是本地展示问题，别在自己这边瞎调。

5.3 换台机器打开工程，满屏红叉

现象：工程在 A 机器好好的，复制到 B 机器后所有 interface 变红，请求发不出去。

原因：工程 XML 里缓存了 WSDL 的绝对路径或原始 URL。免安装包自己不带任何项目数据，工程文件是跟人走的，路径一变就断。对方 WSDL 服务下线时同理。

解决：把 WSDL 文件随工程一起放到固定相对目录，导入时选本地文件而不是 URL。已经在工程里的，双击带红叉的 interface，重新指定 WSDL 位置。更彻底的做法是导入时勾上缓存选项，让 WSDL 内容进工程文件，后续即使源文件没了也能打开工程，代价是工程文件变大、WSDL 更新后要手动重新导入。

5.4 HTTPS 接口握手失败，报协议或证书错误

现象：请求 HTTP 接口正常，切到 HTTPS 就报handshake_failure、PKIX path building failed或直接空响应。

原因：两种可能。一是服务端用的 TLS 协议版本或加密套件不在当前 JVM 默认支持范围内；二是自签证书或内部 CA 签发的证书不在信任库里，JVM 直接拒绝。

解决：证书问题把服务端证书导入 JVM 的cacerts，用keytool -importcert命令，导入后重启。协议问题在启动脚本里加 JVM 参数指定协议版本，或者临时在 SoapUI 的 SSL 设置里配置信任库。生产环境不要图省事把所有证书都信任掉，测试环境图快可以，上线前必须收回。

5.5 大报文跑到一半内存溢出，或命令行执行直接卡死

现象：返回报文几十兆时界面卡顿，日志里出现OutOfMemoryError；或者用testrunner批量跑时中途无响应。

原因：启动脚本里的堆内存上限是默认值，图形界面本身也吃内存，几十兆的报文加上断言解析很容易触顶。批量跑时所有用例的响应都攒在内存里，更容易爆。

解决：改bin下启动脚本里的内存参数，一般调到 2G 起步，同时加上-XX:MaxPermSize之类的高版本已废弃参数要删掉。批量跑时用-r之类只输出报告不保留全部响应的选项，减少常驻内存。跑之前用任务管理器看一眼当前占用，留出余量再加。

注意：改启动脚本属于对绿色包的本地化改造，改完记得在目录里留一个README记录改了什么，否则下次换机器重新解压时全忘。

6. 命令行加 CI：把绿色包用出真正的价值

图形界面适合调接口，不适合跑回归。免安装包真正的生产力在bin/testrunner.bat和testrunner.sh上——它们和图形界面共用同一份工程文件，但可以在没有桌面的服务器上跑，出 JUnit 格式报告，失败时返回非零退出码，正好接进流水线。

:: 无界面执行指定 TestSuite 下的指定用例，输出 JUnit 报告到指定目录 cd /d D:\tools\SoapUI-5.3\bin testrunner.bat ^ -s"OrderSuite" ^ -c"QueryOrder" ^ -r -j ^ -f"D:\ci\report\order" ^ -I ^ "D:\ci\project\order-soapui-project.xml"

参数逐个说：-s指定 TestSuite 名，-c指定 TestCase 名，两个都不填就跑整个工程的所有用例；-r生成 JUnit 风格报告，-j表示报告里附带请求响应日志，出问题时能直接翻；-f指定报告输出目录，目录必须已存在否则可能不写；-I把结果同时打到控制台，调试流水线时很有用；最后一个是工程文件路径，必须放在所有参数之后。如果工程里配了多个环境，用-E指定环境名，换测试环境和生产环境只改这一个参数。

退出码是接 CI 的关键：全部用例通过返回 0，有失败返回非零。流水线里只需要判断这一步的退出码，不用去解析报告文件。

一个血泪经验：命令行跑的结果和图形界面不一致时，九成是环境属性没对上。图形界面里手动改过的端点、认证信息有时只存在会话里没落盘，而命令行读的是工程文件里保存的值。定位方法是在命令行加-I，把实际发出去的报文打出来比对，一眼就能看出端点是旧的还是新的。

从那以后我每次接 WebService 项目，工程文件建好的第一件事就是把testrunner那行命令写进脚本，先在本地跑通、确认退出码正常，再交给流水线。这份免安装包解压即用、依赖自带、命令行和界面共用同一份工程，恰恰最适合这种“本地调、服务器跑”的分工。希望这套流程能帮到你。

本文还有配套的精品资源，点击获取