通过定义测试策略,可以帮助您在恰当的时间将测试资源集中在测试正确的代码部分。
当开发中型和大型应用程序时,首要问题是“从何处入手?”,然后是“下一步做什么?”。提供了一些衡量标准作为指导,来帮助您分析方法、类和被测组件(CUT)的复杂程度和可靠性,并帮助您决定应该采取的策略。
与功能测试不同,组件测试主要是针对单个软件组件:类、方法以及 Enterprise JavaBeans™(EJB)和 Web Service 组件。组件测试的要点是将每个组件隔离开,以确保它们正常工作。必要时,可以使用存根来替换其它组件,从而将测试结果仅限于被测组件的行为。一旦创建了可靠的测试套件,就可以定期重新运行它以确保 CUT 不存在回归。
子系统级别测试的范围是测试必须互相合作才能提供某些服务的一组集成类。在多层环境中,子系统可能只是其中一层。子系统级别测试的重点是验证被测组件与其它子系统之间的接口。这些测试以子系统的不同对象之间的交互作为测试目标。
尽管子系统级别测试在整个测试过程中应该充当重要角色,但是,一定要将方法级别测试和类级别测试作为对子系统级别测试的补充。如果只进行子系统级别测试,则测试覆盖率还是比较狭窄,这是因为它不会为您提供对单个类的足够控制权。
方法级别测试把在方法代码中定义的不同条件作为测试目标,并与任何其它方法隔离开。测试重点通常在于确保该方法正确处理它所有可能的输入。在许多情况下,隔离测试一系列方法的测试覆盖率不完整,并且某些方法(例如,专用方法)不能够进行隔离测试。(专用方法对于对象状态有重要影响,并且会更改其它方法调用的行为。)
一个类的各个方法之间的交互通常是产生问题的根源,发现这些问题的最佳方式就是在各种情况下使用这些方法。因此,始终应该将方法级别测试与类级别测试和/或子系统级别测试结合起来执行。在某些情况下,例如,在测试无状态类,您可以只集中精力进行方法级别测试。但在其它情况下,您可以决定不进行方法级别测试,而是只集中精力进行类级别测试。
成功地进行方法级别测试的关键在于确定真正要测试哪些方法。下表解答了有关方法级别测试的一些常见问题:
问题 | 解答 |
---|---|
如果方法是从超类继承的该怎么办? | 如果方法从超类继承且已经作为超类的一部分进行了测试,则在继承对象的上下文中不需要对此方法进行方法级别测试。您应仍然在继承对象的类级别测试的上下文中使用此方法。 |
如果一种方法覆盖了父类的方法该怎么办? | 如果已经在父类的上下文中测试了方法,则需要重新测试覆盖方法。 |
如果方法已重载或者被覆盖该怎么办? | 当同一个类中的多个方法具有相同名称但具有不同参数时,方法是重载的。当在类中声明了方法,而在子类中定义或改变了该方法的实现时,该方法就会被覆盖。被覆盖方法允许多种对象类型。在任何一种情况下,务必逐个测试这些类方法的每个实现。 |
可以使用抽象测试来测试 Java 接口、抽象类和超类。尽管抽象类实际上不能自己单独运行,但是,可以对用来实现接口、实现抽象类或者从超类继承的任何类应用抽象测试。
测试 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 服务描述文档(WSDL)中所述)。