Skip to content

Latest commit

 

History

History
128 lines (63 loc) · 4.73 KB

性能测试最佳实践.md

File metadata and controls

128 lines (63 loc) · 4.73 KB

性能测试最佳实践

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

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

最佳实践

准备期

  • 测试目标

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

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

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

  • 测试环境

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

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

  • 测试工具

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

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

  • 日志

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

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

设计期

  • 脚本可重复性

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

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

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

  • 与版本同步

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

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

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

测试期

  • 测试启动

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

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

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

分析期

  • 真实有效的数据

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

常见性能问题

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

客户端性能

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

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

服务器

内存泄漏

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

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

CPU较高

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

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

数据库

索引

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

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

N+1 Query

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

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

网络通信

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

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