第 9 章 测试部署  9.1 测试  9.2 部署

9.1 测试  应用测试：使用 JUnit 单元测试框架 测试的目的是检验开发结果是否满足规定需求，测试是保证软件质量的一个重要手段， 在软件开发过程中是不可缺少的组成部分。 单元测试与集成测试分别有各自的定义：在实际开发中，两者之间的界定是模糊的。 因此，在这里一起讨论。 虽然测试是一件乏味的工作，但是对自己开发的程序代码进行单元测试是程序员必要 的份内工作。在 J2EE 项目中，一般有以下两种方法进行单元测试： 方法 1: 编写 main 方法 在被测试类中编写一个 main 方法是传统而简单的方法，但缺点不少。首先，增加了源 代码的长度；其次，有可能破坏源代码的可读性，特别是对于那些拥有多个对外接口的类， 要求其在一个 main 方法中完成所有测试案例，测试繁杂。若是把这些案例分解成一个一个 私有测试方法的话，将降低代码的可读性。最后，可能使得功能类引入多余的依赖类，比 如，测试类引用了类所有接口的实现类。 Main 方法根本性缺点在于测试结果的直观阅读性问题， main 方法测试必须执行后通 过对控制台的输出信息进行观察才能判断结果是成功还是失败。这显然是不方便, 浪费时间 的。

9.1.1 应用测试：使用 JUnit 单元测试框架 方法 2: 使用 Junit 单元测试框架 JUnit 是 main 方法的完善替代方案， Junit 是一套功能强大而使用简单的单元测试框 架。实际上，它现在已经是 Java 代码单元测试的事实标准。 下面以 bookstore 进行说明。 Bookstore 项目如图 9-1 所示。 图 9-1 文件在项目中的位置

9.1.1 应用测试：使用 JUnit 单元测试框架 需要一个 Spring-mock.jar 包，加载到该工程。所有集成这个类的方法都是一个测试类， 对 UserDAO 类进行测试。 将 WEB-INF 下的 applicationContext.xml 拷贝到 test 文件夹下。 package org.apex.bookstore.test; import org.springframework.test.AbstractDependencyInjectionSpringContextTests; import org.apex.bookstore.dao.IUserDAO; import org.apex.bookstore.vo.User; public class UserDAOTest extends AbstractDependencyInjectionSpringContextTests { // 测试 DAO, 所以注入一个 DAO // 这个实例被依赖注入 private IUserDAO userDAO; // 一个用来实现 UserDAO 实例依赖注入的 setter 方法 public void setUserDAO(IUserDAO _userDAO){ userDAO = _userDAO; protected String[] getConfigLocations() { // 指定 Spring 配置文件加载这个 fixture return new String[] {"classpath:org/bookstore/test/applicationContext.xml"}; } // 测试 UserDAO 中的 validateUser() 方法。 public void testValidateUser(){ User user = userDAO.validateUser("yuyan","yuyan"); assertNotNull(user); }

9.1.1 应用测试：使用 JUnit 单元测试框架 加入 JUnit 库，选择 Java Build Path 中的 Add Library ，如图 9-2 所示。 添加类库 图 9-2 加入 JUnit 的类库

9.1.1 应用测试：使用 JUnit 单元测试框架 出现如图 9-3 的对话框，选择 JUnit 类库。 图 9-3 添加 JUnit 类库

9.1.1 应用测试：使用 JUnit 单元测试框架 点击 “Next” ，选择 JUnit 的版本，如图 9-4 所示。 图 9-4 添加 JUnit 版本

9.1.1 应用测试：使用 JUnit 单元测试框架 运行，选中 UserDAOTest 文件，右击菜单 Run AS  JUnit Test 。如果结果正确，得 到如图 9-5 所示界面，否则得到图 9-6 所示界面。 图 9-5 运行结果（结果正确） 图 9-6 运行结果（结果错误）

9.1.1 应用测试：使用 JUnit 单元测试框架 不用将应用程序部署到应用服务器上或者实际连接到企业集成系统里就可以进行一 些集成测试。这样可以测试以下内容： Sprong IoC 容器的 context 装配是否正确， 使用 JDBC 或者 ORM 工具的数据访问，这将包括 SQL 语句或者 Hibernate 的 XML 映 射文件是否正确。 Spring Framework 为集成测试提供了支持，这些支持通过 Spring Framework 发行 包里 spring-mock.jar 文件中的一些类来提供支持。这个库中的类远远超越了 Catus 等容 器内测试工具。 当类 AbstractDependencyInjectionSpringContextTests 及其子类装载 ApplicationContext 时候，可以通过 Setter 注入任何配置的测试类的实例，只需要定义变 量和相应的 setter 操作。 AbstractDependencyInjectionSpringContextTests 将从 getConfigLocations() 方法指定的配置文件中自动查找对应的对象。

9.1.2 性能与压力测试 经常会被人问到，你的应用请求相应速度如何？能支持多少个并发用户？在强负 载的情况下，软件可靠性如何？显然这些问题通过常规的测试手段是无法回答的。为 此，需要寻找其他的测试方法，这些测试可分为： ● 可靠性测试 对于一个像 bookstore 这样的运行系统来说，保证提供 7X24 连续稳定的服务是 非常必要的。可靠性测试通常的做法是使用一定的负载（通常是系统可遇见的最佳并 发用户数，而不是系统最大并发用户数）长时间地对系统服务加压，并观察随着压力 时间的延长，响应时间，吞吐量以及服务器相关资源利用率的变化；记录每次系统发 生故障的时间，计算出相邻故障的时间间隔，从而统计出系统不发生故障的 “ 最小时间 间隔 ” ， “ 最大时间间隔 ” 和 “ 平均时间间隔 ” ，其中 “ 平均时间间隔 ” 就是要了解系统大概的 “ 可靠 ” 程度。 ● 压力测试 压力测试目的是评估出系统在特定环境下能保持正常运行的极限状态。通常做 法是在正确输入情况下反复增减并发用户数，观察系统受压的情况，直到捕捉到系统 刚好不瘫痪时的临界状态。 ●性能测试 性能测试的目的是检查应用系统的各项性能值是否达到预期的要求，查找出 系统的性能瓶颈，以便为系统调优以及评估软件系统的合理软硬件配置方案提供参考。 通常，测试的性能指标有：请求处理成功率 (%) ，请求处理平均响应时间 (ms) ， 吞吐量 (b/s) ，系统最大处理能力 ( 请求 / 秒 ) 和系统支持的最大并发用户数等。

9.1.2 性能与压力测试 通常需要借助一个第三方的性能与吞吐量测试工具才能帮助解决性能测试的问题。 这些工具比较流行的有： LoadRunner 、 WAS 、 QALoad 、 JMeter 等。 下面使用 jMeter 测试工具对应用系统做一下性能测试。 JMeter 是 Apache 组织 100%Java 实现的免费的性能测试工具，它可以用于在模拟 重负载条件下分析整个应用服务的性能。其官方网址为： 。 一个典型的 jMeter 测试计划包括： ● 线程组 用于定义运行的线程数以及线程等候周期。每一个线程模拟一个用户，而等候周 期用于指定创建所有线程所花费的时间。例如：线程数 50 ，等候时间为 100 秒，则等 于创建每个线程的时间间隔为 2 秒；如果等候时间为 0 秒，则代表 50 个线程同时创建， 也就是并发访问。循环数则定义了线程运行次数，也就是某个线程创建后执行多少次 请求就结束。 ● 取样器 定义访问应用服务请求。这些请求包括 http ， jms 等，这里主要定义 http 请求。 ● 监听器 用于请求数据后期的分析处理。它提供很多结果分析方式，如可以使用图形结果， 表格结果和聚合报告来实例。

9.2 部署  部署网上书城 部署网上书城，将系统打包成一个 WAR 文件。选择部署按钮，出现如图所示画面 9-7 ， 选择 Add 按钮。 选择要部署的服务器 图 9-7 部署

9.2.1 部署网上书城 出现如图 9-7 所示的对话框，选择 Tomcat 6.x 服务器，部署的类型选择 Packaged Archive 。部署细节如图 9-8 所示。 选择 Tomcat 6.x 服务器 选择部署的类型和路径 图 9-8 部署细节

9.2.1 部署网上书城 在部署时，常会听到 Ear （扩展名为 ear ）、 Jar( 扩展名为 jar) 、 War( 扩展名为 war) 文 件。它们是什么意思？有何不同呢？在文件结构上，三者并没有什么不同，它们都采用 zip 或者 jar 档案文件压缩格式，但是它们的使用目的有所区别： JAR 文件包含 Java 类的普通库，资源（ resources ）、辅助文件（ auxiliary files ）等。 WAR 文件包含全部 Web 应用程序。在这种情况下，一个 Web 应用程序被定义为单独 的一组文件、类和资源，用户可以对 jar 文件进行封装，并把它作为小型服务程序来访问。 EAR 文件包含全部企业应用程序。在这种情况下，一个企业因公程序被定义为多个 jar 文件、资源、类和 web 应用程序的集合。 每一种文件（ jar,wear,ear ）只能由应用服务器、小型服务器程序容器、 EJB 容器等 进行处理。

9.2.2 部署方式 对于一个 J2EE 应用体系，可由以下任意部署单元模块构成： Web 应用 WAR 包 一个 War 文件包含一个 Web 应用各种实现 Java 类、依赖库类、视图页面（如 html 、 Jsp 、图像文件等等）以及部署描述文件（如 web.xml ）。 EJB 组件的 Jar 包 一个 EJB 组件 Jar 包可以包含多个 Ejb 实现 Java 类以及它们的部署描述文件。 资源连接器（ JCA ） RAR 包 包含企业应用 JCA 所实现的 Java 类和依赖库。 应用客户端 Jar 包 包含一个准备在客户端运行的独立应用程序。 J2EE EAR 文件是通过特定的部署描述文件（ application.xml ）把它们装配成统一 的发布包的。 EAR 部署的优点是准确反映应用的语义；由于是 J2EE 标准规范，几乎所 有的 J2EE 应用程序服务器都提供了友好的可视化部署工具，发布过程方便简单。

9.2.2 部署方式 然而，采取 EAR 部署方式所面临的一个最大挑战是各个部署单元模块之间的类加载 问题。 JVM 用 ClassLoader 类加载器来检查类和对象并把它们载入内存。默认情况下，系 统的类加载器会根据系统环境变量的 classpath 的位置来加载类。而对一个 EAR 部署应用 来说，各个部署单元模块都有各自单独分离的 ClassLoader ，这些加载器之间的关系却没 有很明显地约定，加上各个应用服务器的类加载机制又存在差异，这都给 EAR 包的可移植 性带来大的挑战。另外还很容易导致 ClassNotFound 和 ClassCastException 异常。这无疑 需要先了解自己使用的服务器的类加载机制后，才能成功建立一个可运行的 EAR 部署包。 EAR 部署方式不便于维护和扩展。比如，更新或者新增加一个功能模块，都需要重 新打包，重新发布。这是一个乏味罗嗦的过程，倘若遇上服务器卸载不干净，费了大半天 更新完毕的一个应用，运行起来却莫名其妙出错。 为了解决 J2EE 应用部署灵活性的问题，大多数应用服务器支持扩展式部署。就是将 前面提到的各种单元部署模块包以独立形式进行部署发布，也就是，把 EAR 文件结构扩展 成一个应用目录结构，代替原来一个档案包文件的形式。这样，应用的发布、更新和扩展， 就直接变成了对操作系统的目录文件的管理。

9.2.2 部署方式 例如一个 J2EE 的 bookstore 应用程序，针对 Jboss 在 Windows 系统上部署： 1. 准备好待发布的 bookstore 系统文件 首先，对于编译好的 Java 类，为了方便以后维护和发布，按照 bookstore 应用程序包 多层的结构，分别建立以下 4 个 jar 文件： bookstore_Util.jar 将 bookstore 各层公共使用的类打成一个公共包，内容： com.apex.bookstore.Util bookstore_Action.jar 将 bookstore 应用表示层所有类打成一个包，内容：包 com.apex.bookstore.action bookstore_Service.jar 将 bookstore 应用业务逻辑层所有的类打成一个包，内容：包 com.apex.bookstore.Service. bookstore_DAO.jar 将 bookstore 应用数据层所有的类打成一个包。 其次，构建 Web 应用发布的 bookstore.war 目录（这里不采用 War 文件包的形式），目 录中包含了页面视图及其相关的所有资源，但不包含 Java 类以及依赖库。 最后，对业务框架所依赖的 EJB 组件打包成 businessEJB.jar ， 2. 创建 bookstore 应用单独目录结构 有关 Jboss 服务器体系结构这里不多介绍。这里新建一个 Server 级 bookstoreApp 目录 来部署 bookstore 应用，这也相当于一个 JBoss 服务器只部署和运行 bookstore 应用程序。 如图 9-9 所示。

9.2.2 部署方式 图 9-9 部署方式

习题 1. 使用 JUnit 对用户登录模块进行测试。 2. 部署网上书城到另外一台非开发机器上。