压力测试实例

1、压力测试实例2003-03-24 李明艳-51cmm利用现代的设计技术和正式的技术复审可以减少代码中存在的初始错误，但是错误总是存在的，如果开发者找不到错误，那么，客户就会找到它们。越来越多的软件组织认识到软件测试是软件质量保证的重要元素之一，很多软件开发组织将30/40%甚至更多的项目资源用在测试上，软件测试技术和软件测试策略受到了高度的重视和广泛的应用。本文不想就软件测试技术和软件测试策略作深入的理论分析，而是列举一个在软 件系统测试阶段进行的压力测试实例，希望能通过这个实例与从事软件测试相关工作 的朋友进行交流。首先介绍一下实例中软件的项目背景，该软件是一个典型的三层C/S架构的MIS系

2、统（客户端/应用服务器/数据库管），中间层是业务逻辑层，应用服务器处理所有 的业务逻辑，但应用服务器本身不提供负载均衡的能力，而是利用开发工具提供的 ORB（对象请求代理）软件保证多个应用服务器间的负载均衡。本次测试的目的是：进行单个应用服务器的压力测试，找出单个应用服务器能够支持的最大客户端数。测试压 力估算的依据是：假定在实际环中，用户只启用一个应用服务器进行所有的业务处理。方法是：按照正常业务压力估算值的110倍进行测试，考察应用服务器的运行情况。压力测试的详细计划如下：压力测试计划1、测试计划名称河北省公安交通管理信息系统压力测试计划。2、测试内容背景本次测试中的压力测试是指模拟实际应

3、用的软硬件环境及用户使用过程的系统负荷，长时 间运行测试软件来测试被测系统的可靠性，同时还要测试被测系统的响应时间。用户的实际使用环境：由两台 旧M XSeries250 PC Server 组成的 Microsoft Cluster ；数据库管理系统采用；应用服务器程序和数据库管理系统同时运行在Microsoft Cluster 上。有200个用户使用客户端软件进行业务处理，每年通过软件进行处理的总业务量为：150万笔业务/年。测试项应用服务器的压力测试；不被测试的特性系统的客户端应用程序的内部功能；数据库中的数据量对程序性能的影响。3、测试计划测试强度估算测试压力估算时采用如下原则：全年的

4、业务量集中在 8个月完成，每个月20个工作日，每个工作日8个小时；采用8020原理，每个工作日中 80%勺业务在20%勺时间内完成，即每天 80% 的业务在小时内完成；测试压力的估算结果:去年全年处理业务约100万笔，其中15%勺业务处理每笔业务需对应用服务器提交7次请求；70%勺业务处理每笔业务需对应用服务器提交5次请求；其余15%勺业务每笔业务向应用服务器提交 3次请求。根据以往统计结果，每年的业务增量为15%考虑到今后三年业务发展的需要，测试需按现有业务量的 2倍进行。每年总的请求数量为：（100*15%*7+100*70%*5+100*15%*3） *2=300 万次/年。每天的请求数

5、量为：300/160=万次/天。每秒的请求数量为：（18750*80%） / （8*20%*3600）二次/秒。正常情况下，应用服务器处理请求的能力应达到：3次/秒。测试环境准备基本硬件及软件环境的准备1）网络环境：公司内部的以太网，与服务器的连接速率为100M,与客户端的连接速率为10/100M自适应。2）使用两台 旧M XSeries250 （1G内存）PC Server 作 Microsoft Cluster ，安装 系统软件 Windows 2000 Advance Server 及 Microsoft Cluster Server （MSCS。3）数据库管理系统的安装及配置：在测试用

6、的 旧M XSeries服务器上安装，数据 库 采用Oracle Fail Safe （ofs）的Active/Passive 配置。 安装数据库管理系统及支 撑软件（包括 VisiBroker 和 BDE Administrator ）。4）安装被测的应用服务器程序。5）客户端的 PC 机：10 台（Pm 600/128M RAM。系统客户端测试程序的编写系统客户端测试程序使用Delphi编写，要求测试程序实现如下功能:1）模拟一个主要的向应用服务器发送请求并接收响应信息的功能。要求交替模拟 两种情况：第一种，发送的请求至少包括10个参数，参数类型涵盖字符、日期、数字种类型；接收的 响应信息

7、不少于1个参数；第二种，发送的请求不少于 1个参数；接 收的响应信息至少包括10个参数，参数类型涵盖字符、日期、数字种类型。2）必须能够通过参数设定在每台 PC机上运行的客户端测试程序个数、请求的时间间隔（单位：毫秒）、运行时间（单位：小时）。3）在数据库中建立测试记录表，生成测试记录，向数据库写入测试记录的功能不 通过被测的应用服务器实现。日志内容包括：发送测试请求的机器名、客户端测试程 序序号、发出请求时间、收到响应时间、处理是否成功。表名： TEST_LOG字段名： MACHINE ID> START_TIME END_TIME FLAG系统本底数据的准备为考察系统运行一段时间后系

8、统的响应性能，参照实际运行情况及发展进行系统 的本底数据准备。业务处理中涉及到的业务表中都要求按设计规模进行本底数据的准 备。要求准备的数据记录的有效性符合系统要求，数据有效性的具体要求参见数据库 设计及系统设计文档。破坏性测试按照设计连接的客户端连接数量进行测试，把应用服务器处理请求的设计频度增 加1 10倍，分别测试出现错误的状态和和出现错误的比率，考察是否出现不可恢复 错误，系统设计要考 虑出现严重错误情况下负荷减轻错误自动恢复的实现方法。计划时间：2天；这个时间包括破坏性的修复和自动恢复的实现需要的时间。在测试过程中每10分钟记录一次 旧M Xseries PCServer的内存及CP

9、U®用情况, 包括被测程序的内存占用百分比、数据库管理系统的内存占用百分比、操作系统的内 存占用百分比。强度稳定性测试选择一种负荷比设计负荷重的情况（应用服务器处理请求的频度为应用服务器处理请求的 设计频度的倍），进行 24小时稳定性测试。测试方法和工具黑盒测试测试工具：无外购的测试工具，自己编制的测试工具。测试时间计划环境准备：2天。其中：基本硬件、软件环境及系统本底数据的准备：1天，系统客户端测试程序的编写及测试：1天。破环性测试：2天。强度稳定性测试：1天。测试中的问题及处理暂停标准和再启动要求暂停标准：被测试软件在强度稳定性测试中频繁出现异常（每小时出现1次以上）时。用户或公

10、司要求暂停测试时。再启动要求：通过调试后，预计被测试软件的可靠性有所提高时，可再次启动测不可预见问题不可预见问题包括:测试环境被破坏而导致测试无法进行；当出现上述不可预见问题时，测试终止，就已完成的测试内容编制测试总结报 告，并在报告中说明测试终止的原因。测试报告测试总结报告提交日期：。应生成的测试文件测试记录（测试负责人和参与测试的人员签字）；测试总结报告。测试总结报告中必须包含的内容被测试软件名称、测试项、测试环境；被测试软件的压力测试结论：响应时间、最大 /最小并发数、失败的次数、正常连 续运行的最长/最短时间，并发数与失败的关系。4、人员和职责职责测试工程师：负责编写测试计划，组织测试，对测试过程进行记录，收集、整理 测试记录数据，对测试结果进行分析，编写测试总结报告。软件工程师：负责编写、调试客户端测试软件；