51Testing软件测试论坛

标题: TDP—测试驱动性能 [打印本页]

作者: lsekfe    时间: 2021-4-26 15:10
标题: TDP—测试驱动性能
 摘要
  本文讲述了软件开发过程中普遍出现的性能问题,分析了性能问题产生的根源,并提出了解决性能问题的策略-TDP(Test-driven  Performance测试驱动性能)。结合公司的实际情况,制定了软件开发过程中应用TDD的解决方案。在实际的项目中,也对TDD进行了实践。结果表明,依照[url=]测试[/url]驱动性能的实践,软件的性能有了可靠的保障。
  一、前言
  在很多软件项目中,开发者们通常在前期都不太注重性能等非功能性需求,直到项目进入到交付阶段或系统上线之后,许多在压力负载较大情况下发生的问题才被发现,导致开发工作陷入一片混乱。然而,即使在设计阶段对性能进行过比较完善的考虑和设计,总还是有一些现实的问题是无法仅仅通过设计就能解决的。面对性能问题,本文通过分析公司的实际案例,结合公司的实际情况,提出了性能问题的解决方案-TDP(Test -Driven Performance,测试驱动性能),并应用到实际的项目交付流程中,到目前为止取得了比较好的效果。
  二、一次真实的性能危机
  笔者所在的公司,前段时间一个"云端数字资产管理平台"项目发生了一次性能危机。系统上线之后,在高并发的情况下,生产环境的两台认证LDAP服务器都宕机了。而且,在一个月左右的时间内,接连发生了两次。更为严重的是,每次宕机都导致了一小部分数据的丢失。毫无疑问,这是一个非常典型的、由于系统性能缺陷而引发的问题。
  当时,客户满意度急剧下降,整个项目因此进入了一个非常危机时刻。面对危机,公司的应对比较及时,调用了很多专家对问题进行分析、找解决方案。最终,我们成功地解决了问题,度过了危机,但也付出了相当大的代价。如图1所示,我们在分析、重现、解决、验证、部署等工程活动上,至少花了10个人周的工作量。

  图 1 解决危机的工作量

  总而言之,任何项目一旦发生性能问题,特别是后期或系统上线之后,其修复代价往往是巨大的,成本上是难以承受的。
  该项目的这个性能问题虽然最终得到了妥善解决,从软件工程的角度来看,这个性能问题的根本原因是什么?我们如何又能避免类似的问题再次出现呢?
  三、性能危机的根源
  就云端数字资产管理平台项目的人员构成、以及整个事件的处理和结果来看,这次项目性能危机的根源在于性能测试环节。
  在项目初期,项目团队对系统选型进行过比较充分的讨论和研究,对系统架构也进行了比较完善的设计和评审,团队成员的技术能力也很强。而且,在项目进入中期后,团队规划并实施了系统级别的性能测试。按道理说,这样的团队发布的产品应该不会有大问题。但是,性能测试方案有问题而没有真实地模拟出生产环境的状况,这就导致了应该在测试阶段暴露的问题遗留到了生产环境。
  四、性能问题的普遍性
  2016年下半年,我们挑选了5个项目进行了一次调查,对比了五个项目在性能方面碰到过的问题、挑战、以及应对策略。
  根据得到的数据和信息,对被调查的项目在基本技能、设计平衡、测试、调试、实践分享这五个方面进行了对比统计。采用的方法是:对于某一个方面,比如基本技能,如果一个项目做得还可以,就记1分,做得不好,就扣1分,与项目不太相关的方面就不参与统计计算,然后求和。
  表1、项目性能工程活动比较分析

  最终结果是,在性能测试上的分数最低。有的项目是性能测试本身的方案有问题,有的项目是在生产环境出现性能问题后再补性能测试,有的项目因客户没有明确需求而甚至没有做过性能测试。
  这五个项目在生产环境都暴露过比较严重的性能问题,而普遍最缺失的是性能测试。
  五、TDP-测试驱动性能
  出了问题不可怕,从问题中吸取经验和教训,找到解决问题的方案,预防类似问题的再次出现才是最重要的。结合我们公司的交付流程和各项目的实际情况,经过TEC(Technology Excellence Committee,技术卓越委员会)内部充分讨论,我们提出了TDP-测试驱动性能的解决方案。
  在项目的实施过程中,前期的设计固然重要,但并不能解决所有的性能问题。而且,如果过度设计的话,反而会适得其反,导致项目成本上升或交付延期。所以,在项目前期对性能进行适当的考虑和设计,在敏捷迭代的过程中,再用测试来驱动是比较客观而有效的方式。
  性能测试可以尽早地发现性能问题。可以在很大程度上预防性能问题延迟到生产环境才被暴露出来。










欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2