模拟系统难以实施及应用的原因

模拟系统的实施背景：

现状：由于公司负责的项目开都需要接入当地的第三方系统，而且接口联调和系统开发必须到当地才能进行。而第三方接口接口联调花费时间长，完成进度慢，为了不拖慢系统程序的开发，并且可以在公司完成部分开发，因此需要一个可以模拟到第三方接口的系统来辅助在公司开发系统程序和提供模拟环境进行测试。

愿景：模拟系统完全模拟第三方的系统，提供正常和异常的模拟返回，为在公司开发和测试工作提供环境，减少出差开发和测试的成本。

PS：实施背景和方案见：http://www.cnblogs.com/whylaughing/p/5593290.html

模拟系统难以实施的原因：

• soapUI工具的局限制与可行性

1. soapUI工具只支持webservice接口协议，其他接口协议不支持。
2. soapUI工具对于做正异常的判断需要编写groovy脚本实现，而且每一个用例要有对应的脚本进行判断，soapUI工具是否具体可行性未知，而且用例、脚本和报文之间的管理是否具备管理特性及便利性未知。

• 第三方接口规则及报文难以获取

1. 由于项目是要对接第三方系统，而且第三方无提供规范的接口文档，也难以获取接口文档，尤其项目为政府项目
2. 接口联调时，正常报文容易获取，但各种异常情况的报文难以获取。
3. 通过联调来摸清对方的接口规则相关困难。

• 模拟系统开发的投入产出比低

1. 第三方系统经过长期积累和开发而且，并非简单就可以模拟。
2. 接口规则的摸清，正异常报文获取工作量大，而且获取困难。
3. 用例脚本编写和接口变更时维护工作量大，成本极高。

• 开发与测试应用价值不高

1. 模拟系统开发的最大价值的切入点应该在项目在做接口需求联调时完成开发，然后后续的系统开发和系统测试可以利用好该模拟系统做好一部分相关的开发测试工作，而不需要最后到现场去做，从而缩短出差周期，减少成本。但目前阶段项目周期短，模拟系统开发工作量大，无法在开发测试之前完成，因此模拟系统最大的价值无法得到体现。项目结束后做的模拟系统可能对后续需求变更后的系统维护有部分用处。
2. 模拟关联系统无法覆盖所有正异常的情况，而且现场环境与模拟环境存在一定的区别。因此测试工作仍必须到现场接入内网环境进行测试。
3. 项目功能会涉及多个接口关联，系统功能测试面向是系统而不是单个接口，如果存在部分接口无法模拟，或未完成模拟系统开发都会直接影响到系统测试的开展。
4. 模拟系统仅作为测试覆盖的一种手段，而不是主要的测试环境和测试方法。如果项目具备第三方系统的测试环境，模拟系统的开发就变得无必要。