这不可能是网络的原因

　　结果，eVersity 项目在该应用程序正式产品化之前就被取消了（这里的取消，我指的是客户某一天突然打电话告诉我们，他们的整个部门被解散了），所以我们没有机会看到我们的性能测试是如何准确了。从好的方面来看，这意味着我们的团队可以工作在几个星期后出现的一个从客户端服务器到Web 呼叫中心的改建项目了。

　　从性能测试的角度来说，该项目的前几个月非常平静。Sam 和其余的开发人员从一开始就一直和我分享各种信息。委托该项目的客户的副总裁Jim ，曾经是擅长于性能的框架开发人员，所以我们对合同或交付项定义中有关性能的部分没有任何异议，且历史系统使用文档已经为我们准备好了。当然，我们同样面临典型的环境、测试数据和脚本的挑战，但我们都通过协作一一攻克了。

　　接着，我遇到了迄今为止最奇怪的性能问题。在向数据库请求信息的网页上，我看到了我称之为“随机4秒”的响应时间模式。在一些研究和开发人员的帮助下，我们发现这些网页在被请求时，有一半的情况在大约0.25 秒内就返回了。剩余情况中的一半，它们在4.25 秒内返回。再剩余情况的一半，8.25 秒，以此类推。

　　通过共同努力，我们系统地排除所有不会导致随机4秒的东西。事实上，我们系统地排除了系统中我们可以接触到的每一部分，即除网络基础设施外的一切。我对于一切都感觉良好，所以当我被告知我不能同IT 部门的任何人交谈时，我以为那是个玩笑。但它不是。看起来是因为之前的一些开发团队曾把所有问题都归咎于IT 部门，浪费了他们很多时间，因此他们制定了这一政策，以确保类似的事情不会再次发生。

　　唯一的与IT 部门进行交互的方法是我们发出一份需求备忘录并由Jim 签字，内容包括详细的说明，通过跨部门的邮件发给IT 部门的副总裁。我起草了一份备忘录。Jim 签字并送交了。两天后，Jim 收到了写着“不同意”的回复。Jim 认为我们应该发送另一份备忘录，说明我们所做的测试显示网络是我们应该追查的方向。那份备忘录返回时附带了一张纸条，写着：“已检查。不是我们的问题。”

　　这种情况持续了一个多月。我们做越多测试，就越相信这是我们控制以外的东西的结果，而此应用程序的唯一不受我们控制的部分就是网络。最后，Jim 设法安排了一个与IT 部门的一小时的电话工作会议，表面上的理由是“让我们放弃骚扰他们”。我们把一切都设置好了，这样IT 人员在电话上准备好时，我们所有要做的就是点击一个按钮。我们整个团队都拨入了电话，只是为了确保我们可以回答任何可能出现的问题。

　　IT 人员在一小时整拨通了电话，并要求我们提供产生负载的机器和与我们的应用程序相关的服务器的ID 号码（即他们部门安装电脑时贴在机器上的纸条）。几分钟后，他们让我们继续。我们就按下了按钮。在约5分钟的静默后，我们听到线路里传出不太清晰的说话声。其中一个IT 人员要求我们停止测试。他说，他们将要静音，但要求我们不要断线。又过了20 分钟左右，他们回来了，让我们重新启动测试，并告知他们问题是否已经解决了。

　　10 分钟不到，我们就确认问题已经解决了。在这10 分钟，有人（我不记得是谁）问IT 工作人员（他们没有告诉我们他们的名字）他们发现了什么。他们只是说，看上去像是一个路由器在最近的机架安装时物理上损坏了，他们已经更换了路由器。

　　据我们所知，这次的互动并没能使之后的团队与这些IT 人员的交流变得更容易。我一直在想我是多么幸运，能在一个我能获得充分帮助和支持的团队中工作。从我发现了这个问题一直到IT 部门更换损坏的路由器之间的6个星期时间里，开发人员写了一些公用工具，抽取系统片断，留到很晚实时监控非工作时间的测试，并花了很多时间帮助我整理我们所做的测试的文档，就为了证明我们需要IT 部门的时间。这些交互才使得我确信性能测试可以是美丽的。

　　因为它太慢了，我们讨厌它

　　随机4秒问题解决之后，真正的测试开始了：用户验收测试（User Acceptance Test，UAT ）。在某些项目中，验收测试不过是走个形式，但在这个项目（以及在呼叫中心支持软件之后，所有我工作过的项目）中，验收测试是决定是否能发布的核心。为了这一点，Susan （呼叫中心经理）和该项目的验收测试组长，享有对任何关于什么可以在产品中发布以及何时发布的决定的否决权。

　　验收测试在功能方面如预期一样顺利。需要进行一些小的修改，但没有什么不合理的或过难实现的。让我们都感到困惑和关注的反馈意见是，每一个用户验收测试人员都或多或少地提到，应用程序“很慢”或“时间太长了”。显然，我们很担心，因为没有什么使呼叫中心代表的一天更糟糕了——在听着客户各种各样的不满的同时，还要忍受“谢谢您的耐心等待，我们的系统今天有点慢”。我们感到困惑是因为我们的网站速度很快，尤其是在公司的网络上，每个用户验收测试小组由5个代表组成，每人同时接10 个模拟电话，或者大约每小时100 个电话。测试表明，在速度显著变慢之前，应用程序可以处理高达每小时近1000 次电话。