Shift Left性能测试-不一样的测试方法-阿里云开发者社区

开始着手全球性IT转型项目对于任何组织来说都是一件即兴奋又富有挑战的事情。当然，降低失败风险是整个项目的主要目标之一。而测试是能明显帮助降低失败几率的活动之一。

　　本文介绍了与传统多用户 性能测试所不同的测试方法；尽管所使用的工具相同，但该方法结合了现代数据可视化技术，从而早早就能对那些可能存在有“沉睡着的”性能问题的特定位置及应用程序区域有所洞察。

　　大多数项目会首先专注于功能，然后才是其它。使用类似HP LoadRunner或Neotys Neoload这类测试工具的多用户性能测试往往属于测试循环后期才会发生的活动。很多时候会与UAT并行发生，而这时新系统已经暴露给终端用户了。因此在性能测试时发现性能问题的几率很高，修复的几率却很低。因为这种情况下，通常距离上线时间已所剩无几。

　　多用户性能测试通常发生于项目后期的原因有多种，根据项目的不同而不同。以下两个原因最为常见：

　　1.多用户性能测试要求工具和自动化。自动化性能测试脚本所需的资源只有在性能测试即将开始时才有望存在，即应用程序达到“稳定”的开发状态时。假如自动化一个性能测试脚本需要2天的话，那么拥有多个测试脚本（比如：10至20个）就要花费大量的时间或人力。为了不破坏当前在性能测试脚本开发上所花费的资源，该阶段不允许修改应用程序。所造成的结果就是：开发阶段的任何延迟或需要对代码进行大量的修改都将进一步延误性能测试，这给执行带来了风险，也不能及时提供相应价值。

　　2.多用户性能测试需要一个类产品环境。尤其是处于IT转型的项目，这样的环境不一定在项目初期就存在，需要时间、精力和金钱去构建。但与之竞争的是早期测试周期中所有其它必需的对测试环境的配置和那些“真正办事的”功能。对项目而言，绝对需要类产品环境的最早一刻是测试部署时（即彩排时刻）。而这时要想让性能测试对项目成果产生正面影响已为时过晚。

　　作为降低风险的活动，性能测试是绝对必要的。真正的挑战在于如何以不同方式进行，这样可以在有更多时间和预算时就能解决与性能相关的问题。性能测试应在测试生命周期内更频繁地被执行，同时与主要发布周期相互协调，从而提供更好的投资回报，并不断地帮助降低项目风险。

　　 以下这些目标很可能与大部分IT转型项目的目标类似：

　　1.现代化全球IT通过更新ERP和CRM应用程序到最新版本，为未来创新铺平了道路。

　　2.合理化优化应用程序以降低成本和复杂性

　　3.集中化集中化IT基础架构以降低成本和提高灵活性

　　本文所要说明的方法曾被一个处于IT转型的项目采用，该项目运行于一个中等规模企业，该企业在全球范围内运营，世界各地的办事处数量也在不断扩大。其通过标准的客户关系管理系统（CRM）和企业资源规划（ERP）应用程序, 在本地办公室内面对面地处理与客户的业务。

　　这两个应用程序的共同关键属性是显示大量数据给用户的同时，执行关键业务流程。此外，这些面向客户的业务流程还需要输入大量数据集（数百个记录/业务流程），然后在彼此上层处理。在以前使用大量数据集的测试业务流程往往只计划发生于用户验收测试（UAT）。其主要原因是：想在允许时间内覆盖所有必需测试集而手动输入数据的话，太费时间。数据迁移工作流被指定来为UAT传输这些数据，但是由于延迟，我们往往要等到UAT开始时才能期望用得上这些数据。

　　之前版本的CRM解决方案已经报告存在性能问题。当时该CRM已经集中化，并应用于世界各地的多个办公室。这些性能问题因地点而异，分布于不同的功能块；而且是由终端客户报告出来的，没有具体的测试或时间可供参考。

　　相反，之前的ERP解决方案是独立安装于各个地区或国家的，目前还没报告有性能问题。但是集中运行这两个应用程序的话，不由得让人担忧其性能，尤其在处理数据输入、扫描和打印等活动时。

　　可拓展性测试虽然是多用户性能测试的一个关键点，但却算不上该项目的关注点。以市场为导向的标准软件在实施时尽量地减少定制，并在产品环境中配置大小正好的基础设施服务器。

　　非功能性需求被定义为该项目的一部分，却需要被验证。该组织多年前曾购买过HP LoadRunner作为性能测试的首选工具。但由于预算的限制，后来并未在测试工具上做进一步的投资。

　　 综合考虑各方面的限制和需求，该项目将以下这些定义为性能测试的主要目标：

　　1.度量度量来自不同办公地点的应用程序的性能。

　　2.对比与非功能需求的性能结果进行对比。

　　3.改进为潜在的改进提供建议。

　　该解决方案从单一用户角度出发进行性能测试。对关键业务流程的测试将在数个月内以真实的、自动化的形式在世界各主要地点进行，同时还覆盖了各主要发布周期。现代可视化技术将显著地减少分析及诠释测试结果，还有呈现到 项目管理团队的时间。该单一用户性能测试方法相比于“传统的”多用户性能测试有以下众多优点：

　　1.不需要类似产品一样的环境，可以使用任一现有测试环境。

　　2.其迭代方法允许性能测试脚本随着应用程序的发展而不断成熟，频繁的使用带来了良好的投资回报。与其冒着无法及时交付测试结果的极大风险而在短期内将大量预算花费在聘请众多性能测试脚本编写者上，这些费用大可以用于长期聘请一两位性能测试脚本编写者。

　　3.并非所有性能测试脚本都要同时准备好，并运行。

　　4.无需工作负载配置文件。

　　5.一旦类产品环境可用，自动化脚本可重用于多用户性能测试。

　　6.相比于手动测试，由于数据创建是自动的，单一用户性能测试可以在业务流程中使用更多更真实的数据量。

单一用户性能测试解决方案在执行时用到以下工具和方法：

　　1.资源上的限制决定了客户端的执行性能（比如：渲染时间）将不被考虑在内。这将通过在客户机上使用Profilers来完成(谷歌开发者工具)，或将功能测试自动化工具结合类似WireShark等网络协议分析器。测试最初只专注于包括网络时间在内的服务器响应时间。

　　2.每个办公地点都会有两个用户配有已识别好的台式机，机器上装有HP的Load Generator软件。来自同一地点的两组测量数据保证了所收集数据的正确率。如果在任何时候两台机器针对相同活动所收集的数据都相差很多，我们就可以认为是本地用户设置出了问题。这不需要额外的硬件投资，也能从真实用户地点收集到响应时间测量值，因此特别真实。在该测试中所用到的脚本也能在多用户性能测试中复用，为性能测量提供统一、可重复的方法。不需要支付其它附加的测试工具许可证费用。

　　3.每个办公地点和数据中心的HP Load Generator分别以每15/1分钟频率执行性能测试脚本，确保我们不会稀里糊涂地陷入到执行多用户性能测试的陷阱中。其主要目的是将测试系统中的并发降到最低。从数据中心获取的测量数据扮演着“基准值”的角色，换句话说就是所谓的参考点。因此不同办公地点间的响应时间与“基准值”的不同可被假定为终端用户总体响应时间中与地点相关的那一部分，具体包括影响终端用户性能体验的网络延迟、路由、繁琐性及大小等等。“基准值”代表了服务器时间的具体值。根据测试环境的配置，从该测量数据中获取的结论可以用来判断是否存在与测试环境设置相关的问题。总体上的建议是测试环境应只水平地与产品环境版本进行缩放，而CPU速度、每个并发用户的内存及硬盘等输入输出速度应当与产品环境相当。这样我们就就可以很容易的假设”基准值”就是服务器的实际性能.

　　4.监测网络延迟（ICMP）和路由（tracert），并将其作为标准HPLoadRunner客户端吞吐量的一部分。这三个测量值的组合允许我们评估网络、路由和带宽限制的质量。

　　5.通过使用较低层的HP LoadRunner Web/HTML协议，应用程序的繁琐性将自动被记录，其影响也可评估出。而使用类似Ajax True Client协议这样较高层的HP LoadRunner协议，在检测繁琐度时则需要额外的精力和工具（比如：Wireshark或Google 开发者工具集）。

　　该整体SUPT方法可以通过使用其他性能测试或类似HP Business Availability Centre(HP BAC)这样的性能监控工具以类似的方法来执行。

　　为了收集有价值且有效的数据，我们在所有办公地点将所有性能测试脚本执行上一段足够长的时间。每个地点都使用两个Load Generator的策略让我们对测试结果更有自信，也帮助我们定位及解决用户在配置上的不同。

　　“基准值”允许我们在不同环境上执行测试，比如：系统集成、用户验收或预产品等环境，通过对比不同地点的响应时间及相应数据中心的响应时间，我们可以区分出特定性能问题来自应用程序，还是环境或地点。

　　但要想使之成为可能的先决条件是在数据中心每隔一分钟执行一遍性能测试脚本的循环。而其他所有地点则会每15分钟循环一遍（每个地点间交错开1分钟的间隔）。目的在于观察服务器和远程地点在执行相同流程时响应时间的不同，而不是让服务器超载。

　　一旦结果出来，我们要面对的挑战是如何尽快有效地分析这些数据并为以下内容提供信息和分析数据：

　　1.性能最差的地点。

　　2.性能最差的测试脚本（业务流程）。

　　3.针对非功能需求的性能（SLAs）。

　　4.可被网络管理团队定位的路由和网络延迟信息。

　　5.针对如何改进性能所提出的建议。

　　SUPT的结果是由每个地点每一个事务响应时间而组成的大数据表。我们选择第90百分位作为响应时间的代表值。

　　 圆形可视化

　　我们所面临的挑战是找到能快速分析这些数据的工具。查看过各种各样可视化工具及技术之后，我遇到了Mike Bostoks的“D3”项目，从那找到了圆形可视化及Circos，从而发现完成这一工作的最佳工具。

　　“Circos是将数据和信息可视化的软件包。它以圆形布局可视化数据，这使得Circos成为研究事务或地点间关系的理想工具，也是展示图表的理想工具。圆形布局除了美观外，还有其它的有利因素。”

　　有不少工具可让Circos更易于使用，Table Viewer tool就是其中一个，在网上就可以找到。

　　建议在Linux上下载并配置Circos。第一次分析时，最简单的方式是使用这里的Table Viewer tool的在线版本。

　　性能测试结果需导入到数据表中，其内容应与下图相似。数据表还需符合以下要求：

　　1.无重复事务名。对于所有业务流程中相同的业务，推荐使用“S01_xx”作为惯例（比如：S01_Login）。

　　2.事务或地点名中无空格。

　　3.将地点作为列（“A1”，“A2”等）

　　4.将HP LoadRunner事务名作为行（“da”，“db”等）。

　　5.将第一列重命名为“Label”。

　　6.尽量保持名字短小。

　　7.将文件分割符选为“Tab”。

　　单单使用Table Viewer默认在线配置就能生成令人惊喜的结果。用于在线生成图形的配置文件可以下载下来与本地安装一起使用。

　　所得到的结果是类似下图。理解该图像的关键是从12点钟开始，然后顺时针查看HP LoadRunner响应时间测量值；或者参考事务（小写字母），然后逆时针查看地点（大写字母）。地点所对应的厚度是该地点所有响应时间的总和。同时生成的柱状图对进一步分析也非常有用。仅通过视觉比较，我们一眼就可以看出哪些地点受到低性能的影响，以及相对应的特定流程和步骤。

　　由于事务的数量可以相当大，该图像在分析事务时信息量可能会有所减少。下一步我们需要过滤掉那些没有问题的响应时间。比如那些响应时间少于最低SLA（以5秒为例）的事务就可以被排除出去。使用Table Viewer工具的话，有两种方式可以达到这一目的。其中一种是过滤掉这些事务，但将其保留在总体计算中。

　　该图像确实突出了性能最差的事务，以及它们在总体业务流程性能上所占的百分比，同时它还为理解潜在的性能改进提供了基础。

　　要想在更紧凑且缩放的视图中查看相同信息的话，我们还可以将那些通过SLA的事务从总体计算中排除。

我们现在可以清楚地识别出“fa”、“ea”、“dz”和“da”事务的性能是最差的，而“A1”、“A2”和“A8”地点的性能最好，“A1”地点则是数据中心。

　　现在的目标是生成网络延迟和路由的相似视图。第一步我们需要用LoadGenerator将HP LoadRunner Analysis中的从源到目的地的路由所对应的总网络延迟信息分组（Analysis工具的一个功能）。然后将这些信息导出到电子表格中。

　　我们的目的在于验证网络延迟是否在预期的SLA范围之内。下图比较了网络延迟测量值和已知的从源到目的地的SLA临界值。为了了解是否有已知地点超出SLA，需要添加主机地点的信息。举个例子：如果HOST11位于欧洲，那么SLA就通过了，如果位于其它地方，则失败。

　　同样每个地点的吞吐量也要与参考点进行对比，与地点的假定可用带宽及用于数据中心的实际带宽进行对比。数据中心地点的测量值将决定达到假定的接近无限带宽的可能最大值（比如：千兆以太网）。

　　下一步目标是为网络管理团队获取更多的细节，我们尝试获取更多关于路由和网络延迟的详尽分解信息。该分析的基础是HP LoadRunner分析工具中的网络段延迟图（Network Segment Delay Graph）。

　　 桑基图

　　桑基图是有向图，其箭头线的大小代表了流量大小。桑基图被用于各种流程的可视化，不限于能源和材料，是任何“从”源“到”目的地的流程定义（实际或虚拟）。桑基图将我们的注意力带到了流量最大的流程上的同时，也显示了各个流程间的流量比例，指示了“从 - 到”的流动方向。桑基图是以爱尔兰工程师Captain Matthew Henry Phineas Riall Sankey（1853-1925）的名字命名的。

　　下图的创建使用了来自http://www.d3noob.org/ 的桑基图实例和从HPLoadRunnerAnalysis工具中提取的网络段延迟数据。