性能工程高手课
庄振运
Facebook 性能优化和容量管理高级专家
24631 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 40 讲
性能工程高手课
15
15
1.0x
00:00/00:00
登录|注册

12 | 九条性能测试的经验和教训:如何保证测试结果可靠且可重复?

测试结果和生产环境比较
几种测试最好互相验证
根因分析要由易到难
一次调一个参数的利弊
测试环境要稳定
性能数据日志要适当输出
足够的负载请求和数据
快速地复位测试环境
详细记录测试环境和测试过程
结果分析
测试进行
测试规划
性能测试
性能测试结果可靠且可重复

该思维导图由 AI 生成,仅供参考

你好,我是庄振运。
上一讲我们介绍了十几种常用的性能测试工具。我们知道,性能测试的一个关键是保证测试结果可靠、可重复,否则就没有意义。所以,我们今天来学习一下进行性能测试时,这方面的经验和教训。
根据以前做过的相关工作,我总结了九条这样的经验和教训。按照逻辑时间顺序,我将它们大体上分成三大类别,就是测试前的规划、测试中的变化和测试后的结果分析;每一类又有三条要点。

测试规划

三大类别的第一类别是测试规划,我们先来说说测试规划时要注意的三条要点。

1. 详细记录测试环境和测试过程

做每个性能测试时,测试的环境至关重要。这里的环境包括软件硬件、操作系统、测试的负载、使用的数据等等。
测试的环境不同,性能测试的结果可能会迥异。除了测试环境,其它几个因素比如测试的过程,包括步骤和配置的改变也有相似的重要性。所以,我们每次测试都要把测试环境和测试过程记录下来,为将来分析数据做参考。
这些测试环境信息包括什么呢?大体上是操作系统和程序的版本号,以及各种软件参数的设置等等。
记录测试环境的目的是为了以后的各种分析。比如我们如果发现两次测试结果不匹配,需要找到不匹配的原因,那么这些测试环境就是相当关键的信息。如果两次测试结果的不同是因为软件配置不同导致的,那么根据记录的测试环境信息,我们就很容易根因出来。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

性能测试是软件开发中至关重要的一环,保证测试结果的可靠性和可重复性是其关键。本文总结了进行性能测试时的九条经验和教训,分为测试规划、测试进行和结果分析三大类别。 在测试规划阶段,详细记录测试环境和测试过程,包括软件硬件、操作系统、测试负载和使用的数据等信息,以便未来分析数据时参考。同时,需要快速地复位测试环境,确保能够快速恢复到初始测试环境的状态,以降低手工复位的工作量。另外,足够的负载请求和数据也是必要的,需要保证它们的多样化和代表性,以避免测试结果失真。 在测试进行阶段,性能数据日志要适当输出,并保存起来以便后期处理。同时,测试环境要保持稳定和一致,避免不可控因素影响测试结果的可靠性。此外,在性能调优测试中,一次只调一个参数,通过对比实验找出系统的最优配置。 最后,在结果分析阶段,需要关注输出数据的存储开销和可能影响性能测试结果的因素,同时保持测试环境的稳定性。 这些经验和教训为进行性能测试提供了重要的指导,有助于保证测试结果的可靠性和可重复性,从而提高软件系统的性能和稳定性。文章还提到了根因分析的逐步排查方法、不同测试工具互相验证的重要性,以及测试结果与生产环境比较的注意事项。通过分享经验和教训,文章鼓励读者不断学习、吸取他人的经验,以解决性能测试中的各种挑战,从而得出可靠、可重复并有意义的性能测试结果。 文章内容涵盖了性能测试的关键步骤和注意事项,为读者提供了宝贵的指导和思考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《性能工程高手课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(10)

  • 最新
  • 精选
  • 林林总总0107
    木桶理论那里举例不太适用每次只改一个参数的例子,木桶板属于同一个变量,基于控制变量法的思想,调整所有的木板也是相当于只调了一个参数

    作者回复: 我或许没讲清楚(应该多加一句来解释),我的例子的每块木板代表一个参数。

    2019-12-23
    3
  • 吴桂明
    庄老师,您好,文中的“详细记录测试环境和测试过程”,如何有效的手工记录呢?目前还没找到方法。而自动记录的软件有没有推荐的呢?

    作者回复: 手工记录其实也简单,比如把几个重要的系统和软件参数记下来就是了;因为测试的时候变来变去的就是那几个。 自动记录的有很多,比如CFEngine。

    2020-03-22
  • 若镜
    老师 我有在虚拟化环境下压测的问题:  "虚拟机硬软场景下的问题定位"      实际经验证明,现在虚拟化环境,当出现一个性能问题时(通过javacore等文件诊断)可能是一种假像,其原因是虚拟化并不是真正能做到资源的严格隔离,极有可能是别的机器正在运行大型的批处理或程序有严重的bug导致资源被无限制占用.  (示例:我们在虚拟机环境跑压力测试一场景,同样非上班时间点,发现有一天比平时要慢近10秒,后来到虚拟机管理员那才查到是虚拟群里另一台机器消耗了更多的cpu(其cpu一直处于报警状态,此问题如果不是每天用压测场景比较,很有可能就事论事定位错了,实际生产环境偶尔发生后,后续分析时,实际发生问题场景已不可重现)      同时业务系统潜在有问题的地方,也可能因为整体虚拟化环境资源充裕,而被掩盖.  (示例:同样一个sql有严重IO问题,因资源充裕,没被暴露,当数据库移至实体机时问题即出现)     问题是:虚拟化环境,通常部署各种系统,其业务访问峰值,后台跑批时间等都不可控,作为具体的业务系统,如何避免 只见树木不见森林?走入问题诊断的误区.      

    作者回复: 虚拟化和多任务里面情况很复杂,很多因素影响,比如OS机制,虚拟平台,Workload特性。我后面有一个章节是关于这方面的,一个具体的生产案例。虽然不能面面俱到,但希望能开阔思路。

    2019-12-30
    2
  • Linuxer
    有一个问题想请教一下各位?我们最近测试发现pthread_mutex_t会频繁进入native_queued_spin_lock_slowpath,导致系统CPU飙高,但是这种现象只出现256线程时,提升线程就不会出现,我在网上看到说是锁竞争激烈才会进入native_queued_spin_lock_slowpath,想不明白的是为什么只出现在256线程的时候呢?请教下老师或者各位同学有没有什么好的思路
    2019-12-24
    1
    2
  • 天时地利人和,时间地点人物,性能测试有趣或者痛点之处在于和很多因素相关,有些比较明显有些比较阴晦,时间不对环境不对数据不对都可能导致测试数据的失真。所以,需要做对照实验,以期待发现其中的规律和不同。 我印象深的吃过一次预期值的亏,由于之前的预期值有误导致一次压测值不符,各种分析找性能瓶颈,后来发现那个服务就是那样,只是之前的预期值有误,说性能挺好的,其实一般般,后来的压测也是OK的,并没有差太多,也不需要找性能瓶颈。
    2020-03-04
    1
  • 追风筝的人
    对redis集群 进行性能测试 只开一个xshell 窗口用redis-benchmark 工具压 cpu不能达到100% ,至少2个以上redis-benchmark 进程压集群
    2022-06-16
  • 在路上
    在 Web 服务器中等负载的情况下,这几十毫秒的链路层延迟,就可能导致应用层响应时间增加惊人的几十秒延迟。 庄老师好,能解释下这个的原因吗?或者推荐下相关的资料。
    2021-01-30
  • 在路上
    如果一个随机 8KB 或 16KB 数据的对硬盘的读写,测量出的延迟不到 1 毫秒,那就实在是“太快”了。 庄老师好,第8讲熟记的一组常用的性能数字,提到SSD NVMe一次读写是10us,是可能满足1ms的,为什么说实在太快了呢
    2021-01-30
  • Geek_6e8c17
    踩过没有足够负载数据,命中缓存的坑。因此后来准备了10w个虚拟用户账号。
    2020-01-22
  • Linuxer
    今天文章中提到的坑基本都踩过,针对之前踩过的坑,我们采取了两种办法避免重复踩坑,一种是能自动化检测的自动化检测,另一种是形成一种流程规范,针对流程中的每个点都有一些检查项,根据检查项提前检查来规避之前遇到过的问题。 没踩过的坑,这个点就说不准了。
    2019-12-23
收起评论
显示
设置
留言
10
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部