oa性能测试方案、报告模版

OA系统考勤业务模块性能测试方案

1

修订记录

OA系统考勤业务模块性能测试方案

1、概述

本测试方案用于指导《OA系统》中用户登录及考勤模块性能测试工作。本文档主要描述了OA系统用户登录及考勤模块性能指标及测试方法，便于项目经理、研发部、测试部对《OA系统》用户登录及考勤模块性能从技术层面与实际运行表现进行评估，并指导测试工程师验证《OA系统》用户登录及考勤模块的响应速度、负载能力及系统资源耗用情况是否达到真实运行场景的压力和性能要求。

2、测试目标

3、测试设计

对象分析

《OA系统》采用B/S（Browser/Server）模式设计。用JSP实现前台，Mysql做后台数据库。Web服务器采用Tomcat+JDK。

测试策略

使用商用压力测试工具LoadRunner 8.1，模拟用户并发操作。测试用户登录及考勤功能模块在多并发、长时间业务环境下是否能够稳定正常运行，各项指标是否能够达到以上要求的标准。使用Spotlight监控Mysql数据库，ManageEn gine_ApplicationsManager监控Tomcat的JVM使用情况。

测试模型

正式系统组网图

业务流程

OA系统用户通过浏览器发出业务请求，经由JSP代码处理，转发到Web服务器（Tomcat），Web 服务器通过代码分析请求类别，如涉及数据库操作，则转发请求给后台数据库，最终获取数据，经过Web 服务器组合，反馈至客户端，完成用户的业务请求。

测试环境描述

测试环境需求

测试工具要求

HP公司LoadRunner 8.1英文版，Quest Software 公司的Spotlight on Mysql 2.0.1.42，ManageEngine公司的ManageEn gine_ApplicationsManager 8。

测试代码要求

测试执行前完成对应功能已经完成功能测试。

4、详细测试方法

本部分主要描述测试方法、并发用户计算及测试启动等方面内容。

测试方法综述

本次测试使用HP公司的性能测试工具LoadRunner。它通过创建多个虚拟用户的方式，对录制的单用户脚本增加负载，来达到增加系统压力的测试目的。LoadRunner提供了Analysis工具对压力运行的结果进行分析，得出测试脚本运行期间，系统响应事务的最小时间，平均时间和最大时间等性能信息。同时可监视各后台服务器的CPU占用率与内存使用情况。利用该工具录制用户登录的业务模型，然后设计多用户并发登录的场景模式。对于Web服务器Tomcat的监控使用Quest Software 公司的Spotlight on Mysql，主要监控Tomcat的JVM使用情况，至于Mysql数据库的监控，这里使用的是ManageEngine公司的ManageEn gine_ApplicationsManager 8，主要考察Mysql的SQL执行性能。

业务模型分析

《OA系统》用户登录考勤业务模块一般集中在早上8:40到9:10这个时间段，那么登录及考勤业务操作的高峰期可能出现在这个时间段，同时，每个用户只能执行一次考勤业务，据此，本次测试的业务场景可以设置如下：

并发用户计算及启动

并发数设计为7个，采取逐步增加的办法，首先启动1个，每隔5秒增加1个，到达指定用户个数后，持续运行30分钟左右，30分钟后，每隔5秒降1个。

5、统计测试数据

根据性能测试的目的，需记录测试过程中相关的数据，如下表所示：

OA系统考勤业务模块性能测试报告

7

修订记录

《OA系统》考勤业务模块性能测试报告

1、概述

本测试报告用于说明《OA系统》用户登录及考勤模块的并发性能，检查在多用户并发登录进行考勤业务时，系统的性能反应情况，以此结果指出项目的性能质量，便于项目组开展性能调优工作及决定能否发布。

2、测试目的

本次测试从事务响应时间、并发用户数、系统资源使用等多个方面，以专业的性能测试工具，分析出当前系统的性能表现，以实际测试数据与预期的性能要求比较，检查系统是否达到既定的性能目标。

3、测试设计

对象分析

系统采用B/S（Browser/Server）模式设计。用JSP实现前台，Mysql做后台数据库。Web服务器采用Tomcat。

测试策略

使用商用压力测试工具LoadRunner 8.1，模拟用户并发操作。测试用户登录及考勤功能模块在多并发操作下是否能够稳定正常运行，各项指标是否能够达到项目要求的标准。

4、测试模型

测试环境描述

测试环境需求

1、系统环境标准配置：

2、测试客户端配置：

测试工具要求

HP公司LoadRunner 8.1英文版，Quest Software 公司的Spotlight on Mysql 2.0.1.42，ManageEngine公司的ManageEn gine_ApplicationsManager 8。

测试代码要求

测试执行前完成对应功能已经完成功能测试。

5、详细测试方法

本部分主要描述测试方法、并发用户计算及测试启动等方面内容

测试方法综述

本次测试使用HP公司的性能测试工具LoadRunner。它通过创建多个虚拟用户的方式，对录制的单用户脚本增加负载，来达到增加系统压力的测试目的。LoadRunner提供了Analysis工具对压力运行的结果进行分析，得出测试脚本运行期间，系统响应事务的最小时间，平均时间和最大时间等性能信息。同时可监视各后台服务器的CPU占用率与内存使用情况。利用该工具录制用户登录的业务模型，然后设计多用户并发登录的场景模式。对于Web服务器Tomcat的监控使用Quest Software 公司的Spotlight on Mysql，主要监控Tomcat的JVM使用情况，至于Mysql数据库的监控，这里使用的是ManageEngine公司的ManageEn gine_ApplicationsManager 8，主要考察Mysql的SQL执行性能。

业务模型分析

《OA系统》用户登录考勤业务模块一般集中在早上8:40到9:10这个时间段，那么登录及考勤业务操作的高峰期可能出现在这个时间段，同时，每个用户只能执行一次考勤业务，据此，本次测试的业务场景执行步骤如下：

并发用户计算及启动

并发数设计为7个，采取逐步增加的办法，首先启动1个，每隔5秒增加1个，到达指定用户个数后，持续运行30分钟左右，30分钟后，每隔5秒降1个。

6、测试结果

并发数状态图

“Running Vusers（运行的并发数）”显示了在场景执行过程中并发数的执行情况。显示了在OA系统考勤业务性能测试过程中Vusers运行情况，从图中我们可以看到，Vusers的运行趋势与我们场景执行计划中的设置是一样，表明在场景执行过程中，Vusers是按照我们预期的设置运行的，没有Vuser出现运行错误。

集合点的图形如下图所示，从图中可以看到，所有用户到达集合点后，立刻就释放了。与之前设定的集合点策略设置“所有运行用户到达后释放“是一致的，说明整个场景执行过程中，并发数用户的执行正确，OA系统测试服务器能够应付7个并发用户的业务操作。

响应时间图

从下图可以看出，所有Action平均事务响应时间的趋势都非常平滑。登录业务的“90 Percent Time”是5.298秒-3秒（思考时间）=2.298秒，考勤业务的“90 Percent Time”是1.469秒，与期望结果3秒比较，

都通过了。

每秒点击数

下图显示的是“Hits per Second”与“Average Throughput (bytes/second)”的复合图，从图中可以看出，

两种图形的曲线都正常并且基本一致，说明服务器能及时的接受客户端的请求，并能够返回结果。

从图中可以看出，所有的Aciton都是绿色的，即表示为Passed，同时除了vuser_init与vuser_end两个

事务，其他的事务通过数为2163，也就表明在30分钟的时间里，共完成了2163次登录考勤业务操作。那么根据这些可以判断本次测试登录业务与考勤业务的成功率是100%

系统资源

本次测试监控的是测试服务器的CPU使用率与内存使用率，以及处理器队列长度，具体的数据下图所示。

从图中可以看出，CPU使用率、可用物理内存、CPU的队列长度三个指标的曲线逗较为平滑，三者的平均值分别为：53.582%、83.456M、8.45，而测试服务器总的物理内存为384M，那么内存使用率为（384-83.456）/384=78.26%，根据本次性能测试要求的：CPU使用率不超过75%，物理内存使用率不超过70%这两点来看，内存的使用率78.26%大于预期的70%，故内存使用率不达标。根据Windwos资源性能指标的解释，一般情况下，如果“Processor Queue Length（处理器队列长度）”一直超过二，则可能表

示处理器堵塞，我们这里监控出来的数值是8.45，而且总体上保持平衡，那么由此推断，测试服务器的CPU也可能是个瓶颈。同时在测试过程中，场景执行到23分半钟的时候，报出了下图的错误，意思是说被监控的服务器当前无法再进行计数器数据的获取了，所以，本次操作系统资源的监控只得到了场景执行的前23分半钟的数据。这样对本次测试结果有一定的影响。

Tomcat JVM使用率

从图中我们可以明显看出，Tomcat的JVM使用率不断上升，配置Tomcat服务器时共分配了100M左右的物理内存给其，测试初期使用的JVM相对来说较少，我们的测试场景是从15:58:40开始，到16:29:42结束，共历时31分2秒。从图中看到，从16:00到16:30这个时间内，也就是测试场景执行期间，JVM的使用率不断上升，并没有在请求达到均衡状态后也呈现一种平衡状态，而随着请求的持续增长而增加。从这点可以推断，如果测试场景继续执行，或者加大并发数，最终很可能导致Tomcat内存不够用而报出“Out Of Memory”内存溢出的错误。

Mysql数据库SQL执行状态

从图中可以看到，“Selects（查询）”与“Inserts（插入）”两种语句执行的趋势在场景执行过程中

是比较平滑，并且测试中没有错误发现，也就说明在处理相关业务时Mysql的处理是正常的。

7、测试结论

从测试结果中可以看出，OA系统服务器除了内存使用率外，其他指标都达到了我们预期的期望结果，内存这点需要加大，同时Tomcat的JVM使用率在场景执行过程中不断增加，需增加并发数、延长场景执行时间以验证是否存在内存泄漏问题。