Web 服务测试
Rational Application Developer Web 服务向导中包含了广泛的 Web 服务功能。在使用 Web 服务向导创建 Web 服务的过程中，有两个可以进行测试的阶段：
在最初创建完服务并将服务部署到 服务测试页上面之后。
如果用户选择了生成客户程序，那么就等到在 客户程序测试页面上创建了客户程序之后。
如果查看 图 11 您会见到两种不同的测试 Web 服务的方法。这些方法对应于 Web 服务向导中的不同测试页面。对于第一种测试方法，可以直接使用 WSDL 中的信息。客户程序要获得服务的位置并形成正确的 XML 信息发回到 Web 服务。Web 服务浏览器使用这种方法来测试 Web 服务。该选项会在用向导创建 Web 服务之后立即出现。通常使用这种方法来确保 Web 服务像设计中一样工作（在生成客户程序之前）。
图 11： Web 测试应用程序概述
另一种测试 Web 服务的方法是生成包含 Java 代理的 Requestor 文件并用 Java 客户程序调用 Java 代理中的方法。要记住向导生成的 Requestor 文件是基于 WSDL 的。 像其他服务测试页一样，客户程序测试页也有扩展点，这些会提供将测试客户程序包含到向导中的功能。这个实例提供了两个 Java 测试应用程序：GSTC 和 UTC。 这两个测试客户程序都将复杂 bean 作为参数处理。复杂 bean 中有除基本类型和字符串的其他类型。
GSTC 由四个基于代理中所包含的方法的 Java Server Page （JSP） 组件组成。对于用户来说，GTSC 就是一个有关如何设计基于 Web 的客户程序的指南。GTSC 使您键入输入参数信息并调用操作。因为很容易使用，所以在做简单测试时，它经常是受欢迎的选择。
UTC 同样是一个基于 Web 的测试方案。它动态地加载代理中的 Java 操作并提供调用操作的功能。UTC 能够处理大多数复杂类型且是复杂测试的最好选择。
Java 测试客户程序
当在 Web 服务向导中生成 Requestor 时,有大量文件自动生成.这些文件的生成使得访问 Web 服务变得很容易.现在可以在一个 Java 文件上直接 build 您的客户应用程序.顶层文件称为代理文件.在 Rational Application Developer 环境中，该文件被创建到客户应用程序项目中。用服务来命名代理并将其放置于客户端的文件夹中（包（文件夹）名是根据 WSDL 名称空间而定）。
Rational Java 测试客户程序客户端
在客户程序生成之后，您可能想要建立自己的符合特定需要的 Java 客户程序（基于实例提供的代理）。这需要花费时间，并且您可能想要测试已生成的客户程序以确保其能像设计中一样工作。Rational 提供了 GSTC 和 UTC 来实现该目标。二者都有优势和劣势，这些将在本文最后进行讨论。根据要做的内容，您可以选择其中一种。
那么 Java 测试客户程序是如何工作的呢？答案很简单。Java 测试客户程序的主要目的是在运行时调用 Java 代理上的方法。查看 图 12 您会看到在代理中生成了两个方法。您会发觉在 SEI 文件中的这些方法和在端口部件下的 WSDL 文件中的这些方法是不同的。这两种方法存在于最初自底向上方案中的 Java 类中。
文章来源于领测软件测试网 https://www.ltesting.net/
