Postman 打开的接口那一瞬间，我其实有点烦它。测试一个 REST 接口，工具点一下 Send 就完事，接口偏要等它转两秒加载 UI。测试后来换成 curl，工具一行命令跑完，接口输出干净利落。测试但遇到 SOAP 的工具 WebService，curl 就有点力不从心了——你得手写 XML envelope，接口还得处理 WS-Security 头，测试稍微复杂点的工具场景直接劝退。

这就是接口 WebService 接口测试工具存在的理由。不是测试所有接口都叫 REST，还有一大堆老系统跑着 SOAP、工具WSDL、UDDI 那一套。银行、电信、政务平台，很多核心服务至今没挪窝。你拿 Postman 去测，它确实能发 POST，但 WSDL 解析、SOAP 动作识别、附件传输这些，它做得不够顺。

SoapUI：老牌选手，功能全但有点重

SoapUI 是我用得最多的一个。新建项目时直接贴 WSDL 地址，它会自动拉取所有操作、生成请求模板。这点很省事，不用对着文档一个个手敲 XML。断言也丰富，XPath Match、XQuery、Contains 都能用。做数据驱动测试时，DataSource 配个 Excel 或 JDBC，循环跑几百条用例没问题。

但它的毛病也明显。启动慢，内存吃得多，开着它再开 IDEA 风扇就狂转。界面是 Swing 写的，在高分屏上字体发虚。开源版不支持 Mock 服务，要那功能得买 ReadyAPI，价格不便宜。我一般只在需要复杂断言或安全测试时才开它，日常调试更倾向轻量方案。

Postman 其实也能测 SOAP

很多人不知道 Postman 可以发 SOAP 请求。方法很简单：新建 POST 请求，URL 填服务地址，Body 选 raw + XML，把 SOAP envelope 粘进去，再手动加一个 SOAPAction 头。跑起来跟 REST 没区别。缺点是 WSDL 不会自动解析，每个操作的 XML 得自己拼。适合接口数量少、结构固定的场景。

我有个做支付对接的朋友，他们后端全是 SOAP 服务，但前端团队习惯用 Postman。他就写了个脚本，用 Python 的 zeep 库解析 WSDL，自动生成 Postman collection。省了手工活，也绕开了 SoapUI 的笨重。这思路挺实用——工具是死的，组合起来用就灵活了。

命令行党可以看看 curl 和 xmlstarlet

如果你跟我一样经常在服务器上排查问题，图形工具根本装不了。这时候 curl 配 xmlstarlet 就是救星。curl 发请求，xmlstarlet 解析响应里的节点值，再用 grep 或 awk 做断言。写进 shell 脚本里，跑回归测试快得飞起。

curl -s -X POST -H "Content-Type: text/xml" \ -d @request.xml http://example.com/service | \ xmlstarlet sel -t -v "//ns:Result" -n

这行命令的意思很直白：发 XML 请求，提取 Result 节点的文本。没有花哨的界面，但胜在稳定、可版本控制、能塞进 CI 流水线。Jenkins 里跑一轮，失败就发邮件，比手动点按钮靠谱得多。

选工具这事，别纠结

我见过团队为了统一工具吵半天。其实没必要。SoapUI 做复杂场景和报表，Postman 做日常调试和文档分享，curl 做自动化回归，各干各的活。关键是接口定义要清楚——WSDL 文件别乱改，XSD 校验别跳过。工具只是壳，底层协议理解透了，用什么都顺手。

最后提一句：测 WebService 时记得关掉 SOAP UI 的默认超时。有些老服务响应慢，30 秒不够用，请求直接断掉，你还以为是服务挂了。这种坑踩过一次就记住了。