性能测试详细测试方案
前言
平台XX项目系统已经成功发布，依据项目的规划，未来势必会出现业务系统中信息大量增长的态势。
随着业务系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：每天大数据量的“冲击”，系统能稳定在什么样的性能水平，面临行业公司业务增加时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。
1第一章XXX系统性能测试概述
1.1 被测系统定义
XXX系统作为本次测试的被测系统（注：以下所有针对被测系统地描述均为针对XXX系统进行的），XXX系统是由平台开发的一款物流应用软件，后台应用了Oracle11g数据库，该系统包括主要功能有:XXX等。在该系统中都存在多用户操作，大数据量操作以及日报、周报、年报的统计，在本次测试中，将针对这些多用户操作，大数据量的查询、统计功能进行如预期性能、用户并发、大数据量、疲劳强度和负载等方面的性能测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统的吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数。
1.1.1 功能简介
主要功能上面已提到，由于本文档主要专注于性能在这里功能不再作为重点讲述。
1.1.2 性能测试指标
本次测试是针对XXX系统进行的全面性能测试，主要需要获得如下的测试指标。
1、应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。
2、应用系统的吞吐量：即在一次事务中网络内完成的数据量的总和，吞吐量指标反映的是服务器承受的压力。事务是用户某一步或几步操作的集合。
3、应用系统的吞吐率：即应用系统在单位时间内完成的数据量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的数据量。
4、TPS：每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。
5、点击率：每秒钟用户向服务器提交的HTTP请求数。
5、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户端请求发起，到服务器端应答返回所需要的时间，包括网络传输时间和服务器处理时间。
6、应用系统的可靠性：即在连续工作时间状态下，系统能够正常运行的时间，即在连续工作时间段内没有出错信息。
1.2 系统结构与流程
XXX系统在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样的，交易流程也完全一致的。不过，由于硬件条件的限制，本次性能测试的硬件平台跟实际生产环境略有不同。
1.2.1 系统总体结构
描述本系统的总体结构，包括：硬件组织体系结构、网络组织体系结构、软件组织体系结构和功能模块的组织体系结构。
1.2.2 功能模块
本次性能测试中各类操作都是由若干功能模块组成的，每个功能都根据其执行特点分成了若干操作步骤，每个步骤就是一个功能点（即功能模块），本次性能测试主要涉及的功能模块以及所属操作如下表
|
步骤 |
说明 |
备注：Action、平均响应时间（S） |
|
1 |
打开主界面 |
Action：访问首页(FWSY)；5 |
|
2 |
输入用户名密码（需进行参数化），登录系统，进入首页 |
Action：登陆(DL)；5 |
|
3 |
点击“我的通知”标签，进入通知列表页面 |
Action：进入通知列表(JRTZLB)；5 |
|
4 |
在我的通知上点击已收通知标题链接，查看通知（重要通知） |
Action：查看通知(CKTZ)；5 |
|
5 |
在我的通知上点击已收通知的“回复”链接，进入回复界面 |
Action：进入回复界面(JRHFJM)；5 |
|
6 |
在通知回复界面上填写回复内容并提交 |
Action：回复通知(HFTZ)；5 |
1.2.3 关键点描述（KP）
本次性能测试的关键点，就是查看XXX系统在不同用户数量（并发）压力下的表现和大数据量操作时系统的性能状态，即：支持的并发用户数目和并发用户发送频率，以及在较大压力下，系统的处理能力以及CPU、数据库I/O和内存的使用情况，并找出相应的性能瓶颈。
1.3 性能测试环境
本次性能测试环境与真实运行环境硬件和网络环境有所不同，是真实环境的缩小，数据库是真实环境数据库的一个复制（或缩小），本系统采用标准的CS结构，客户端通过前台安装访问应用系统。
其中具体的硬件和网络环境如下：
中间件服务器：Weblogic9
操作系统：Windows7/Linux
网络环境： LAN（10M）
数据库：Oracle 11g RAC
客户端： PC （Windows）
网络拓扑和结构图如下：
2第二章 性能测试
从广泛意义上讲性能测试包括：预期性能测试、用户并发测试、大数据量测试、疲劳强度测试、负载能力测试等。在不同应用系统的性能测试中，需要根据应用系统的特点和测试目的的不同来选择具体的测试方案，本次XXX系统的性能测试主要是采用通常的压力测试模式来执行的，即：逐步增加压力，查看应用系统在各种压力状况下的性能表现。
在本次性能测试中，将使用性能测试工具LoadRunner11.0对被测试项目的各模块进行监控，判断XX系统各模块的性能表现，并帮助项目人员分析系统各个操作的性能瓶颈点。
2.1 预期性能测试
2.1.1 预期性能概述
通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。通俗地说，这种方法就是要在特定的运行条件下验证系统的能力状态。
2.1.2 测试特点
1、主要目的是验证系统是否有系统宣称具有的能力。
2、要事先了解被测试系统经典场景，并具有确定的性能目标。
3、要求在已经确定的环境下运行。
2.2 用户并发测试
2.2.1 并发测试概述
并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。
2.2.2 测试目的
1、主要目的是发现系统中可能隐藏的并发访问时的问题。
2、主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。
3、可以在开发的各个阶段使用需要相关的测试工具的配合和支持。
2.3 大数据量测试
2.3.1 大数据量测试概述
测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。大数据量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
2.3.2 测试目的
1、主要目的是确定软件发生故障的极限。
2、确定测试对象在给定时间内能够持续处理的最大负载或工作量。
3、可以在开发的各个阶段使用需要相关的测试工具的配合和支持。
2.4 疲劳强度测试
2.4.1疲劳强度测试概述
即压力测试，测试系统在一定饱和状态下，例如cpu、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。
2.4.1测试目的
1、主要目的是检查系统处于压力性能下时，应用的表现。
2、一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。
3、一般用于测试系统的稳定性。
通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或都某种资源已经达到饱和状态。
1、主要目的是找到系统处理能力的极限。
2、需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。
3、一般用来了解系统的性能容量，或是配合性能调优来使用。
详情参见《XX项目测试用例.doc》的“性能测试”章节
在本次性能测试中，各类测试指标包括测试中应该达到的某些性能指标，这些性能指标均是来自应用系统设计开发时遵循的业务需求，当某个测试的某一类指标已经超出了业务需求的要求范围，则测试已经达到目的，即可终止性能测试。
2.7.1.1 应用软件级别的测试指标：
ü CPU的利用率小于40%
ü 内存占用小于80%
ü Processor queue length 小于2
ü Response time 小于 1s
ü 吞吐量throughtput大于90%
ü 业务执行的平均响应时间（期望值：<15s）
ü 不同并发用户数的状况下的记录上述值
2.7.1.2 网络级别的测试指标：
ü 吞吐量：单位时间内网络传输数据量
ü 冲突率：在以太网上监测到的每秒冲突数
2.7.1.3 操作系统级别的测试指标：
ü 进程/线程交换率：进程和线程之间每秒交换次数
ü CPU利用率：即CPU占用率（％）
ü 系统CPU利用率：系统的CPU占用率（％）
ü 用户CPU利用率：用户模式下的CPU占用率（％）
ü 磁盘交换率：磁盘交换速率
ü 中断速率：CPU每秒处理的中断数
2.7.1.4 数据库级别的测试指标：
ü 数据库I/O的流量大小
ü 数据库锁资源的使用数量
ü 数据库的并发连接数：客户端的最大连接数
2.7.2.1 案例数据：满负荷压力
根据测试系统的硬件条件，选择满负荷的压力，在系统的资源使用基本维持在90%左右的状况下，测试天威宽带业务管理系统的处理能力。
测试数据库需具备与真实环境成一定比例或基本一致的数据
记录可扩展性测试中的测试结果及其系统的运行状况。除了记录测试指标以外，应该结合测试实时记录系统各个层次的资源和参数。主要包括：
ü 硬件环境资源
ü 服务器操作系统参数
ü 网络相关参数
ü 数据库相关参数：具体数据库参数有所不同，结合各个数据库独有的特点记录
3 第三章测试过程及结果描述
在测试数据准备完备以后，测试将进行。记录每次测试的结果数据，分析测试结果对系统进行全面评估。
示例：
|
步骤 |
说明 |
备注：Action、平均响应时间（S） |
|
1 |
打开主界面 |
Action：访问首页(FWSY)；5 |
|
2 |
输入用户名密码（需进行参数化），登录系统，进入首页 |
Action：登陆(DL)；5 |
|
3 |
点击“我的通知”标签，进入通知列表页面 |
Action：进入通知列表(JRTZLB)；5 |
|
4 |
在我的通知上点击已收通知标题链接，查看通知（重要通知） |
Action：查看通知(CKTZ)；5 |
|
5 |
在我的通知上点击已收通知的“回复”链接，进入回复界面 |
Action：进入回复界面(JRHFJM)；5 |
|
6 |
在通知回复界面上填写回复内容并提交 |
Action：回复通知(HFTZ)；5 |
测试中，使用逐步加压的模式，测试运行场景安排如下：
每隔2秒增加1个用户连接，最多增加到100个用户，查看并记录运行情况
每隔2秒增加2个用户连接，最多增加到200个用户，查看并记录运行情况
每隔2秒增加1个用户连接，最多增加到300个用户，查看并记录运行情况
每隔3秒增加1个用户连接，最多增加到400个用户，查看并记录运行情况
每个场景都包括：用户登录-业务操作-业务完成-退出系统，所有用例都按以上场景进行测试，由于pc性能限制，为了更准确模拟现场环境，将运行的所有脚本部署在LoadRunner终端上，主要目的就是检查在不同的压力的情况下，业务系统的性能表现。
测试结束标准一般依据以下原则：
1. 所有计划的测试已经完成；
2. 所有计划收集的性能数据已经获得；
3. 所有性能瓶颈得到改善并达到设计要求。
执行每个场景时需要记录以下相应的数据
1. APP服务器主机上的CPU利用率：
2. 在数据库（Oracle）服务器上主机上的CPU利用率：
3. IO和CPU利用率对照表如下：
4. APP服务器监控的网络流量：
5. DB服务器上监控的网络流量：
6. 运行的并发用户数目：
7. 测试中完成各操作的平均响应时间：（单位：秒）
8. 测试中每秒的点击率如下：
9. 交易的吞吐率（每秒处理数据量）：
4第四章 测试报告
在XXX系统的性能测试结束后，根据测试结果，将生成测试报告。
对应的文档名称如下：
ü 《XX项目性能测试报告》
转载自原文链接, 如需删除请联系管理员。
原文链接：性能测试详细测试方案，转载请注明来源！