当上级要求对新的系统做压力测试时，而制作压力测试计划与测试报告的任务就落在我的身上，从没有做过测试计划的我不知从何下手，而是到网络上到处搜寻，竟找不到一个很好的模块和一份好的压力测试所必须包括的内容，于是我结合公司实际情况和自已在QCC活动中所学到的手法编写了这一份压力测试计划与报告，得到了上级的赞赏，所以在此与大家分享。
压力测试计划书
压力测试计划书必须包括的内容有：
1. 测试内容：即在此次测试中所要测试的内容，如Client or Server的连接数/内存使用情况
2. 达成准则：只所以把他放在第二的位置，是因为这样大家一看就知道此次测试预计要达成的目标是什么，系统要达成一个什么样的标准才算是通过。
3. 压力测试的详细计划：包括 测试计划名称、测试内容（测试背景，测试项，不被测试的特性）、测试计划（测试强度估算，测试环境准备，破坏性测试，强度稳定性测试，测试方法和工具，测试时间计划，测试中的问题及处理，测试报告）
测试背景：主要说明所使用的用户测试环境所需要的硬件以及软件要求；
测试项：在此次测试中所必须记录的选项；
不被测试的特性：在此次测试中可以不必记录的选项；
测试强度估算：根据实际用户结系统所需的要求计算出测试压力的估算结果以及在测试鞍程中所要把握的输入条件；
测试环境准备：Server端与Client端环境必须具备些什么，以及用户端程必须具备哪些功能；
破坏性测试：按照测试强度估算出来的结果的基础上如果增加倍数所出现的各种情况来测试系统的出错以及错误恢复能力
4. 人员和职责：职责区分，人员分配
5. 批准：定义此份计划书只有经过谁批准后方可开始实施
压力测试报告书主要包括以下三大块：
测试内容：开篇破题，点明报告的内容是哪些
测试结果：交代结果，说明最后测试结果，这部分是最高级主管想要看的，如果直接主管或者其它想知道具体情况的人想了解结果是如果得到可以继续往下看
具体结果以及如何得到：此处是一个汇总的工作，根据所收集到的资料来从各个不同的角度来分析，如果得到我们想要的结果。此处我运用到的是折线图来表示系统的运行情况与变化情况，当然QC手法中还有很多值得借鉴的方法，如果大家有兴趣不妨去了解一下，不管在工作还是生活中都有用。
实例：
压力测试计划二
压力测试（Stress Testing）是指模拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。扩展开来说，其一压力测试应该是较短时间的，其次是模拟巨大的工作负荷的，再次压力测试是要使应用程序的使用达到峰值。
此次压力计划主要是在阶段一的基础上进行的一个更高层的测试，测试内容包括：
仿真产线的实际作业进行应用服务器的最大连接数、内存、CPU使用情况、响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间，并发数与失败的关系；
此次测试完成准则需达成如下标准：
测试项目 | 二厂client目前速度 | 所占比例 | Server端资料量 | 新系统判稳标准 |
Special(packing) | 3秒/pcs | 36% | 108万笔（半年） | >3sec/pcs NG |
Normal(packing2) | 27秒/箱(48pcs/箱) | 64% | 108万笔（半年） | >27秒/箱(48pcs/箱) NG |
说明：对于整条线如言，进入shopfloor数据站有：打X板、上料、入站、背板目检、背板维修、正板上料、正板入站、Mapping、正板目检、正板维修、裁板前目检、上料、入站、目检、TX、RX、WriteMAC、ChkMAC、TX、RX、Packing、WriteMAC、ChkMAC、入库、出货，其中下划线部分划定为接近packing站速度，占总站的36%
压力测试的详细计划如下：
1. 测试计划名称：
MIS新Askey shopfloor control system压力测试计划
2. 测试内容：
2.1 测试背景
本次测试中的压力测试是指仿真实际应用的软硬件环境及用户使用过程的系统负荷，长时间运行测试软件来测试被测服务器的可靠性，同时还要测试被测服务器的响应时间。
用户的实际使用环境：
硬件要求：128M RAM
软件要求：Oracle9i链接工具，DBE的安装，windows 2000繁体以上；
有200个用户使用客户端软件进行数据处理
2.2 测试项
通过仿真产线的实际作业进行应用服务器的压力测试，包括最大连接数、内存、CPU使用情况、响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间，并发数与失败的关系；
2.3 不被测试的特性
系统的客户端性能问题；
3. 测试计划
3.1 测试强度估算
测试压力估算时采用如下原则：
(1)Special一般要求速度最高的为产线功能测试段，那我们以全厂要求速度最高的Wirless 为例：一般1小时可完成1.2k的量
(2)Normal 一般的收集站，如packing2、packing3、入库、出货等，在此以packing2收集站为例：
测试压力的估算结果：
Wirless ：1小时完成的最大量为1200pcs，即完成每1pcs所需时间为（60*60）/1200=3秒/pcs，每pcs需完成fCanIGoTest、fCkMapID、fSetMapID、FSendData四个函数，所以应用服务器处理请求的能力应达到：1/3(pcs/秒) *4(个/pcs)=1.3333个/秒
Packing2 ：最佳时候packing2 一箱48入的，完成的时间为：27秒/48pcs
所以应用服务器处理请求的能力应达到：48/27(pcs/秒) *3(个/pcs)=5.3333个/秒
正常情况下，如果special工作站台占36%，normal占64%，所以应用服务器处理请求的能力应达到：
36%*1/3(pcs/秒) *4(个/pcs)+64%*48/27(pcs/秒) *3(个/pcs)=3.8933个请求/秒
3.2 测试环境准备
3.2.1基本硬件及软件环境的准备
1)网络环境：公司内部的以太网，与服务器的连接速率为100M，与客户端的连接速率为10/100M自适应。
2)数据库管理系统的安装及配置：在测试用的服务器上安装Oracle9i，数据 库采用Oracle
3)安装被测的应用服务器程序。
4)客户端的PC机：10台（PⅢ600/128M RAM）。
3.2.2系统客户端测试程序的编写系统客户端测试程序使用Delphi编写，要求测试程序实现如下功能：
3.2.2.1模拟产线实际的special站台packing1中所实现的功能
3.2.2.2模拟产线实际的normal站台packing2中所实现的功能
具体每个函数所完成的功能如下：
① fCanIGoTest (pchIPK , pchModelK , pchTestIdK , pchItemNameK , pchOperatorIDK , pchStationIDK , hReturnMsgK : PChar)
功能: 检查这一关可不可以进行测试
参数定义：
② fCkMapID(pchIPK , pchModelK , pchIDNameValueK , pchOperatorIDK , pchStationIDK , pchReturnMsgK : PChar)
功能: 检查 数据库中做关连对应(Mapping)的某一组ID是否正确
参数定义
Ex. Result:=fCkMapID(IP , Model , 'id1 61000066013 id2 000BA0020013',Operator , Station ,ReturnMessage);
③ fSetMapID (pchIPK , pchModelK , pchIDNameValueK , pchOperatorIDK,pchStationID ,pchReturnMsgK : PChar)
功能: 将 各种 ID 存入数据库做关连对应(Mapping)
参数定义
Ex. Result:=fSetMapID(IP , Model , 'id1 11223344100 id2 0090968A9237' , Operator , Station , ReturnMessage);
④ fSendData (pchIPK , pchModelK , pchTestIdK , pchItemNameK , pchErrcdK , pchPfmdataK , pchOperatorIDK , pchStationIDK , pchReturnMsgK : pchar)
功能: 传送测试数据
参数定义
⑤ Check_sn_unique_I
功能：与fcan I go test类同
⑥ SET_SN_CARTON
功能：传送数据
具体每个函数所完成的功能：各函数功能.xls
3.2.2.3 记录每次程序所发出的请求时间、处理时间、处理结束时间
考虑到本次测试由于Special&Normal程序所实现的功能均已完毕，所以此次测试完全可以利用现有dll直接来模拟,我们只需书写简单的Client.exe送入与dll相同的参数即可，这样即节省了人力另外去写复杂的dll程序，同时也可以确实的仿真产线的实际作业情况，同时也可以发现在正常测试情况下无法发现的问题点。
3.2.3系统本底数据的准备
为考察系统运行一段时间后系统的响应性能，参照实际运行情况及发展进行系统的本底数据准备。要求准备的数据记录的有效性符合系统要求，数据有效性的具体要求如下：
① 产端一天有600个点在进行作业，每天每个站点资料收集量为1000个记录，那么一年的资料量为600*1000*30*12=216百万
现产线采取的作业方式是：大概半年每个机种备份一次，但现在系统是所有的机种均放于同一Server，所以现在要测的就是在108万笔资料存在的情况下新系统是否能够正常作业？
② 其中30%的数据处于待测packing关，70%的数据处于待测packing关
3.3 破坏性测试
按照设计连接的客户端连接数量进行测试，把应用服务器处理请求的设计频度增加1－10倍，分别测试出现错误的状态和和出现错误的比率，考察是否出现不可恢复错误，系统设计要考虑出现严重错误情况下负荷减轻错误自动恢复的实现方法。
计划时间：2天；这个时间包括破坏性的修复和自动恢复的实现需要的时间。
在测试过程中每10分钟记录一次Server的内存及CPU使用情况。
3.4 强度稳定性测试
选择一种负荷比设计负荷重的情况（应用服务器处理请求的频度为应用服务器处理请求的设计频度的1.5倍），进行24小时稳定性测试。
3.5 测试方法和工具
测试方法：黑盒测试
测试工具：无外购的测试工具，自己编制的测试工具client.exe。
3.6 测试时间计划
3.6.1环境准备：2天。
其中：基本硬件、软件环境 准备完成
系统本底数据的准备：1天。
系统客户端测试程序的编写及测试：1天。
3.6.2破环性测试：2天。
3.6.3强度稳定性测试：1天。
3.7 测试中的问题及处理
3.7.1暂停标准和再启动要求
暂停标准：被测试软件在强度稳定性测试中频繁出现异常（每小时出现1次以上）时。用户或公司要求暂停测试时。
再启动要求：通过调试后，预计被测试软件的可靠性有所提高时，可再次启动测试。
3.7.2不可预见问题
不可预见问题包括：
测试环境被破坏而导致测试无法进行；
当出现上述不可预见问题时，测试终止，就已完成的测试内容编制测试总结报告，并在报告中说明测试终止的原因。
3.8 测试报告
测试总结报告提交日期：暂定
3.8.1应生成的测试文件
测试记录（测试负责人和参与测试的人员签字）；
测试总结报告。
3.8.2测试总结报告中必须包含的内容
被测试软件名称、测试项、测试环境；
测试项包括：Server的connectins、内存及CPU使用情况、响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间，并发数与失败的关系。
4、人员和职责
4.1 职责
系统管理部支持服务部&系统验证部：负责架设客户端测试环境的架设.
系统验证部：负责编写测试计划，组织测试，对测试过程进行记录，收集、整理测试记录数据，对测试结果进行分析，编写测试总结报告。
SDD3：负责编写、调试客户端测试软件；数据库管理系统的安装、配置及系统的本底数据准备。
系统管理部支持服务部：负责测试用的硬件维护及操作系统安装、配置。
系统验证部主管：负责对测试计划及测试总结报告进行批准。
用户：必要时可参加测试，并提出具体的测试要求；可要求暂停测试。
4.2 人员和训练要求
本次测试无特别的人员及培训要求。
5、批准
本测试计划必须经过系统验证部主管批准后才能开始实施。
压力测试（Stress Testing）是指模拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。扩展开来说，其一压力测试应该是较短时间的，其次是模拟巨大的工作负荷的，再次压力测试是要使应用程序的使用达到峰值。
此次压力测试主要是在阶段一的基础上进行的一个更高层的测试,测试内容包括：
仿真产线的实际作业进行应用服务器的最大连接数、内存、CPU使用情况、响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间，并发数与失败的关系；
测试对象为：Normal(Packing2)
此次测试达成情况：
测试项目 | 二厂client目前速度 | 所占比例 | Server端资料量 | 新系统判稳标准 | 测试结果 |
Normal(packing2) | 27秒/箱(48pcs/箱) | 64% | 108万笔（半年） | >27秒/箱(48pcs/箱) | NG |
此次压力测试具体结果如下：
服务器的最大连接数：74
随着时间的变化，mem，cpu，connection的变化如下：随着连接数的增多，cpu&mem呈现出递增现象，当connection达到74时，cpu利用率达到接近100%，
此时Client段无法开启新的程序，已经开启的程序数据写入速度非常慢，接近1分钟才写入一次（一次写入50pcs，没有达到预期结果，27秒写入48pcs）
[attach]107952[/attach]
随着时间、connection的增加，数据量的变化情况如下：
[attach]107953[/attach]
随着时间的变化，数据错误发生情况，标准的一箱写入数据量为50pcs，出错率非常高！
[attach]107954[/attach]
点击下载：数据明细.cvs随着时间的变化，新增连接数与新增数据量的关系如下：
此图说明随着服务器负载的增加，可以反映出数据写入速度的变化情况：速度趋势呈下降状态。
[attach]107955[/attach]
所以，此次测试结果并未达到产线要求，当连接数为74时（实际并不止74台），其它站台无法再作业，且此时党连接数为74时此时的写入速度已非常缓慢不符合产线需求。
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |