性能测试分析报告模板.doc

PAGE 1 目录 TOC \o 1-3 \h \z \u 1. 引言 1 1.1. 编写目的 1 1.2. 项目背景 1 1.3. 定义 1 2. 测试背景 1 2.1. 测试重点关注指标 2 3. 测试执行策略 2 3.1. 测试方法 2 3.2. 测试脚本开发原则 2 3.3. 统一的测试设置原则： 2 3.4. 50个用户响应时间曲线图及点击率 3 4. 测试结论 3 测试分析报告 引言 编写目的 本文档通过对性能测试的描述，记录性能测试的结果并对该结果进行分析。供项目组开发成员和测试成员阅读。 项目背景 测试Xx项目所能承受的压力。 测试时间： 测试地点： 定义 响应时间：客户端从发送请求的那一刻起到收到应用程序响应的最后一个字节时止而不 得不等待的时间长短； 通过率: 在测试过程中，服务器处理的请求数与总的请求数之比；在测试中通过率不低 于98％视为系统运行正常； 思考时间: 用户在操作过程中的延时；在测试时分两种情况，取消think时间和不取消 think时间；当取消了think时间，测试过程更接近于并发访问；不取消thin k时间，测试过程更接近于真实的环境。 Total Throughput(bytes):在整个测试过程中，从服务器返回给客户端的所有字节数量 Total Hits : 按照客户端向后台发起了多少次用户计算,而不是按照用户的鼠标点击次数计算。如：在访问一次页面中，假设该页面包含5个图片，那么，用户只要点鼠标一次就可以访问该页面，而loadrunner视该访问的点击量为1+5=6次 测试背景 此次测试应用服务器为192.0.0.6的服务器上进行测试，数据库服务在192.0.0.7，访问通过192.0.0.15进行appache页面访问。 测试重点关注指标 测试系统的体系架构能否经得住大负荷的业务压力。 测试各业务模块中存在的系统瓶颈 重点考察了如下指标： 本地系统的响应能力：即在各种负载压力情况下，本地系统的响应时间，也就是从客户端交易发起，到服务器端的交易应答返回客户端所需要的全部时间，包括网络传输时间和服务器处理时间。 应用系统的吞吐率：即应用系统在单位时间内完成的交易量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的交易数量。 应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。 测试执行策略 测试方法 本次测试以性能测试为主，不涉及功能测试。 本次性能测试的主要方法是：使用性能测试软件工具LoadRunner，对被测系统进行脚本录制、测试回放、逐步加压和跟踪记录。测试过程中，由LoadRunner的管理平台调用各测试压力机器，发起各种组合的交易请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。 测试脚本开发原则 针对绩效系统的特点，选取用户使用频率最高、数据量大、使用人员最广泛、最具代表性的功能点进行性能测试 在开发测试脚本的过程中，我们遵循如下原则： 所有的测试脚本均增加检查点，确保交易的成功率指标的可靠性。 把“登录系统”操作放在vuser_init中，把“退出系统”操作放在vuser_end部分，保证脚本只登录和退出系统一次，其余操作就是反复执行真正的业务操作。 所有的测试脚本进行严格的关联增强，保证脚本执行时候的可靠性。防止脚本报告执行正确，而数据没有加入到数据库中的现象出现。 统一的测试设置原则： 每15秒钟增加10个用户，达到最大并发用户数后持续时间晚上执行一晚上，白天以小时为单位，然后按照每15秒钟减少10个用户的方式减压，直至测试结束。 所有Vu以线程的方式运行。 所有测试脚本执行的时候忽略思索时间think time，关闭Log。 对浏览器的模拟：每次循环以一个新的用户登录系统，并且清空Cache内容，每次浏览器对Web服务器静态页面的访问都要真正下载该页面，而不是从cache中获取。这样的设置保证了最严格的测试。也会使真实用户进行访问时所获得的性能体验要好于本测试报告中所报告的性能结果。 50个用户响应时间曲线图及点击率 颜色 事物 最小 平均 最大 点商户商品登记菜单 0.166 1.82 2.11 点商品修改查询 0.423 2.712 3.244 选择商品后的第一个确认 0.029 0.291 0.37 确认提交确认 0.17 1.099 1.437 初始操作 3.719 4.288 5.404 Hits 170 255.973 266.203 通过本次程序修改后加压，点击率在260对