测试策略

通过定义测试策略,可以帮助您在恰当的时间将测试资源集中在测试正确的代码部分。

当开发中型和大型应用程序时,首要问题是“从何处入手?”,然后是“下一步做什么?”。提供了一些衡量标准作为指导,来帮助您分析方法、类和被测组件(CUT)的复杂程度和可靠性,并帮助您决定应该采取的策略。

与功能测试不同,组件测试主要是针对单个软件组件:类、方法以及 Enterprise JavaBeans™(EJB)和 Web Service 组件。组件测试的要点是将每个组件隔离开,以确保它们正常工作。必要时,可以使用存根来替换其它组件,从而将测试结果仅限于被测组件的行为。一旦创建了可靠的测试套件,就可以定期重新运行它以确保 CUT 不存在回归。

组件测试可侧重于以下几方面:

子系统级别测试

子系统级别测试的范围是测试必须互相合作才能提供某些服务的一组集成类。在多层环境中,子系统可能只是其中一层。子系统级别测试的重点是验证被测组件与其它子系统之间的接口。这些测试以子系统的不同对象之间的交互作为测试目标。

尽管子系统级别测试在整个测试过程中应该充当重要角色,但是,一定要将方法级别测试和类级别测试作为对子系统级别测试的补充。如果只进行子系统级别测试,则测试覆盖率还是比较狭窄,这是因为它不会为您提供对单个类的足够控制权。

常用的两种集成测试类型为自顶向下自底向上
  • 自顶向下测试是从程序层次结构的顶部开始测试,然后逐步向下测试它的所有分支。自顶向下测试可以采用两种方法来完成,一种方法是从最上面的路径开始,一直测试到最底层,然后再选择另一条测试路径;另一种方法是在层次结构的一个层次测试完毕之后,再进入下一个层次进行测试。这种类型测试的主要优点是,可以较早看到和测试子系统的全局体系结构。其主要缺点是,在编写较低层次的组件之前需要使用存根,这不一定会为顶层组件提供可靠的测试结果。
  • 自底向上测试通常是从最低层次的组件开始测试,首先是对组件逐个进行测试,然后再按集群进行测试。这种测试可以确保每个组件在被它的调用组件使用之前都已经过充分测试。这种方法的优点在于,在开发过程中能够及早检测到关键组件中的错误。其主要缺点是,必须构建了大多数或多个组件之后才能提供可工作的程序。面向对象的语言非常适合于自底向上测试。
  • 第三种选择是严格遵循设计策略。这意味着在构建每个组件时就对它进行测试。测试定义是组件设计的一部分。作为此策略的一部分,您可以采用自顶向下或自底向上方法。

类级别测试

类级别测试以一个类或者由多个类组成的小型集群中方法之间的交互作为测试目标。重点是验证该类支持其使用者所需的全部用例,并且验证它足够健壮,能够处理意外的方法序列。由于下列原因,类级别测试通常会考虑使用最有效的方式来测试面向对象的软件:
  • 对于代码覆盖来说,在类级别进行测试是非常有效的。只需进行少量测试,代码覆盖率就可以达到 60% 到 70%。
  • 类级别测试将反映类为它的使用者提供的服务。这些测试很容易编写,并且可以用作类的文件。
  • 类级别测试是最佳级别的测试,它能够在设计过程中及早发现错误。

方法级别测试

方法级别测试把在方法代码中定义的不同条件作为测试目标,并与任何其它方法隔离开。测试重点通常在于确保该方法正确处理它所有可能的输入。在许多情况下,隔离测试一系列方法的测试覆盖率不完整,并且某些方法(例如,专用方法)不能够进行隔离测试。(专用方法对于对象状态有重要影响,并且会更改其它方法调用的行为。)

一个类的各个方法之间的交互通常是产生问题的根源,发现这些问题的最佳方式就是在各种情况下使用这些方法。因此,始终应该将方法级别测试与类级别测试和/或子系统级别测试结合起来执行。在某些情况下,例如,在测试无状态类,您可以只集中精力进行方法级别测试。但在其它情况下,您可以决定不进行方法级别测试,而是只集中精力进行类级别测试。

成功地进行方法级别测试的关键在于确定真正要测试哪些方法。下表解答了有关方法级别测试的一些常见问题:

问题 解答
如果方法是从超类继承的该怎么办? 如果方法从超类继承且已经作为超类的一部分进行了测试,则在继承对象的上下文中不需要对此方法进行方法级别测试。您应仍然在继承对象的类级别测试的上下文中使用此方法。
如果一种方法覆盖了父类的方法该怎么办? 如果已经在父类的上下文中测试了方法,则需要重新测试覆盖方法。
如果方法已重载或者被覆盖该怎么办? 当同一个类中的多个方法具有相同名称但具有不同参数时,方法是重载的。当在类中声明了方法,而在子类中定义或改变了该方法的实现时,该方法就会被覆盖。被覆盖方法允许多种对象类型。在任何一种情况下,务必逐个测试这些类方法的每个实现。

接口、抽象类和超类测试

可以使用抽象测试来测试 Java 接口、抽象类和超类。尽管抽象类实际上不能自己单独运行,但是,可以对用来实现接口、实现抽象类或者从超类继承的任何类应用抽象测试。

EJB 测试

测试 Enterprise Java Bean(EJB)通常包括验证 EJB 的业务逻辑以及它的生命周期方法是否成功。此验证过程是通过测试在 bean 类中定义的各种方法来完成的,而此测试是通过这些方法的各种接口调用这些方法来完成的。测试可以与 EJB 位于同一容器中,也可能位于应用程序服务器外部。

测试 EJB 的最佳方式是将它部署在应用程序服务器上,然后在其容器的上下文中运行它。如果 EJB 具有本地接口,则必须从同一应用程序服务器中测试它,例如,使用另一个 EJB。如果 EJB 具有远程接口,则可以使用在应用程序服务器外部运行的 Java 客户机来测试它(这种方法的缺点是增大了网络流量)。无论是哪种方式,都需要排除被测 EJB 调用的组件,以便您可以隔离 EJB 的行为。

可以使用容器管理的持久性或 bean 管理的持久性(CMP 或 BMP)来测试有状态和无状态会话 bean 及实体 bean。要测试它们,所有 bean 都必须具有远程接口或本地接口。目前还不支持测试消息驱动的 bean。

几种测试模式简化了 EJB 的测试模式。

Web Service 测试

当测试诸如 Web Service 的分布式组件时,其方法基本上与测试任何其它组件相同。最佳方法是向服务器提交一系列请求,并验证服务器响应与期望的返回值一致。

要为 Web Service 自动生成组件测试,必须输入 Web Service 接口(如 Web 服务描述文档(WSDL)中所述)。

相关概念
Java 子系统
基于状态的测试技术
相关任务
测试 Java 方法
测试 Java 类
反馈
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.