3.3.8　网上银行案例回顾

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

测试团队

只有一个人的测试团队显然是不理想的，但这种情况也并不少见。提供性能测试服务的公司通常至少会配备一名项目经理和至少一名测试执行人员。当性能测试在公司内部进行时，情况就会更加不确定：很多公司没有专门的测试团队，他们倾向于随机分配资源。对于那些中型和大型的企业来说，他们则会进行常规的性能测试，依我看来，一个专门的性能测试资源是必要的。

测试环境

从本次性能测试案例提供精确的测试环境来看，在模拟真实部署环境方面做得很理想（例如，测试环境与用户环境完全是同一个环境）。本案例这个不同寻常的情况会引起另外一些问题，诸如生产环境下的其他活动会影响到性能测试的结果，还可能会对应用程序的真实用户造成负面影响。如果这些问题都能够得到很好的解决，那么这种方法不失为一种能够提供理想的性能测试环境的非同一般的做法。

KPI监视器

正如前文所述，由于客户内部的限制不允许我们使用性能测试工具中所集成的监视器，因此客户有必要自己进行性能监控，然后测试团队还需要将这些数据手动整合到性能测试工具中进行统一的结果分析。

这种情况很不理想，因为这使得分析测试结果变得相当复杂，同时也使在网络和服务器性能指标上准确调整响应时间及扩展性数据变得很困难。然而，有的时候我们别无选择。

本案例中，性能数据通过CSV格式导入到Excel中，从而对其进行图形分析。假如你无法使用集成的KPI监视器，那么将第三方数据导入性能测试工具的分析模块中是种非常有用的方法。

性能目标

唯一的性能目标就是测试基于1000个并发用户的软件可扩展性。此目标对于最小响应时间没有具体要求，因为应用程序已经部署并已投入使用，所以响应时间可以很轻易地推测出来。1000个用户的可扩展性目标是随意给出的，并且软件的利益相关者没有在这方面达成一致。这意味着性能测试团队要冒很大的风险，因为这会对测试结果的分析带来一定困难。

本案例在性能测试执行的过程中，对系统最终用户操作的独立监控可以消除对前面所提到的无法达到负载的担心。正如在3.3.7中论述的那样，即使性能测试工具能实现1000个并发虚拟用户的负载，但是单靠其本身是无法实现1000个并发程序用户的目标的。解决这个难题的方法就是在性能执行过程中让上百个真实用户保持活动状态，他们能有效地充实性能测试工具所生成的并发软件用户数目。

录制事务脚本

为了避免录制事务的混淆，这十个事务需要精心挑选并记录。这受到了主流的影响，正因为如此，在性能测试中使用20个以上的事务是很非常罕见的。脚本唯一需要修改的地方在于登录的认证。

数据需求

网上银行的输入数据需求仅限于一张合法的卡号列表，这些卡号为每一个虚拟用户提供登录到程序所需的初始权限。

目标数据库是真实的数据库，它与真实环境下的数据规模一致。然而，性能测试只关注哪些数据需要提交到数据库。尽管针对用户读取数据库的操作进行了测试，但却没有机会测试数据库的写操作，这就造成了一定的风险。

运行时数据需求包括：确认并重复使用一套标准安全问题的问答，从一套PIN码中随机选取的字符，以及输入到测试事务的卡号数据。

测试设计

性能测试设计关注一个独立的测试类型，我将其定义为负载测试。应用程序可以轻松地在最繁忙的时段同时支持380个用户，我们前面提到的目标是试图使用户数达到1000，大约是现有能力的四倍。正如前文提到的，在做测试设计时要加入具体的思考时间和步进时间，以此来保证事务吞吐量的准确性。