性能测试项目名称
修订记录
目录
介绍 4
1 目的... 4
2 总览... 4
表 1.1 – 软件性能测试计划内容... 4
3 范围... 4
性能测试方法... 5
4 负载测试流程... 5
4.1 系统分析... 5
4.1.1 创建虚拟用户脚本... 5
4.1.2 创建负载测试场景... 5
4.1.3 测试用例执行和性能监控... 5
4.1.4 分析结果... 5
5 远景目标和近期目标... 5
业务流程&测试用例... 5
6 业务流程... 6
6.1.1 高容量/高负载 流程... 6
6.1.2 低容量/低负载 流程... 6
7 数据准备... 6
8 LoadRunner 事务(Transactions)... 6
9 LoadRunner 脚本(Scripts)... 6
10 Load Runner 场景(Scenarios)... 6
11 LoadRunner 监控器(Monitors)... 7
11.1 具体的监控器... 7
11.2 具体的监控器... 7
负载测试需求... 7
12 Checklist 7
13 测试入口标准... 8
14 测试结束标准... 8
应用程序环境... 8
15 应用程序软件环境... 8
16 应用程序硬件环境... 8
17 LoadRunner 环境... 8
测试结果和版本管理... 9
18 缺陷/版本 管理... 9
19 发现... 9
20 详细测试结果... 9
20.1 场景1. 9
介绍
1 目的
目的介绍
2 总览
本文档表格中第二部分到第七部分为重要部分。
表 1.1 – 软件性能测试计划内容
3 范围
计划适用范围.
l 软件需求规格说明书(Software Requirements Specifications - SRS)
l 软件详细设计文档(Software Detail Design - SDD)
l 软件测试计划 (SoftWare Test Plan - STP)
l White Paper: Load Testing to Predict Web Performance. Mercury Interactive Corp.
性能测试方法
采用何种性能测试的方法。取决于业务需求、开发周期和应用程序的生命周期,对于特定的应用,需要选择相应的测试方法。.
4 负载测试流程
4.1 系统分析
分析业务流程
4.1.1 创建虚拟用户脚本
如何开发脚本
4.1.2 创建负载测试场景
创建压力负载场景
4.1.3 测试用例执行和性能监控
如何采集性能数据。
4.1.4 分析结果
分析性能测试数据。
5 远景目标和近期目标
需求定义
业务流程&测试用例
下边介绍在进行性能测试过程中每个阶段如何做。
6 业务流程
6.1.1 高容量/高负载 流程
创建以下业务流程给服务器和数据库施加更大的压力。
6.1.2 低容量/低负载 流程
以下业务流程只是仅仅用于创建小百分比的并发量,同样也可以创建用户并发量大百分比的压力测试。
7 数据准备
性能测试前进行数据准备。要开始收集、处理有关业务数据,为系统进入性能测试运行做好数据准备,本部分主要描述如何进行数据准备,数据的来源是什么。
8 LoadRunner 事务(Transactions)
执行的一个功能或一系列的活动就可以是一事务,具体情况,要依照你自己要测试的目标 是什么,从而明确你自己定义的事务指的是什么, 本部分具体明确什么是事务。
9 LoadRunner 脚本(Scripts)
本部分定义在性能测试中的脚本。这些脚本将模拟系统真实的运行情况。
10 Load Runner 场景(Scenarios)
场景是一个执行单位,可以通过 场景来模拟一个工作负载,模拟真实的世界操作。本部分具体解释清楚什么是场景。
11 LoadRunner 监控器(Monitors)
LoadRunner内含实时监测器,在负载测试期间,您都可以查看应用系统的运作 性能。本部分主要解释什么是监控器,并通过下表把要在性能测试中用到的监控器列举出来。
11.1 具体的监控器
监控具体的技术器指标.
11.2 具体的监控器
· Run Time Resources: The total memory in use within the Java Virtual Machine. The following data points may be monitored.
负载测试需求
12 Checklist
场景执行过程中需要确认:
l 数据库更新情况,基础数据是否完整
l 脚本所用到的数据是否准备完毕.
l 每个脚本中的run-time settings设置是否正确 (think-time, logging, pacing, iterations).
l 所有的 LoadRunner monitors 是否配置正确.
l load injectors 配置是否正确以及LoadRunner Controller 能否连接到injectors.
13 测试入口标准
性能测试一旦开始:
l 系统测试完毕并认为系统稳定的情况下
l 补充
14 测试结束标准
性能测试一旦成功完成:
l 性能测试目标已经达到
l 性能测试结果经过项目团队认可
l 所有在压力测试中发现的问题被成功解决.
应用程序环境
本部分定义被测试应用配置情况,包含软件和硬件配置。
15 应用程序软件环境
下边表格为软件配置资源.
16 应用程序硬件环境
下边表格为硬件配置资源.
17 LoadRunner 环境
本部分描述 LoadRunner在进行压力测试中的测试环境配置。下表描述Controller以及Injector 配置。包括Injector每台机器配置多少用户。
测试结果和版本管理
评估性能测试结果是在压力测试中最重要的步骤。LoadRunner Analysis用于评估性能测试的结果。很多可用的图表可以帮助你定位系统瓶颈。下边为具体在本次性能分析重要到的图表介绍。
具体性能分析图表:描述,分析该图表作用。
18 缺陷/版本 管理
所有的性能测试报告文档利用版本控制工具进行跟踪。
19 发现
发现的问题描述。
20 详细测试结果
性能场景执行两次,第一次是小并发用户量的测试,第二次是在高负荷情况下的测试 ,利用长时间运行的方法。
20.1 场景1
场景描述.
表 7.4.1: 事务摘要
第二篇:XXX实际项目性能测试方案模板(修订)
XXX项目
性能测试方案
修订记录
目 录
1 项目简介.... 1
1.1 测试目标... 1
1.2 测试范围... 1
1.3 性能测试指标要求... 2
1.3.1 交易吞吐量... 2
1.3.2 交易响应时间... 2
1.3.3 并发交易成功率... 2
1.3.4 资源使用指标... 2
2 测试环境.... 3
2.1 网络拓扑图... 3
2.2 软硬件配置... 3
3 测试方案.... 4
3.1 交易选择... 4
3.2 测试数据... 4
3.2.1 参数数据... 4
3.2.2 存量数据... 5
3.3 资源监控指标... 5
3.3.1 台式机... 5
3.3.2 服务器... 5
3.4 测试脚本编写与调试... 5
3.5 测试场景设计... 5
3.5.1 典型交易基准测试... 5
3.5.2 典型交易常规并发测试... 6
3.5.3 稳定性测试... 7
3.6 测试场景执行与数据收集... 8
3.7 性能优化与回归... 8
4 测试实施情况.... 9
4.1 测试时间和地点... 9
4.2 参加测试人员... 9
4.3 测试工具... 9
4.4 性能测试计划进度安排... 10
5 专业术语.... 11
1 项目简介
1.1 测试目标
通过对XXXXXX系统的性能测试实施,在测试范围内可以达到如下目的:
Ø 了解XXX系统在各种业务场景下的性能表现;
Ø 了解XXX业务系统的稳定性;
Ø 通过各种业务场景的测试实施,为系统调优提供数据参考;
Ø 通过性能测试发现系统瓶颈,并进行优化。
Ø 预估系统的业务容量
1.2 测试范围
XXX系统说明以及系统业务介绍和需要测试的业务模块,业务逻辑图如下:
本公司服务器环境以及架构图
为了真实反映XXXX系统自身的处理能力,本次测试范围只包(XXX服务器系统和Web服务系统、数据库服务器系统)。
1.3 性能测试指标要求
本次性能测试需要测试的性能指标包括:
1、交易吞吐量:后台主机每秒能够处理的交易笔数(TPS)
2、交易响应时间(3-5-8秒 )
3、并发交易成功率99.999%
4、资源使用指标:前置和核心系统各服务器CPU(80%)、内存占用率(80%)、Spotlighton数据库;LoadRunner压力负载机CPU占用率、内存占用率
1.3.1 交易吞吐量
根据统计数据,XXX系统当前生产环境高峰日交易总量为【】万笔。根据二八原则(80%的交易量发生在20%的时间段内),当前生产环境对主机的交易吞吐量指标要求为:
TPS_1 ≥ 【】 * 80% / (24 * 20% * 3600) = 【】 笔/秒
为获取系统主机的最大处理能力,在本次性能测试中可通过不断加压,让数据系统主机CPU利用率达到【】%,记录此时的TPS值,作为新主机处理能力的一个参考值。
1.3.2 交易响应时间
本次性能测试中的交易响应时间是指由性能测试工具记录和进行统计分析的、系统处理交易的响应时间,用一定时间段内的统计平均值ART来表示。
本次性能测试中,对所有交易的ART指标要求为:
ART ≤ 5 秒
1.3.3 并发交易成功率
指测试结束时成功交易数占总交易数的比率。交易成功率越高,系统越稳定。
对典型交易的场景测试,要求其并发交易成功率 ≥ 99.999% 。
1.3.4 资源使用指标
在正常的并发测试和批处理测试中,核心系统服务器主机的资源使用指标要求:
CPU使用率 ≤ 80%
内存使用率 ≤ 80%
2 测试环境
2.1 网络拓扑图
压力产生器(Load Generator)连接服务端系统,客户端发送请求到服务端,服务端响应并处理后将结果返回到客户端。本次测试的网络环境为1000Mb ps局域网,使用独立的网段,忽略防火墙网络延迟,交易请求以及结果返回的网络传输时间可以忽略不计。
简图如下:
公司网络传输拓扑结构图
2.2 软硬件配置
性能测试环境的硬件和软件配置如下表所示:
3 测试方案
3.1 交易选择
通过业务数据统计和业务模型分析,最终选择的典型交易如下表所示:
3.2 测试数据
3.2.1 参数数据
为了尽可能的模拟系统生产环境,所以JVM的初始堆栈大小、WEB服务器的线程池、数据库连接池等系统配置,统一参考WAP生产环境配置。
3.2.2 存量数据
存量数据来自XXXX实际生产系统,对生产数据进行脱敏处理,并导入测试环境核心系统数据库。基础数据的数据规模。
3.3 资源监控指标
本次性能测试通过LoadRunner进行的资源监控包括:操作系统UNIX、AIX资源监控。定义的监控指标如下:
3.3.1 台式机
Ø 系统CPU使用率 80%
Ø 系统内存使用率 80%
Ø 系统IO使用率 80%
监控的服务器包括WEB服务器。
3.3.2 服务器
Ø 系统CPU使用率 80%
Ø 系统内存使用率 80%
Ø 系统IO使用率 80%
监控的服务器包括数据库服务器。
3.4 测试脚本编写与调试
3.5 测试场景设计
3.5.1 典型交易基准测试
典型交易基准测试是单交易单用户测试,目的是对选择的每个典型交易在无压力情况下(无额外进程运行并占用系统资源)情况下,获取系统处理单笔交易的耗时,为下一步模拟多个用户、混合交易的性能测试提供一个基本数据参考。
基准测试要达到以下目标:
l 验证测试脚本及测试参数的正确性。
l 获取系统处理单笔交易性能数据,主要是单笔交易平均响应时间。
3.5.1.1 测试方法
使用一个Vuser,分别运行每个典型交易的脚本,设置脚本的迭代次数1次,验证所有脚本是否运行正确、所有交易事务是否成功返回,并获取每个典型交易的平均交易响应时间ART。
3.5.1.2 测试场景-基准测试(测试单业务单人测试获取典型交易的平均响应时间)
3.5.2 典型交易常规并发测试
单交易多用户并发测试对每个典型交易通过多个用户多次迭代执行,获得该交易在并发用户情况下的平均响应时间以及每秒响应交易数,同时检验服务器端对每个典型交易多个并发用户的处理能力。
3.5.2.1 测试方法
对单交易多用户并发测试:使用手动场景,设置并发用户数35、45,持续时间15分钟,无思考时间,无迭代延迟。测试每个交易在不同压力下的应时间以及每秒响应交易数量。从而发现交易的单点瓶颈,并针对问题进行优化。
3.5.2.2 测试场景-用户并发测试(针对问题进行优化)
3.5.3 稳定性测试
通过生产系统的总用户数,模拟生产环境,考察在模拟生产环境的情况下是否会出现宕机、响应时间变长、交易成功率下降、内存使用率持续上升等异常现象。
3.5.3.1 测试方法
通过基准测试得出的交易响应时间,按照响应时间设置交易占比。然后不断施加压力,观测系统的CPU使用率。来判断系统所能承受的极限压力。再根据此压力的并发数量,让场景持续运行时间8小时,各交易无思考时间、无迭代延迟时间。获取核心主机TPS值、各典型交易的平均响应时间ART和性能监控数据。
3.5.3.2 测试场景-稳定性测试
在系统资源使用到达极限时长时间压力测试的场景
3.6 测试场景执行与数据收集
性能测试执行过程中应收集的测试场景执行结果数据包括:
l LoadRunner的Controller中的场景执行结果数据;
l LoadRunner的资源监控数据;
l 核心主机记录的资源(CPU、MEM)监控数据文件。
3.7 性能优化与回归
4 测试实施情况
4.1 测试时间和地点
时间:XXXX年 XX月XX 日 — XXXX年 XX 月 XX 日
地点:XXXXXXXXXXXXXXX
4.2 参加测试人员
参加本次核心系统主机升级性能测试的人员包括:
- 项目经理: XXXXXX
- 测试负责人: XXXXXX
- 测试人员:XXXXXX
- 运维人员: XXXXX、XXXX
4.3 测试工具
注意:Loadrunnet客户方是否具备lisence,如具备正版lisence更佳。其他工具为开源或免费软件。
4.4 性能测试计划进度安排
在实际测试过程中,由于测试环境有时不太稳定、和功能测试共用测试环境以及测试场景执行出错需重复测试等原因,实际进度可能会稍有推迟。