1、性能测试计划阶段

测试计划阶段主要工作如下：

1、明确测试对象

2、定义测试目标

3、定义测试通过的标准

4、规划测试进度

5、规划测试参与人员（需求、开发、测试、运维和配置）

6、申请测试资源

7、风险控制

2、性能测试设计阶段

测试设计阶段主要工作如下：

1、测试用例设计

2、测试方法设计（单场景和混合场景）

3、定义监控指标，如测试性能指标以及性能计数器等

3、性能测试实施阶段

测试实施阶段工作如下：

1、测试环境搭建

2、测试过程文档定义以及配置

3、测试脚本开发、调试

4、测试数据准备

5、基准测试

        4、性能测试执行阶段

测试执行阶段工作如下：

1、执行测试用例模型，包括执行脚本和场景

2、测试过程监控，包括测试结果、记录性能指标和性能计数器的值

5、性能测试结果分析和报告阶段

<一>测试结果分析阶段工作如下：

1、根据测试结果、记录性能指标和性能计数器的值进行测试分析

2、根据性能测试目标规划，分析出系统存在的性能瓶颈，并给出优化建议

<二>测试报告的内容包括如下：

1、测试范围

2、测试执行以及参与人员

3、基准测试数据

4、测试执行的详细步骤（场景设计）

5、测试数据记录、性能指标以及性能计数器的值（有效的）

6、测试结果对比以及总结性评价

1、学习业务：

通过查看文档、手工操作系统对系统功能进行学习。

2、需求分析：

分析系统非功能需求（关注业务量、业务分布、用户规模、性能指标等信息），确定性能测试范围，了解性能指标。

一、系统非功能需求采集

（1）系统架构：物理架构（硬件及部署策略）和逻辑架构（系统的功能与服务），包括中间件产品与配置、数据库配置等，供我们搭建测试环境时进行参考。

（2）业务流程：业务量和业务分布。采集业务（分析出哪些业务纳入性能测试范围）并量化业务、业务扩展趋势（年增长率或者未来的业务量）、业务发生时段（业务高峰的发生时间和高峰业务量）、业务分布（各项业务之间的比例）。

（3）用户信息：在线用户数、活动用户数、业务分布。有些系统用户量特别大，会对系统造成性能瓶颈，可以通过分析活动用户数和业务分布来分析负载情况。

（4）系统是否与第三方系统有关，是否需要做挡板（Mock程序）。

（5）系统是否有归档机制：如果数据库有归档机制？？？，可以把一些无用或者过时的信息移到归档库，这样就减少当前数据库的数据，有利于提高系统性能。

（6）性能指标：吞吐率、响应时间、事务成功率，CPU、内存、磁盘、带宽使用阀值。

二、系统非功能需求分析

确定性能测试范围

1. 是否核心业务，是否要求严格的质量

2. 是否高频次的业务

3. 是否占用系统较多资源、或性能影响大的业务

4. 使用人数多还是少

5. 在线人数多还是少

6. 确定此功能的可测性、可验证性：功能是否可验证（是否牵连到第三方程序，是否需要做挡板Mock程序）。

明确性能指标
业务性能指标
1. 吞吐量（PV）、吞吐率（TPS等）
2. 响应时间（RT）/ 应用响应时间（ART）：3秒以内
3. 事务成功率：99%以上
4. 稳定波动正常范围

响应时间2-5-8原则
当用户在2秒以内得到响应时，会感觉系统的响应很快；
当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；
当用户在5-8秒以内得到响应时，会感觉系统的速度很慢，但是还可以接受；
而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟糕透了，或者认为系统已经失去响应。

硬件性能指标
CPU、内存、磁盘、网络带宽等。

系统硬件指标阀值

3、工作评估：

工作量分解，评估工作量，计划资源投入（即需要多少人力，多少工作日来完成性能测试工作）。

4、设计模型：

圈定测试范围后，把业务模型映射成测试模型。

业务模型：业务流程，系统在某个时间段内运行的业务种类及其业务占比，即哪个业务在什么时段在运行，业务量是多少？

测试模型：从业务模型中分析整理出来的需要进行测试的业务。对业务进行拆分对象，实现这个完整的功能包含哪些流程、环节。比如“购买商品”，具体的流程环节包括“登录->搜索商品->提交订单->支付订单->退出”。接着，明确业务占比，重要程度，目的在于：
（1）明确重点测试对象，安排测试优先级
（2）建模，混合场景中，虚拟用户资源分配，针对不同业务功能施加不同的负载。
（3）明确下“需求分析-指标分析”中相关业务功能所需基础数据及数据量问题，因为那块需求分析时可能只是大致估算下，评估指标是否合理，需要认真再分析下。

有些因为特殊原因无法测试（比如第三方非开源加密程序，测试程序无法模拟）的业务，测试模型中将会去掉这部分业务，或者设计替代等价方案，比如第三方程序可以使用挡板程序实现。

性能测试场景：参照用户使用习惯设计负载场景，比如哪些业务的测试脚本一起运行，哪些业务有先后顺序，运行多少并发用户等。比如WMS系统（仓库管理系统），WMS中都会有盘点功能，此功能就不应该与日常功能混合在一起，因为盘点通常都是一个月一次。所以组织测试场景时尽量要与实际业务情况一致。

5、编写计划

在文档中明确列出测试范围、人力投入、持续时间、工作内容、风险评估、风险应对策略等。

• 系统概述：简述系统使命、系统功能，用于给非专业人士了解系统是做什么的。

• 测试环境：生产环境、测试环境（服务器+负载机）的硬件架构和详细配置信息。

• 需求分析：需要测试的业务模型及其信息采集，性能指标的采集和确定。

• 测试策略：测试目的、测试执行的可行性分析、具体的测试手段及测试监控策略。

• 测试场景：如何组合业务场景进行性能测试。

• 测试准备：包括：测试工具的准备（负载工具、监控工具、文档管理工具）；测试脚本及测试程序准备；测试数据准备；测试环境准备。

• 时间计划：进行需求分析、测试策略后，就可以相对合理的估算测试资源及耗时。

• 测试组织架构：测试相关干系人，明确不同干系人的工作职责。

• 交付物清单：性能测试计划、性能测试脚本、性能缺陷报告、性能测试阶段性报告、性能测试报告（包括且不仅限于事务成功率、TPS、硬件性能指标等）。

• 系统风险：风险预测及风险评估（包括且不仅限于人员风险、软件风险、进度风险、变更风险、系统风险、数据风险、环境风险），并提出应对策略。

6、开发脚本

录制脚本或手动开发，添加固定计时器模拟ThinkTime，增加同步定时器模拟集合点，增加IF条件控制器判断逻辑，添加后置处理器获取参数。脚本注意做断言？？？，验证事务是否成功。
开发挡板程序，开发测试工具等。

7、测试环境准备

测试环境包括服务器和负载机。找出这些：

• 请求顺序、请求之间相互调用关系。

• 数据流向，数据是怎么走的，经过哪些组件、服务器等。

• 预测可能存在性能瓶颈的环节（组件、服务器等）。

• 明确应用类型IO型，还是CPU消耗性、内存消耗型->弄清楚重点监控对象。

• 关注应用是否采用多进程、多线程架构->多线程容易造成线程死锁、数据库死锁，数据不一致等。

• 是否使用集群/是否使用负载均衡。

准备被测系统的主数据（保证系统能够正常运行的数据，比如论坛版块、角色、用户等数据）与业务数据（运行业务产生的数据，比如订单；订单出库需要库存数据，库存数据也是业务数据）。

我们知道数据量变会引起性能的变化。在制作测试数据时，一要注意量，需要准备足够的存量/历史业务数据，二要注意数据的分布。比如我们计算出需要并发100个虚拟用户，我们至少需要准备100个以上账号，并对账号赋予相应的权限（浏览、发帖、删除、查询）。

数据制作方法
可以使用工具、SQL或者存储过程？？？来完成。建议使用SQL，同时还能够熟悉数据库的物理设计（索引、字段、范式、反范式等）和ER关系？？？

9、测试执行

测试执行是性能测试的关键，同样的脚本不同执行人员得出的结果可能差异较大。这些差异主要体现在场景设计与测试执行上。

场景设计
前面已经确定了测试模型。场景设计是根据测试模型与目标，组织虚拟用户、组合业务种类到一个测试单元。组织测试场景时尽量要与实际业务情况一致。

基准测试
采用单业务场景、单用户的方式执行脚本。用于验证测试环境、测试脚本，以及为后续的测试执行提供性能基准。比如一个登录系统，如果系统登录时间为8秒，那么这个系统也就没必要再进行性能测试，因为它连一般性能都达不到要求。

配置测试
配置测试场景一般为混合场景（多个业务同时执行），用于帮助分析系统软、硬件配置是否满足性能需求指标，优化配置使各项资源达到最优分配原则。测试过程是一个实验过程，先是找出不合理配置，然后进行修改，最后进行验证；周而复始到配置满足需求。

负载测试
负载测试的目的是分析性能变化趋势，找出性能拐点分析性能问题与风险，对系统进行定容定量；为系统优化、性能调整提供数据支撑。负载测试分为单场景与混合场景；单场景有利于分析性能问题，因为排除了其他业务干扰；混合场景更贴近用户实际使用习惯，是一个综合的性能评估。建议先做单场景测试再做混合场景测试。

稳定性测试
稳定性测试在正常性能阀值下尽量加大负载，长时间运行，确定系统的软、硬件环境是否运行稳定。什么是阀值呢？比如响应时间要求3s以内，3秒就是阀值；比如CPU利用率70%以下，70%就是阀值。假设满足性能要求的负载是B，那么稳定性测试时负载一般是1.5B~2B。执行时采用混合场景，按惯例执行时间不低于8小时。时间上越长越好，有些隐藏较深的诸如内存溢出的问题是需要长时间运行才能反映出来的。

测试监控
测试监控

10、缺陷管理

对性能测试过程中发现的缺陷进行管理。

11、性能分析和性能调优

性能测试工程师与开发人员一起来解决性能问题。

13、测试报告

• 性能测试背景：测试原因，性能测试开展的必要性。

• 性能测试目标：对系统进行定容定量、响应时间、配置、稳定性等测试，风险评估。

• 性能测试范围：参考测试计划中的测试范围。

• 名词术语： 涉及专业名词的解释，参考测试计划。

• 测试环境：报告结果基于的测试环境，不同的环境结果可能大相径庭。

• 测试数据：报告测试数据量，参考测试计划。

• 测试进度：报告测试过程，什么时候做什么工作，比如哪一天执行了哪些测试脚本。

• 测试结果：基准测试、配置测试、负载测试、稳定性测试等，全面多方位的报告测试结果，TPS、ART、事务成功率、硬件资源使用率（CPU、内存、网络、IO等）。

• 测试结论：分析给出测试结论，系统能否满足性能要求？存在什么问题？有哪些缺陷？解决了哪些问题？还有哪些问题没有解决？列出仍没有解决的系统缺陷。

• 系统风险：报告系统可能存在的风险，帮助决策层应对风险。

14、评审