标签：重复 博客 包含 根据 分布式 不同的 建设 数据 时间
面对日益复杂的业务场景和不同的系统架构，前期的需求分析和准备工作，需要耗费很多的时间。而不同的测试策略，也对我们的测试结果是否符合预期目标至关重要。
这篇博客，聊聊我个人对常见的性能测试策略的理解，以及它们的适用场景。。。
一、常见的测试策略
性能测试实施过程中，针对不同的业务场景，我们经过分析和场景建模后，会选择不同的测试策略。下面的十种测试策略，覆盖了绝大多数的场景。
1、并发测试
模拟客户端请求，在单位时间内(S)同时发起一定量的请求，验证系统是否具有并发性的问题。
PS：不要无脑高并发！！！
2、负载测试
不断增加请求压力，直到服务器某个资源项达到饱和（比如CPU使用率达到90%+）或某个指标达到安全临界值（比如运维的监控告警阈值or拐点）；
负载测试（也叫阶梯式压测）一般主要用来寻找性能的拐点，验证系统在既有测试环境不同的请求压力下能否正常运行。示例如下：
3、容量测试
采用负载测试策略，验证在现有测试环境下被测系统的最大性能表现（可接受的最大性能表现，不一定是最优性能表现）。
4、极限测试
在既有测试环境下，不考虑资源占用率的极限情况（CPU使用率达到95%以上或IO异常繁忙或Load值较高），在系统不宕机的情况下的最大处理能力。
PS：由于被测系统的业务场景各不相同，这种策略，采用率相对较少。
5、配置测试
不断调整系统各方面的配置（软硬件、参数配置等），验证在性能达到最优时（最优的性能一定是权衡各方面因素找到的平衡点）的最佳配置。
6、浪涌测试
验证系统在某段时间内并发突增或请求量波动较大的情况下，系统能否正常稳定的提供服务。
PS：这种测试策略使用的也相对较少，主要针对不确定性的短期的峰值流量涌入场景（比如某微博的离婚、恋爱、分手话题）。
7、稳定性测试
以恒定的并发数（根据负载测试的结果，CPU使用率在70%时对应的并发数），验证系统在混合场景下的性能表现。
8、批处理测试
验证待测系统在既有环境下，系统的批处理（一般都是一个crontab或者触发式的job）业务能力能否满足生产的业务需求指标。
9、高可用测试
在集群多节点或分布式的情况下，破坏其中一个或多个集群节点，验证系统能否及时恢复服务能力。
10、容错恢复测试
验证系统能否在出现故障的情况下仍能保持正常提供服务的能力或出现故障后的自我恢复能力。比如下面这张图：
a1面积越大，说明系统的处理能力越强；a2面积越大，说明系统稳定性越好；a3面积越大，说明系统的容错能力越好（啧啧，图有点丑。。。）
之前有手动画了好几个性能模型图，找不到了，尴尬。。。
二、适用场景
以上十种测试策略，根据适用的业务&测试场景、采用该策略的目的以及场景出现频次来划分，仅供参考。
三、经验之谈
1、中小型团队：常规的测试策略选型：并发、负载、容量、配置、批处理、稳定性、高可用策略，可以覆盖绝大部分需求。
2、电商类业务：高并发、高可用、稳定性，是重中之重。
3、业务场景：很多时候一个性能需求包含好几个业务场景，但并发、负载、容量、稳定性，建议都采用。
4、需求场景：需求分析和场景建模做不好，测试结果往往偏差很大。
5、压测环境：环境的调研选型，建议和生产环境等配置最小化部署，这是成本和结果精准度的平衡。
6、测试数据：无论是数据量还是数据的有效性以及热点数据的覆盖率，都决定了测试结果的可参考价值。
7、技术建设：基础架构（包括环境、服务部署、详尽的监控体系、问题处理流程）的完备，才能让性能测试左移。
8、文档建设：一定要重视文档建设和数据留存，这样可以避免很多不必要的麻烦和重复性工作。
9、平台化：平台的作用是对流程的规范以及多人协同工作的效率整合，不要过度追求平台化（但一定要有技术规划和方案准备）。
10、不要无脑高并发！！！
标签：重复 博客 包含 根据 分布式 不同的 建设 数据 时间
原文地址：https://www.cnblogs.com/imyalost/p/11204522.html
