浅析性能测试策略及适用场景

面对日益复杂的业务场景和不一样的系统架构，前期的需求分析和准备工做，须要耗费不少的时间。而不一样的测试策略，也对咱们的测试结果是否符合预期目标相当重要。

这篇博客，聊聊我我的对常见的性能测试策略的理解，以及它们的适用场景。。。

 

1、常见的测试策略

性能测试实施过程当中，针对不一样的业务场景，咱们通过分析和场景建模后，会选择不一样的测试策略。下面的十种测试策略，覆盖了绝大多数的场景。

一、并发测试

模拟客户端请求，在单位时间内(S)同时发起必定量的请求，验证系统是否具备并发性的问题。

PS：不要无脑高并发！！！

二、负载测试

不断增长请求压力，直到服务器某个资源项达到饱和（好比CPU使用率达到90%+）或某个指标达到安全临界值（好比运维的监控告警阈值or拐点）；

负载测试（也叫阶梯式压测）通常主要用来寻找性能的拐点，验证系统在既有测试环境不一样的请求压力下可否正常运行。示例以下：

三、容量测试

采用负载测试策略，验证在现有测试环境下被测系统的最大性能表现（可接受的最大性能表现，不必定是最优性能表现）。

四、极限测试

在既有测试环境下，不考虑资源占用率的极限状况（CPU使用率达到95%以上或IO异常繁忙或Load值较高），在系统不宕机的状况下的最大处理能力。

PS：因为被测系统的业务场景各不相同，这种策略，采用率相对较少。

五、配置测试

不断调整系统各方面的配置（软硬件、参数配置等），验证在性能达到最优时（最优的性能必定是权衡各方面因素找到的平衡点）的最佳配置。

六、浪涌测试

验证系统在某段时间内并发突增或请求量波动较大的状况下，系统可否正常稳定的提供服务。

PS：这种测试策略使用的也相对较少，主要针对不肯定性的短时间的峰值流量涌入场景（好比某微博的离婚、恋爱、分手话题）。

七、稳定性测试

以恒定的并发数（根据负载测试的结果，CPU使用率在70%时对应的并发数），验证系统在混合场景下的性能表现。

八、批处理测试

验证待测系统在既有环境下，系统的批处理（通常都是一个crontab或者触发式的job）业务能力可否知足生产的业务需求指标。

九、高可用测试

在集群多节点或分布式的状况下，破坏其中一个或多个集群节点，验证系统可否及时恢复服务能力。

十、容错恢复测试

验证系统可否在出现故障的状况下仍能保持正常提供服务的能力或出现故障后的自我恢复能力。好比下面这张图：

a1面积越大，说明系统的处理能力越强；a2面积越大，说明系统稳定性越好；a3面积越大，说明系统的容错能力越好（啧啧，图有点丑。。。）

以前有手动画了好几个性能模型图，找不到了，尴尬。。。

 

2、适用场景

以上十种测试策略，根据适用的业务&测试场景、采用该策略的目的以及场景出现频次来划分，仅供参考。

 

3、经验之谈

一、中小型团队：常规的测试策略选型：并发、负载、容量、配置、批处理、稳定性、高可用策略，能够覆盖绝大部分需求。

二、电商类业务：高并发、高可用、稳定性，是重中之重。

三、业务场景：不少时候一个性能需求包含好几个业务场景，但并发、负载、容量、稳定性，建议都采用。

四、需求场景：需求分析和场景建模作很差，测试结果每每误差很大。

五、压测环境：环境的调研选型，建议和生产环境等配置最小化部署，这是成本和结果精准度的平衡。

六、测试数据：不管是数据量仍是数据的有效性以及热点数据的覆盖率，都决定了测试结果的可参考价值。

七、技术建设：基础架构（包括环境、服务部署、详尽的监控体系、问题处理流程）的完备，才能让性能测试左移。

八、文档建设：必定要重视文档建设和数据留存，这样能够避免不少没必要要的麻烦和重复性工做。

九、平台化：平台的做用是对流程的规范以及多人协同工做的效率整合，不要过分追求平台化（但必定要有技术规划和方案准备）。

十、不要无脑高并发！！！