TDP—测试驱动性能
摘要本文讲述了软件开发过程中普遍出现的性能问题，分析了性能问题产生的根源，并提出了解决性能问题的策略-TDP（Test-drivenPerformance测试驱动性能）。结合公司的实际情况，制定了软件开发过程中应用TDD的解决方案。在实际的项目中，也对TDD进行了实践。结果表明，依照测试驱动性能的实践，软件的性能有了可靠的保障。
一、前言
在很多软件项目中，开发者们通常在前期都不太注重性能等非功能性需求，直到项目进入到交付阶段或系统上线之后，许多在压力负载较大情况下发生的问题才被发现，导致开发工作陷入一片混乱。然而，即使在设计阶段对性能进行过比较完善的考虑和设计，总还是有一些现实的问题是无法仅仅通过设计就能解决的。面对性能问题，本文通过分析公司的实际案例，结合公司的实际情况，提出了性能问题的解决方案-TDP（Test -Driven Performance，测试驱动性能），并应用到实际的项目交付流程中，到目前为止取得了比较好的效果。
二、一次真实的性能危机
笔者所在的公司，前段时间一个"云端数字资产管理平台"项目发生了一次性能危机。系统上线之后，在高并发的情况下，生产环境的两台认证LDAP服务器都宕机了。而且，在一个月左右的时间内，接连发生了两次。更为严重的是，每次宕机都导致了一小部分数据的丢失。毫无疑问，这是一个非常典型的、由于系统性能缺陷而引发的问题。
当时，客户满意度急剧下降，整个项目因此进入了一个非常危机时刻。面对危机，公司的应对比较及时，调用了很多专家对问题进行分析、找解决方案。最终，我们成功地解决了问题，度过了危机，但也付出了相当大的代价。如图1所示，我们在分析、重现、解决、验证、部署等工程活动上，至少花了10个人周的工作量。
http://www.51testing.com/attachments/2017/10/14982672_201710181200071J7Q0.jpg
图 1 解决危机的工作量
总而言之，任何项目一旦发生性能问题，特别是后期或系统上线之后，其修复代价往往是巨大的，成本上是难以承受的。
该项目的这个性能问题虽然最终得到了妥善解决，从软件工程的角度来看，这个性能问题的根本原因是什么？我们如何又能避免类似的问题再次出现呢？
三、性能危机的根源
就云端数字资产管理平台项目的人员构成、以及整个事件的处理和结果来看，这次项目性能危机的根源在于性能测试环节。
在项目初期，项目团队对系统选型进行过比较充分的讨论和研究，对系统架构也进行了比较完善的设计和评审，团队成员的技术能力也很强。而且，在项目进入中期后，团队规划并实施了系统级别的性能测试。按道理说，这样的团队发布的产品应该不会有大问题。但是，性能测试方案有问题而没有真实地模拟出生产环境的状况，这就导致了应该在测试阶段暴露的问题遗留到了生产环境。
四、性能问题的普遍性
2016年下半年，我们挑选了5个项目进行了一次调查，对比了五个项目在性能方面碰到过的问题、挑战、以及应对策略。
根据得到的数据和信息，对被调查的项目在基本技能、设计平衡、测试、调试、实践分享这五个方面进行了对比统计。采用的方法是：对于某一个方面，比如基本技能，如果一个项目做得还可以，就记1分，做得不好，就扣1分，与项目不太相关的方面就不参与统计计算，然后求和。
表1、项目性能工程活动比较分析
http://www.51testing.com/attachments/2017/10/14982672_201710181200231UJ3m.png
最终结果是，在性能测试上的分数最低。有的项目是性能测试本身的方案有问题，有的项目是在生产环境出现性能问题后再补性能测试，有的项目因客户没有明确需求而甚至没有做过性能测试。
这五个项目在生产环境都暴露过比较严重的性能问题，而普遍最缺失的是性能测试。
五、TDP-测试驱动性能
出了问题不可怕，从问题中吸取经验和教训，找到解决问题的方案，预防类似问题的再次出现才是最重要的。结合我们公司的交付流程和各项目的实际情况，经过TEC（Technology Excellence Committee，技术卓越委员会）内部充分讨论，我们提出了TDP-测试驱动性能的解决方案。
在项目的实施过程中，前期的设计固然重要，但并不能解决所有的性能问题。而且，如果过度设计的话，反而会适得其反，导致项目成本上升或交付延期。所以，在项目前期对性能进行适当的考虑和设计，在敏捷迭代的过程中，再用测试来驱动是比较客观而有效的方式。
性能测试可以尽早地发现性能问题。可以在很大程度上预防性能问题延迟到生产环境才被暴露出来。
页:
[1]
