本指南主要讲述测试基于 WebSphere 的应用程序组件(例如 Servlet、JSP 和 EJB)的一组最佳实践,并首先着重于单元测试和功能集成测试的技术和方法。此外,我们将大致了解一些可用的故障解决帮助。
主题
对于 J2EE 1.3,测试和调试还必须考虑消息驱动 Bean 的故障解决和 Servlet 过滤。
测试编写应自然而然成为 Java 编码的一部分。通常,从测试入手并围绕它构建代码是比较好的做法。一般来说,开发人员可能花 20% - 50% 的开发时间来制订类的测试。越早进行测试,越频繁地进行测试,今后的开发速度就会越快。
需要许多种测试:
- 单元测试
- 功能(用例)测试
- 线程交互测试
- 持续时间(长期运行)测试
- 性能测试
在本指南中,我们将重点简介单元测试和功能测试。不过,我们也会指出在开发 WebSphere 应用程序时需要重点留意哪些附加测试注意事项。
单元测试
单元测试主要是基于类的测试,您在这里可能会发现潜在的软件错误,如下:
此外,设计和代码的协调得到验证。此验证便于在以后有把握地修改代码。单元测试用例由该代码的开发人员编写并执行。
集成测试
功能集成测试运行相同的类测试,但也检查集成中所涉及的路径。设计不匹配情况会被发现,并可以证明系统是端到端工作的。集成测试可以通过重用常见测试固定元素(样本和示例)来从您的类测试中构建。现有的测试可以作为组重新运行。
您应考虑针对以下各项编写测试:
- 每个用例
- 每个主要备用路径
- 每个类中的每个主要 public 方法
白盒测试:
黑盒:
就实际情况而言,测试代码应与正在测试的代码分处在不同的包中。类对同一个包中定义的类的受保护成员(标记为受保护的字段或方法)具有特殊访问权。如果测试类要定义在正在测试的类的同一个包中,则这些类的可访问性可能无法有效得到测试。更实际地说,测试对开发有用,但对部署就没那么有用了。让这些测试处于一个完全不同的包中,部署就只需要将测试包排除在外。
JUnit(www.junit.org)是一种对制订测试很有用的工具(关于 JUnit 的更多信息,请参阅 [Fowler]
和 [Davis])。在 JUnit 中,这些测试用例是以 Java 编写的,并与正在测试的代码受到相同的版本控制。让这些测试处于同一 WebSphere Studio Application Developer(Application
Developer)项目中,您实际上就保证了无论该代码在哪里,这些测试都将适用。同时,如果这些测试与代码一起维护,则 Application Developer 版本控制可以保证您的代码和测试始终同步。
在以下示例中,JUnit 中的基本构建块是 Testcase 类。所有测试都是从此类推导而来的,包括 BankAccountTests 类,它包含用以测试 BankAccountBroker 的代码:
package com.wtb.brokers.tests; // 您的测试类包
import junit.framework.*;
import com.wtb.brokers.*; // 您的类包
public class BankAccountBrokerTests extends Testcase
{
public BankAccountBrokerTests(String name)
{
super(name);
}
public void testFind() {}
public void testInsert() {}
public void testUpdate() {}
} |
缺省情况下,在一个 JUnit Testcase 中,以“test”为前缀的所有方法都被视为单个测试用例,并将由测试运行程序自动运行。
这些测试方法不是以任何特定顺序调用的,并且不应依赖于其它测试(即,您通常不应定义依赖于其它测试的结果的测试;每个测试都应在运行后自行清除)。当前存在的这些测试并不是特别引人关注,实际测试代码尚未填写。实际上,正在测试的代码甚至尚未定义。剩余步骤就是练习填写这些方法并使它们运行。一旦创建了这些方法,并且这些测试成功运行,则说明迭代开发流程的这一部分是完整的。
在“先启”、“精化”和“构造”阶段开始制订“用户验收测试计划”(作为“分析和设计规程”的一部分)是至关重要的,原因如下:
-
使用户团体及早介入可以促进当最终产品展示时对它的大宗购买。
- 如果将它视为需求流程的一部分,则收集需求并从用户的角度加以阐明。
- 用户验收测试计划是由系统用户制订的一个计划,它是为了让用户及早介入,以确保所开发的功能能够满足用户的需要,并且以适当的优先级开发和交付。
- 对于确定的所需功能使用“用例”驱动方法。
常见的开发方法是使用用例制订功能和系统测试。这很好,并且是必要的。用户验收测试计划用于确定用户将自然而然希望使用的用例的组合(和序列)。这对于软件设计人员、开发人员和测试人员并不总是显而易见的,某些功能的组合可能产生出乎意料的副作用。
具体到测试 WebSphere 应用程序,应计划和执行以下各项:
- 测试系统的所有方面
- Java Bean
- 后端逻辑
- Servlet
- JSP
- EJB
- 应用程序客户机(applet,Java 客户机等)
- 使用商业负载测试工具及早进行负载测试,这可以发现一些意外的交互:
- 测试失败场景
- 及早获取性能数字(请求数/秒)
当您将应用程序构建到不同的层时,将每一层分离出来并逐个测试。使用“测试安全带”表示较低的层。
许多项目已成功使用 JUnit 测试类测试每一层。

层测试 EJB

优点:
-
能够试验使用 EJB 的各种方式,而不必害怕将错误引入较高的层
- 应用程序客户机几乎是“第一次工作”,因为较低的层已经过测试。
- 设置适当的测试环境:
- 将机器(与开发)分开
- 单独的、孤立的(或可孤立的)网络
- 至少模拟一个小型生产环境,即,一台机器用于所有组件是不适当的,除非生产环境就将如此设置。
- 使用商业负载测试程序
- 使用概要分析程序
保持最新
随着中间件的熟化,许多系统组件将需要补丁。
您将需要使您的环境保持最新:
- JDK
- WebSphere
- JDBC
- HTTP Server
- 数据库服务器
- 其它后端系统,例如 CICS 和 MQ
- 操作系统
测试之前
始终尝试先消除明显的错误,并验证某一问题不是设置/配置错误所造成的。验证环境正确设置并工作是很重要的。确保应用了所有建议的产品版本和补丁级别,并且满足了所有先决条件。如果您的服务器在 DNS 中注册,则验证这些主机名可以由 DNS 解析。要执行此测试,则使用将用于访问所有服务器的简短名称和标准名称对所有服务器进行 ping 操作。
如果您的应用程序访问在数据库中存储的信息,则验证 JDBC URL。同时,验证 PATH 和 CLASSPATH 变量设置为正确的目录。
跟踪和日志记录
WebSphere 包含内置的跟踪和日志记录接口。所有 WebSphere 组件都装备有它们。将跟踪执行到一个环形缓冲区,在转储为标准输出、标准错误或某一文件时会被格式化。使用标准输出或标准错误要比使用标准文件更高效。如果写入标准文件,则不大可能隐藏问题。
消息和跟踪是系统或用户代码响应事件而生成的。消息提供重要事件的高级视图,并始终在控制台的底部收集和显示。跟踪受您所做设置的控制,在所需要的信息比消息提供的信息更详细时非常有用。
您应注意,跟踪可能对性能有负面影响,应在转换到生产阶段后谨慎使用。
跟踪应用程序服务器
应用程序服务器可能因配置错误或应用程序出错而产生错误。跟踪应用程序服务器时,将仅跟踪 IBM 代码,但这将在某些情况下帮助您解决问题。例如:类或资源文件没有正确定位,或 JDBC 驱动程序没有正常工作。
您自身在应用程序服务器中运行的 Servlet 或 EJB 代码可以受到跟踪。
关于跟踪和调试的更多详细信息,请参阅产品信息中心。
性能查看器
性能查看器是作为一个安装选项包含在 WebSphere 中的。它使用性能监视基础结构客户机 API 显示模块的值,这些模块的装备级别已设置为针对 EJB 模块的“低”、“中”、“高”或“最高”值。
有了性能查看器,您就能够将数据记录到文本文件中,以供回放和复审。
在下图中,性能查看器将显示某一节点上特定应用程序服务器的 JVM 信息。

|