很多朋友接触性能测试是从工具开始的，比如流行的JMeter、Loadrunner等。熟悉一个测试工具，有助于对性能测试的过程、方法和机制有个直观的理解。

我们知道，无论是什么类型的测试，其目标不外乎两个，一是为了证明系统满足当初的定义（Requirement）；二是尽可能早、尽可能多地发现潜在的问题（Defect）。工具是为解决特定问题而服务的，其使用是相对简单和可控的，在性能测试中，方案设计则显得更为关键。

通常，我们在做性能测试方案设计时，会从以下几个角度去思考。需要知道的是，它们之间并不是割裂的，会有交叉，界限也并不那么明显。

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

讲到测试场景的设计，就离不开业务上的分析，可尝试回答以下几个问题：

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

在性能测试设计的过程中，需逐步明确和落实以下几个方面的内容：

1. 确定测试系统中的注册用户和同时在线用户数；
2. 通过注册和同时在线用户数，推导出并发虚拟用户数；
3. 不能确定的，三个用户数之间可先按十分之一的比率来演算；
4. 选择测试的接口，确定各自所需支持的每秒访问量；
5. 设计3个以上综合业务场景，包括其中各接口请求量的占比；
6. 针对资源消耗大的业务，如文件读写、网络传输、AI训练等，重点进行测试；
7. 根据经验预测容易出问题的地方，单独设计测试场景；
8. 确定各场景下的思考时间、运行时长、加压策略等测试参数配置；
9. 综合考虑服务环境因素，如硬件、网络、（微）服务实例数、是否有负载均衡等；
10. 确定测试工具和环境，如加压机器数量、测试工具配置等。

最后，确定测试中需要度量的性能指标，可包括：

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

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走！

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。