|
|
知识路径： > 自动化测试 > 负载压力自动化测试 >
|
|
相关知识点：2个
|
|
|
|
|
负载压力测试工具基本上都是采取录制回放的方式来模拟用户的实际操作的，而且测试工具一般都会有一个后台代理进程，通过该代理进程，测试工具可以监视并获取在各种通信协议下应用系统的客户与服务器端的通信信息，测试工具会用一种类C或者其他的脚本语言（TSL）生成一个测试脚本，该脚本记录了你对服务器的请求过程，然后测试工具就可以回放刚才的访问过程，接收服务器的响应，当然你也可以用手工编程生成这个脚本。
|
|
|
|
通常情况下，实施负载压力测试的工作示意图如下图所示。
|
|
|
|
|
|
|
|
当被测系统运行时，脚本生成器会自动获取系统客户端与服务器的通信信息并转换成测试工具可以识别的脚本，测试工具通过控制台将测试脚本分发到其他负载生成器上以模拟多用户对服务器的并发访问，同时，控制台还可以通过服务器上开启的远程RPC服务，获取相关的资源使用信息，最后可以收集测试数据。
|
|
|
|
在进行测试脚本录制与分配的过程中，应遵循如下几个原则。
|
|
|
|
. 脚本越小越好。就像编写程序代码一样，不要太长，尽量做到一个功能一个脚本。如果那些功能是连续有序的，必须先做上一个，才能执行下一个，那就只好放在一起了。
|
|
|
|
. 选择负载压力最高的业务功能进行测试。有些人总希望能够测试几乎所有的功能，但事实上，这种想法不可行，因为测试是需要投入时间和金钱的，我们应该结合用户实际的使用情况，选择负载压力最高的业务功能进行测试，以满足性能测试的需求，达到测试的预期目的。
|
|
|
|
. 选择所需要的操作进行录制。例如，需要测试服务器承受负载压力的性能，某些客户端的操作不会对后台服务器产生负载压力，就可以不录制。比如一些查询操作，选择查询条件的页面可以不录制，但对于一些页面有可能要与后台服务器传递参数，就需要录制了。如何确定哪些操作需要录制，一是可以找开发人员了解清楚程序设计结构和运行模式，二是可以靠自己的经验，熟能生巧当然不会错。
|
|
|
|
由于负载压力测试工具是一种预测系统行为和性能的负载测试工具。它需要模拟成百上千甚至上万的用户同时操作应用系统，实施并发负载及实时性能监测。通常情况下，测试工具模拟多用户并发访问可以有以下两种方式。
|
|
|
|
①进程回放模式：模拟多进程运行方式，即客户端与服务器的访问采用进程方式，每一个虚拟用户通过一个进程建立与服务器的通信连接并访问。
|
|
|
|
②线程回放模式：模拟多线程运行方式，即客户端与服务器的访问采用线程方式，每一个虚拟用户通过一个线程建立与服务器的通信连接并访问。
|
|
|
|
不论测试工具采用的是哪种录制回放模式，其必须经历的几个操作步骤如下。
|
|
|
|
. 协议选择：如前所述，测试工具都是通过获取在各种通信协议下应用系统的客户端与服务器端的通信信息并进一步来实现负载压力测试的，所以首先要确定被测应用系统客户端与服务器端的通信所使用的协议类型。一般而言，B/S系统选择Web（Http/Html），两层C/S系统则根据C/S结构所用到的后台数据库来选择不同的协议，协议的选择请参考有关章节。
|
|
|
|
. 创建测试脚本：选择好相应的录制协议以后，就可以启动脚本录制工具，通过测试工具的代理进程获取应用系统客户端和服务器端的通信信息，测试工具可以自动记录客户端对服务器端的访问操作并自动转换成所需的脚本代码，还可以直接编辑测试脚本以满足各种复杂测试的需求。
|
|
|
|
. 参数化测试数据。对于创建的测试脚本，你可以利用数据池技术对其中的某些数据参数化，从而更好地模拟真实应用访问。以一个订单输入过程为例，参数化操作可将记录中的常量数据，如订单号和客户名称，由变值来代替，以更好地模拟多个实际用户的操作行为。
|
|
|
|
. 创建虚拟用户，设定负载方案：由于负载压力测试的目的就是要模拟多用户并发访问应用系统，所以在开始测试之前就应该设计好需要模拟的虚拟用户数，然后使用测试工具控制台设定负载方案。
|
|
|
|
. 执行测试：设定了相应的负载测试方案后，就可以开始测试了，测试过程中，测试工具会自动记录测试结果，包括事务处理的响应时间，服务器的资源占用情况等。
|
|
|
|
. 结果分析：测试结束后，测试工具会收集汇总所有的测试数据并生成测试结果报告，这些数据主要包括交易性能数据（如响应时间等）、服务器资源占用情况、网路设备和数据库的实时性能数据等。通过这些数据就可以从客户端、服务器端以及网络三方面来评估系统组件的运行性能，从而定位应用系统存在的主要问题，为系统改进做准备。
|
|
|
