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

附录三 OA系统考勤业务模块性能测试方案产品名称Product Name密级Confidentiality LevelOA系统秘密产品版本Product Version共6页1.00OA系统考勤业务模块性能测试方案拟制:审核:日期：审核:日期：批准:日期：修订记录日期修订版本描述作者OA系统考勤业务模块性能测试方案1、概述本测试方案用于指导OA系统中用户登录及考勤模块性能测试工作。本文档主要描述了OA系统用户登录及考勤模块性能指标及测试方法，便于项目经理、研发部、测试部对OA系统用户登录及考勤模块性能从技术层面与实际运行表现进行评估，并指导测试工程师验证OA系统用户登录及考勤模块的响应速度、负载能力及系统资源耗用情况是否达到真实运行场景的压力和性能要求。2、测试目标本次测试检测OA系统用户登录及考勤模块性能需满足下表指标：测试项响应时间业务成功率业务总数CPU使用率内存使用率登录=3秒100%30分钟完成200075%70%考勤=3秒100%30分钟完成20003、测试设计对象分析OA系统采用B/S（Browser/Server）模式设计。用JSP实现前台，Mysql做后台数据库。Web服务器采用Tomcat+JDK。测试策略使用商用压力测试工具LoadRunner 8.1，模拟用户并发操作。测试用户登录及考勤功能模块在多并发、长时间业务环境下是否能够稳定正常运行，各项指标是否能够达到以上要求的标准。使用Spotlight监控Mysql数据库，ManageEngine_ApplicationsManager监控Tomcat的JVM使用情况。测试模型正式系统组网图业务流程OA系统用户通过浏览器发出业务请求，经由JSP代码处理，转发到Web服务器（Tomcat），Web服务器通过代码分析请求类别，如涉及数据库操作，则转发请求给后台数据库，最终获取数据，经过Web服务器组合，反馈至客户端，完成用户的业务请求。测试环境描述测试环境需求1、系统环境标准配置：主机用途机型/OS台数CPU/台内存容量/台对应IPOA系统应用服务器PC/Win2003 Server111G192.168.1.108OA系统数据库服务器PC/Win2003 Server111G同上2、测试客户端配置：主机用途机型/OS台数CPU/台内存容量/台浏览器版本对应IP压力负载生成器PC/Win XP111GIE 6.0192.168.1.100测试工具要求HP公司LoadRunner 8.1英文版，Quest Software 公司的Spotlight on Mysql 2.0.1.42，ManageEngine公司的ManageEngine_ApplicationsManager 8。测试代码要求测试执行前完成对应功能已经完成功能测试。4、详细测试方法本部分主要描述测试方法、并发用户计算及测试启动等方面内容。测试方法综述本次测试使用HP公司的性能测试工具LoadRunner。它通过创建多个虚拟用户的方式，对录制的单用户脚本增加负载，来达到增加系统压力的测试目的。LoadRunner提供了Analysis工具对压力运行的结果进行分析，得出测试脚本运行期间，系统响应事务的最小时间，平均时间和最大时间等性能信息。同时可监视各后台服务器的CPU占用率与内存使用情况。利用该工具录制用户登录的业务模型，然后设计多用户并发登录的场景模式。对于Web服务器Tomcat的监控使用Quest Software 公司的Spotlight on Mysql，主要监控Tomcat的JVM使用情况，至于Mysql数据库的监控，这里使用的是ManageEngine公司的ManageEngine_ApplicationsManager 8，主要考察Mysql的SQL执行性能。业务模型分析OA系统用户登录考勤业务模块一般集中在早上8:40到9:10这个时间段，那么登录及考勤业务操作的高峰期可能出现在这个时间段，同时，每个用户只能执行一次考勤业务，据此，本次测试的业务场景可以设置如下：步骤序号步骤描述1用户打开OA系统首页地址2输入用户名“erbao”3输入密码“123456”4点击【登录】按钮5进入erbao个人页面，展开“行政管理”6展开“员工事务”，点击【员工考勤】链接7默认设置，点击页面右边【发送】按钮8考勤成功，点击【退出】按钮，退出系统并发用户计算及启动并发数设计为7个，采取逐步增加的办法，首先启动1个，每隔5秒增加1个，到达指定用户个数后，持续运行30分钟左右，30分钟后，每隔5秒降1个。5、统计测试数据根据性能测试的目的，需记录测试过程中相关的数据，如下表所示：测试项目标值实际值是否通过登录业务响应时间=3秒考勤业务响应时间=3秒登录业务成功率100%考勤业务成功率100%登录业务总数30分钟完成2000考勤业务总数30分钟完成2000CPU使用率75%内存使用率70%附录四 OA系统考勤业务模块性能测试报告产品名称Product name密级Confidentiality levelOA系统秘密产品版本Product version共10页1.00OA系统考勤业务模块性能测试报告拟制:日期：审核:日期：审核:日期：批准:日期：修订记录日期修订版本描述作者OA系统考勤业务模块性能测试报告1、概述本测试报告用于说明OA系统用户登录及考勤模块的并发性能，检查在多用户并发登录进行考勤业务时，系统的性能反应情况，以此结果指出项目的性能质量，便于项目组开展性能调优工作及决定能否发布。2、测试目的本次测试从事务响应时间、并发用户数、系统资源使用等多个方面，以专业的性能测试工具，分析出当前系统的性能表现，以实际测试数据与预期的性能要求比较，检查系统是否达到既定的性能目标。3、测试设计对象分析系统采用B/S（Browser/Server）模式设计。用JSP实现前台，Mysql做后台数据库。Web服务器采用Tomcat。测试策略使用商用压力测试工具LoadRunner 8.1，模拟用户并发操作。测试用户登录及考勤功能模块在多并发操作下是否能够稳定正常运行，各项指标是否能够达到项目要求的标准。4、测试模型测试环境描述测试环境需求1、 系统环境标准配置：主机用途机型/OS台数CPU/台内存容量/台对应IPOA系统应用服务器PC/Win2003 Server111G192.168.1.108OA系统数据库服务器PC/Win2003 Server111G同上2、 测试客户端配置：主机用途机型/OS台数CPU/台内存容量/台浏览器版本对应IP压力负载生成器PC/Win XP111GIE 6.0192.168.1.100测试工具要求HP公司LoadRunner 8.1英文版，Quest Software 公司的Spotlight on Mysql 2.0.1.42，ManageEngine公司的ManageEngine_ApplicationsManager 8。测试代码要求测试执行前完成对应功能已经完成功能测试。5、详细测试方法本部分主要描述测试方法、并发用户计算及测试启动等方面内容测试方法综述本次测试使用HP公司的性能测试工具LoadRunner。它通过创建多个虚拟用户的方式，对录制的单用户脚本增加负载，来达到增加系统压力的测试目的。LoadRunner提供了Analysis工具对压力运行的结果进行分析，得出测试脚本运行期间，系统响应事务的最小时间，平均时间和最大时间等性能信息。同时可监视各后台服务器的CPU占用率与内存使用情况。利用该工具录制用户登录的业务模型，然后设计多用户并发登录的场景模式。对于Web服务器Tomcat的监控使用Quest Software 公司的Spotlight on Mysql，主要监控Tomcat的JVM使用情况，至于Mysql数据库的监控，这里使用的是ManageEngine公司的ManageEngine_ApplicationsManager 8，主要考察Mysql的SQL执行性能。业务模型分析OA系统用户登录考勤业务模块一般集中在早上8:40到9:10这个时间段，那么登录及考勤业务操作的高峰期可能出现在这个时间段，同时，每个用户只能执行一次考勤业务，据此，本次测试的业务场景执行步骤如下：步骤序号步骤描述1用户打开OA系统首页地址2输入用户名“erbao”3输入密码“123456”4点击【登录】按钮5进入erbao个人页面，展开“行政管理”6展开“员工事务”，点击【员工考勤】链接7默认设置，点击页面右边【发送】按钮8考勤成功，点击【退出】按钮，退出系统并发用户计算及启动并发数设计为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、测试结论本