服务测试

    此 SOA 开发流程的第二步是开发服务测试，以将用例系统编写为可执行格式。仅当服务恰当地实现了用例时，测试才能通过。

    Kent Beck 指出，测试 应该是自动而独立的，而且应该对可能出现问题的部分进行检查(请参阅参考资料部分，以获得有关他的书籍 Extreme Programming Explained 和 Test Driven Development 的信息)。测试——通过测试开发工作软件——是 Beck 称为极限编程 (XP) 的方法所包含的十二项实践之一。它是测试驱动的开发 (TDD) 的核心——如果您只能遵循一个实践，该如何执行 XP 呢?当采用 XP 和 TDD 时，将首先开发测试，然后开发软件以通过测试，接着重复这些步骤，直到软件足够完善为止。

    应该测试什么?测试的概念源于许多地方，但用例是测试的非常好的来源。用例文本和关系图描述用户对需求的理解。测试以更明确的方式表述这种理解，并以可靠和重复执行的代码加以表示。用例和测试是面向不同的受众(人和计算机)以不同形式表示相同内容的对等项。

    服务用例的服务测试 没有什么不同，不过更多地将其看作功能测试，而不是单元测试。服务测试不会验证服务如何实现;提供程序开发团队可以自行实现此用途的单元测试。服务测试验证服务是否提供了服务用例认为其应该提供的行为。这些测试还需要对错误路径进行测试。

    测试将最终定义服务的期望接口。此接口通常为 Web 服务的 Web 服务描述语言(Web Services Description Language，WSDL)文件、Java 接口或 Java 组件的 EJB 远程接口等等。如果首先开发接口，然后根据接口实现测试，可能会看起来更简单，不过更直接的方法是首先开发测试，然后开发接口，以使测试能够成功编译。

    示例服务测试

    可以使用简单的单元测试框架(JUnit 或 Cactus)来开发测试。该框架将充当服务的使用者，并进行使用者将进行的操作。下面是一些可能的测试:

    1.使用 IBM 调用 simple quote ，以验证获得的结果是“$100.00”。

    2.使用 MSFT 调用 simple quote，以验证获得的结果是“$30.00”。

    3.使用 BOGUS 调用 simple quote，以验证获得的结果是 invalid stock symbol 错误。

    对复杂报价和历史报价的测试将与此类似。另外，还有针对可能的基础结构错误的测试，如远程异常和 HTTP 400 错误。最后，测试应该对服务用例中指定的所有内容进行验证;如果在用例中指定了操作，但却不在一个或多个测试中进行检查，则意味着使用者不能期望提供程序将实际执行该操作。