|
|
知识路径： > 测试技术的分类 > 应用负载压力测试 > 负载压力测试实施 > 测试环境、工具、数据准备 > 测试工具准备 >
|
|
相关知识点：3个
|
|
|
|
|
古人云“工欲善其事，必先利其器”，进行负载压力性能测试首先应该选择一个合适的测试工具，一个测试工具能否满足测试需求、能否达到令人满意的测试结果，是选择测试工具要考虑的最基本的问题。更进一步可以考虑一些细节问题，比如该工具对于处理扩展的交互（例如一个请求取决于上一个请求的结果）如何；对于处理cookies（cookies对于许多面向会话的J2EE系统是必不可少的）如何；如果J2EE应用程序客户机需要处理一些JavaScript，以进入下一次通信会如何处理；在收集了响应时间数据后，如何对它进行分析；对CPU时间、网络使用、堆大小、分页活动或者数据库活动如何监控等都是选择一个测试工具需要考虑的具体问题。一些高端工具与基本工具往往在一些细节、适用范围以及易用性方面存在差别。比如，顶级的负载测试工具可以模拟多个浏览器，与大多数应用服务器集成，收集多个服务器主机的性能数据（包括操作系统、JVM和数据库统计数字），生成可以在以后用高级的分析工具分析的数据集。
|
|
|
|
当然，测试工具的选择首先应该看是否能够满足基本测试需求，该工具必须可以模拟应用程序客户机，如果应用程序使用一些不常见的浏览器功能组合或者其他非标准客户机技术，那么就排除了相当一部分候选者。具备了基本功能后，可以考虑工具的生产率。一般来说，包含的分析工具越多，可以记录的性能数据类型越多，可以达到的生产率就越高，价格也就越高。不过有些低端负载测试程序是免费的，在预算有限的情况下，“免费”的意义是不言自明的。
|
|
|
|
|
|
|
|
首要要求一定是负载测试程序能够处理应用程序所使用的功能和协议。
|
|
|
|
|
|
这是负载测试程序最基本、且最重要的功能，它有助于确定哪些是负载测试程序以及哪些不是。
|
|
|
|
|
|
如果不能编辑客户机与服务器之间交互的脚本，那么就不能处理除最简单的客户机之外的任何东西。编辑脚本的能力是最基本的，且小的改变不应该要求重新生成脚本。
|
|
|
|
|
|
如果不支持会话或者cookies，就不算是真正的负载压力测试工具，并且不能对大多数J2EE应用程序进行负载测试。
|
|
|
|
|
|
测试程序应该可以让您指定每个脚本由多少个模拟用户运行，包括让您随时间改变模拟用户的数量，因为许多负载测试可以做到从小的用户数量开始，并慢慢增加到更多的用户数量。
|
|
|
|
|
|
每一个脚本都必须定义一个方法来识别成功的交互以及失败和错误模式（错误一般不会有页面返回，而失败可能在页面上得到错误的数据）。
|
|
|
|
|
|
如果测试工具可以检查一些发送给模拟用户的页面，这会很有用，这样可以做到心中有数，以确保测试工作是正确进行的。
|
|
|
|
|
|
可以用不同的工具来分析测试结果，这些工具包括电子表格和可以处理数据的自定义脚本。虽然许多负载测试工具包括大量的分析功能，但是导出数据的能力使您在以任意的方式分析和编辑数据方面具有更大的灵活性。
|
|
|
|
|
|
真实世界的用户不会在收到一页后立即请求另一页，一般在查看一页和下一页之间会有延迟。考虑时间这个标准术语表示在脚本中加入延迟以更真实地模拟用户行为。大多数负载测试程序支持根据统计分布随机生成考虑时间。
|
|
|
|
|
|
用户一般不会使用同样的一组数据，每位用户通常与服务器进行不同的交互。模拟用户应该也这样做，如果在交互的关键点，脚本可以从一组数据中选择数据，则可以更容易地让您的模拟用户表现出使用不同数据的行为。
|
|
|
|
|
|
相对于编写脚本，用浏览器手工运行会话并记录这个会话，然后再编辑会容易得多。
|
|
|
|
|
|
一些应用程序大量使用JavaScript并且需要模拟客户机支持它。不过，使用客户端JavaScript可能会增加对测试系统上系统资源的需求。
|
|
|
|
|
|
得到测试数据只是成功的一半，另一半是分析性能数据。因此测试工具提供的分析工具越多，就越有利于从不同的方面进行数据分析。
|
|
|
|
|
|
基本负载压力测试工具测量客户机/服务器交互中基于客户机的响应时间。如果同时收集其他统计数据（如CPU使用情况和页面错误率）就更好了，有了这些数据，就可以进一步做一些有用的工作，如查看服务器负载上下文中的客户机响应时间和吞吐量统计。
|
|
|
