软件性能测试报告模板

目录1前言1第一章XXXXXXXX核心业务系统性能测试概述1.1被测系统定义1.1.1功能简介1.1.2性能测试指标1.2系统结构及流程1.2.1系统总体结构1.2.2功能模块描述1.2.3业务流程1.2.4系统的关键点描述（KP）1.3性能测试环境1.3.1硬件及网络环境1.3.2系统装配描述1.3.3系统启动和管理2第二章性能测试2.1压力测试2.1.1压力测试概述2.1.2测试目的2.1.3测试方法及测试用例2.1.4测试指标及期望2.1.5测试数据准备2.1.6运行状况记录3第三章测试计划及方案2.2测试步骤2.2.1被测系统调研2.2.2测试环境的部署2.2.3脚本的录制和调试2.2.4准备测试场景2.2.5准备测试数据2.2.6执行性能测试2.2.7生成测试报告2.3测试时间进度及人员安排2.3.1人员安排3第四章测试报告1前言目前，XXXX的XXXXXXXX核心业务系统（以下简称新业务系统）已先后在XXXX、成功上线，从而公司的XXXX信息管理逐步走上了集中管控的道路。后续，xxx等34家分公司的XXXX信息也将分布进入业务系统，从而将会势必出现新业务系统中信息大量增长的态势。随着新业务系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：XXXX大数据量的“冲击”，在XXXX信息进入时，系统能稳定在什么样的性能水平，面临公司业务冲刺时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。本《性能测试规划书》即是基于上述考虑，参考科学的性能测试方法而撰写的，用以指导即将进行的XXXXXXXX核心业务系统的性能测试。1第一章xxxx系统性能测试概述1.1被测系统定义xxxx业务系统作为本次测试的被测系统（注：以下所有针对被测系统地描述均为针对XXXXXXXX核心业务系统进行的），该业务系统的主要功能包括：xxxxx在本次测试中，将针对上述的功能进行压力测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统地吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数，1.1.1功能简介xxxxxx主要功能如下：ØxxxØxxxxxØ1.1.2性能测试指标本次测试是针对XXXXXXXX核心业务系统的性能特征和系统的性能调优而进行的，主要需要获得如下的测试指标。1、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户端交易发起，到服务器端交易应答返回所需要的时间，包括网络传输时间和服务器处理时间。2、应用系统的吞吐率：即应用系统在单位时间内完成的交易量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的交易数量。3、应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。1.2系统结构及流程xxxx业务系统在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样的，交易流程也完全一致的。不过，由于硬件条件的限制，本次性能测试的硬件平台跟实际生产环境略有不同。1.2.1系统总体结构描述本系统的总体结构，包括：硬件组织体系结构、网络组织体系结构、软件组织体系结构和功能模块的组织体系结构。1.2.2功能模块本次性能测试中各类交易都是由若干功能模块组成的，每个交易都根据其执行特点分成了若干操作步骤，每个步骤就是一个功能点（即功能模块），在xxx业务系统中，各种交易及其包含的功能模块关系如下：1．xxx2．xxxx3．xxxx本次压力测试主要设计的功能模块以及所属的路径如下表名称所属交易路径1.2.3业务流程本次性能测试中，选择的各类交易的业务流程如下：1．xxxxxx2．xxxxxxx3．xxxxxx：4．xxx：5．xxxxx6．xxxx查询交易的业务流程只是单一步骤的，即：输入查询条件后获取查询结果，因此在本次性能测试中只作为一个事物处理，交易流程图略。1.2.4关键点描述（KP）本次性能测试的关键点，就是查看xxxx业务系统在并发压力下的表现，即：支持的并发用户数目和并发用户发送频率，以及在较大压力下，系统的交易处理能力，并找出各类交易的性能瓶颈。1.3性能测试环境本次性能测试环境与真实运行环境基本一致，都运行在同样的硬件和网络环境中，数据库是真实环境数据库的一个复制（或缩小），本系统采用标准的CS结构，客户端都是通过浏览器访问应用系统。其中具体的硬件和网络环境如下：Ø服务器设备：IBM570（DBserver），IBM690（APserver）Ø操作系统：AIXØ网络环境：LAN（10M）Ø数据库：OracleØ客户端：PC（Windows）网络拓扑和结构图如下：2第二章性能测试从广泛意义上讲性能测试包括：压力测试、稳定性测试、负载能力测试和可扩展性测试等。在不同应用系统的性能测试中，需要根据应用系统的特点和测试目的的不同来选择具体的测试方案，本次XXXXXXXX核心业务系统的性能测试主要是采用通常的压力测试模式来执行的，即：逐步增加压力，查看应用系统在各种压力状况小的性能表现。在本次性能测试中，也将使用美科利的新产品性能测试诊断工具（Diagnostic）对测试应用的各层进行监控，判断J2EE各层次的各类方法和类的调用使用时间和效率，并帮助开发人员分析J2EE应用的各类交易的性能瓶颈点。2.1压力测试在性能测试中，压力测试主要是为了获取系统在较大压力状况下的性能表现而设计并实现的，压力测试主要是获取系统的性能瓶颈和系统的最大吞吐率。2.1.1压力测试概述本次压力测试是指针对现行的xxx核心业务系统的联机交易处理能力的测试，检验系统的吞吐率。本系统的压力测试主要是针对xxxxx，检查在日间交易高峰时期，并发用户数较多的时候的处理能力等等。2.1.2测试目的压力测试的目的就是检验系统的最大吞吐量，检验现行的xxxx业务系统在各种压力交易量下的运行状况，检验系统地运行瓶颈，获取系统的处理能力等等。本次针对xxxx核心业务系统所进行的压力测试的测试目的为：²给出xxxx系统当前的性能状况²定位新业务系统性能瓶颈或潜在性能瓶颈²总结一套合理的、可操作的、适合公司现实情况的性能测试方案，为后续的性能测试工作提供基本思路。2.1.3测试方法及测试用例使用美科利公司（Mercury）的性能测试软件LoadRunner，对现行的xxxx业务系统进行脚本录制、测试回放、逐步加压和跟踪记录。测试过程中，由LoadRunner的管理平台调用各台测试前台，发起各种组合的交易请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。使用的测试用例包括：联机处理交易和查询交易，其中联机交易测试试用的交易包括：xxxx查询类交易包括：xxxx测试用例列表包括：交易种类案例一案例二案例三案例四30%40%25%10%10%10%25%0%20%10%15%0%20%20%15%10%30%20%20%80%本次测试将依照如下场景进行测试：用户数功能模块业务操作交易配比（%)2004007001000针对每个测试案例，都将采用逐步加压和瞬间加压两种客户端连接方式进行，查看服务器端在客户端的连接数量变化过程中对应的处理能力，测试运行安排如下：·每隔2秒增加1个用户连接，最多增加到200个用户，查看并记录运行情况·每隔2秒增加2个用户连接，最多增加到200个用户，查看并记录运行情况·一次性连接10个用户，查看记录运行情况·一次性连接100个用户，查看记录运行情况3.3.1第一次测试第一次测试使用了200个并发用户，并发用户的启动信息如下：各类交易的交易相应时间（秒）ColorScale交易名称最小平均最大1AutoUW_Transaction0.023.73387.8711Confirm_Transaction210.203210.203210.2031CTDetail_Transaction105.878151.032199.4771EdorNoscanAppInput_Transaction60.704153.425259.2341GeneralQuery_Transaction0.06713.62339.0941IndividualQuery_Transaction0.78128.04264.9841Issue_Transaction5.14530.660.221Login_Transaction4.265115.433246.7361ManualUW_Transaction77.09477.09477.0941NBQuery_Transaction0.33422.34849.6251PayIn_Transaction1.50359.944112.6391PayOut_Transaction5.25629.17860.2791PayOutQuery_Transaction0.0781.2916.8721PEdorTypeAC_Transaction111.253160.054213.5441PosNoScanApp_Transaction9.254158.276271.3811POSQuery_Transaction29.602122.815212.931PrtNoInput_Transaction1.722146.879263.0941Relogin_Transaction30.1670.939105.241ReportInput_Transaction1.155101.387184.7831Review_Transaction5.091112.682387.0871RiskInput_Transaction2.821113.049211.4271vuser_end_Transaction0.00.00.01vuser_init_Transaction0.00.1582.41712.084112.373267.65910.2786.31215.39413.7513.5625.92510.226.24315.93918.531109.639210.74611.2818.55315.47410.09319.46959.271各类交易的平均响应时间图：可以看出随着测试的进行，交易相应时间逐渐增大，最终导致交易超时而失败。测试中，每秒的点击率如下：测试中每秒页面的下载速度如下：根据上面两组数据，即：每秒的点击率和每秒下载页面的速度，可以看出，在测试执行开始4分钟以后，核心业务系统用户登录的并发数量不断在增加，但是用户登录后的数据下载量却变化不大，这样将最终导致大量的用户登录因为交易处理超时而失败。3.3.2第二次测试第二次测试调整了交易处理逻辑，大大减少了用户登录的操作数目，每个用户只执行一次用户登录，然后执行对应的交易处理，交易过程中不再执行用户登录操作。运行的并发用户数目如下图：在用户登录过程中，交易的平均响应时间如下图：从图中可以看出，随着并发用户数量的不断增加，所有的交易的平均响应时间都在加大，直到并发用户数不再增加，这时候所有的交易相应时间下降到一定的数值，并一直稳定在这个数值左右。在第二次测试中，各类交易的平均响应时间如下表：（单位：秒）ColorScale交易最小平均最大1Audit_Transaction19.481162.12207.6271AutoUW_Transaction0.013.00149.4941ClaimRegister_Transaction75.599143.641163.9781Confirm_Transaction1.13151.42794.5851CTDetail_Transaction37.25765.967148.3341EdorNoscanAppInput_Transaction16.50479.919169.2391EndCase_Transaction11.8846.54685.6581GeneralQuery_Transaction0.15211.01735.3211IndividualQuery_Transaction0.87514