我试图理解使用SOAPUI模拟wcf服务。
从smartbear's blog引用这可以很方便
快速Web服务原型
在几秒钟内从WSDL生成完整的静态模拟实现 并使用Groovy添加动态功能。这允许你 比你需要等待更快地实现和测试客户端 为了获得构建的实际解决方案。
客户端测试或开发
可以针对MockService开发客户端 测试时无法访问实时服务。
所以从我和其他一些博客中我了解到，主要的事情（通过我读到的）是在服务可用之前继续进行测试（我必须说我没有得到这个实际上。在发送一些模拟请求和响应之前，服务必须启动。是否意味着在我们设置此模拟时应该可以使用该服务，以便我们可以在以后实际无法使用它们时使用它们？
我们还可以说，在给定服务启动和运行的情况下，保存多个测试用例和模拟之间不会有区别（在它的所有服务应该运行之后）。
答案 0 :(得分：1)
我参与了一个大型项目，其中3个不同的系统都使用服务交换数据。它是相同的WSDL（一个“行业标准”，非常复杂的野兽，不适合我们的系统特别好），我们都有客户端将数据发送到其他系统的服务器。每个开发/测试团队都必须开发客户端和服务，我们并不真正了解模拟 正如您所料，在任何服务准备好之前，我们都已经完成了客户。几个月来，测试无法做任何事情。当他们最终可以测试时（开发人员能够获得数据最终流动的第二天），事情就变得一团糟。
所以我不能再回到2010年并拯救自己，但我能救你。
这是你仍然没有得到它的地方：
在发送一些模拟请求之前，服务必须启动 反应
您不需要启动，构建，编码，资助甚至批准该服务。 SoapUI模拟服务是服务。相反，它是一个非常有能力的替身。因此，一旦拥有了WSDL，就可以构建模拟服务，创建一些示例响应，并使用客户端（可能是SoapUI的其他实例）来命中它。
为什么这样做？很多原因。
多个开发团队，在不同的时间轴上。
可以继续进行测试，是的。
避免意外（代码之后）仅仅因为我们同意使用此WSDL，并不意味着我的数据是您的系统所期望的，反之亦然。我们马上找出来吧！
示例：
理想情况下，系统将首先使用模拟服务和SoapUI开发。开发WSDL后，站起来模拟服务，然后通过SoapUI发送提交样本请求。应该参与测试和开发。查看从SoapUI客户端发送的数据和构建/脚本响应。花几天时间开发测试用例。审核无效数据，返回实际响应，确保返回失败和成功，并尝试考虑（并记录）所有预期的失败情况，包括超时（可以在模拟服务中使用sleep（）函数编写脚本） 。超时场景可用于模拟负载，以便您可以看到对客户端和基础架构的影响（我们能够通过以比服务可以处理的更高的速率发送事务来提示层7网关，如果我们保留它的话30分钟） 因此，使用模拟服务作为联合研讨会来确定面向服务的解决方案的详细信息，然后编写代码。你会很高兴的。