测试开发之性能篇-性能测试设计（草稿）

很多朋友接触性能测试是从工具开始的，比如流行的JMeter、Loadrunner等。熟悉一个测试工具，有助于对性能测试的运作机制、指标采集和统计分析等过程和机制，有个直观的理解。

我们知道，工具始终是为解决特定问题而服务的。无论是什么类型的测试，其目标不外乎两个，一是为了证明系统满足当初的设想（Requirement）；二是尽可能早、尽可能多地发现潜在的问题（Defect）。为了更好地完成这两个目标，工具的使用是相对容易和可控的，而性能测试方案、过程的优劣和有效性则显得尤为重要。

通常，我们在做性能测试方案设计时，会从以下几个角度来思考问题。

编号	名称	描述
1	性能指标	系统在常规的工作负荷下，各项性能指标是否满足当初设计要求。
2	数据容量	可预期的未来业务增长情况下，大数据量可能引发的性能瓶颈。
3	能力评估	单位资源、时间内，系统可处理的业务量。可用于仿真环境到生产环境的软硬件资源估算。
4	压力测试	验证系统在超出正常负载情况下的性能表现。可据此评估生存环境中，不同类型软件硬件资源的配比。
5	疲劳测试	长时间施加一定量的负载，验证系统是否会出现诸如内存泄漏、网络拥堵等方面的问题。
6	强度测试	验证系统在高强度、资源匮乏的情况下，依然可以正常工作，未发生系统崩溃、重启，处理能力急剧下降，以及数据不一致等问题。

以上列出的性能测试中的一些着眼点，之间的通常会有交叉，界限也并不那么明显。所以笔者并没有像一些软件工程实践（如RUP）中的那样，称之为不同的性能”测试类型“。

讲到性能测试场景的设计，就离不开业务上的分析，一般可以考虑：

1. 系统的用户规模有多大？
2. 在可预期的未来某个时间点，数据量会到达多少？
3. 各个子系统、功能模块，分别需承受多大访问量？
4. 在特定的日期或时间，是否存在某个业务的峰值？
5. 按照现有的架构设计和资源配比，可能的瓶颈在哪？

建议和市场、产品和开发等相关人员一起，预估未来规模、开展业务分析、确认性能需求。然后，开始性能测试场景的设计。通常包括以下的几个方面：

1. 确定测试系统中的注册用户和同时在线用户数；
2. 选择测试的接口，确定所需要支持的每秒访问量；
3. 设计综合业务场景，包括其中各个接口请求量的占比；
4. 针对资源消耗大的，如AI训练、文件读写、网络传输，重点进行测试；
5. 评估容易出问题的地方，单独设计测试场景；
6. 确定各场景下的测试参数，如思考时间、运行时长、加压策略；
7. 确定服务环境，如硬件资源、网络带宽、（微）服务配比、负载均衡；
8. 确定测试工具和环境，如加压节点数量、测试工具配置等。

测试中需要度量的性能指标包括：

• 吞吐量(Throughput)
• 每秒查询率（QPS）
• 响应时间(RT)，包括平均、最大、最小、正态分布
• 请求失败或业务错误率
• 系统指标，如CPU、内存、网络的方面

专题目录