一、概述
　　本文目的是提供性能测试分析人员在测试需求分析阶段提供技术指导作用，指导其对采集的业务数据进行整理并转换为合理的项目性能需求指标，并提供测试执行人员在执行过程中以此为目标。
　　二、名词解释
　　·  业务模型：描述业务系统在运营过程中核心交易配比（通常采集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%