介绍
任何特定软件即将发布并投入生产期间，其性能一直备受关注。尽管一软件已被用户证明如预期的正常运作（通过功能测试后），故障仍可能会发生，尤其当它无法承担用户生成的大量loads， volumes， transactions等时。评估软件的质量和适用性时，很少认真考虑这种非功能需求。因此，谨慎和周密的策划分析和性能测试用例设计是防止软件性能故障的关键。有了正确的性能场景，就可以系统地进行测试执行和软件性能评估，从而可以对性能改进做出详细的分析和建议。
本文通过展示一个实际的案例研究（关于如何为一个基于云的系统规划和设计性能测试用例）解决了这个问题。性能测试结果对性能测试执行的分析，被证为测试用例设计的有效性的证据。
关于被测的基于云的系统的概述
开发被测系统的目的是：通过（最初是上网本上的）移动设备上的统一智能平台为大众提供各种在线服务。
该系统主要包括几个子系统：安装在上网本上的客户端系统，智能服务门户，位置感知服务，内容整合服务，以及承载所有在线服务系统的云或虚拟平台。
图1．被测系统的逻辑结构
客户端系统是使用Java语言开发，Java网络启动协议（ JNLP ）执行的。为了获取所需在线服务，客户端系统到智能服务门户网提出服务请求。存储所有服务的门户网还结合了内容整合服务和位置感知服务。所有这些使得合适的内容根据所请求的服务被推送到客户端系统的最终用户那儿。除此之外，门户网站还能够简介并结合适合服务的相关内容。另一方面，多个虚拟机上的云平台承载了所有子系统（智能服务门户网站，内容整合，以及位置感知），可以运行虚拟机实例并提供虚拟机负载的可扩展性。
该系统的逻辑结构如图1所示。从部署的角度去看，图2展示了整个系统的操作环境。
根据这两个图，很明显本系统的性能测试需要覆盖终端用户场景及服务器场景。
这是因为一个成功的服务器性能测试并不能保证在客户端运用该系统时，最终用户也会同样成功。
性能测试
这只是常用来衡量任何被测系统性能的一个概括。通常，我们设计并执行一次性能测试以弄清系统是如何响应特定load的，无论load有没有被定义为许多并发用户，volumes或 transactions。
如下表1描述了性能测试各个领域的重点。
表1．性能测试重点
上述重点保证了被测系统应对用户不断增长的loads时是可延展的，且一旦它被发布并投入生产就没有任何意想不到的问题，长远来看还有助于提高最终用户的满意度。这也将会使该系统比市场上的其它相似系统更具竞争优势。
设计性能测试用例
评估系统的测试用例的设计主要是受早前在规划和分析阶段设置的性能标准制约的。该系统需要足够快的响应速度，或者至少要达到规定的通过性能测试的最低性能标准。
图2.被测系统的物理架构
如果系统可以表现得超出这些标准，即比最低标准值更快，该系统则被认为具有更好的性能及未来可以应对更多用户的可扩展性。另一个重要方面是确保性能测试用例的目的是建立真实世界模拟测试。现实世界测试用例将大幅度提高测试结果的可靠性。确定要模拟的测试用例时的重点是“最常见使用场景”和“业务关键使用场景”。测试用例一度不得不预测最常见的场景，因为系统还未上市且唯一知道的信息是：要求的程度。一旦系统上市，例如β测试中，就应有足够的关于用户如何使用系统的信息。该系统在Apache Web服务器上，因此可以访问日志，上面提供所有游客到过系统的记录。日志可以用“流量分析器”跟踪一直以来的用户的模式和习惯。因此测试用例可用于反映真实世界场景。系统拥有者或利益相关者为使该系统通过性能测试而设置的标准规范是：系统需要在1到100个并发用户的负载下5秒内做出响应。
然而，该标准应当通过设计正确的、运行系统的、可能的场景而被进一步分解。最根本的是把性能测试一分为二：客户端性能和服务器端（云计算）性能。原因是，一个成功的测试服务器端并不等同于成功的客户端，反之亦然。
利益相关者都同意，要测试的用户数目为1 ，100，200 ，300，400 ，500，1000 ， 1500和3000个并发（虚拟）用户。这些数字与下面表2中给出的各场景相关：
表2.性能测试场景和相关虚拟用户
设计性能测试用例时通常会被忽略的一方面是：将表2中的场景和一个网速测试或网络延迟连接以获得更逼真的测试用例，像对客户端系统所做的一样。这是为了模拟用户将如何体验不同互联网连接速度下系统的响应。选定的匹配性能测试的速度是标准LAN速度（这种情况下，1GbpsLAN速度），无线LAN速度，1 Mbps的有线宽带和0.44 Mbps的无线宽带。
