如何拆解一个性能测试任务？

前言

为什么会选择这样的一个主题？

因为近期我们组成员接到了一个性能测试任务，经我了解后发现他对这块的认知非常的欠缺，接到任务之后立刻就开始埋头苦干起来，下载工具，设计压测脚本...... 我相信这是大部分测试新手在拿到一个性能测试任务之后的常见行为，潜意识里面觉得性能测试就是用工具发起一定量的请求，看一下RT和TPS等指标来判断被测系统是否正常。但是在这种情况下，我们的测试大多是无效的，要么拿到是一个不可信的测试结果，或者说即使拿到了结果但是我们依然无法依此来判断是否达到了我们的预期。所以，借今天分享的机会来和大家一起来聊一聊如何正确拆解一个性能测试任务？希望通过今天的分享讨论，无论是测试，研发还是运维都能达成共识性能测试到底是做什么？我们应该怎么做，以及通过实施性能测试可以帮助我们解决什么样的问题？

新手实施性能测试的不当行为有哪些？

1. 不清楚具体的的准入和准出标准（功能测试还未完成就进行性能测试，以及性能测试应该进行到什么程度就可以结束）；
2. 性能测试目标不清晰（直接压死？预期的RPS是多少？最大并发数？）；
3. 没有在正确的压测环境下进行测试（大多在自己本地进行测试）；
4. 未从真实业务场景角度来考虑设计压测场景（没有经过计算就定义测试的最大并发数，测试时长，测试数据以及思考时间）；
5. 加压方式设计不合理；（启动就直接加到最大并发）
6. 没有设立明确的监控指标；（只关注TPS，RT，错误率）

性能测试的流程

案例拆解

以上就是我们同事接到的任务，从任务描述上我们可以大概清楚研发的目的是想通过性能测试来验证新加的文档转换接口是否能够支持30个用户并发请求。我们的测试同学接到这个任务之后马上就开始了他的测试脚本的编写。这样肯定是不对的，因为有太多不明确的信息，贸然就直接开始测试脚本的编写，会导致我们最终达不到预期的测试目的，所以我们正确的做法应该是先对需求进行进一步的详细分析。

 1. 通过需求分析，明确性能测试目标。

 历史数据相关的监控平台搜寻到，graylog或者阿里云SAE监控。

普通计算：预期TPS = 最近一周总请求数 / 总时间

二八原则计算：预期TPS =  总请求数 80% / (总时间20%)

业务数据计算：TPS = 峰值请求数/峰值时间 * 系数

新增

不论是依照那种方式分析的需求目标结果，都需要和研发进行二次review，确保目标合理。

2. 规划相关模型（业务模型，压力模型，测试部署模型等）

•  业务模型：

• 先进行文档的上传，然后才会进行文档转换；
• 需要支持不同类型的文件的转换；
• 同一个文件，首次转换时长，重复转化，因为有缓存的机制会变快。
• 文件转换是异步进行的，即使接口返回正常也不代表转化成功。
•  压力模型：
  • 匀速加压模式：（最常用的模式，大部分工具默认使用的模式）

• 阶梯加压模式：
• 脉冲加压模式：        
• 测试部署模型 

从部署架构来看，正常的用户请求如果要达到我们的服务需要经过好几层。所以在实施测试之前，测试需要和研发，运维一起进行部署方案的确认，为了避免对生产现有的功能进行影响，不可直接对生产进行压测。

• 根据生产现有服务器的配置，申请额外的机器或者在预发环境部署被测系统。
• 申请专门的压测机器，与运维沟通压测场景需求，确保我们的施压请求能够按照预期的层。
• 施压请求数据应该打上相关标记，方便后续进行流量跟踪和数据清理。

3. 制定测试方案

业务范围	文档工具下对PDF&图片文件内容提取转换
业务接口	B 转换接口
业务配比	100%
并发配比	30
加压策略	梯度增压5个VU
测试环境	生产独立服务器+数据库
场景配置	1. 接口间思考时间1秒 2. 文件参数需保证唯一性
预期指标	TPS >= 预期值 平均RT <= 1S  CPU占用率 <= 80% 内存占用率 <= 70%
启停标准	启动：服务器空闲时 停止： 1. 满足预期指标 2.TPS曲线稳定不再增长 3. 压测时间执行完成自动停止 4. 其他监控异常出现

4. 监控策略 

5. 选择合适的测试工具，执行测试

6. 测试结论

基于测试结果，总结测试结论。相关结果截图或者工具报告存档

总结

性能测试是一系列计划周密而实施的测试活动，通过性能测试可以让我们明确被测服务在一定条件下是否可靠。整个过程测试作为负责人，需要与研发和运维一起紧密协作才能确保我们的测试是行之有效且可信的。