第一篇:压力测试开始准备工作[推荐]
在压力测试开始之前,你需要做哪些准备工作?
翻译:尚勇
原作者:不详
如果你在负载测试、压力测试、性能测试或者可量测性测试方面是个新手,你大概会疑惑在测试过程中会牵涉到一些什么。或许你在自动化测试或者人工功能测试方面有很多的经验,并且也打算制作一个负载测试的流程。这会有一些相似之处,但最为重要的是,有巨大的差别。
1.系统:安装一个用作负载测试的环境看起来要花费很多的努力。仔细研究当前的生产系统。决定下来负载测试环境的范围。你是否想要模拟整个的生产系统?或者你只是想模拟生产系统的一个部分?尽管后者不是最为理想的一个方法,但是它是很实用的。会有什么样的组件参与进来?第三方的软件有否集成到你的底层架构中?你想要包括这些第三方的软件吗?硬件如何?记住:你不但需要包含测试下的系统(SUT),而且要包含LoadRunner的压力注射器。如果有可能的话,你应该单独有一个压力测试的环境,和其他的开发、测试或者生产的环境分离开来。所有的这些问题和以及将来更多的问题需要包含在预算中的。
2.网络:理想的状态,你的压力测试的环境应在一个独立的网络中。如果无关紧要,可以用一个交换网络来替代。原因是非常明显的,但又常常被忽略掉。首先,你不想让一些和测试无关的操作介入你的测试。如果你正在进行一个压力测试,这时其他人却在网络上通过FTP或者NDM传送大量的文件或者数据,这样会导致你的测试失去意义。同时,你也不想让你的大规模的压力测试影响网络上的开发或者生产系统。如果你对网络造成涌堵会成为不受欢迎的人。
3.范围:你的压力测试实验室的主要焦点是什么?是针对单独的一个应用程序?或者是负责整个企业的多个应用程序的测试?这是一个需要你在安装你的测试实验室之前需要考虑的关键问题。
4.计划:对一个压力测试来讲,在测试计划方面下再大的努力也是不充足的。试图在一个礼拜之内运行一个大规模的压力测试是有很多问题存在的。你必
须创建一个非常详细的计划,在这个计划里需要包含关于这个测试的方方面面:交易的流程/工作量/生产量,而且需要测试的系统的详细图表,关于你的测试方法论的相关信息(换算系统,成功因素,运行测试的每一步的步骤),整个项目组的观点以及他们的关心,需要收集的重要属性的解释,执行测试的日期和时间,联络人的列表,包含在内的系统的组件,风险和减轻风险的措施。这些都是你测试计划里需要包括的例子。并非所有的测试都需要做到如此的详细,但是你应该从类似的模板中精选出你认为需要包括进去的。
5.支持:在你运行你的测试的时候,总是需要系统和开发部门的人做支持的。在一个关键测试运行的中间阶段,如果一个服务器出现锁定是让每一个人灰心丧气的事情。如果你自己能够解决最好,不能解决就要找人来解决。
6.人员:压力测试会消耗掉你的大量的时间。如果你在对多个应用程序进行压力测试,并且是按照特定的程序重复你的测试,那么你需要有足够的人员来满足你的需求。
第二篇:压力管道评审准备工作
审核准备工作
1、压力管道安装GB1(PE)、GB2(2)、GC2级。执行标准
2、压力管道安装现场评审:
⑴安装(工程)批号是完成工程(GB1(PE)、GB2(2)、GC2级、工程资料、拍片、监检等)。
3、原材料堆放整齐、分类清楚、标识清楚。
4、原材料检验记录要规范填写。材料质保书盖好材料确认章同时签字。(原材料供应单位:必须是合格供方名单上生产企业。钢制无缝钢管、锻件、管件、法兰、阀门、膨胀节、标准件等必须要有特种设备制造许可证的企业)(原材料质保书合格供方单位盖质检原公章、复印件无效)(焊材质保书)(供方名单、采购计划、供方质量保证调查、采购合同等)
5、工程所有安装过程控制记录,检验记录填写完整规范。
6、安装现场整理清洁、堆放整齐、标识清楚。
7、材料批号(编号)、安装(工程)批号(编号)一定要有可追溯性。
8、受检工程的合同按照(工程)标准签订。
9、仓库原材料整理材料质保书,检验记录。
10、公司员工的劳动合同签订,社保相关材料,工资发放表(日期2015.1~目前)
11、安装设备、安装检测设施一定满足压力管道安装许可规则。
12、产品相关标准整理齐全。(最新版标准)
13、建立技术资料、文件资料、工程归档,焊工档案、档案室。
14、焊接工艺评定(试件标识清楚)
15、检验、试验区域标识清楚(合格品区、不合格品区、待检品区)
16、焊材库(焊接是工程主要工序,应当有专用的焊接材料库,有确保焊接材料湿度、温度符合要求的吸湿机设备;应当有焊接材料烘干设备3台,适应制造需要的焊条保温桶。(吸湿机、温湿表、烘箱、保温桶、相关记录)
17、焊接试焊室
(1)试件的保管(登记台帐,存放在柜子中、试件标识清楚)
(2)焊接工艺评定资料(材料、焊接位置、产品(试件)材料规格)。(检查是否遗漏项目)
(3)焊接通用工艺卡。(根据安装工程编制)
(4)现场焊接样品准备常规的产品。(评审现场焊工考试)(5)焊条的规格要齐全并与现场的一致。(6)焊接试验室:配备焊机、试样存放框
18、评审现场焊接工考试,准备好理论、实际考试。
19、检测设备、安装监控设施(市计量检验所检定合格证书)20、检验、试验区域标识清楚(合格品区、不合格品区、待检品区)
21、安装工程现场不能有焊条随便摆放。
22、焊接工艺评定试件理化检测委托机构必须有资质单位(签订分包协议)
23、工程焊接的无损检测委托机构必须有资质单位(签订分包协议)
24、工程图纸设计单位委托设计必须有资质的机构(签订分包协议)
25、原特种设备安装许可证上产品(GB1(PE)、GB2(2)、GC2)所有进货检验记录、材料质量证明书(盖材料确认章),安装过程控制记录,检验记录、成品检验、合格证(质量证明书)填写完整规范。(日期:2011年取证以后~目前《抽查例年安装工程档案》,按月归档或合同归档)(以上安装工程(产品)的订货合同或特检院监检报告)
26、设备台账、日常维护保养记录、维修计划、档案等。
27、计量器具台账、(检定合格证)档案等。
28、员工能力评定表、档案、培训等。
第三篇:项目开始前的准备工作
CEO埋下了失败的“种子”
“企业信息化是什么?”
许多的时候CIO都告诉CEO,信息化可以提高企业的反应能力,提高与客户的沟通效率,增强企业应对市场的灵活性,从而使企业能够更加灵活地应对市场竞争,满足于客户的需求,从而获得更多利润。
这种解释,貌似讲明了信息化对企业的价值,但只不过是信息化对企业作用的表层显现。信息化最重要的价值,并不是它能创造什么显性价值,而是在于它能够打破企业中原有的各种信息的沟通障碍,形成一种信息共享“文化”。这种“文化”将逐步削弱信息孤岛效应,使企业获得快速的市场反应能力,按照市场的要求改变自身的行为,让企业的产品服务更加贴近用户,赢得顾客的喜爱,企业也在赢得顾客的同时获得更多利润。
在京华公司的ERP项目实施中,老板的尝试心理,在项目实施之初就已经为ERP项目的失败埋下了“种子”。“ERP供应商是为我们服务的,我们花了钱,当然是要什么,就让他们做什么。”这是企业老板的常见心理,至于信息化到底是什么,能带来什么样的效益,需要对信息化提供怎样的支持……他们并没有真正认识到,因此在项目进行中,往往最具决策权的老板却对项目没有明确的认识,实施中做出一系列决策失误也就在所难免。
CIO迷住了自己眼睛
流程改造、第三方咨询、员工培训……这些项目的实施过程,相信CIO们都已经烂熟于心,但真正到了项目实施的时候却往往手忙脚乱,是谁迷住了CIO的眼睛?不是别人,常常是CIO自己!
京华公司在项目实施前并没有认真进行项目的各种准备工作,仅仅是老板的一次“尝试”便启动了ERP项目。这让CIO李杰在项目实施中吃尽了苦头。在京华公司ERP项目前期调研阶段,各个部门表面赞同实则推诿、对信息化建设在自己部门的应用认识不足、需求不清,又不跟IT部门进行沟通,惯性的依赖让业务部门把所有的任务转嫁给IT部门,也因此逃避了责任,继而在项目后续实施中,提出各种各样的改进需求,无穷无尽的二次开发最终将项目拖进了成本不断增加的泥潭……
项目开始前,一些准备工作必不可少,做好这些工作可以帮助CIO在项目实施中擦亮双眼,及时预测并规避各种风险。这是工作包括:
1、识别企业信息化的关键流程,对需要改进的“短板”进行必要补充;
2、对企业进行变革的数据进行基础性整理,规范数据类型;
3、根据实际情况制定员工基础IT技能培训计划;
4、选择信息化硬软件产品、及第三方的咨询服务;
5、取得企业中各种力量的支持;
6、尽可能多的考虑各种可能发生的困难和阻力,进行风险预测;
7、对人员、财务、文化变革风险进行思考规划;
……
只有在前期准备阶段,尽可能多地考虑项目为企业带来的变革和影响,才能有效降低项目实施的阻力。
第四篇:测试准备工作状态报告
测试准备工作状态报告
目录
1测试方法分类...........1
1.1静态测试................1
1.2动态测试................2
1.2.1黑盒测试..........2
1.2.2白盒测试..........2
1.3单元测试、集成测试、确认测试、系统测试、验收测试...........2
1.3.1单元测试..........2
1.3.2集成测试..........3
1.3.3确认测试..........3
1.3.4系统测试..........3
1.3.5验收测试..........3
2.各种测试方法的优缺点................3
2.1各种测试方法的优点.............3
2.2各种测试方法的缺点.............4
3.对软件测试方法的理解................4
1测试方法分类
1.1静态测试
静态测试又可分为代码走查,代码审查,技术评审。它可以由人工进行,充分发挥人的逻辑思维优势,也可以借助软件工具自动进行。
1.代码走查
开发组内部进行的,采用讲解、讨论和模拟运行的方式进行的查找错误的活动。
2.代码审查
开发组内部进行的,采用讲解、提问并使用编码模板进行的查找错误的活动。一般有正式的计划、流程和结果报告。
3.技术评审
开发组、测试组和相关人员(QA、产品经理等)联合进行的,采用讲解、提问并使用编码模板进行的查找错误的活动。一般有正式的计划、流程和结果报告。
实际工作,我们完全不必要被概念所束缚住,根据项目的实际情况来决定采取什么的静态测试形式,不用严格去区分到底是代码走查,代码审查和还是技术评审。在实际使用中,代码检查比动态测试更有效率,能快速找到缺陷,发现30%~70%的逻辑设计和编码缺陷;代码检查看到的问题本身并非征兆。
1.2动态测试
动态测试又分黑盒测试、白盒测试和回归测试。
1.2.1黑盒测试
黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。
黑盒测试的测试用例设计方法:等价类划分方法、边界值分析方法、错误推测方法、因果图方法、判定表驱动分析方法、正交实验设计方法、功能图分析方法
1.2.2白盒测试
白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。
1.3单元测试、集成测试、确认测试、系统测试、验收测试 软件测试类型按开发阶段划分单元测试、集成测试、确认测试、系统测试、验收测试
1.3.1单元测试
测试的对象是软件设计的最小单元,目的是检验模块中有无故障存在,针对每个模块解决5个方面问题:模块接口测试,模块局部数据结构测试,覆盖测试,出错处理测试,边界条件测试。在对每个模块进行单元测试时,需要考虑模块与周围环境之间的相互联系,因为每个模块在整个软件中并不是单一的。为模拟这一联系,在单元测试时,必须设计辅助测试模块,即驱动模块和桩模块,被测模块与这两个模块一起构成一个测试环境。单元测试要完成这个全过程。
1.3.2集成测试
是按照设计要求将通过单元测试后的模块组合成一个整体测试的过程。因为程序在某些局部没有出此案的问题,很可能在全局上暴露出来。主要方法分为非增量式集成测试和增量式集成测试两种。
1.3.3确认测试
通过集成测试之后,独立的模块已连接起来,构成一个完整的程序,其中各模块之间存在的问题已被消除,即可进入确认测试阶段。
1.3.4系统测试
软件和硬件进行了一系列系统集成和测试,已保证系统各组成部分能够协调地工作。系统测试实际上是针对系统中各个组成部分进行的综合性测试等。系统测试的目标不是要找出软件故障,而是要证明系统的性能。
1.3.5验收测试
验收测试是将最终产品与最终用户的当前需求进行比较的过程,使软件开发结束后软件产品向用户交付之前的最后一次质量检验活动,它解决软件产品是否符合预期的各项要求,用户是否接受等问题。验收测试是全面的质量检验并决定软件是否合格。
验收测试的主要任务:明确验收测试通过的标准;确定验收计划、方式并对其进行评审;确定测试结果的分析方法;设计验收测试的用例;执行验收测试,分析验收结果,决定是否通过验收。
2.各种测试方法的优缺点
2.1各种测试方法的优点
黑盒测试的优点:简单,不需要了解程序内部的代码及实现;从用户角度出发,能很容易的知道用户会用到哪些功能,会遇到哪些问题;基于软件开发文档,所以也能知道软件实现了文档中的哪些功能;在做软件自动化测试时比较方便。
白盒测试的优点:迫使测试人员去仔细思考软件的实现,可以检测代码中的每条分支和路径,揭示隐藏在代码中的错误,对代码的测试比较彻底,最优化。
2.2各种测试方法的缺点
静态测试的缺点:代码检查非常耗费时间,而且代码检查需要只是和经验的积累。黑盒测试的缺点:测试不可能覆盖所有的代码,覆盖率较低;自动化测试的复用性较低。白盒测试的缺点:程序运行有很多路径,不可能测试所有的路径;基于代码,只能测试程序设计的对不对,不能判断功能设计合不合理;测试开销大。
3.对软件测试方法的理解
在测试软件时应该先使用黑盒测试法,在在此基础上进行白盒测试。主要应该使用等价类划分方法、边界值分析方法。要仔细划分有效等价类和无效等价类。
第五篇:压力测试计划实例
压力测试计划实例
发布时间: 2007-4-14 11:22作者: tonny来源: 转载
字体:小中大| 上一篇 下一篇 | 打印| 我要投稿| 每周一问,答贴有奖
利用现代的设计技术和正式的技术复审可以减少代码中存在的初始错误,但是错误总是存在的,如果开发者找不到错误,那么,客户就会找到它们。越来越多的软件组织认识到软件测试是软件质量保证的重要元素之一,很多软件开发组织将30%—40%甚至更多的项目资源用在测试上,软件测试技术和软件测试策略受到了高度的重视和广泛的应用。
本文不想就软件测试技术和软件测试策略作深入的理论分析,而是列举一个在软件系统测试阶段进行的压力测试实例,希望能通过这个实例与从事软件测试相关工作的朋友进行交流。
首先介绍一下实例中软件的项目背景,该软件是一个典型的三层C/S架构的MIS系统(客户端/应用服务器/数据库管),中间层是业务逻辑层,应用服务器处理所有的业务逻辑,但应用服务器本身不提供负载均衡的能力,而是利用开发工具提供的ORB(对象请求代理)软件保证多个应用服务器间的负载均衡。本次测试的目的是:进行单个应用服务器的压力测试,找出单个应用服务器能够支持的最大客户端数。测试压力估算的依据是:假定在实际环中,用户只启用一个应用服务器进行所有的业务处理。方法是:按照正常业务压力估算值的1~10倍进行测试,考察应用服务器的运行情况。
压力测试的详细计划如下:
压力测试计划
1、测试计划名称
河北省公安交通管理信息系统压力测试计划。
2、测试内容
2.1背景
本次测试中的压力测试是指模拟实际应用的软硬件环境及用户使用过程的系统负荷,长时间运行测试软件来测试被测系统的可靠性,同时还要测试被测系统的响应时间。用户的实际使用环境:
◇由两台 XSeries250 PC Server组成的Microsoft Cluster;
◇数据库管理系统采用Oracle8.1.6;
◇应用服务器程序和数据库管理系统同时运行在Microsoft Cluster上。
◇有200个用户使用客户端软件进行业务处理,每年通过软件进行处理的总业务量为:150万笔业务/年。
2.2测试项
应用服务器的压力测试;
2.3不被测试的特性
◇系统的客户端应用程序的内部功能;
◇数据库中的数据量对程序性能的影响。
3、测试计划
3.1测试强度估算
测试压力估算时采用如下原则:
◇全年的业务量集中在8个月完成,每个月20个工作日,每个工作日8个小时;
◇采用80—20原理,每个工作日中80%的业务在20%的时间内完成,即每天80%的业务在1.6小时内完成;
测试压力的估算结果:
去年全年处理业务约100万笔,其中15%的业务处理每笔业务需对应用服务器提交7次请求;70%的业务处理每笔业务需对应用服务器提交5次请求;其余15%的业务每笔业务向应用服务器提交3次请求。根据以往统计结果,每年的业务增量为15%,考虑到今后三年业务发展的需
要,测试需按现有业务量的2倍进行。
每年总的请求数量为:(100*15%*7+100*70%*5+100*15%*3)*2=300万次/年。
每天的请求数量为:300/160=1.875万次/天。
每秒的请求数量为:(18750*80%)/(8*20%*3600)=2.60次/秒。
正常情况下,应用服务器处理请求的能力应达到:3次/秒。
3.2测试环境准备
3.2.1基本硬件及软件环境的准备
1)网络环境:公司内部的以太网,与服务器的连接速率为100M,与客户端的连接速率为10/100M自适应。
2)使用两台IBM XSeries250(1G内存)PC Server作Microsoft Cluster,安装系统软件
2000 Advance Server及Microsoft Cluster Server(MSCS)。
3)数据库管理系统的安装及配置:在测试用的IBM XSeries服务器上安装Oracle8.1.6,数据 库采用
Fail Safe(ofs)的Active/Passive配置。安装数据库管理系统及支撑软件(包括VisiBroker和BDEAdministrator)。
4)安装被测的应用服务器程序。
5)客户端的PC机:10台(PⅢ600/128M RAM)。
3.2.2系统客户端测试程序的编写系统客户端测试程序使用Delphi编写,要求测试程序实现如下功能:
1)模拟一个主要的向应用服务器发送请求并接收响应信息的功能。要求交替模拟两种情况:第一种,发送的请求至少包括10个参数,参数类型涵盖字符、日期、数字种类型;接收的响应信息不少于1个参数;第二种,发送的请求不少于1个参数;接收的响应信息至少包括10个参数,参数类型涵盖字符、日期、数字种类型。
2)必须能够通过参数设定在每台PC机上运行的客户端测试程序个数、请求的时间间隔(单位:毫秒)、运行时间(单位:小时)。
3)在数据库中建立测试记录表,生成测试记录,向数据库写入测试记录的功能不通过被测的应用服务器实现。日志内容包括:发送测试请求的机器名、客户端测试程序序号、发出请求时间、收到响应时间、处理是否成功。表名:TEST_LOG,字段名:MACHINE、ID、START_TIME、END_TIME、FLAG。
3.2.3系统本底数据的准备
为考察系统运行一段时间后系统的响应性能,参照实际运行情况及发展进行系统的本底数据准备。业务处理中涉及到的业务表中都要求按设计规模进行本底数据的准备。要求准备的数据记录的有效性符合系统要求,数据有效性的具体要求参见数据库设计及系统设计文档。
3.3破坏性测试
按照设计连接的客户端连接数量进行测试,把应用服务器处理请求的设计频度增加1-10倍,分别测试出现错误的状态和和出现错误的比率,考察是否出现不可恢复错误,系统设计要考
虑出现严重错误情况下负荷减轻错误自动恢复的实现方法。
计划时间:2天;这个时间包括破坏性的修复和自动恢复的实现需要的时间。
在测试过程中每10分钟记录一次IBM Xseries PC
Server的内存及CPU使用情况,包括被测程序的内存占用百分比、数据库管理系统的内存占用百分比、操作系统的内存占用百分比。
3.4强度稳定性测试
选择一种负荷比设计负荷重的情况(应用服务器处理请求的频度为应用服务器处理请求的 设计频度的1.5倍),进行24小时稳定性测试。
3.5测试方法和工具
黑盒测试
测试工具:无外购的测试工具,自己编制的测试工具。
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测试报告 2002.06.21
测试总结报告提交日期:2002.06.21。
3.8.1应生成的测试文件
测试记录(测试负责人和参与测试的人员签字);
测试总结报告。
3.8.2测试总结报告中必须包含的内容
被测试软件名称、测试项、测试环境;
被测试软件的压力测试结论:响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间,并发数与失败的关系。
4、人员和职责
4.1职责
测试工程师:负责编写测试计划,组织测试,对测试过程进行记录,收集、整理测试记录数据,对测试结果进行分析,编写测试总结报告。
软件工程师:负责编写、调试客户端测试软件;数据库管理系统的安装、ofs配置及系统的本底数据准备。系统工程师:负责测试用的硬件维护及操作系统安装、MSCS配置。
总工程师:负责对测试计划及测试总结报告进行批准。
用户:必要时可参加测试,并提出具体的测试要求;可要求暂停测试。
4.2人员和训练要求
本次测试无特别的人员及培训要求。
5、批准
本测试计划必须经过总工程师批准后才能开始实施。