|
|
知识路径： > 自动化测试 >
|
|
考试要求：掌握
相关知识点：15个
|
|
|
|
|
|
|
当一个企业自己组织力量或委托其他的软件公司开发了一套应用系统的时候，尤其是以后在生产环境中实际使用起来时，用户往往会产生疑问，这套系统能不能承受大量的并发用户同时访问，随着生产数据的不断累积，系统的响应处理能力是不是会明显下降直至用户不能接受。这类问题最常见于采用联机事务处理（OLTP）方式的数据库应用、Web应用和视频点播应用等系统。
|
|
|
|
比如，电信计费软件，众所周知，每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动，收费过程一般分为两步，首先要根据用户提出的电话号码来查询出其当月产生的费用，然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤，当成百上千的终端同时执行这样的操作时情况就大不一样了，如此众多的交易同时发生，对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统承受力。预见软件系统的并发承受力，这是在软件测试阶段就应该解决的。
|
|
|
|
如何模拟实际情况呢？找若干台电脑和同样数目的操作人员在同一时刻进行操作，然后拿秒表记录下反应时间？这样的手工作坊式的测试方法不切实际且无法捕捉程序内部的变化情况。这就需要负载压力测试工具的辅助。
|
|
|
|
那么，什么是负载测试和压力测试呢？负载测试是为了证明在与产品（预期）规模等同的数据库中处理给定的事务请求的容量下，系统功能与性能是否与需求规格说明中规定的，可接受的响应时间一致的测试过程。而压力测试则是使客户机在大容量情况下运行的测试过程，目的是查看应用将在何时何处出现中断，即识别系统的薄弱环节。压力测试中可能暴露的系统缺陷有内存泄漏、系统资源过量消耗、磁盘空间用完等。
|
|
|
|
负载压力测试工具可以记录下客户端的操作，并以脚本的方式保存，然后建立多个虚拟用户，在一台或几台PC机上模拟上百或上千虚拟用户同时操作的情景，同时记录下每一事务处理的响应时间、中间件服务器资源使用、数据库负载等，测试工程师可以根据测试结果分析系统瓶颈。
|
|
|
|
在各种类型的并发测试中，基于Web的应用占了很大的比例，现在有相当数量的联机事务处理（OLTP）类型系统采用Web方式，还有一些网站，对并发连接的数量和自己网站对大量用户访问的支持能力，都表示出了相当程度的关心。对于负载压力测试工具，它提供了对Web页面压力测试的完整解决方案，包括用户模拟、Web服务器监控、页面每秒钟点击率统计、单独页面加载时间分析等各种专门针对Web的特性。
|
|
|
|
随着服务器端处理任务的日益复杂以及网站访问量的迅速增长，服务器性能的优化也成了非常迫切的问题。在优化之前，最好能够测试一下不同负载条件下服务器的性能表现。定位性能瓶颈所在，是设计性能改善方案之前的一个至关紧要的步骤。
|
|
|
|
负载测试是任何Web应用的开发周期中一个重要的步骤。如果你在构造一个为大量用户服务的应用，搞清楚你的产品配置能够承受多大的负载非常重要。如果你在构造一个小型的Intranet网站，测试能够暴露出最终会导致服务器崩溃的内存漏洞、资源竞争等情况。但是在实际的开发过程中，要按照实际投入运行的情况，组织成千上万的用户来进行压力测试，无论从哪个方面看，都是不现实的。而且一旦发现了问题，不仅需要重复地进行这种耗费巨大的测试，而且问题不容易重现，不能方便地找出性能的瓶颈所在。而使用测试工具进行压力测试就不会存在这种情况。
|
|
|
|
无论是哪种情形，花些时间对应用进行负载压力测试可以获得重要的基准性能数据，为未来的代码优化、硬件配置以及系统软硬件升级带来方便。即使经费有限的开发组织也可以对它们的网站进行负载压力测试，因为有些测试工具是可以免费下载的。
|
|
|
|
在测试阶段使用负载压力测试工具进行测试，还可以模拟数据库死锁情况，结合压力分析SQL效率，优化应用程序和数据库配置等工作，使软件系统更加健壮和高效。这样的实例也很多，比如有公司在测试某省的大型电信业务网上受理系统时，200个并发用户同时联机时速度正常，但当达到用户量达到500个的时候，受理速度明显变慢，通过监控发现Web服务器的流量有所降低，而表空间对应的数据文件中发生的磁盘物理读的次数却大于正常水平，最后通过诊断确定有部分复杂的SQL查询（如大表连接操作，嵌套查询等）没有利用合适的索引和采用最优的解释方案，而造成全表扫描。而且数据库配置参数DB_BLOCK_BUFFERS太小，不能适应500个用户或更大规模的并发情况。经过测试人员和开发人员对系统的共同调整，再次测试的时候一切恢复正常，500个用户的并发测试顺利通过。
|
|
|
|
|
|
负载压力测试工具基本上都是采取录制回放的方式来模拟用户的实际操作的，而且测试工具一般都会有一个后台代理进程，通过该代理进程，测试工具可以监视并获取在各种通信协议下应用系统的客户与服务器端的通信信息，测试工具会用一种类C或者其他的脚本语言（TSL）生成一个测试脚本，该脚本记录了你对服务器的请求过程，然后测试工具就可以回放刚才的访问过程，接收服务器的响应，当然你也可以用手工编程生成这个脚本。
|
|
|
|
通常情况下，实施负载压力测试的工作示意图如下图所示。
|
|
|
|
|
|
|
|
当被测系统运行时，脚本生成器会自动获取系统客户端与服务器的通信信息并转换成测试工具可以识别的脚本，测试工具通过控制台将测试脚本分发到其他负载生成器上以模拟多用户对服务器的并发访问，同时，控制台还可以通过服务器上开启的远程RPC服务，获取相关的资源使用信息，最后可以收集测试数据。
|
|
|
|
在进行测试脚本录制与分配的过程中，应遵循如下几个原则。
|
|
|
|
. 脚本越小越好。就像编写程序代码一样，不要太长，尽量做到一个功能一个脚本。如果那些功能是连续有序的，必须先做上一个，才能执行下一个，那就只好放在一起了。
|
|
|
|
. 选择负载压力最高的业务功能进行测试。有些人总希望能够测试几乎所有的功能，但事实上，这种想法不可行，因为测试是需要投入时间和金钱的，我们应该结合用户实际的使用情况，选择负载压力最高的业务功能进行测试，以满足性能测试的需求，达到测试的预期目的。
|
|
|
|
. 选择所需要的操作进行录制。例如，需要测试服务器承受负载压力的性能，某些客户端的操作不会对后台服务器产生负载压力，就可以不录制。比如一些查询操作，选择查询条件的页面可以不录制，但对于一些页面有可能要与后台服务器传递参数，就需要录制了。如何确定哪些操作需要录制，一是可以找开发人员了解清楚程序设计结构和运行模式，二是可以靠自己的经验，熟能生巧当然不会错。
|
|
|
|
由于负载压力测试工具是一种预测系统行为和性能的负载测试工具。它需要模拟成百上千甚至上万的用户同时操作应用系统，实施并发负载及实时性能监测。通常情况下，测试工具模拟多用户并发访问可以有以下两种方式。
|
|
|
|
①进程回放模式：模拟多进程运行方式，即客户端与服务器的访问采用进程方式，每一个虚拟用户通过一个进程建立与服务器的通信连接并访问。
|
|
|
|
②线程回放模式：模拟多线程运行方式，即客户端与服务器的访问采用线程方式，每一个虚拟用户通过一个线程建立与服务器的通信连接并访问。
|
|
|
|
不论测试工具采用的是哪种录制回放模式，其必须经历的几个操作步骤如下。
|
|
|
|
. 协议选择：如前所述，测试工具都是通过获取在各种通信协议下应用系统的客户端与服务器端的通信信息并进一步来实现负载压力测试的，所以首先要确定被测应用系统客户端与服务器端的通信所使用的协议类型。一般而言，B/S系统选择Web（Http/Html），两层C/S系统则根据C/S结构所用到的后台数据库来选择不同的协议，协议的选择请参考有关章节。
|
|
|
|
. 创建测试脚本：选择好相应的录制协议以后，就可以启动脚本录制工具，通过测试工具的代理进程获取应用系统客户端和服务器端的通信信息，测试工具可以自动记录客户端对服务器端的访问操作并自动转换成所需的脚本代码，还可以直接编辑测试脚本以满足各种复杂测试的需求。
|
|
|
|
. 参数化测试数据。对于创建的测试脚本，你可以利用数据池技术对其中的某些数据参数化，从而更好地模拟真实应用访问。以一个订单输入过程为例，参数化操作可将记录中的常量数据，如订单号和客户名称，由变值来代替，以更好地模拟多个实际用户的操作行为。
|
|
|
|
. 创建虚拟用户，设定负载方案：由于负载压力测试的目的就是要模拟多用户并发访问应用系统，所以在开始测试之前就应该设计好需要模拟的虚拟用户数，然后使用测试工具控制台设定负载方案。
|
|
|
|
. 执行测试：设定了相应的负载测试方案后，就可以开始测试了，测试过程中，测试工具会自动记录测试结果，包括事务处理的响应时间，服务器的资源占用情况等。
|
|
|
|
. 结果分析：测试结束后，测试工具会收集汇总所有的测试数据并生成测试结果报告，这些数据主要包括交易性能数据（如响应时间等）、服务器资源占用情况、网路设备和数据库的实时性能数据等。通过这些数据就可以从客户端、服务器端以及网络三方面来评估系统组件的运行性能，从而定位应用系统存在的主要问题，为系统改进做准备。
|
|
|
