2.6　识别并确认关键业务的事务

性能测试的核心是驱动负载的事务。一个简单的例子是登录系统，转到搜索页面，执行一个查询，然后退出登录。您需要找出那些在一个工作日当中一个普通的用户最经常执行的大量关键任务。这些事务将是您的性能测试的所有构成部分，因此您必须确保已经正确地识别出它们。

不要将性能测试中的关键业务操作同功能测试用例混淆起来，请记住您的目标不是做功能测试（您应该已经做过功能测试了），而是创建一个符合实际情况的负载向应用程序施加压力，并且从性能的角度去评估应用程序的反应，性能测试应该发现任何由于并发或缺乏足够容量而引起的问题。

2.6.1　事务检查列表

对于每一个事务，您都应该完成以下这些检查操作。

定义每个执行步骤并形成文档，保证不出现具有歧义的路径

每个步骤都必须通过适当的输入输出给出清晰的定义。这不仅对于准确地生成脚本是很重要的，而且对于定义每个事务中需要计时的部分同样重要。（参见图2-3中事务的例子）。

确定所有输入数据的要求和预期结果

这是在每一个步骤中需要用户输入的信息，而且是定义一个事务的关键部分。例如：登录、输入密码以及（更重要的是）这些操作会得到什么样的响应。

定义事务涉及的用户类型

例如管理员、客户、呼叫中心操作员，还有组长。定义用户类型通常是为了确定这个事务使用量是大还是小。举个例子，呼叫中心操作员的数量比管理人员多，因此管理员可能会限制自己的后台管理任务，而操作员将处理大量的客户查询。

事务的链接模式是什么

事务可能会通过局域网、广域网和互联网，或者也可能是这几种方式的组合。正如我们讨论过的，一个在局域网环境下性能良好的事务，在部署到一个低带宽的广域网环境中时，可能就不是这样了。

主动型事务还是被动型事务

主动型事务指的是那些对性能要求高的且对用户可见的操作，而被动型事务指的是那些通过提供现实的负载实现测试的后台操作。例如，可能有一个需求会包括一定比例的用户，这些用户虽然已经登录，但却并没有真正地使用系统。对于这一类型的用户，事务可能会简单地定义为登录，在一段时间内无任何操作，然后退出——这就是被动型事务。

技巧

对于这个步骤用不着太担心，即使您的应用程序看起来很复杂，而且功能强大。以我的经验来看，无论是什么样的应用程序，采用什么样的架构，最终被选定的事务数也很少会超过20个。假如您发现事务的数量超过预期，则有必要对此进行一个风险评估，以决定这些操作在给定的性能测试时间里是否确实有必要测试。