基于客运需求预测系统的Web应用测试研究

邱吉雨 宋欣悦

（北京交通大学计算机与信息技术学院 北京市 100044）

据统计，在软件开发的多个阶段中，同比代码、系统设计等阶段，需求分析阶段的产物——需求规格说明书是软件缺陷出现最多的地方。由经验可知，需求分析阶段的错误会随着产品开发进度而被无限放大，且开发越接近于尾声，改正错误所需要的代价越大。为了保障软件质量，降低缺陷发生时的修复成本，本文中系统的测试采用W 模型（如图1）。同理，为了项目的风险控制，大多数的Web 应用的测试都是伴随着需求规格说明书的完成而展开的。

1 客运需求预测系统

客运需求预测系统由我们自行开发，能够将十年客运历史数据以图表的方式展现并且对未来几年客运趋势进行预测的系统。该系统包括客运需求分析子系统、客运需求预测子系统、基础数据管理子系统和预测模型管理子系统等四个子系统，各子系统又细分了不同的条目，系统具体结构见图2。客运需求预测系统是一个典型的Web 应用系统，具有内容驱动性、及时性、安全性和美观性等特性。

2 测试计划及测试方案

在本项目的需求分析以及设计阶段，测试人员对阶段产物——需求规格说明书进行评审，即测试人员拿到需求规格说明书之后，首先通读并分析规格说明书，将模棱两可以及晦涩难懂的部分记录下来。直到参加需求评审会议的时候，与与会人员讨论并明确存在异议的需求，并根据自己以往的测试经验和对系统的理解，从用户的角度提出意见。评审会议后，完善的需求规格说明书发布时，测试人员便着手设计相关的测试计划以及初步的测试方案。

测试计划是基于管理者角度所写，对测试全过程进行管理的计划书，其内容包括测试项、被测特性、各阶段的测试任务、时间进度、安排测试任务的执行者和风险控制。测试方案是以测试计划为指导，在软件生命周期中的概要设计后，根据其阶段性产物——概要设计说明书及之前的需求规格说明书撰写而成的。测试方案的制定条目包括明确测试策略、细分测试子项、根据测试计划编写测试用例和选择测试工具[1]。测试方案撰写完成后，所有参与本次测试的测试人员组织开会，进行测试方案的评审。本文采用单元测试——集成测试——系统测试——验收测试的步骤对本系统进行分步测试。当测试方案过审后、开发人员完成代码自检时，由测试组进行单元测试。

3 单元测试

图1：W 模型图

图2：客运需求预测系统功能图

图3：全国客运量分析界面中的单元测试元素图

单元测试，顾名思义，是指对系统中最小单位进行验证以及问题排查。后来，单元模块也特指程序中的最小模块——类。本系统共有12 个html 页面、6 个数据存取类、8 个业务逻辑Servlet 以及1 个数据库关联类。为了能够更有效地发现缺陷，我们将单元测试分为静态单元测试和动态单元测试。静态测试，即在不运行代码的情况下对程序进行检测。与之相反，动态测试就是通过运行代码来对程序进行检测。由于编码结束后才开始单元测试会增加软件缺陷的风险，且缺陷发现的越晚，对于项目的人力物力损失越大，因而在开发人员完成单元模块的代码自检后，测试人员便开始对该模块的所有子功能进行测试。测试人员检测时，首先使用SourceMonitor检测代码复杂度，当代码复杂度大于50，或者且代码深度超过6 时，将该结果记录下来并且报告给开发人员。在完成代码复杂度检测之后，便开始准备对代码实现的功能进行检测。此时便要为上述的测试方案逐步增添测试用例。每当开发组完成一个系统子模块时，我们就要为该子模块设计相关的测试案例。根据本系统的系统特点，将单元测试详细划分为对以下几部分的测试：

表1：全国客运量分析界面元素单元测试表

表2：CityServletData 函数功能测试用例表

表3：集成测试用例表

（1）业务逻辑模块函数功能能否实现；

（2）数据存取单元能否实现数据存取；

（3）Html 页面上所有的模块能否正确显示。

下面以客运需求预测系统的全国客运量分析界面为例，详细分析该系统中单元测试的用例。图2 为该html 页面中可测试的功能点，表1 是对图3 所要检测的单元功能点的表述。

对该html 页面进行测试之后，测试与之相关的业务逻辑及数据存取类中的模块函数是否能够正确完成其功能。仍然以全国客运量分析子模块为例，展示其相关的单元代码模块测试条目（模块代码测试用例表以CityServletData 中的CityServletData 函数为例，见表2）：

（1） 测 试NewPassengerDF.src.dao.DBConnector.java 是 否能够与数据库连接成功（此处“.”代表目录分隔，即“dao.DBConnector.java”代表dao 目录下的DBConnector.java 文件）；

（2）测试User 类中的方法能否实现其预期的功能（包括isUser 方法、getUsrName 方法、addUser 方法、setUsername 方法、setName 方法、getUsername 方法、setName 方法、getName 方法、setPassword 方法、getPassword 方法以及User 方法）；

（3）测试CityServletData 的所有方法能否实现预期功能（包括CityServletData 方法、show 方法以及toString 方法）；

（4）测试ForecastData 类中的所有方法是否能够实现预期功能（包括ForecastData 方法以及toString 方法）。

4 集成测试

在系统的子模块分支进行单元测试之后，便进行集成测试的设计。集成测试，即将通过单元测试的模块根据系统要求组装集成，来检查这些单元模块之间的接口是否存在问题[2]，包括接口参数一致性的引用，集成后的模块是否满足需求规格说明书中该子模块的预期功能。在集成测试的模式方面，为了及早发现模块中的错误、明确错误的具体出错点，本系统采用渐增式集成模式及自底向上的集成方式对通过测试的单元模块进行集成。首先，将底层模块组合成实现某些特定功能的族；其次为该族编写一个用以测试的驱动模块并对该族进行测试；然后组合其他单元模块，当单元模块全部组装完成测试后，沿着软件结构上移，并对新的子模块进行集成；最后反复执行该过程直到模块集成到系统最顶层。下面以客运需求预测系统中的需求侧影响因素下的GDP 变化模块集成为例展开论述本系统的集成测试，即：

（1）测试该页面中的下拉框选项与折线图是否发生联动；

（2）该折线图中的数据是否与数据库中相关年份的正确数据对应。

本次集成的模块包括：DBConnector.java、数据库中的china_base_data 表、GDPServlet.java 以及相对应的html 页面。测试用例见表3。

5 系统测试

系统测试开始前，各模块间的接口问题已被消除，原本被分解的模块被继承，形成相对完整的体系。系统测试是将经过集成测试后的模块，作为计算机系统的一个部分，与计算机硬件、某些支持软件、数据和平台等系统元素结合起来，在真实运行环境下对计算机系统进行一系列严格有效的测试来发现软件的潜在问题，以保障系统的正常运行。测试条目包括功能测试、回归测试、性能测试、安全测试、容错性测试、兼容性测试以及可靠性测试[3]。根据甲方要求以及系统特性，本系统的系统测试分别从功能测试、回归测试、性能测试以及兼容性测试几个方面展开。

5.1 功能测试

系统测试中的功能测试不仅要衡量单元模块功能是否实现以及模块接口是否能够正常运作，还要考虑系统的应用环境。它的衡量标准是产品规格说明书上所要求的所有功能是否都已实现，需要实现的功能包括程序的正常安装启动、每项功能符合实际的产品要求、html 元素的正常、功能逻辑清楚、系统符合用户的使用逻辑、能支持多种应用环境等。

本系统的功能测试使用Selenium 编写自动化测试脚本对系统中所有的已有功能仿照用户操作进行验收。Selenium 的核心部分是由纯JavaScript 编写，因而能够直接运行在浏览器上面，方便了Web 系统的测试[4]。其次，在下载Selenium 时，由于seleniumIDE是Firefox 的一个插件，依附于Firefox，所以需要先安装Firefox 浏览器，而后在火狐浏览器的组件中找到Selenium 进行下载。

5.2 回归测试

当系统出现缺陷时，测试组将缺陷报备给开发组，在开发组改正缺陷后，在其它受影响的区域很有可能出现新的缺陷。倘若此版本就此发布，会给用户带来严重不便。回归测试是在系统完成修改原有BUG 或者增加新的功能后，为了保证程序中其他模块没有受到影响而破坏原有的功能，即为了发现回归缺陷所做的测试。

对于系统的回归测试，测试人员在综合考虑时间和成本等因素后，构造了一个精简后的用例组来进行测试。回归测试的测试集需要验证的内容是：

（1）对系统的修改是否破坏了现有的功能；

（2）验证修改工作本身是否存在缺陷，其过程如下[5]：首先识别出系统中被修改的地方；其次从原有的测试集中删除不适用的测试用例，保留对修改后的系统有效的测试用例，形成新的测试集[6]。若回归测试集的测试用例覆盖率没有达到规定的量级，测试人员需要为之增添新的测试用例，形成新的测试用例集[7]。

由于回归测试的工作具有重复性，一般会编写对应的测试脚本，将重复的工作交给自动化测试，以达到节省人力物力的目的。本项目使用由IBM 开发的Rational Functional Tester 工具以及python 语言编写脚本进行自动化测试。

5.3 性能测试

性能测试是在用户的操作环境以及特定的负载中为了发现系统的性能问题或为了获取系统的相关性能指标而进行的测试[8]。系统的性能指标包括系统资源的使用率以及系统的行为表现[9]。根据需求规格说明书，为本系统制定的测试方案中性能测试包括了系统负载测试、压力测试、容量测试[10]。本系统使用测性能测试工具是Jmeter，测试过程如下：

（1）测试人员模拟100 个用户并发访问系统，设定每个用户的启动时间为2 秒，循环50 次。模拟过程中，共存在5000 次请求。由于本地请求和远程服务器端请求所耗费的时间不同，因而将两个服务器端分离开来测试。

（2）将测试结果进行对比。从结果上来看：

1.本地段请求5000 次请求在200s 内全部成功，平均访问时间为87s，最大访问时间为1086s，因而在本地端系统的并发能力很好。

2.在远程服务器端进行测试时，5000 次请求在200s 内只有4321 个请求发送成功，且最长的反应时间为21855ms，较本地请求测试差了许多，但是请求成功率大于80%，因而系统在远程端请求的并发能力较好。

本系统分别采用汇总报告、图形结果、结果树的方式来观察其性能变化（相关的结果见图4 至图6）。各反馈方式代表的含义见下：

3.通过汇总报告可查看到label、samples、Average、Median、Min、Max、Error%以及Throughput 等量化指标。Label 是请求类型，如HTTP，FTP 等请求；#Samples 是图形报表中的样本数目，即发送到服务器的总样本数；Average 是图形报表中的平均值，计算法则是总运行时间除以发送到服务器的请求数[11]；Median 是图形报表中的中间值，是代表时间的数字，在请求测试中有一半样本的服务器响应时间低于该值而另一半高于该值[12]；Min 是时间数字，代表服务器响应的最短时间；Max 同样也是时间数字，代表服务器响应的最长时间；Error%代表请求的错误百分比；Throughput 是图形报表中的吞吐量，代表服务器每单位时间处理的请求数，单位为秒或分钟；KB/sec 是每秒钟请求的字节数。

图4：Jmeter 测试结果树图

图5：Jmeter 测试结果图

图6：Jmeter 测试汇总报告图

表4：市面上常见的屏幕尺寸及其分辨率表

4.通过结果树可观察HTTP 请求是否发送成功，绿色为发送成功，红色为失败。单击每一条HTTP 请求后可了解该条请求的相关参数。

5.通过图形结果可以观察样本数、最新样本、吞吐量、中间值以及偏离。样本数目是发送到服务器的请求总数[13]；最新样本是时间数字，代表服务器响应最后一个请求的时间；吞吐量代表服务器每分钟处理的请求数；平均值即总运行时间除以发送到服务器的请求数；中间值是时间数字，测试样本中，有一半的服务器响应时间低于该值而另一半高于该值；偏离表示服务器响应时间变化、离散程度测量值的大小即数据分布。

5.4 数据库测试

由于本系统不存在并发数据操作数据库，所以不会存在丢失数据、不可重复读数据以及读脏数据等问题，因而测试方案中没有设计数据库的并发测试方案。只是在单元测试中验证了数据库的一致性。

5.5 兼容性测试

软件的兼容性测试是指验证软件之间是否正确地交互和共享信息，包括同步共享、异步共享、本地交互以及远程通信交互[14]。由于本系统是Web 项目，因而做了浏览器兼容性测试以及分辨率兼容性测试。

浏览器兼容性测试是指从不同的浏览器登录本系统，核对该系统在每个浏览器中html 元素的位置、大小以及该元素以及元素中存在的业务逻辑是否能够正常显示。分辨率兼容性测试指的是测试在不同分辨率的屏幕中Web 界面元素的位置能否按照原定比例显示。常见的浏览器内核可以分四种：Trident、Gecko、Blink、Webkit，例如：IE 浏览器为Trident 内核，也称为IE 内核；Chrome浏览器：Webkit 内核，现在为Blink 内核；火狐浏览器：Gecko 内核，俗称Firefox 内核；Safari 浏览器：Webkit 内核。本系统的浏览器兼容性测试中选取了以下三种浏览器：ie 浏览器、火狐浏览器以及360 浏览器进行测试。在三种浏览器中，界面元素的置大致相同且相应的功能都可以实现。关于屏幕分辨率测试，表4 是市面上最常见的电脑屏幕分辨率，在本系统的分辨率兼容性测试中，在尺寸为14、15、22 的屏幕上分别选取两个分辨率作为测试环境。

6 验收测试

验收测试是在软件进行系统测试之后、产品发布前所做的测试[15]。因代表着技术测试到了尾声，验收测试也被称之为“交付测试”。验收测试与系统测试最主要的区别是测试的人员相异，前者是由用户来执行测试操作的[16]，其主要目标是向用户展示所开发出来的软件符合用户需求，并验证该软件在实际场景中的有效性和可靠性，以确保用户能使用该系统顺利完成既定的任务和功能。通过了验收测试，该产品便可发布。然而，在实际交付之后，开发人员是无法预测该软件用户的实际使用方法。因此，从用户的角度出发，测试人员应当设计Alpha 测试和Beta 测试这两种情形的测试。Alpha 测试是系统在开发环境下由用户进行的测试。Alpha 测试主要是对照需求规格说明书从软件产品的功能、局域化、界面、可使用性以及性能等方面进行评价。而Beta 测试是由多个用户在实际环境中对其进行测试，并将测试过程中发现的错误有效反馈给系统开发人员。本系统的验收测试测试人员包含了系统的开发人员、测试人员以及随机用户。

7 结束语

本文以客运需求预测系统中的测试条目为案例，延伸分析了一种优化后Web 系统的测试思路、步骤以及每个步骤中相关的测试方法和测试工具。旨在为Web 项目中的软件测试提供一条清晰的测试分析思路。