压力测试计划

测试计划包括准备采用哪种测试工具，根据现有条件准备搭建的测试模拟环境，测试完 成的标准(包括数据库的大小、并发用户的多少等)，是否进行对比测试，测试方法与进度安 排等等。
具体而言，评价WEB应用的有以下几个指标：
Number of hits：测试间隔内虚拟用户点击页面的总次数
3.2测试环境准备
3.2.1基本硬件及软件环境的准备
1)网络环境：公司内部的以太网，与服务器的连接速率为100M，与客户端的连接速率为10/100M自适应。
2)使用两台IBM XSeries250（1G内存）PC Server作Microsoft Cluster，安装系统软件
Administrator）。
4)安装被测的应用服务器程序。
5)客户端的PC机：10台（PⅢ600/128M RAM）。
3.2.2系统客户端测试程序的编写系统客户端测试程序使用Delphi编写，要求测试程序实现如下功能：
1)模拟一个主要的向应用服务器发送请求并接收响应信息的功能。要求交替模拟两种情况：第一种，发送的请求至少包括10个参数，参数类型涵盖字符、日期、数字种类型；接收的
要，测试需按现有业务量的2倍进行。
每年总的请求数量为：（100*15%*7+100*70%*5+100*15%*3）*2=300万次/年。
每天的请求数量为：300/160=1.875万次/天。
每秒的请求数量为：（18750*80%）/（8*20%*3600）=2.60次/秒。
正常情况下，应用服务器处理请求的能力应达到：3次/秒。
分析系统有两个主要任务:第一,搞清系统对各个资源的分布与使用情况,它将帮我们确定可能系统性能的瓶颈;第二,搞清用户事务的分布,确定压力测试的针对点。我们定义事务是用来表示用户要求服务器连续完成的操作任务。
分析对象也是测试运行时记录的内容,下面是压力测试的分析对象:（1）测试使用的时间和被测事务的响应时间(有多少个用户同时运行);（2）压力测试参与的进程个数,成功个数,失败个数;（3）压力测试参与进程失败的原因;（4）事务的响应时间随用户增加的变化图;（5）资源限制。
◇测试环境被破坏而导致测试无法进行；
◇当出现上述不可预见问题时，测试终止，就已完成的测试内容编制测试总结报告，并在报告中说明测试终止的原因。
3.8测试报告 2002.06.21
测试总结报告提交日期：2002.06.21。
3.8.1应生成的测试文件
测试记录（测试负责人和参与测试的人员签字）；
◇采用80—20原理，每个工作日中80%的业务在20%的时间内完成，即每天80%的业务在1.6小时内完成；
测试压力的估算结果：
去年全年处理业务约100万笔，其中15%的业务处理每笔业务需对应用服务器提交7次请求；70%的业务处理每笔业务需对应用服务器提交5次请求；其余15%的业务每笔业务向应用服务器提交3次请求。根据以往统计结果，每年的业务增量为15%，考虑到今后三年业务发展的需
测试总结报告。
3.8.2测试总结报告中必须包含的内容
被测试软件名称、测试项、测试环境；
被测试软件的压力测试结论：响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间，并发数与失败的关系。
4、人员和职责
4.1职责
测试工程师：负责编写测试计划，组织测试，对测试过程进行记录，收集、整理测试记录数据，对测试结果进行分析，编写测试总结报告。
TTLB Avg：从第一个请求发出到测试工具接收到服务器应答数据的最后一个字节之间的平均时间
根据以上数据，可以从以下ห้องสมุดไป่ตู้个方面分析应用程序性能，生成相应报表：
Number of hits vs. Users：随着虚拟用户的增加，服务器在规定时间内所能处理的总点击数
Requests per second vs. Users：随着虚拟用户的增加，服务器在规定时间内所能处理的每秒请求数
3.7测试中的问题及处理
3.7.1暂停标准和再启动要求
暂停标准：被测试软件在强度稳定性测试中频繁出现异常（每小时出现1次以上）时。用户或公司要求暂停测试时。
再启动要求：通过调试后，预计被测试软件的可靠性有所提高时，可再次启动测试。
3.7.2不可预见问题
不可预见问题包括：
3.5测试方法和工具
黑盒测试
测试工具：无外购的测试工具，自己编制的测试工具。
3.6测试时间计划
3.6.1环境准备：2天。
其中：基本硬件、软件环境及系统本底数据的准备：1天，
系统客户端测试程序的编写及测试：1天。
3.6.2破环性测试：2天。
3.6.3强度稳定性测试：1天。
首先介绍一下实例中软件的项目背景，该软件是一个典型的三层C/S架构的MIS系统（客户端/应用服务器/数据库管），中间层是业务逻辑层，应用服务器处理所有的业务逻辑，但应用服务器本身不提供负载均衡的能力，而是利用开发工具提供的ORB（对象请求代理）软件保证多个应用服务器间的负载均衡。本次测试的目的是：进行单个应用服务器的压力测试，找出单个应用服务器能够支持的最大客户端数。测试压力估算的依据是：假定在实际环中，用户只启用一个应用服务器进行所有的业务处理。方法是：按照正常业务压力估算值的1~10倍进行测试，考察应用服务器的运行情况。
软件工程师：负责编写、调试客户端测试软件；数据库管理系统的安装、ofs配置及系统的本底数据准备。
系统工程师：负责测试用的硬件维护及操作系统安装、MSCS配置。
总工程师：负责对测试计划及测试总结报告进行批准。
用户：必要时可参加测试，并提出具体的测试要求；可要求暂停测试。
4.2人员和训练要求
压力测试的目的是: 测试系统在各种负荷（由并发用户所产生的综合处理量）下的性能和稳定性。
下面是一些压力测试目标:
（1）测定终端用户事务的响应时间,它可能随用户的增加而增加,但要定义一个可接受时间。
（2）定义主机最优配置,我们可以以最低的价格发挥最佳的性能。在压力测试目标确定过程中,要邀请用户、设计人员等对其进行评审。
Performance vs. Users：随着虚拟用户的变化，应用性能的变化等
软件测试中谈一谈有关压力测试计划实例
本文不想就软件测试技术和软件测试策略作深入的理论分析，而是列举一个在软件系统测试阶段进行的压力测试实例，希望能通过这个实例与从事软件测试相关工作的朋友进行交流。
2.2测试项
应用服务器的压力测试；
2.3不被测试的特性
◇系统的客户端应用程序的内部功能；
◇数据库中的数据量对程序性能的影响。
3、测试计划
3.1测试强度估算
测试压力估算时采用如下原则：
◇全年的业务量集中在8个月完成，每个月20个工作日，每个工作日8个小时；
本次测试无特别的人员及培训要求。
5、批准
本测试计划必须经过总工程师批准后才能开始实施。
Windows 2000 Advance Server及Microsoft Cluster Server（MSCS）。
3)数据库管理系统的安装及配置：在测试用的IBM XSeries服务器上安装Oracle8.1.6，数据 库采用Oracle
Fail Safe（ofs）的Active/Passive配置。 安装数据库管理系统及支撑软件（包括VisiBroker和BDE
用户的实际使用环境：
◇由两台IBM XSeries250 PC Server组成的Microsoft Cluster；
◇数据库管理系统采用Oracle8.1.6；
◇应用服务器程序和数据库管理系统同时运行在Microsoft Cluster上。
◇有200个用户使用客户端软件进行业务处理，每年通过软件进行处理的总业务量为：150万笔业务/年。
在测试过程中每10分钟记录一次IBM Xseries PC
Server的内存及CPU使用情况，包括被测程序的内存占用百分比、数据库管理系统的内存占用百分比、操作系统的内存占用百分比。
3.4强度稳定性测试
选择一种负荷比设计负荷重的情况（应用服务器处理请求的频度为应用服务器处理请求的 设计频度的1.5倍），进行24小时稳定性测试。
Errors vs. Time：随着模拟访问时间的延续，出现错误的数量
Errors vs. Users：随着虚拟用户的增加，出现错误的数量
Performance Distribution vs. Users：针对虚拟用户数的应用性能分布情况，包括服务器的内存、CPU使用情况等
响应信息不少于1个参数；第二种，发送的请求不少于1个参数；接收的响应信息至少包括10个参数，参数类型涵盖字符、日期、数字种类型。
2)必须能够通过参数设定在每台PC机上运行的客户端测试程序个数、请求的时间间隔（单位：毫秒）、运行时间（单位：小时）。
3)在数据库中建立测试记录表，生成测试记录，向数据库写入测试记录的功能不通过被测的应用服务器实现。日志内容包括：发送测试请求的机器名、客户端测试程序序号、发出请求时间、收到响应时间、处理是否成功。表名：TEST_LOG，字段名：MACHINE、ID、START_TIME、END_TIME、FLAG。
3.2.3系统本底数据的准备
为考察系统运行一段时间后系统的响应性能，参照实际运行情况及发展进行系统的本底数据准备。业务处理中涉及到的业务表中都要求按设计规模进行本底数据的准备。要求准备的数据记录的有效性符合系统要求，数据有效性的具体要求参见数据库设计及系统设计文档。
3.3破坏性测试
压力测试的详细计划如下：
压力测试计划
1、测试计划名称
河北省公安交通管理信息系统压力测试计划。