5.2.2 压力测试
压力测试的目的是找出超出服务峰值负载时被测系统的行为。它的结果说明了当服务负载超预期增长或是当出现突然的、意料之外的峰值时，服务可能发生什么事。传统的压力测试不断增加负载，直到被测系统在某一刻发生某些事情。压力测试可能导致响应时间急剧增加或是系统通知事件不断出现，当然，压力测试也可能导致被测系统完全失效。对云服务进行压力测试会影响使用该服务的其他客户，因此在压力测试期间，测试人员需要确保遵守该服务的使用条款。对服务供应商来说，他们倒是可以享受压力测试，只要没有客户连接到正在被测试的服务就行。
压力测试的一个变种是测试系统在供应商承诺的负载水平边缘处的行为，执行这种测试能够帮助客户得到有用的信息。达到或超过阈值时，是出现可见的通知，还是性能表现一落千丈？负载变回到低于阈值水平后，情况会恢复吗？在这种情况下，我们其实是在用边界值分析方法测试负载。在后续如何测试服务弹性的部分，我们将详细介绍这方面的内容。
5.2.3 耐力测试或容量测试
有各种不同的原因导致性能下降。通常的原因包括内存溢出（日志文件、内存泄漏）、文件碎片化，或者简单地因为在不断扩大的数据集中找到特定数据变得越来越困难。一段时间后，系统性能可能会下降甚至服务会完全停止。使用实际用户负载测试可能的性能下降需要过长的执行时间，因此在容量或耐久性测试中，我们在短时间内加入尽可能多的负载，以更快地获得结果。然而，这种做法可能带来风险。和压力测试一样，这种做法可能轻易就超过了官方允许的负载。作为客户，需要考虑没有明确标明，但在"公平使用原则"中存在的边界。服务供应商当然不会受限这一点：在这种情况下，供应商自行测试服务的稳定性甚至是明智的行为。
生产环境中的性能下降可能表明出现了内存问题，但还有很多其他的可能原因（如不断增加的负载）。支持部门经常使用内存监控工具，显示内存的即时使用情况。用户可以结合IaaS自行执行监视，因为IaaS提供了可自行安装监控工具的（虚拟）环境。提供的环境中是否安装了监控工具不是我们选择IaaS服务提供商的标准，但可以是我们选择软件的标准。对于SaaS来说，提供监控工具是供应商的责任。
5.2.4 测试弹性和手工操作的可扩展性
测试弹性是性能测试的一个新方面。对弹性进行测试的目标是确定服务的性能是否满足客户的整个负载范围，以及分配的服务容量是否与服务负载相称。按使用付费的模式往往与服务的弹性相关。管控（财务）处理可以成为弹性测试的一部分。
该测试方法执行负载测试，先增加负载至超出边界（扩展），然后将负载降低到边界以下（缩减）。在整个测试过程中，可能需要手动操作。同时，需要指明软件包在边界位置的可能行为（见5.2.10节）。
测试弹性中可能出现以下错误。
-（自动的）容量扩展不符合需求。
-（自动的）容量缩减不符合需求。
-容量扩展和缩减过程中出现功能问题。
-基于使用付费的信息不符合需求。
5.2.5 建立测试用例
性能测试用例基于负载剖面（Profiles）。测试负载基于各种需求状况来建模，如平均值、最大值、压力、峰值、较低值。验收标准显然形成了测试依据，但还不足以用于建立测试用例。性能测试用例来源于运行情况，最好根据服务的实际或预期使用情况生成用例。这样，测试会尽可能接近真实情况，测试结果也会有足够的代表性。
通常，不可能对服务的所有功能进行性能测试。需要基于风险分析进行慎重的选择（系统的运行情况可以提供重要的参考）。负载剖面描述了预期的用户数，最好带有用户活跃的时间段。剖面还需要描述用户执行的操作。注意定期（批处理）行为，例如，定期的票据操作。这些定期操作在特定的时间导致额外的（峰值）负载。如果多个应用程序在相同的位置运行，这也必须加以考虑。与被测应用具有重合高峰负荷的应用程序也会对性能产生影响。在公有云中，来源于其他渠道（客户）的负载是个未知因素。基于这些剖面，我们执行特定的测试用例，说明在特定的时间段内，服务是否符合我们的期望。
本文选自《云服务测试》第五章，本站经人民邮电出版社和作者的授权。
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
