第9章项目测试发布.ppt

9.1 发 布 9.2 测 试 9.1.1 应用测试：使用JUnit单元测试框架 测试的目的是检验开发结果是否满足规定需求，测试是保证软件质量的一个重要手段，在软件开发过程中是不可缺少的组成部分。 单元测试与集成测试分别有各自的定义：在实际开发中，两者之间的界定是模糊的。因此，在这里一起讨论。 虽然测试是一件乏味的工作，但是对自己开发的程序代码进行单元测试是程序员必要的份内工作。在J2EE项目中，一般有以下两种方法进行单元测试： 9.1.1 应用测试：使用JUnit单元测试框架 1．编写main方法 在被测试类中编写一个main方法是传统而简单的方法，但缺点不少。 首先，增加了源代码的长度； 其次，有可能破坏源代码的可读性，特别是对于那些拥有多个对外接口的类，要求其在一个main方法中完成所有测试案例，测试繁杂。若是把这些案例分解成一个一个私有测试方法的话，将降低代码的可读性。 最后，可能使得功能类引入多余的依赖类，比如，测试类引用了类所有接口的实现类。 Main方法根本性缺点在于测试结果的直观阅读性问题，main方法测试必须执行后通过对控制台的输出信息进行观察才能判断结果是成功还是失败。这显然是不方便,浪费时间的。 2．使用JUnit单元测试框架 引入JUnit单元测试框架的bookstore项目目录如图9.1所示。 编写测试类UserDAOTest的代码所示。 加入JUnit库，单击Java Build Path中的【Add Library…】按钮，如图9.2所示。 出现如图9.3所示的界面，选择JUnit类库。 单击【Next】按钮，选择JUnit的版本，如图9.4所示。 运行，选中UserDAOTest文件，右击选择菜单【Run AS】→【JUnit Test】。如果结果正确，得到如图9.5所示的界面，否则得到如图9.6所示的界面。 1．可靠性测试 可靠性测试通常的做法是使用一定的负载长时间地对系统服务加压，并观察随着压力时间的延长，响应时间、吞吐量以及服务器相关资源利用率的变化；记录每次系统发生故障的时间，计算出相邻故障的时间间隔，从而统计出系统不发生故障的“最小时间间隔”、“最大时间间隔”和“平均时间间隔”，其中“平均时间间隔”就是要了解系统大概的“可靠”程度。 2．压力测试 压力测试目的是评估出系统在特定环境下能保持正常运行的极限状态。通常做法是在正确输入情况下反复增减并发用户数，观察系统受压的情况，直到捕捉到系统刚好不瘫痪时的临界状态。 3．性能测试 性能测试的目的是检查应用系统的各项性能值是否达到预期的要求，查找出系统的性能瓶颈，以便为系统调优以及评估软件系统的合理软、硬件配置方案提供参考。 一个典型的JMeter测试计划如下： （1）线程组。 用于定义运行的线程数以及线程等候周期。 （2）取样器。 定义访问应用服务请求。这些请求包括http、jms等，这里主要定义http请求。 （3）监听器。 用于请求数据后期的分析处理。它提供很多结果分析方式，如可以使用图形结果、表格结果和聚合报告等。 9.2.1 发布网上书店 发布网上书店，将系统打包成一个war文件。选择部署按钮，出现如图9.7所示的界面，单击【Add】按钮。 选择Tomcat 7.x服务器，部署的类型选择Packaged Archive（打包发布），部署细节如图9.8所示。 部署成功之后，在Tomcat目录：C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps下会自动生成一个名为bookstore.war的文件，这就是发布到服务器上的项目产品包，如图9.9所示。 打开浏览器，输入http://localhost:8080/bookstore/并回车，即可显示如图9.10所示的网上书店首页。 在部署时，常会听到Ear（扩展名为ear）、Jar(扩展名为jar)、War(扩展名为war)文件。它们是什么意思？有何不同呢？ 在文件结构上，三者并没有什么不同，它们都采用zip或者jar档案文件压缩格式，但是它们的使用目的有所区别： JAR文件包含Java类的普通库，资源（resources）、辅助文件（auxiliary files）等。 WAR文件包含全部Web应用程序。在这种情况下，一个Web应用程序被定义为单独的一组文件、类和资源，用户可以对jar文件进行封装，并把它作为小型服务程序来访问。 EAR文件包含全部企业应用程序。在这种情况下，一个企业因公程序被定义为多个jar文件、资源、类和web应用程序的集合。 每一种文件（jar,wear,ear）只能由应用服务器、小型服务器程序容器、EJB容器等进行处理。 对于一个Java EE应用体系，可