vlambda博客
学习文章列表

接下来阐述一下性能测试的流程：

01

—

    了解你想要测试的系统想要达到一个什么样的指标或者要求。比如常见的：qps 500、平均响应时间2s以内、或者根据现有产品日活计算得出qps、或者根据业务增量计算得出qps、事务错误率、被测系统cpu、内存、磁盘io、数据库dao维持在百分之多少等等。

充分理解被测系统

1、理解被测系统代码实现逻辑；

2、理解被测系统运行环境的配置；

3、理解被测系统缓存、中间件调用机制；

4、理解被测系统逻辑分支关系；

5、了解被测系统压力过大时，降级处理能力；

6、了解被测系统压力过大时，自我恢复能力；

这里有一个最重要的核心原则，即：一切配置与生产环境保持一致或等比配置。

制定测试策略

1、核心原则

    80%策略针对现有业务的预期增长计算，20%策略针对突发业务增量或意外请求增量。

2、策略设计

    根据压测和稳定性有所不同，常用策略是根据pv、uv的统计结果进行换算出预期结果。

3、策略调整

    根据被测系统代码被执行的随机性和用户实际出发代码命中率，按比例进行策略调整。

准备测试脚本

1、测试工具选择

    某些场景下，一些测试工具会拖慢整个事务的相应时间，从而导致qps上不去，比如locust的复杂业务，相同场景下会比jmeter慢很多，再有因为python语言的特性，运行速度相对java写的jmeter要慢，不过可以经过c重写或者用golang request client替换，以提高并发能力。

3、脚本优化：要根据使用工具特点和模拟事务场景，以及缓存策略、代码算法、代码调用依赖、接口降级等多方面因素考虑。

准备测试数据

1、测试数据

    数据对策略和脚本的影响非常大，是不可忽略的一项工作，压测过程中不能以全部随机数据为第一原则；

• 全部随机数据：好处是准备数据简单，但实际的代码命中率非常低，导致实际测试平均qps偏高；
  

• 命中原则随机数据：分析代码逻辑分支、算法、用户命中几率，用真实数据或等比准备数据，这样好处是几乎可以达到生产环境一致的测试效果；

2、测试数据和生产数据的一致性问题

• 数据量：数据量的差异会导致数据库dao响应时间存在差异，间接影响qps指标，保持好测试和生产的数据一致性所得出的测试结果才是正确的。
  

• 数据缓存：全新数据和新刷入缓存的数据，所测出的结果完全不同，如果没有好的理解被测系统的数据缓存机制，新数据会进redis，再进数据库，而老数据完全读取redis，所得结果也天差地别，没有完全对也没有完全错，而是完全根据实际业务场景和用户行为分析得出最佳结果。
  

脚本执行

1、执行环境

• 压力机：cpu、内存、网络带宽占比等因素，影响压力机生成压力，如果并发数过高，单台难以到达预期，考虑多机联合。
  

• 负载机：考虑静态和压测状态下增长变化。

• 数据库dao：dao响应会拖慢代码响应速度，导致qps低。

• redis：制定合适的针对策略，验证不同场景。
  

2、观察响应趋势

    响应时间和qps：如果不是开始或结束阶段，有明显上升或下降趋势，就要当心了，可能是各种原因造成的，一定要认真排查。

收集测试结果

1、日志：如果过程有错误产生，错误在可接受范围内，一定做好日志的分析；

2、压测过程中的压力机和负载机状态：静态和压测状态下的对比；

3、grafana或阿里云，搜集相关接口状态统计；

4、jmeter、lr、locust等报告输出；

环境恢复

1、压测造成的数据影响及时恢复，主要是写库会插入很多垃圾数据；

2、压力机或负载机的临时扩容，恢复到初始状态；

往期推荐 

🔗