一旦开发人员编写了必要的代码来执行服务及其基本技术组件，服务的行为和安全性就需要被验证。验证服务背后的代码工作是否正常的唯一办法是援引该服务，然后验证基本的记录系统是否正确更新，因为在现实世界中没有硬编码响应，并且那种安全性是应该遵守的。

　　同样地，一个测试案例是用来调用并验证业务需求、行为以及安全策略得到了落实。如果候选服务可以通过这些策略测试，那么它就可以被发布在注册器中被消费者使用。如果这些测试失败了，那么该服务就不应该被提供给消费者。

　　作为非常好的做法，单个服务一旦可用就应该进行负载测试。如果我们在组件开发的过程中就进行负载测试，根据测试结果随时改善系统性能，而不是等到系统部署完毕再去做这些事情，那么引入风险的概率就会小很多，因为系统一旦部署完毕，问题修复就会变得很难并且代价昂贵。渐进式开发团往往是在服务功能得到确认后立刻开始负载测试，从而使开发人员可以在消费者开始利用这些服务之前就修改代码，优化逻辑和数据访问。

　　在运行时阶段，服务会被提交到注册器中，同时还要进行功能测试，并把它提供给消费者作为自己应用流程的一部分。这些消费者也会承担使用该服务所造成的后果的责任。最好的方法是建立一个可执行测试资产来验证当服务被使用时，整个消费者工作流的架构、行为和性能方面是被支持的。当测试作为治理过程的一部分被连续运行时，这将会带来极大的方便。

　　最后一个阶段是变更阶段。SOA和敏捷性开发的真正有优点就是在这一阶段开始体现出来的。如果需要增加一项新的服务，或修改了现有服务以适应不断变化的业务需求，那么服务策略必须被重新审核。我们不仅要根据预期的新行为更新任何行为策略，而且还要复原现有策略。

　　如何你自己是一个服务消费者。你怎么才能相信打破现有的业务流程并使用新的服务，不会对你造成意想不到的后果（比如失败）？每个消费者需要将自己期望的行文作为一项策略放在注册器中，同时还要附带相应的测试，以便能够在做出更改之前自动验证。在测试中，自动化结构和策略行为代表了消费者的权利，以及他们使用这些服务的责任。当这些测试作为SOA治理的一部分自动运行时，服务消费者和生产者之间的信任就实现了。