SOA 服务测试
测试 SOA 服务的最佳方法是什么？我应该使用 WCF 编写自己的测试还是应该使用 SOAPUI 等测试框架。每种方法都有哪些限制？是否有更好的工具？
What is the best way to test SOA services? Should I write my own tests using WCF or should I be using a testing framework such as SOAPUI. What are the limitations to each method and are there better tools?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您绝对应该使用 SoapUI。尤其是在混合环境中。即在混合环境（java、delphi、WCF 等）中，SoapUI 将成为您的常用工具，可以确认哪些有效，哪些无效。它还可用于设置模拟服务，以便您可以针对尚未构建的服务进行测试。即，通过 WSDL，您可以在几分钟内构建一些记录请求并给出响应的东西。这是非常有益的。今后，您将能够使用通用工具验证哪些有效，哪些无效，而不是争论“在技术 x 中有效，所以这一定是您的问题”。
查看 mockservices 演示，其中展示了如何基于 xpath 进行简单的预设响应。非常简单，而且有效。您可以发送响应并返回各种可预测的响应。例如，您发送员工 Tom、Dick、Harry 的更新。配置 SoapUI 模拟服务，为 Tom 返回成功，为 Dick 返回软错误，为 Harry 返回灾难性错误。
IMO，在构建任何 Web 服务之前，最好的起点是在 SoapUI 中构建模拟服务。然后，您可以使用示例有效负载进行测试，看看每个人是否都看到了他们所期望的内容。例如，HR 使用每个人都同意的 WSDL 将一名新员工发送到 Payroll。 Payroll 开发人员甚至还没有编写他的部分代码，但通过查看 SoapUI 中的事务，他发现 EmpID 格式“在我们这边完全不起作用”。现在HR可以做出改变。薪资开发人员还发现，尚未被解雇的员工的终止日期为 1889 年 12 月 31 日。他预计''。现在，开发人员和分析师之间可以进行讨论，而不是稍后在集成或启动期间进行，当时的讨论可能涉及多层 PM、“情况领导”等。
You definitely should be using SoapUI. Especially in a mixed environment. i.e. in a mixed environment (java, delphi, WCF, etc..) SoapUI will be your common tool that can confirm what works and what doesn't. It can also be used to set up mock services so you can test against a service that isn't yet built. i.e. from the WSDL you can build something in minutes that will log requests and give responses. That's hugely beneficial. Down the road, you'll be able to verify what works and what doesn't using the common tool, rather than fighting about "works here in technology x, so it must be a problem at YOUR end".
Look into the mockservices demo where they show how to do simple canned responses based on xpath. Very simple, and effective. You can send a response and return a variety of predictable responses. for example, you send updates for emps Tom, Dick, Harry. Configure your SoapUI mockservice to return success for Tom, soft error for Dick, catastrophic error for Harry.
IMO, the best place to start before building any web service is to build a mockservice in SoapUI. Then you can test with sample payloads and see if everybody is seeing what they expect. i.e. HR sends a new employee to Payroll, using the WSDL that everyone agreed to. The Payroll dev hasn't even coded his part yet, but by looking at the transaction in SoapUI, he sees that the EmpID format is "totally not going to work on our end". Now HR can make a change. The Payroll dev also sees that the Termination Dates are 12/31/1889 for employees that haven't been fired yet. He expected ''. Now a discussion can ensue between the devs and analysts, instead of later on during integration or startup, when the discussion would likely involve several layers of PMs, "situation leads", etc..
我建议你也看看 Tellago Studios 的全新 SO-Aware； http://www.tellagostudios.com/ 。其中一项功能是自动服务测试。
I suggest you also take a look of the brand new SO-Aware from Tellago Studios; http://www.tellagostudios.com/ . One of the features is automatic service testing.
Soa 测试只是确保所有独立服务以预期方式运行，同时始终遵守这些服务建立的输入和输出契约。该工具不应仅限于 Web 服务测试。
SOA 测试工具：
Soa testing just ensures that all independent services behave in the expected manner, all the while adhering to the input and output contract established by these services. The tool should not just limit itself to webservices testing.
SOA testing tools: