应用程序性能测试的艺术（连载）第一章为什么要进行性能测试（续1）

1.2  糟糕 的性能：为何如此普遍？

好了，我已经试着对好的和不好的性能给出一个基本的定义。他们的区别看起来是很明显的，但为什么很多应用系统都没有办法达到好的性能这一崇高的愿望呢？让我们一起来看看一些比较普遍的原因。

1.2.1 IT 商业价值曲线

性能问题有一个讨厌的坏习惯，那就是等到发现 他们 ，往往已经是太迟了，而且您越晚发现 他们 ，解决 他们 的成本就越高。图 1-1 解释了这一点：

 

图： 1-1 IT 商业价值曲线

实线（计划）表示在开发一个应用程序的计划阶段，考虑过程中因素的预期结果（黑色方块）。应用系统成功发布的进度表，并在系统发布后不出现或少出现问题，从而立即开始为企业带来效益。

虚线（实际）表示在实际的产品研发过程中，非常频繁的发生发布和发布目标的疏忽（条纹方块），是由于在解决性能问题时大量的时间和金钱花费。对于企业来说，这可不是个好消息，因为这个应用系统未能实现预期的效益。

这种类型的失败在高层管理者的面前变得日益明显，于是许多公司开始实施信息技术服务管理（ ITSM ）和信息技术投资管理（ ITPM ）战略，并逐步通向与信息技术基础设施库（ ITIL ）趋向一致的圣殿。 目前的参考框架认为 IT 部门仅仅是另一个（重要的）商业部门，他的运营必须受到经营预算的限制。 IT 部门再也不能随意制订游戏规则，肆意挥霍金钱和资源而不受控制。

1.2.2     性能测试成熟度：分析师的考虑

不过，您可别轻信我的话，还是用数据来说话吧。 Forrester 研究公司在 2006 年针对在一个典型应用系统上发现的必须进行修复性能缺陷的数量进行了调查，图 1-2 就是 他们 所收集到的数据：

图： 1-2 市场调研公司 Forrester Research 对于未解决性能缺陷的调查报告

正如您所看到的，图中定义了三个性能测试成熟度级别。第一层级别是“救火（ Firefighting ）”，指的是那些在应用系统发布之前很少或从来没有进行过性能测试的情况，因此，实际上在生产环境上发现的所有性能方面的缺陷都必须去解决。这是最不可取的做法，然而令人不解的是，这种做法却依然十分普遍。

第二层级别是“性能验证（或确认）（ Performance Validation ）”，这一级别的情况是：公司为性能测试单独安排了一段时间，而不是在产品的后期才开始进行性能测试。因此，在研发过程中，仍然有相当多的性能缺陷被发现（ 30% ）。这是当前绝大多数公司的做法。

最后一层级别是“性能驱动（ Performance Driven ）”，这一级别指的是在应用系统生命周期中的每一个阶段，均对系统性能加以考虑。因此，当系统上线后，出现的性能缺陷就不会太多（ 5% ）。对于企业而言，这是性能测试模型应该努力追寻的目标。

1.2.3     系统设计阶段缺少性能方面的考虑

现在再回到我们先前讨论的有关性能测试失败原因的话题：如果在应用设计阶段没有对性能加以考虑，您简直就是在自找麻烦。好的设计可以让应用系统拥有优异的性能，至少也能够在出现意想不到的性能问题时灵活地进行修改或重新配置。与设计相关的性能问题，假如一直到了后期才发现，那么解决起来可就困难重重了，有时候甚至是一项不可能的任务，除非重新开发。

大多数的应用程序都是基于可独立进行测试的组件进行开发的，而这些组件在单独执行的时候，性能可能都不错，然而同样重要的是，必须将整个系统作为一个整体来考虑。这些组件之间需要具有良好的交互性，才能在集成后达到一个良好的性能。

1.2.4     直到最后一刻才进行性能测试

正如前面提到的，大多数的公司是处于“性能验证（或确认）（ Performance Validation ）”模式下。在这种情况下，性能测试直到系统发布前才会进行，并且很少考虑到性能测试所需的时间，以及失败后所造成的后果。虽然这个级别比“救火（ Firefighting ）”级别要好那么一点点，然而还是存在显著的风险，因为在产品的开发过程中，您无法发现那些严重的性能缺陷，或者是在产品发布前发现了性能问题，但却没有足够的时间去解决。

这样做造成的一个典型的后果就是，在这些问题得到解决之前，应用系统发布推迟。假如一个应用系统在发布后出现了很明显的性能问题，他的代价是相当高的，在系统发布后需要花费很多时间去修复。更要命的是，整个应用系统可能将不得不被完全放弃，因为他已经支离破碎得不成样子了。

所有的这些后果都将在那些准备使用这套应用系统的用户当中，对企业的信心造成极为不利的影响。因此，针对性能问题的测试越早开始越好，最好不要到了最后一刻才开始。

1.2.5     有多少用户？

通常，很少有人对系统的容量或规模加以足够的考虑。开发人员和测试人员可能经常会忽视系统最终用户的规模和分布。很多的应用系统在开发和测试的过程中都从来没有考虑过以下这些问题。

·         有多少用户在实际使用这套系统？

·         会有多少用户 [1] 同时使用这套系统？

·         用户是如何连接到系统上来的？

·         随着时间的推移，预计会增加多少用户访问？

·         最终的应用系统架构是什么样？服务器的数量和位置如何分布？

·         网络的容量会对应用系统有什么样的影响？

忽视对这些问题的考虑表现在对应用系统要支持的并发用户数有不切实际的预计。此外，开发人员往往没有考虑到有相当多的用户仍然在使用着低带宽、高延时的 WAN 网络连接。我会在第 2 章里详细讨论连接方面的问题。

1.2.6     低估您的人气

这句话听起来似乎有点奇怪，但确实有很多公司低估了他们一个新上线的 Web 应用系统的人气，有部分的原因是他们在发布系统的时候忘记考虑一些“新的因素”。当出现一些新奇又时尚的东西时，人们总是会觉得很有趣并且一窝蜂地去凑热闹。于是乎，当系统发布的第一天，您小心翼翼地估计他的点击数会达到 1 ， 0000 次，可他却一下子就猛增到了 100 ， 0000 次点击，然后，您的应用系统就这样崩溃了！

换句话说，您需要做计划的是可能出现的访问高峰，而不是访问的低潮期。

令人震惊的失败：一个真实的例子

在很多年以前，英国政府决定在互联网上公布 1901 年人口普查的结果。这涉及到大量的将旧文档转换成现代的数字格式文档的工作，并且还需要创建一个应用系统以供公众访问。

我个人十分期待这项成果的推出，因为我正在追溯我的家族历史，这肯定是一份巨大的信息资源。这个站点终于发布了，我也如期登录了。尽管我发现系统有点慢，不过我还是可以执行我初步的搜索，没有遇到太多问题。然而，当我在 24 小时之后再回到这个站点，我却收到了一个致歉的信息，说该网站无法访问。在之后的几个星期里，他始终无法访问，一直到最后他重新发布。

这是一个低估您的人气的典型例子，对这个站点感兴趣的用户数量远远超过了预期，于是他无法处理这么大数量的点击。这并不是说他们在发布之前没有做性能测试，但这确实说明了对这个站点的性能预期太过保守了。您必须将这些访问的峰值都在需求中考虑进去。

---

[1] 译者注：以下是性能测试过程中常说的几种用户的概念

1）   系统用户数：指所有可能访问这套系统的用户数，也叫系统的全部用户数。

2）   在线用户数：指同时访问这套系统的用户数量。

3）   并发用户数：在一个时间切面上同时向这套系统发起请求的用户数。