5.不要在测试上自寻烦恼

　　为什么SOA更容易测试

　　对SOA缺点的一种看法是测试困难。这种看法完全不恰当，原因有很多。

　　首先，在SOA中使用元数据可以避免错误被植入到系统中。可以在元数据层次就对系统进行验证，例如，保证所有需要处理的数据在使用前就被汇总并校验。在整个业务流程范围内都可以实现这点。当你可以验证设计的时候就不要测试整个系统。

　　其次，几乎所有测试，包括所有系统集成测试，一旦测试基准被建立后都可以自动完成。但是，需要一些前提条件。表现层和业务执行层必须被严格的区分。好在这是使用SOA的一种很自然的方式。对所有输入，都应该存在相应的XSD。使用该XSD，可以生成测试记录。同理，也可以生成带有预期输出结果的测试记录。在测试过程中，不能产生可以证明系统运行正常的任何输出地方，必须在测试脚本中添加专门为此生成的附加输出的查询语句。当测试开始运行时，测试记录被一条条输入系统，然后输出的结果自动和期望的结果进行对比。这会产生一个异常列表，其中每项都应仔细考虑。测试可以按需进行。自然，测试的结果可能取决于存积在数据库中的数据，所以这点需要进行弥补。而且，系统不可表现出时间相关的行为。系统必须有能力响应每隔一段时间(它对自动化测试序列更适合)就产生的事件，而不是花上一周时间去等待某个基于时间的触发器被触发。用户界面的测试应该单独进行，而且永远不在集成测试中使用。

　　第三，SOA的设计趋向于产生更加健壮的系统：系统出错的机会更少。SOA减少了信息系统为了协同工作而需要达成协议的因素数量，这样一来，导致在某关键因素上产生分歧的设计错误的概率也减少了。就算真的出错，也能够在造成损害之前检测到。使用SOA，消息在被处理前会被验证，这样可以判断消息是否格式正确、是否符合相应的XSD。

　　可行性测试

　　最后，作为数据库时代特有的产物——测试环境和生产环境必须严格区分，从此不再需要了，而且有时候这也是不适合的。这是很有可能的，这是因为我们不再实际进行系统测试了，而是对测试通路和信息处理的方式进行测试。SOA提供了三重安全的、有效区分测试消息和生产消息的方法。除了被封装好的消息，其他每个消息自身和相应的命名空间都包含版本号。而且每个消息都包含一个标签用以指示它是用于测试还是生产。所需的只是一个SOA网关，它存在于防火墙内部，对每条进入消息进行如下处理：

　　校验消息以确定其是否与一个已知XSD的版本相符(被封装好的消息除外)。

　　使用我们对相应XSD的副本对消息进行校验，以确定其是否有效。

　　如果消息用于生产的，就验证消息版本号是否被允许用于生产。只有这样，消息才能够被传递到生产系统。其他所谓的“生产”消息都会被拒绝。

　　如果消息用于测试，消息可能会被传递到指定的测试版系统。在特殊情况下，消息如果只是用来做数据检索，那也有可能被传递到生产系统。

　　只有在消息被完全测试过后，生产版本的注册库和XSD才能得以更新。

　　这样的处理方法不仅仅只是三重安全的，而且使得消息的路由能以一种合乎实际的方式得到测试。这也大大降低了从测试系统切换到生产系统时重新进行配置的需求。因为这种重新配置天生就是不可测试的，常常成为错误的根源。发布经理只能通过在半夜或者周末发布新的版本软件来弥补这类错误;这样，就算新版本出现了任何错误，也可以在有人发现错误之前恢复到老版本。但如果这样的变化影响到了其他组织那就没有办法这样操作了。SOA发布管理要简单得多!

　　我们对于SOA测试的一般认识是时候该改变了。SOA是能够把测试需求和设置测试的工作减少到最低的一种方案。它能使重要测试更自动化的完成，结果也更好。

　　完善之理论

　　SOA使得信息系统的开发和部署能够比使用数据库化的方法支持更为丰富的用户体验。这样的系统能够涵盖更多的信息格式、更广的行为集合，其行为上也可以达到更高层次的统一和一致以及更加可靠，不管是从客户还是从组织内关注合规的人员的观点来衡量。然而，要想获得这些好处需要我们跟已有的数据库方法实践说再见。