7.性能测试流程

性能测试从体量上来讲，大致上可以分为两类：

1.测试某个功能或者需求的时候，验证一定并发下的代码逻辑

2.作为项目的形式存在，耗费相对较多的人力、精力

 

第一类往往可以通过工具或者代码，简单的进行并发的验证，功能逻辑无误，即可认为验证通过。执行起来相对较为容易

第二类则需要完全按照项目的形式去走，从立项，分析，执行到结项，都有一套完成的流程。

 

笔者根据自己所做的性能测试项目的经验，整理如下流程：

说明：流程中各个阶段会有一些相互交叉，需要结合具体项目去思考各个阶段的具体工作，甚至需要增加、细化或者弱化、删减某个阶段的工作

 

1.需求阶段

需求阶段是性能测试的开始阶段，也是整个流程中最重要的阶段，直接决定项目的成功与否，该过程需要作出大量的分析、确认和论证 

1.1受理需求

受理需求阶段，主要是指接到了性能测试需求，以正式或者非正式的形式被告知需要对测试目标进行性能评估验证，这个阶段包含以下几点

1) 确认需求背景和本次验证目标。这里主要是根据初步信息判断需求的合理性以及测试必要性

2) 获取被测目标的具体业务属性。如：业务流程、业务场景、高峰时段、并发数、响应时间等具体业务相关属性，这里如果不确定，可以和需求及产品人员进行详细确认，甚至可以预约客户直接交流

3) 确认需求的期限以及能够调用的资源情况

1.2分析需求

需求受理后，接下来就需要根据掌握的信息，对需求进行详细的分析。这个过程极为重要，包含如下

(1) 分析需求的业务流程和具体的业务场景，抽象出业务模型

(2) 根据业务模型，确定被测系统以及被测主体以及相关属性信息，如：被测系统、被测接口、被测产品、测试指标等等

(3) 得出基本的测试思路和测试方法，并论证其可行性

(4) 思考测试过程中可能存在的风险点以及解决方案

(5) 根据给予期限，和各方勾兑资源情况，确保项目可支持程度

(6) 项目的产出：阶段性产出和最终产出

1.3确认需求

此阶段主要是在需求分析的过程中，对于部分不确定或者不合理的问题，和相关人员进行确认。需要强调的是，尽可能的考虑周全，及时确认

 

2 策略制定

需求分析结束后，开始编写测试策略。性能测试策略作为性能项目比较重要的一个环节，主要为项目的分析、执行、结果提供指导性纲领。通俗点讲，就是这个项目打算这么玩，一般包含以下几点

2.1确定测试范围及指标

编写测试策略文档时，首先需要交代项目背景和目的。由于3.1阶段已经具体讲过，这里不再累述。交代完项目背景和目的后，就要确定测试范围和指标，主要包含如下：

1) 测试业务主要说明本次测试范围中涉及到的业务流。如：收单、代付、钱包等

2) 测试系统主要说明本次测试业务中包含的系统，以及主要测试的目标系统。如：测试收单业务的代扣产品，主要目标系统为代扣前置和核心，其余系统在测试过程中观测其性能指标

3) 涉及产品主要是指测试业务中的具体产品。如：代付业务中的工作日转账产品

4) 测试接口主要指被测业务中被测产品的接口。这里需要注意的是，有时一个产品会涉及多个接口，如：收单业务代扣产品的下单接口、查询接口等

5) 测试指标主要指从需求人员那里获取到关于某个具体产品和系统的通过指标，这个作为测试结果的衡量依据。提示：有的性能项目属于探索性测试，相关指标不会明确给出，需要测试人员提前计算初始值并且边测边分析

2.2测试实施准备工作

测试准备工作包含如下：

(1) 测试环境准备。根据分析结果，部署或者调整相关应用架构及硬件资源，为性能测试提供环境基础。

(2) 确定测试工具。市场上性能测试工具较多，读者需要根据自己实际的项目情况选择合适的性能测试工具

(3) 确定监控工具。监控范围包括但不限于执行监控、应用监控、数据库监控、网络监控、硬件监控等。每个对应目标均需要部署对应的监控工具

说明：监控范围的划定，需要根据具体项目情况分析，不能一概而论。如：数据库已经知道其性能，而测试目标的性能远低于数据库，则无需在进行数据库监控；只是进行一个简单的并发测试，则无需再去准备过多的测试，只需要监控应用服务器和客户端服务器即可

(4) 测试数据准备。主要指测试脚本和模拟的场景需求中用到的数据。如：商户、产品、路由、秘钥等等

(5) 测试脚本准备。根据测试用例，编写对应场景下的测试脚本

2.3测试计划及进度汇报

该节点的工作属于项目管理范畴，但在性能测试项目中，往往会由测试负责人来安排并跟踪

1) 测试计划。根据确定的参与人员以及项目周期，排期，并且把排期结果放在测试策略文档中，方便评审

2) 进度汇报。大型性能测试项目一般跨越时间较长，这期间需要阶段性的进度汇报。这个可以在评审会议上约定汇报形式，邮件和会议均可。笔者建议每周邮件发出进度周报，让各方知晓

2.4测试策略及方法

该节点需要根据测试目标应用场景确定测试策略及方法，主要包含：

(1) 发起策略。主要指发起思路，如：测试代收系统的代扣和快捷产品，确定发起策略为基准测试、单链路测试、多链路测试

(2) 执行策略。主要指执行过程中用到的性能测试方法，如：评估测试代收系统中的代扣和快捷产品的性能，确定执行时使用基准测试、单场景负载测试、混合场景负载测试、稳定性测试、压力测试

(3) 监控策略。确定使用监控对象使用的监控工具。如：使用nmon工具查看应用服务器的CPU、内存、I/O等

(4) 结果检查。确定某个场景通过或者失败的中止条件。如：失败率忽然增加至5%以上，即中止测试

2.5组织结构和项目成员

该节点主要确定以下几点：

1) 组织结构。明确项目负责人、执行人员、支持人员、业务人员等各个角色主要参与人及其责任事项

2) 沟通机制。无规矩不成方圆，作为项目，需要明确沟通、汇报流程等项目管理细节，方便后续工作开展

2.6潜在风险分析

无论经验多么丰富的测试人员，也不可能在项目一开始就考虑到所有的风险点，但是需要尽可能从当前项目的实际情况出发，给出能够考虑到的风险点以及解决方案，一般风险点包含但不限于以下几点：

• 人员风险：人员变更或请假，个人工作的延迟
• 业务风险：业务的有效对等性
• 资源风险：申请的测试资源和真实情况存在预期偏差
• 测试场景风险：测试场景的遗漏或者模拟差异性
• 测试环境风险：测试环境和生产环境机器配置及数量并非完全相同

2.7测试结果输出

测试结果输出只要指两方面：

1) 过程输出。测试过程中会有一些阶段性的成果，如：测试策略、测试方案、测试用例、测试问题列表等等。从项目管理及项目管理者角度来看，这些结果最好能够以正式形式及时发出

2) 结果输出。主要指最终的测试结果，如：测试报告、扩容方案、问题列表、不同配置下的性能结果等等。最终结果一定要进行过会评审，确保各方人员都知晓结果且无异议

测试策略编写完成之后，需要通知各方参与人员进行过会评审，有分歧或异议的地方会后修改确认后再反馈，没有问题的即可达成一致。同时安排好各个角色的工作，即可进入下一个阶段：准备阶段

 

3 测试准备

测试准备阶段，主要是根据测试策略，开始准备各项相关事宜，以更好的开展测试执行工作。该阶段主要进行以下工作

3.1测试人员准备项

(1) 测试用例设计。测试策略评审通过后，需要对测试策略进行细化，其中最重要的就是测试用例的设计。根据前期分析的业务场景以及测试策略、测试方法，对每个测试场景进行详细的测试用例进行设计

(2) 测试方案及评审。测试方案属于细化后的测试策略，其中最细化的就是测试用例和详细测试思路。完成测试方案后，仍然需要通知参与各方开会评审

(3) 测试脚本编写及调试。编写各场景对应的测试脚本并待性能测试环境准备好之后进行调试

(4) 测试数据准备。和其他几项同步进行

3.2其他人员准备项

1) 测试环境准备。不同公司测试环境准备工作负责人不同，一般而言是由运维人员和测试人员来准备。环境准备好之后，需要通过进行交易来测试环境的可用性

2) 监控工具准备。不同的监控工具负责人不同，这个在策略会议上已经明确。数据库监控一般是DBA负责，测试监控由测试人员负责，应用监控由开发人员负责，网络和硬件监控则是运维来负责。具体分配可根据公司实际情况来决定

3) 环境及工具调试。待环境、监控工具、测试脚本都准备好之后，就需要进行简单的压力测试，也就是冒烟测试来检查环境和工具是否符合预期

4 测试执行

4.1测试执行

执行过程按照测试方案中设计的测试用例来执行，中止条件根据指标条件来判断。执行过注意点：

(1) 每次执行前做好必要的初始化操作（如：数据还原、存量数据处理完成等）

(2) 同一个用例的场景，如果时间允许，尽量执行2-3遍，避免偶然性偏差

(3) 每个场景的执行，必须要有明确的测试目标和对应的测试用例，以保证测试的有效性

4.2结果收集

每个测试场景完成后，需要详细记录下该场景下所有的测试数据，方便后期复盘或者分析。收集结果时，需要注意以下几点：

①　结果收集时，最好根据相应的测试用例以及需要的数据项，提前准备好结果收集文档模板

②　结果保存文件命名务必清晰，避免最后做分析支持结果时不能确定数据是否准确

③　建议所有结果，都要保存下来，无论是正常的结果还是异常的结果。甚至有些场景可能会反复执行，这些结果均保存下来

4.3问题反馈

测试过程中会碰到各种各样的问题，要求测试人员先进行初步分析定位，分析的数据来源：

①　根据场景运行过程中的错误提示信息

②　根据测试结果收集到的监控指标

分析问题的基本排查思路：

1) 压测服务器：执行日志、结果信息、内存、CPU负载等

2) 应用服务器：业务日志、监控数据、参数配置、业务逻辑、SQL语句、内存、CPU负载等

3) 中间件：dubbo、Redis、MQ、负载均衡等

4) 网络

5) 硬件

分析完成之后，把相关问题的信息记录汇总，越详细越好，及时反馈给对应模块的负责人，并持续跟踪解决情况。

4.4问题验证

待问题模块负责人修复完成之后，及时进行问题验证。要把问题修复带来的进度延迟影响尽可能降到最低。

对于测试人员，同时需要多多关注每个问题修复前后性能相关参数的指标数据对比，作为后期生产上对应模块提供参数修改的依据

5 结果分析

结果分析中包含测试数据整理、测试结果分析、编写测试报告

5.1测试数据整理

测试执行中，收集了大量的测试结果数据和问题数据。在对数据进行分析之前，需要先对数据进行整理过滤，查漏补缺，留下具有分析价值的数据。

加工数据。通过对数据合并同类项、不同纬度整合，使用Excel等工具进行绘图，通过图像对结果进行分析，会更直观一些

5.2测试结果分析

对标测试指标和测试目的，根据测试数据分析，得出最终测试结论，测试结论包含测试结果和潜在风险。测试结果分析时，需要结合以下几点来看：

(1) 测试目的

(2) 测试指标

(3) 测试结果图形

(4) 监控数据

除综合上述几个因素之外，整体还需要结合具体的场景来进行分析，避免出现结果有失偏颇的情况

5.3编写测试报告

测试报告作为最终的成果展示，需要体现出项目的生命过程和结论。没有固定格式，笔者给出一个模板作为参考

6 项目总结

6.1评审测试报告

测试报告编写完成之后，需要和各方参与人员及需求人员过会评审，主要目的如下：

1) 正式告知参与人员测试结论，听取各方意见并答疑，最终达成一致认同

2) 抛出测试中发现已解决的问题、待解决问题以及潜在的风险和相关建议。并确定相关问题的最终结论或者后续解决方案

3) 感谢各方人员的积极配合，利于下次合作

6.2查漏补缺

每个项目都不可能做的尽善尽美，性能测试项目也是一样。作为测试人员，项目结束后，要查漏补缺，反思总结，主要关注以下几点：

(1) 本次项目中做得好的部分。分析是否有进一步提高的可能性

(2) 本次项目中做的不足的地方。分析原因，并给出解决方案

(3) 本次项目中哪些是自己完全没考虑到的地方。通过总结，完善对性能测试的认知体系

(4) 以书面形式总结本次项目经验，分享

6.3结项

总结会议和发送正式邮件，是结项的标志。意味着当前项目翻篇，如果后期再有相关需求或者疑问，可作为二期，甚至另启项目。