[资料] 基于云的测试系统经历

介绍
　　任何特定软件即将发布并投入生产期间，其性能一直备受关注。尽管一软件已被用户证明如预期的正常运作（通过功能测试后），故障仍可能会发生，尤其当它无法承担用户生成的大量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的无线宽带。
　　对于云平台，只用局域网速度进行性能测试。因此，这一基于云的系统的用以执行性能测试的完整测试用例如表3所示：

表3.性能测试用例

案例研究 –把设计放入执行
　　一个开源性能测试工具被用来执行所有性能测试的云系统测试用例，因为相对于其他性能测试工具，它允许越来越多的user loads且没有虚拟用户许可证限制。
然而，手动执行被用于客户端系统，因为客户端系统只能在上网本上运行，所以手动测试更实用。
　　分布式性能测试方法被用于执行测试，以便工具可以有效地管理代理。
　　工具的环境设置如图3所示：

图3. 分布式性能测试执行的环境设置

　　性能测试结果分为两组：云平台的测试结果和客户端的测试结果。
　　表4详述了云平台的性能测试结果，而表5显示了客户端的性能测试结果。
　　此外，为了更好地理解，图4以图表形式展示了云性能结果。

表4.云平台性能的响应时间结果

图4.云平台性能测试结果

表5.客户端性能的响应时间结果

　　从给出的结果，可以进一步解释几个研究发现。
　　研究发现如下：
　　▪云平台或（客户端可从其获得在线服务的）服务器端系统能够在性能标准的5秒内响应1到100个虚拟用户而无任何中断。
　　▪虽然云平台仍然可以成功响应3000个虚拟用户，但响应时间延迟了，超出性能标准的5秒。
　　▪在客户端，最终用户可能会遇到：在通过客户端系统获取在线服务时，云平台的用户负载过大，响应时间延迟。
　　▪比起那些更慢的互联网获取，通过使用一个更快的互联网连接，最终用户可以更快地获取在线服务

　　结论
　　由于本文的重点是性能测试的测试用例设计，一个展示这些测试用例是如何被用于执行的案例研究为本文提供了论点。很显然，正确的规划对保证任何性能测试的成功都非常关键。性能测试不应该基于“想要时”或“要求时”。性能测试的测试场景和测试用例需尽可能早地被定义和设计，就和其他类型的测试一样，比如功能测试。这将决定能否顺利执行性能测试，其中包括：性能测试工具的选择，测试环境的设置，如何做出性能衡量和分析应该做的选择，性能结果不符合指定准则时扩大云平台的行动计划，以及执行测试的时间和资源。
　　这些到位了，任何经过了严格性能测试的系统，一旦置于生产环境中，都能够应付日益增长的负载量，并且对服务其用户更稳定，更反应灵敏。