Rami Jaamour
Web服务和SOA给IT界带来了一个十分重要，而又保守的趋势：复杂性。它是从应用代码慢慢衍生变为架构的。服务被重用，事务在信息层整合，运行时策略操作信息中的元数据，有时按相应的路线发送这些数据。这些是我们从中看到各个单独的应用所表现出来的复杂性的所有的因素。这个趋势加强了“架构第一“的开发典范，即先创建系统，再进行应用代码编制。
集成已经是问题的主要来源，并将一直持续到开发周期的末尾。因此，以一和生产环境尽可能一样的开发环境来开始是很重要的，以一规则的(一般是每晚)基础建立和部署模型，集成到开发系统中去。当这完成时，就有可能对系统建立和维护回归测试用例，那么测试就可以随着系统的进展而被创建，发展和维护。这样的测试是可以和真实用例尽可能的一样的，因为他们是运行在一个和最终产品很相近的预先部署环境上的，它使得这些测试在确定没有产生bug和在整个生命周期中保证功能的正确性方面更为强大。
完成这个过程的一个主要挑战是在一个类似于产品上下文的环境上下文中从开发中分离出一个应用。这里需要清除和仿真，这些需要做些初始化工作。但是这样的初始化工作是会在这整个周期中获得回报的，因为你最终获得了一个可以做改动并且模型被立即测试和验证的灵活的，连续的过程。这个系统事实上变得易于测试，这是部署之前的很重要的一个特点。只有这个方法使得过程可预测和控制，以便你可以继续进行这个项目，同时知道最后不会有什么大的意料之外的事情发生。
总之，集成测试应该及早的进行，和其他测试(例如单元测试)并行，如果采用了这种方法后应用是不可测的，那么就是出错了。应该在一开始就做一个投入使得它是可测的。如果系统不是可集成测试的，那么开发团队会发现他们浪费大量的时间在手动建模和部署活动上。如果发生了这种情况，那么在项目结尾的时候情况将变得更加糟糕。
文章来源于领测软件测试网 https://www.ltesting.net/
