软件性能测试报告模板.pdf

该【软件性能测试报告模板 】是由【青山代下】上传分享，文档一共【19】页，该文档可以免费在线阅读，需要了解更多关于【软件性能测试报告模板 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。:..(KP):..,XXXX的XXXXXXXX核心业务系统(以下简称新业务系统)已先后在XXXX、成功上线,从而公司的XXXX信息管理逐步走上了集中管控的道路。后续,xxx等34家分公司的XXXX信息也将分布进入业务系统,从而将会势必出现新业务系统中信息大量增长的态势。随着新业务系统在生产状态下日趋稳定、成熟,系统的性能问题也逐步成为了我们关注的焦点:XXXX大数据量的“冲击”,在XXXX信息进入时,系统能稳定在什么样的性能水平,面临公司业务冲刺时,系统能否经受住“考验”,这些问题需要通过一个完整的性能测试来给出答案。本《性能测试规划书》即是基于上述考虑,参考科学的性能测试方法而撰写的,用以指导即将进行的XXXXXXXX核心业务系统的性能测试。(注:以下所有针对被测系统地描述均为针对XXXXXXXX核心业务系统进行的),该业务系统的主要功能包括:xxxxx在本次测试中,将针对上述的功能进行压力测试,检查并评估在模拟环境中,系统对负载的承受能力,在不同的用户连接情况下,系统地吞吐能力和响应能力,以及在预计的数据容量中,系统能够容忍的最大用户数,:..功能简介xxxxxx主要功能如下:,主要需要获得如下的测试指标。1、系统的响应能力:即在各种负载压力情况下,系统的响应时间,也就是从客户端交易发起,到服务器端交易应答返回所需要的时间,包括网络传输时间和服务器处理时间。2、应用系统的吞吐率:即应用系统在单位时间内完成的交易量,也就是在单位时间内,应用系统针对不同的负载压力,所能完成的交易数量。3、应用系统的负载能力:即系统所能容忍的最大用户数量,也就是在正常的响应时间中,系统能够支持的最多的客户端的数量。,交易流程也完全一致的。不过,由于硬件条件的限制,本次性能测试的硬件平台跟实际生产环境略有不同。,包括:硬件组织体系结构、网络组织体系结构、软件组织体系结构和功能模块的组织体系结构。,每个交易都根据其执行特点分成了若干操作步骤,每个步骤就是一个功能点(即功能模块),在xxx业务系统中,各种交易及其包含的功能模块关系如下::...,选择的各类交易的业务流程如下:::,即:输入查询条件后获取查询结果,因此在本次性能测试中只作为一个事物处理,交易流程图略。(KP)本次性能测试的关键点,就是查看xxxx业务系统在并发压力下的表现,即:支持的并发用户数目和并发用户发送频率,以及在较大压力下,系统的交易处理能力,并找出各类交易的性能瓶颈。,都运行在同样的硬件和网络环境中,数据库是真实环境数据库的一个复制(或缩小),本系统采用标准的CS结构,客户端都是通过浏览器访问应用系统。其中具体的硬件和网络环境如下:服务器设备:IBM570(DBserver),IBM690(APserver)操作系统:AIX网络环境:LAN(10M):..Oracle客户端:PC(Windows)网络拓扑和结构图如下:2第二章性能测试从广泛意义上讲性能测试包括:压力测试、稳定性测试、负载能力测试和可扩展性测试等。在不同应用系统的性能测试中,需要根据应用系统的特点和测试目的的不同来选择具体的测试方案,本次XXXXXXXX核心业务系统的性能测试主要是采用通常的压力测试模式来执行的,即:逐步增加压力,查看应用系统在各种压力状况小的性能表现。在本次性能测试中,也将使用美科利的新产品性能测试诊断工具(Diagnostic)对测试应用的各层进行监控,判断J2EE各层次的各类方法和类的调用使用时间和效率,并帮助开发人员分析J2EE应用的各类交易的性能瓶颈点。,压力测试主要是为了获取系统在较大压力状况下的性能表现而设计并实现的,压力测试主要是获取系统的性能瓶颈和系统的最大吞吐率。,检验系统的吞吐率。本系统的压力测试主要是针对xxxxx,检查在日间交易高峰时期,并发用户数较多的时候的处理能力等等。,检验现行的xxxx业务系统在各种压力交易量下的运行状况,检验系统地运行瓶颈,获取系统的处理能力等等。本次针对xxxx核心业务系统所进行的压力测试的测试目的为:2给出xxxx系统当前的性能状况2定位新业务系统性能瓶颈或潜在性能瓶颈2总结一套合理的、可操作的、适合公司现实情况的性能测试方案,:..(Mercury)的性能测试软件LoadRunner,对现行的xxxx业务系统进行脚本录制、测试回放、逐步加压和跟踪记录。测试过程中,由LoadRunner的管理平台调用各台测试前台,发起各种组合的交易请求,并跟踪记录服务器端的运行情况和返回给客户端的运行结果。使用的测试用例包括:联机处理交易和查询交易,其中联机交易测试试用的交易包括:xxxx查询类交易包括:xxxx测试用例列表包括:交易种类案例一案例二案例三案例四30%40%25%10%10%10%25%0%20%10%15%0%20%20%15%:..30%20%20%80%本次测试将依照如下场景进行测试:用户数功能模块业务操作交易配比(%)2004007001000针对每个测试案例,都将采用逐步加压和瞬间加压两种客户端连接方式进行,查看服务器端在客户端的连接数量变化过程中对应的处理能力,测试运行安排如下:·每隔2秒增加1个用户连接,最多增加到200个用户,查看并记录运行情况·每隔2秒增加2个用户连接,最多增加到200个用户,查看并记录运行情况·一次性连接10个用户,查看记录运行情况·一次性连接100个用户,,并发用户的启动信息如下:各类交易的交易相应时间(秒)ColorScale交易名称最小:..:..:..:..:..:可以看出随着测试的进行,交易相应时间逐渐增大,最终导致交易超时而失败。测试中,每秒的点击率如下:测试中每秒页面的下载速度如下:根据上面两组数据,即:每秒的点击率和每秒下载页面的速度,可以看出,在测试执行开始4分钟以后,核心业务系统用户登录的并发数量不断在增加,但是用户登录后的数据下载量却变化不大,这样将最终导致大量的用户登录因为交易处理超时而失败。:..第二次测试第二次测试调整了交易处理逻辑,大大减少了用户登录的操作数目,每个用户只执行一次用户登录,然后执行对应的交易处理,交易过程中不再执行用户登录操作。运行的并发用户数目如下图:在用户登录过程中,交易的平均响应时间如下图:从图中可以看出,随着并发用户数量的不断增加,所有的交易的平均响应时间都在加大,直到并发用户数不再增加,这时候所有的交易相应时间下降到一定的数值,并一直稳定在这个数值左右。在第二次测试中,各类交易的平均响应时间如下表:(单位:秒):..:..:..:..:..:图中最上方的两条曲线(即交易相应时间最慢的)分别是:xxx(Audit_Transaction)和xxx(ClaimRegister_Transaction),除了这两类交易,其他各类交易都是在测试初期执行较慢,随着用户登录完成以后,各类交易的平均响应时间都稳定在对应的数值上,并都保持在90秒以内。测试中每秒的点击率如下::..20分钟开始到35分钟,点击率下降的原因是部分查询交易循环600次已经成功结束,在35分钟左右重新启动,所有出现了途中点击率下滑的现象。下面的几幅图中,数据线下滑的原因相同。交易的吞吐率(每秒处理数据量)如下图:其中数据线下滑的原因同上。4第四章测试报告在xxxxx核心业务系统的性能测试过程中,将分别撰写测试计划和性能测试报告,其中测试计划将在测试开始之前完成,用以指导测试、并做好各个阶段的计划和任务分配工作,在测试结束之后,根据测试结果,将生成测试报告。两份对应的文档名称如下:ü《性能测试计划书》ü《性能测试报告》