拿到一个webservice接口，测试第一件事不是接口找工具，而是测试先看WSDL文档。这玩意儿长得像天书，接口但里面藏着所有秘密——方法名、测试参数类型、接口返回结构，测试全写死了。接口soapui最狠的测试地方就是能直接解析WSDL，把抽象的接口描述变成可视化的请求模板。省去了手搓XML的测试麻烦，也避免了因为一个命名空间拼错导致的接口404噩梦。

我常用的测试是soapui 5.7版本，界面老气横秋，接口但胜在稳定。测试新建项目时把WSDL地址粘进去，软件自动生成所有operation。这时候别急着点发送，先看看soapui生成的默认请求。你会发现很多字段是空壳子，需要手动填充。比如一个查询用户信息的接口，参数里往往藏着userId和token，前者好说，后者得从登录接口的响应里提取。这就是soapui的进阶玩法——用Groovy脚本写断言和属性传递，把多个请求串联成完整的业务流。

调试单个接口时，我习惯先切到“Raw”视图看原始报文。soapui的友好界面有时会掩盖问题——你以为传了个整数，实际上序列化后变成了字符串。看原始XML最直接，<arg0>10086</arg0>和<arg0 type="int">10086</arg0>是两码事。服务端报错时，响应里往往带着soap:Fault节点，里面那串英文描述才是真正的线索。别被界面上的红色感叹号吓住，点开看细节，多半是参数类型不匹配或命名空间对不上。

压力测试这块，soapui做得比postman专业。你可以给同一个请求设置线程数和循环次数，模拟并发场景。我上周测一个支付回调接口，用10个线程跑200次，结果发现服务端在并发第37次时抛出了数据库死锁异常。这个bug在单次调用里根本发现不了。soapui的负载测试报告会生成响应时间曲线和TPS统计，虽然界面土，数据倒是实打实的。

还有个容易被忽略的功能——MockService。后端还没开发完时，你可以根据WSDL先模拟一个假服务，返回预设的响应数据。前端同事拿着这个mock地址就能联调，不用干等。等真实服务上线了，再把soapui里的请求地址切换过去，一套测试用例照样跑。这比写一堆假的controller强多了，毕竟soapui生成的mock服务连SOAP规范都给你处理好，省心。

最后说个坑。soapui默认使用HTTP/1.1，有些老旧的webservice强制要求SOAPAction头。你得在请求属性里手动添加SOAPAction，值通常是目标方法的URI。不填的话，服务端直接返回"Unable to handle request without a valid action parameter"。这问题排查起来最费时间，因为报错信息根本没指到点子上。我的经验是，拿到WSDL后先搜soapAction属性，把每个operation对应的值抄下来，建请求时顺手粘上去，能省半小时。

工具终究是工具，关键看你怎么用。soapui这玩意儿入门容易，但要玩得转，还是得对SOAP协议本身有感觉。报文结构、命名空间、WSDL的schema定义，这些底子扎实了，soapui就是一把趁手的刀。