性能测试最佳实践

前面已经讲过JMeter使用最佳实践，以下再讲讲通用性的性能测试最佳实践。

依据性能测试生命周期不同，对每个周期内的最佳实践进行拆分。

准备期

• 测试目标

  • 明确性能测试的目标: 达成的数量级/基线数量级/场景覆盖

• 场景定位

  • 定位出需要测试的场景: 分析出需要进行性能测试的场景有哪些，核心的业务场景有哪些

  • 不要假想测试场景: 不要假想一些可能会需要测试的场景，以免浪费测试时间

• 测试环境

  • 明确性能测试所测试的环境: 进行性能测试环境，要针对哪个环境进行。建议: 单独搭建用于性能测试的环境，配制参考生产环境的配制。

  • 不要直接使用生产环境进行性能测试，以免给生产环境造成影响。

• 测试工具

  • 针对测试工具的选取，一定要明确所选取的工具的特性，不要盲目选择听起来很NB的工具

  • 测试工具，尽量选择一些小巧/开源，够用即可

• 日志

  • 调整日志的输出级别，减少日志输出对性能的影响

  • 日志中最好能输出对性能测试有帮助的日志

设计期

• 脚本可重复性

  • 性能测试脚本最好可重复执行，便于应对不同的环境或版本更新

• 测试执行时间

  • 测试时间: 设计测试执行时间时，一定要适中。强并发30分钟即可，持续操作2-3小时即可。

  • 测试周期: 条件许可的情况下，最好在每个小迭代版本发布的时候都至少进行一次。至少 确保在上线前进行一次

• 与版本同步

  • 性能测试所涉及的内容，一定要与版本开发的内容同步更新。

• 等待时间

  • 性能测试过程中，在业务操作过程中也可加入适当的等待时间。等待时间在真实的用户行为中是肯定存在的

• 测试机器

  • 一定不要给客户端机器过大的压力，以免客户端机器性能不足时，影响整个测试结果。

测试期

• 测试启动

  • 测试开始时，尽量要减少外部因素对测试环境的影响。如: 网络波动

• 问题收集

  • 及时收集问题: 在测试过程中，若发现问题时，一定要及时保存当时的环境信息/日志文件/测试数据

• 数据记录

  • 测试过程中，确保针对每次的测试结果有准确的记录，便于后期的结果比对。

分析期

• 真实有效的数据

  • 分析性能测试结果时，一定基于真实的测试数据。确保数据的可靠性

常见性能问题

以下内容，不会涉及深入的项目内部代码分析，仅将性能测试过程中经常出现问题的点提出来，并给出对应的参考定位方案。

客户端性能

• 客户端测试机的性能不足，影响整个性能测试结果的真实性。在测试过程中，一定要先明确客户端测试机的物理配制及带宽情况，确保客户端机器有足够的能力来执行测试。

  • 解决方案: 若客户端性能不足，建议增加客户端机器的数量。

服务器

内存泄漏

• 服务器对使用对象的回收不及或部分对象没有回收时，这是服务器内存泄漏的常见问题。但定位出具体哪部分有问题，还需要依据具体的项目去分析。

  • 解决方案: 输出堆栈信息，定位出具体的方法或对象问题。

CPU较高

• CPU在测试过程中，经常会出现居高不下或快速上升的过程。大部分原因是由于服务端程序对CPU的计算量过大。

  • 解决方案: 尝试定位出是哪些业务场景引起CPU变量，再依据业务场景在代码中的处理方法定位出问题根源

数据库

索引

• 数据库中创建的索引过多，引起数据操作过慢，进而影响整个性能测试的时间。

  • 解决方案: 对性能测试场景中进行分析，找出哪些数据操作时长较高。优化数据库脚本

N+1 Query

• 数据库中经常由于表设计的不合理，会引起不必要的多表联合查询，影响数据查询的速度

  • 解决方案：在每个表中字段的设计时，一定要充分考虑放在哪个表中才是最合适的，及是否会对业务的性能产生较大的影响

网络通信

• 服务器的网络数据未做优化时，带宽有可能会被消耗完全。带宽的消耗需要考虑客户端 服务器两方面，每一端的带宽均会影响测试数据的准确性。

  • 解决方案: 测试过程中，需要实时查看客户端/服务器的带宽数据，确保没有达到自身的数据上限。