3.4.8　呼叫中心案例回顾

在后面的内容中我们依据已经建立的性能测试要求列表对这个呼叫中心系统个案的研究进行一次评定。

测试团队

这个测试团队包括一名项目经理和一名测试执行人员，满足我所认为的标准性能测试项目的标准。由于这个应用程序不是公司内部开发的，所以任何问题都要反馈到软件厂商那里。这意味着在问题解决以前，测试不得不暂停一段时间，而这将不止一次地拖延系统既定的部署日期。

测试环境

测试环境是标准的测试环境：有一套独立于真实网络环境架构的硬件。应用服务器的配置与真实应用程序服务器的配置非常接近，最大的差别在于，测试环境下只有一台应用服务器，而真实环境中却是通过负载均衡技术连接的两台服务器。

应用服务器在数量上的差异造成了中间件的瓶颈。这种情况下，你在执行任何压力测试的时候都要小心谨慎。如果负载生成过量，就会造成应用服务器过早地超出负载，因而得出的结果也会有误差。

然而，这种测试配置环境（本次测试的测试环境）却为我们提供了一个测量单台应用服务器负载上限的机会，它为我们提供了关于应用服务器水平扩展性的数据。

KPI监视器

由于本次性能测试应用专门的测试环境，我们就可以使用性能测试工具里自带的服务器和网络监控功能。我们可以通过整合测试工具和微软的Perfmon来获取服务器信息。这是最理想的状况，在每一个性能测试完成后都可以实现响应时间和监控数据的自动关联，这就是使用自动化性能测试工具的最大好处。

性能目标

性能测试的目标是系统支持100个并发用户，同时响应时间不能比上一轮测试过程中的相应时间长。我们利用“检查点（Checkpoint）”来关注Web服务的性能，并且为版本间性能的比较提供一个简单的方法。

录制事务脚本

本次性能测试过程中从呼叫中心客户端选出了5个核心的事务作为此程序性能测试的基础。

录制脚本的问题在于应用程序架构属性的不同寻常，它包含大量的Web服务请求，每一个请求都包含一套广泛的参数。这些参数在版本更新期间会不断修改，并且相关文档也经常描述不清，这就让人无法确定到底改动了哪些地方，结果就造成在各个测试环节用于录制脚本的时间有很大的差异，有时甚至需要重新创建一套全新的脚本，而且并不是简单地复制一下以前的脚本，仅仅改动一下其中的代码而已。当程序版本更新的时候，有些代码就会变得无效，这是使用脚本事务的缺点。

数据需求

呼叫中心的输入数据需求比网上银行业务的情况复杂的多。在进行测试之前需要收集大量的合法预约和车牌号信息等。这些信息可以通过SQL脚本从目标数据库中提取，然后把这些信息输出到CSV格式的文件中。

由于目标数据库是一份真实数据库的最新副本，所以在数据规模方面没有任何问题。因为这是一个真实的测试环境，所以它不限制事务脚本所代表的最终用户活动类型。唯一的缺点就是不能在每次测试运行结束后重置数据库，我一直建议在两次测试执行之间应该重置数据库，这样才能避免由于上一次测试执行对数据库的更改对性能测试结果造成负面影响。

运行时数据需求是相当复杂的，它包含对不同数据组件的截取和重用，这些数据组件代表了服务器生成的关于车辆预约过程中的信息，这就需要程序开发人员参与创建原始事务脚本。

测试设计

在本案例中测试设计使用了“逐步递增”的方法，它每步增加25个虚拟用户，并使他们维持15分钟的稳定运行时间，这允许我们在这段时间内监控系统的响应时间。