性能测试需求指标分析方法

 

一、            概述

本文目的是提供性能测试分析人员在测试需求分析阶段提供技术指导作用，指导其对采集的业务数据进行整理并转换为合理的项目性能需求指标，并提供测试执行人员在执行过程中以此为目标。

二、            名词解释

Ø  业务模型：描述业务系统在运营过程中核心交易配比（通常采集80%业务量的交易作为参考）清晰描述每个交易在系统业务量中的比例

Ø  测试模型：在测试执行时采用的交易配比模型。

三、            数据源分析

Ø  线上业务数据

Ø  运维数情况数据

Ø  未来业务增长数据

 

四、            输出描述

1.       测试需求分析报告中要清晰描述本次测试要进行哪几种类型的测试。例如容量测试、稳定性测试、异常测试、速度测试、负载测试等

2.       测试需求分析报告中要清晰描述测试模型情况，测试模型和业务模型是有区别的，业务模型是从线上业务实际情况统计得来的，统计的数据是真实的线上数据，因此业务模型是线上交易分布的真实展现。测试模型是以业务模型为依据并结合测试需要对业务模型进行调整。例如需要调高某一类交易所占比例来实现测试目的。

3.        测试需求分析报告中要清晰描述测试指标，测试指标是用来评价一个系统是否满足性能需求的标准，测试指标包括系统响应性、系统可用性、系统资源占用率。

五、            测试类型选择

1.       常见性能测试类型

测试类型	测试目的	操作说明
基准测试(speed Testing)	这种类型的性能测试目的是获得每个用户活动的响应时间每个脚本通要对结果进行校验保证返回结果满足预期。	基准测试通常是是首先被执行的性能测试，一些配置和安装导致的问题在这里可以被识别 ，基准测试是执行一个用户，这种测试反映单用户执行时候资源开销情况（IO，CPU，数据转出和数据库访问情况）
单交易负载测试(Contention Testing)	这种类型的性能测试目的通过小量用户并发争夺资源导致的性能瓶颈（例如锁、内存泄漏等）每次执行识别每个活动的最大、最小、平均响应时间，用来确认在多用户并发下数据和流程是相互独立	以系统预期最大并发用户数做为上限对核心交易进行的性能测试。在压力时间内的交易数量应接近或超过系统全天的交易数量。
容量测试 （ Volume Testing)	这种类型性能测试是检查系统所能处理的最大业务量。测试过程中采用梯度加压的方式，不断增加并发用户数量，监控响应时间和系统资源变化情况	当响应时间曲线出现拐点是，这是就是系统最大的容量。
压力测试/负载测试(Stress / Overload Testing)	这种类型性能测试目的是检查系统能够支持最大用户并发量	测试过程采用梯度加压的方法，不断增加并发用户数量，监控事务响应时间和状态，资源情况当出现连接数变平，事务出现超时或错误时，可确定系统衰退点。
稳定性测试（Endurance "Soak" "Longevity" Tests）	这种类型的性能测试是确认系统持续运行的可靠性，最少要运行24小时，用接近系统容量值的并发用户数持续执行事务。 因为长时间的测试通常 会占用大量磁盘空间，所以这种测试过程中需要对周期性临时数据，如日志数据要进行及时清理。
异常测试用例	测试在一定并发量下，操作功能上有互斥关系或有锁机制的场景，检查是否会导致系统性能问题。
	测试在正常业务量情况下持续运行24小时或48、72小时检查系统持续的可靠性	模型选择正常业务日的测试模型，并发量为容量测试中性能点平发量的80%

2、被测试系统背景分类

编号	系统背景	测试类型选择办法
A	全新系统-该类系统是业务和架构上都是个全新的系统。	这类系统通常要做全模型的性能测试包括稳定性、容量、异常等等测试 这类系统在定做性能需求分析阶段时需要对系统的涉众调研来确定业务模型和性能指标。
B	新架构的系统-这种系统通常是在线上已经在运营，新系统采用一种全新的架构来替换原有的线上系统，在业务上支持原有系统的全部业务并无业务扩从。	这类系统在做性能测试时候同样需要考虑进行全面的性能测试类型。 与A类系统的性能测试区别就是性能指标数据的采集来源方式不同，需要对已有系统的运营数据进行采集分析。
C	系统新增加模块-这种需求是针对以后系统增加新的业务或功能模块，架构与原系统基本统一情况下	这种系统测试在测试类型选择上要具有针对性的选择，测试范围可根据系统影响进行调整。
D	原有系统bug修改或功能调整，这种系统修改范围较小，对系统整体结构影响不大。	根据修改的影响做选择性的性能回归测试。
E	支撑系统补丁或版本升级（例如操作系统补丁包，操作系统升级，数据库升级等）	这种系统在做性能测试更关心系统稳定性能，其他类型可选。
F	硬件系统升级测试	这种类型的测试需要回归系统容量测试，检查硬件升级对容量的提升情况。

3、系统与测试类型MAP

	基准测试	单交易负载测试	容量测试	压力测试/负载测试	稳定性测试	异常测试用例
A系统	必选	必选	必选	必选	必选	可选
B系统	必选	必选	必选	必选	必选	可选
C系统	必选 (影响部分)	必选 (影响部分)	必选	可选	可选	可选
D系统	必选 (影响部分)	必选 (影响部分)	可选	可选	可选	可选
E系统	可选	可选	可选	可选	必选	可选
F系统	可选	可选	必选	可选	必选	可选

六、            设计测试模型

1.       业务模型的设计

一个系统的业务模型是通过业务调研获得，业务模型的正确性反映在两个方面首先业务选择的正确性和业务比例的正确性。

首先业务选择，一个系统可能支持几百个业务活动（也有叫做交易）但是只有少数的业务活动非常频繁，占总业务量的80%以上，那么在性能测试时只需关心这些占了大部分业务量的少量业务上。

其次业务比例，如何精确统计业务的数量是关键问题，针对一个全新的系统可能要通过对使用系统的涉众进行调研，搞清楚他们群体数量，操作行为周期。在通过组合这些数据确定在常规业务日中各种业务占总业务的比率，同时也要考虑特殊交易日的情况，

例如某一个商务活动或周期性的业务结算日等都是特殊交易日，在特殊交易日时某一类业务量可能突然增高很多那么在常规业务日的业务比例就不再合适，这点在业务模型上要进行区分。常规业务模型用来测试系统容量，特殊日业务模型要单独做压力负载测试场景。

对于已上线运营的系统做业务模型的调研相对简单，不再需要去调研那么多的涉众，只需与运营维护部门进行协调，由他们协助测试需求调研人员提取系统中的历史数据就可以，那么在数据选择上要有些规则，要选取相对长时期的数据比如几个月，有条件的选取一年数据，取一年中每月平均业务量，选取年度高峰月业务数据，选取月度高峰日业务数据。

 

2.       测试模型

业务模型是根据系统运营真实数据得来的，真实反映系统运营的业务状况。测试模型是以业务模型为基础根据测试需求不同对业务模型调整或不调整纳入到测试场景中直接使用。

七、            性能指标分析方法

1.     性能测试指标

业务处理能力：每秒处理交易数量

业务响应性： 每种业务执行响应时间

业务正确率：执行过程中通过事务占总业务比例

系统资源指标：系统资源占用率

 

2.     业务处理能力

业务处理能力是评测系统每秒所能处理的最大业务量，单位是Transaction/sec

计算每秒处理业务量需要两个关键数据，一个是在指定时间内的指定业务量，二是指定的时间段。如何选择这两个数据是非常关键。通常业务调研阶段给的每天平均业务量或者某高峰日最大业务量。如何转换数据为每秒业务量，通常有算法：

28规则，这是比较常用的计算方法

例如：一个系统日交易高峰某100000笔交易，系统每天运营8个小时

那么计算规则是 100000笔*80% / (8*3600*20%) =14笔/秒