我们决定去除应用程序中所有的图形和其他可省略的部分，使其速度尽可能最快，然后由我自己或某个开发人员监视验收测试，这样我们就可以亲眼见到到底是什么变慢了。让我们更困惑的是应用程序后来更快了——没有任何一个监视验收测试的人注意到哪怕一次用户在等待应用程序，反馈意见却仍然是该应用程序速度很慢。可以预见的是，我们还得到反馈说该应用程序很难看。

　　最后，我意识到，我们所有的反馈都来自Susan 的口述或她的总结报告，我问她我是否能看看实际的反馈表。虽然协议是只有验收测试组长能看实际的表格，我被允许与Susan 一起对其进行审查。我们在看第三份或第四份表格时，我有了一些想法。那张表格上的评论是“用此方法处理调用所需的时间太长”。我问我是否能和发表了那篇评论的用户谈谈，Susan 为我们安排了会议时间。

　　第二天下午，我在验收测试实验室见到了Juanita 。我让她为我做一次模拟。我边看边计时。她模拟了大概2.5 分钟，不过我马上就意识到她既不习惯用户界面的流程，也不习惯使用鼠标。我问她是否可以在现有的系统上为我做一次同样的模拟，她说可以。花了约5分钟时间将加载现有的系统，并准备完毕，她只要登录就可以使用。系统一准备好，她就转身对我说，“准备好了吗？”

　　Juanita 猛地打了一会儿字，然后转过身看着我。几秒钟后，我说，“你已经完成了？”她得意地笑着点了点头，我检查了一下时间：47 秒。我感谢她，并告诉她我已经得到我所需要的。

　　我打电话回办公室，请我的同事们30 分钟后在会议室和我碰头。我到达时所有人都已经聚集在那里了。我花了不到10 分钟来解释，当用户验收测试人员说“慢”的时候，他们并不是指响应时间；他们指的是应用程序的设计影响了他们的工作效率。

　　那时候，我在这个项目的工作基本上结束了，所以我不知道重建后的用户界面的最终模样，但是Sam 告诉我，他们此后与Susan 和她的用户验收测试人员有了更多的互动，他们在应用程序发布后十分兴奋。

　　对于性能测试人员来说，没有几件事能比呼叫中心代表对你测试的应用程序十分满意更美妙了。

　　总结

　　在这一章中，我与你分享了我作为一个性能测试人员在成长过程中遇到的几个事例。事实上，这些都是发生在我工作过的真实项目中的真实故事。事实上，它们是在大约14 个月的时间内连续发生的，这使得它们更有力。

　　几年前，我学到了一项名为关键事件分析（critical incident analysis ）的技术，可以用来确定可用于复杂的任务的共同原则，比如性能测试就是一种复杂的任务。我是在第三次启发式和探索式教学技术研讨会（Workshop on Heuristic and Exploratory Teaching，WHET ）上从Cem Kaner 和Rebecca Fiedler 那里学到这些的。我们试图找出这种方法在确定人们用于测试软件的核心技术或概念时效果如何，这将对建立相关培训很有价值。

　　根据维基百科：

　　关键事件，是指对某项活动或现象产生了重大贡献的事件，而不管其是正面的还是负面的。关键事件可以按多种方式收集，但一般受访者会被要求讲述他们曾经历的某件事的故事。

　　这些故事是我有关性能测试中协作的重要性的关键事件。在这些故事中，通过协作，各种各样的性能测试挑战被解决、攻克了：与其他测试人员协作，与项目管理协作，与客户协作，与开发团队协作，与IT 人员协作，以及与最终用户协作。我所有的性能测试经验都印证了这些故事所暗示的结论——协作是性能测试之美的基石。

版权声明：51Testing软件测试网获机械工业出版社华章公司和作者授权独家连载本章节。

任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。

相关链接：

《测试之美》连载（一）

《测试之美》连载（二）

《测试之美》连载（三）