qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

功能测试自动化的投入和产出

 测试自动化,对于系统性能测试、负载测试等效果是明显的,而且我们也不得不为之。
我们知道,没有测试工具进行负载模拟,要通过手工测试完成系统测试任务,几乎是不可能的。但在功能测试中,情况就大不一样了。

手工测试在功能测试中的优势还是比较大的,工具本身并没有想象力和灵活性,而人对界面美观性、逻辑合理性,容易作出判断。

所以功能测试自动化主要的应用 在回归测试中,而且产品的界面(UI)和功能变化较大,自动化的脚本(Script)维护成本较大,投入和产出往往变成我们最关心的问题,在功能测试中实 现测试自动化究竟是否合算?

  举个例子:假如一个功能测试用例,手工运行需要10分钟,而为此测试用例开发脚本需要4个小时,即240分钟,那么意味着这个测试脚本要被运行24次收回成本,如果在加上测试脚本的维护工作量(10%),需要重复运行40-50次,才收回成本。如果在产品的一个版本中要进行2-3轮测试(一般是需要的),这个产品需要发布15-20个版本才收回成本。所以业界常说,产品发布7个版本才收回成本。

  如何降低成本、可以相对增加产出或者说更快地收回成本?关键是提高脚本开发速度、提高脚本运行的稳定性和降低维护脚本的工作量,主要方法有:

  - 选择较好的、更适合的测试工具

  - 选择适宜自动化的模块

  - 尽量将脚本写成数据驱动的脚本,这一点很重要。

  - 多录制脚本,然后结构化脚本。我们知道,不是所有的模块都可以变为数据驱动方式,这时就要抽象出脚本的结构,进行有效的组合,包括分层,形成有效的层次性。

  - 测试和脚本开发合二为一,效率更明显

  下表也部分说明了这个问题。也希望得到您更好的想法。

结构
成本
收益
净收益
No Automation
0
0
0
Recording and Playback
8.3
11
2.7
Data-drivenstructure using data pools
8.4
18
9.6
Framework structure
9.8
15
5.2
Framework / data-driven (hybrid) structure focusingon views of the application and using data pools
11.6
19
7.4

posted @ 2011-10-13 17:16 顺其自然EVO| 编辑 收藏

IBM测试流程

  在“测试评估和计划”中的一些测试计划和测试策略等活动的介绍,可以在网上搜索到,而且这些内容对于初学者来说只需要了解就行了,因为这些内容大多是测试经理和测试架构师在做。

  在本章节的介绍中

  测试用例的内容:

  测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。

  开始点:当需求已经被记载和复查,相关的测试方案已获批准的时候,测试用例开发才开始。

  结束点:测试用例是用于整个测试执行阶段,并且为后续项目回归测试用例重用而保留。

  测试用例的作用:测试用例是执行的最小实体。简单地说,测试用例就是设计一个场景,使软件程序在这种场景下,必须能够正常运行并且达到程序所设计的执行结果。

  测试数据的内容:

  测试用例在执行过程中,需要一些数据输入。测试数据准备就是在这些测试用例执行前,准备一些这些测试用例需要的测试数据。测试数据和测试用例的结合,产生一个可重复使用的,独特的,可追溯至应用需求的测试场景。

  开始点:当测试方案已获批准后,测试数据准备与测试用例开发进行。

  结束点:在测试准备期间和整个测试执行期间,测试数据将被积极地使用和完善。所有测试数据将被保留为回归测试和后续项目的自动化重用。

  测试数据的作用:测试数据对可重复使用的测试用例具有非常重要的支持性,支持应用程序的质量分析的定义。

  测试用例可以被反复使用,在回归测试的时候测试,或者在下一测试阶段的时候或者在下一软件版本的时候会反复用到这些测试用例。有些时候原封不动的使用这些用例,有些时候是要做一些修改优化,有些时候是要做一些。

  有些时候在做测试准备的时候,要花很多时间建立测试环境和测试数据,而测试执行却花很少的时间。测试数据对测试的验证和测试结果的分析,具有重要的意义,特别是对测试结果的分析具有支撑意义。

  测试设计的能力应该是测试工程师应该具有的很重要的能力之一。在我的博文《测试用例设计步骤》中包含到有少量关于测试分析的,请读者自行到网上搜索测试分析的相关知识,本理论在此不做介绍。

  在我的博文《测试数据的选择》和《软件测试数据的准备》等博文中有介绍测试数据的相关知识,故在这里不再做过多的讨论。

  在我的博文《测试用例基本概念》、《测试用例设计白皮书--等价类划分方法》和《测试用例的粒度的讨论》等博文中有关于测试用例测试的详细讨论。

相关链接:

IBM软件测试理论——测试类型和测试阶段

 

BM软件测试理论——测试类型和测试阶段


  从第一张图片可以看出,最上面一条是典型的软件开发生命周期,那是一条时间轴,给下面的测试定 义在那项测试发生在软件生命周期上的哪一部分做参考。很多不懂测试的或者只是懂点点测试知识的朋友,对测试中的很多定义是混乱的,把各类按照不同标准划分 的测试类型混在啦一起。这一节将会把按照不同标准划分的测试类型讲述清楚,后面的章节会把这些测试中的定义阐述得比较清楚。

  从软件质量保证上来划分测试,测试可以划分成静态测试和动态测试。静态测试就是指不运行被测程序本身,仅通过分析或检查源程序的文法、结构、过 程、接口等来检查程序的正确性,静态测试可以分为代码审查、代码走读、文档审查等行为动态测试是指通过运行被测程序,检查运行结果与预期结果的差异,并 分析运行效率和健壮性等性能的测试过程。从那条参考的时间轴上来看,动态测试和静态测试可以发生在整个软件生命周期的全过程。关于静态测试和动态测试的更 多讨论在我的博文《静态测试和动态测试》中有比较详细的讨论。

  按照测试技术(test techniques)划分,测试可以划分为白盒测试、黑盒测试和灰盒测试。在这套理论的介绍中,后面会有专门的一节来介绍这三种测试。其中灰盒测试是指 白盒和灰盒测试相混合的一种测试。从那条参考的时间轴来看,白盒测试发生时间比较靠前,黑盒测试发生时间比较靠后,而灰盒测试发生的时间介于2者之间。

  按照测试阶段(test levels)划分,测试可以划分单元测试、集成测试、系统测试、系统集成测试、用户验收测试和维护测试,这一划分是根据软件生命周期和测试生命周期中自然形成的阶段进行划分的,当然越靠前的测试越先进行。

  从第二幅图可以看出,单元测试和集成测试是由开发团队来做的,而集成测试和系统集成测试是由测试人员来做的,用户验收测试是由用户和测试团队来 做的,及时用户不参与,测试人员也是在用户的角度进行测试的,这里没有做维护方面的测试。单元测试是指针对各个单元模块进行的测试;集成测试就是由更多的 已经完成了单元测试的测试单元构成的测试,集成测试仍然不是在一个完整的测试过程上测试;系统测试是程序第一次以一个完整的个体形式进行运行而进行的测 试;而系统集成测试在系统测试的基础上,还要关注整个软件系统与外界的交互,比如调用打印机,比如与本软件系统以外的其他系统进行交互;用户验收测试也就 是通常大家所说的UAT,这个时候整个软件系统已经有了比较好运行状态,可以接受用户验收测试啦。每一阶段的结束被看做是输出,都是作为下一阶段的输入, 在测试流程上有明确的定义什么这些输入和输出的标准,后面的章节会对这些标准做详细的阐述。每一阶段的测试,都应该包含前一阶段的测试内容,也就是前一阶 段的测试内容,但是侧重点不一样,从红色的箭头和红色的边框可以看出各个阶段的测试侧重点。比如UAT过程中遇到了不属于UAT测试项的bug,当然也是 属于UAT的内容。

  按照测试类型(test types)划分,这些划分包含审计和控制、文档和过程、功能、需求、接口、回归测试、备份和恢复、工作流、性能、压力、容量、变换、安装、错误处理、并 行、事物流、可用、UI、可操作性和安全性等方面的测试。具体的一些测试类型的定义,可以从网上搜索得知。

  各个测试类型可以发生在各个的测试阶段,从第三幅图可以看出,每个测试阶段所涉及到的测试类型,而静态测试应该和这些测试阶段并列开来,也可以 理解成这些测试阶段都是属于动态测试的。从横行可以看出错误处理和回归测试发生在所有的测试阶段,因为每个阶段都会有bug,有bug就会有回归,当然回 归测试会发生在各个测试阶段。从竖行上可以看出,系统测试涉及到了最多的测试类型,因为这个时候软件系统是第一次以一个完整的个体而运行,需要的测试方面 是最多的。也并不是所有阶段都要进行所有的类型测试。


 


 

IBM软件测试理论——白盒测试、黑盒测试和灰盒测试


 

 按照测试技术test techniques)划分,测试可以划分为白盒测试黑盒测试灰盒测试

  我用google翻译翻译了每页左下角解释什么是白盒测试、黑盒测试和灰盒测试的部分,不太准确,准确的话请看英文原文。

  在这套理论中,关于白盒测试的描述是:

  1、白盒测试,是对一个软件组件或系统内部的设计知识为基础的测试。

  2、白盒测试是逻辑为导向,重点是通过对某些软件测试的执行路径。

  3、测试设计决定被测软件所需要的一定路径下输入设定,并指定每个输入的预期将要采取的路径和输出。

  4、测试执行运行有指定输入的软件,检查了预期的路径追踪,有产出符合预期的结果。

  5、代码覆盖测试经常被用来评估白盒测试的彻底情况。

  在这套理论中,关于黑盒测试的描述是:

  1、“黑盒测试”描述的是不管一个软件组件或系统内部的设计知识的测试。

  2、黑盒测试是需求导向,在所有测试阶段使用。

  3、黑盒测试专注于输入和输出的软件测试。所有可能的输入和/或输入组合输入到测试系统。有效和无效的输入也是用来测试系统。

  4、测试设计根据软件的设置,在确定的输入情况下,指定每个输入的预期输出。

  5、测试执行是运行有指定的输入情况下的软件,检查对预期输出的结果。

  在这套理论中,关于黑盒测试的描述是:

  1、“灰盒测试”描述的测试是一个黑盒测试与白白盒试组合,我们知道被测程序的一些部分(不是全部)是如何工作的。

  2、灰盒测试,侧重于输入与产出(预期结果),但是测试设计和执行是基于算法,架构,数据库的知识。

  3、一个关于灰盒测试的例子,测试人员将到数据库中建立自己的测试数据库中的数据,并实际上将要到数据库中通过SQL查询来确认/验证输出/测试结果。

  4、灰盒测试被最多的用在测试数据的覆盖范围,但也可能是单独使用在确认配置文件的变化。

  网上关于白盒和黑盒测试的定义介绍很多,关于白盒测试的设计也很多,我这里就不在多介绍。我是个专职的测试人员,所以只了解黑盒测试,因为白盒测试一般由开发人员或者专职的白盒测试人员来做。

  每页的左上角的红框部分都是指明白盒测试、黑盒测试和灰盒测试所涉及到的测试阶段。更大的图请看前面一节的博文内容。白盒测试涉及到的是单元测 试和部分集成测试,黑盒测试涉及到的是绝大部分的系统测试和所有的系统集成测试用户验收测试,而灰盒测试涉及到全部集成测试、系统测试、系统集成测试和少 量的单元测试、用户验收测试。

  其实网上有很多关于灰盒测试的内容,只是平时很多人没有明确提出灰盒测试。一些软件公司的测试过程中已经使用了比较多的灰盒测试,当他们遇到灰盒测试的定义和内容后,明白起来很容易。而只知道白盒和黑盒测试的朋友,希望心里有灰盒测试的概念。

  每页右边的input case对白盒、黑盒和灰盒的概念都有一个明确的图示,很容易帮助理解他们的概念。

相关链接:



 

IBM软件测试理论——单元测试和集成测试

 

  从网上可以搜索到很多关于单元测试的定义,比如百度百科中就有详细的介绍。而此理论中关于单元测试的内容有:

  单元测试是对新的或者更改过的代码模块进行的初步测试。它验证程序或模块的内部逻辑和程序规范。

  开始点:单元测试开始在开发阶段,当编码已经完成,单元测试计划已经被有关各方已批准。

  结束点:单元测试结束后,所有的测试案例被成功执行,没有严重缺陷1或2。一项行动计划已经被记录在案,以解决还未解决的其他缺陷。

  单元测试的作用:单元测试有助于早期识别和修复缺陷,早期消除单元模块的不确定性

通过测试程序的各个部分,然后再测试其各部分的总和,集成测试就更简单啦。

  相关活动:测试计划和测试用例审查,由有关各方批准的基线控制之下;

按计划执行单元测试用例;通过跟踪需求变更来验证测试覆盖面;进行缺陷分析;完成单元测试报告。

  单元测试的评估有:代码覆盖率的百分比,符合组编码标准,圈复杂度,行代码,路径,参数,缺陷密度。

集成测试  

从网上可以搜索到很多关于集成测试的定义,比如百度百科中有详细的介绍,而此理论中关于集成测试的内容有:

  集成测试验证多个已经完成了单元测试的模块的执行。所测试的应用程序通常不连接到系统中的其他应用程序。

子系统模块的通信测试是在一个控制和隔离的环境。

  开始点:集成测试开始时,单元测试已经顺利完成,当集成测试计划已经被有关各方已批准,并且在基线控制之下。

  结束点:集成测试结束后,所有的测试案例的成功执行,没有严重缺陷1或2。一项行动计划已经被记录在案,以解决所有还未解决的缺陷。

  集成测试的作用:集成测试有助于较早的识别和修复中缺陷,降低了成本。它也减轻了系统测试过程中的风险。

  相关活动:测试计划和测试用例审查,由有关各方批准的基线控制之下;

按计划执行集成测试用例;通过跟踪需求变更来验证测试覆盖面;进行缺陷分析;完成集成测试报告。

  集成测试的评估有:成本和进度偏差,缺陷,生产力,效率和测试覆盖度。

  圈复杂度一种代码复杂度的衡量标准,中文名称叫做圈复杂度。

在软件测试的概念里,圈复杂度“用来衡量一个模块判定结构的复杂程度,数量上表现为独立现行 路径条数,即合理的预防错误所需测试的最少路径条数,圈复杂度大说明程序代码可能质量低且难于测试和维护,根据经验,程序的可能错误和高的圈复杂度有着很 大关系”。

  在这套理论中,大多用的是缺陷(defect)一词,认为缺陷(defect)包含的范围大于bug所代表的意思,认为软件一切不足的地方都是 可以当做defect处理,而Bug所代表的内容比defect更少一些。其实现在各个公司有各自的叫法,还有叫issue的,但是意思都是一样的,都是 指软件的不足之处。此套理论的后面部分都是称呼为缺陷(defect)。

  以后介绍的各种测试的定义,都是按照图中所展示的那样结构来展示。左上角是一堆相关的测试类型或者测试阶段,第一页的最下面一排是关于这个测试类型中的各种文档,相关的文档并不一定全展示完了。第二页的右上角都涉及到了这个测试阶段或者测试类型所常用到的测试工具。

  “参与者”里面详细地介绍了这个测试阶段有哪些测试角色参与,带点的测试角色就被包含在这个测试中,在实际工作中,各个角色之间可以由同一人担 当。这套理论中,测试团队中都有一两个叫“Test architect”的人,测试架构师是团队中的关键人物,类似于系统架构师或者系统分析师,他的作用是参与系统的研发与架构,分析系统与功能模块,找出测试的难点与关键点,决定测试工具环境平台等方面的主意,在技术上主导团队的测试过程。

  第二页的右下角有相关的评估方面,这些评估方面就是测试用例设计的依据。

  单元测试和集成测试都是由开发人员完成,在写完代码后进行的。单元测试和集成测试都有明确定义的开始点和结束点,并且测试结束的时候都要提供相应的输出。测试开始的时候,测试计划都已经被各方批准了才开始,各方是项目经理、测试经理、开发经理、需求分析负责人甚至是客户或者投资者。当这个阶段的 测试过程中未出现严重性为1和2的defect的时候才能结束此阶段的测试,并且未解决的所有defect都应该被记录下来,并且做好何时解决的计划。一个缺陷被解决得越早,越能节省成本;一个发现的缺陷越到后面才来修复,需要更多的成本。

  很多时候,并没有把单元测试和集成测试分开来做,而是一起当做单元测试来进行的。

 


 

IBM软件测试理论——系统测试和系统集成测试、

 


  从网上可以搜索到很多关于系统测试的定义,比如百度百科就有详细的介绍。而此理论中关于系统测试的内容有:

  系统测试把系统的所有组件和对其他系统的接口当作一个整体来测试,包含功能性的测试和结构性的测试,证实这个系统可以正确的运行。

  开始点:系统测试开始于成功的上一阶段的单元测试集成测试,当系统测试计划已经被有关各方已批准,并且在基线控制之下。


 

IBM软件测试理论——用户验收测试和可操作性测试

 


  用户验收测试的内容是:

  用户验收测试(UAT)验证系统是否满足指定的用户需求。该UAT的模拟用户环境,由最终用户或者站在用户角度去测试系统。

  开始点:用户验收测试开始于成功的上一阶段的系统集成测试的结束,用户验收测试计划已经被有关各方已批准,并且在基线控制之下。

  结束点:用户验收集测试执行完所有的这阶段的测试用例,结果中没严重性为1或者2的缺陷。如果未被测试的用例应该被记录下来,并标明原因;所有测试应该被记录下来;有相应的阶段测试报告和总结。

 用户验收测试的作用:用户验收测试使使用者,客户或其他授权实体决定是否接受这个系统。成功的UAT有助于确保业务需求得到满足,为系统在生产中使用做好高度信任的准备。

  相关活动:测试计划和测试用例审查,由有关各方批准的基线控制之下;按计划执行用户验收测试用例;通过跟踪需求变更来验证测试覆盖面;进行缺陷分析;完成用户验收测试报告。

  系统测试的评估有:成本和进度偏差,缺陷,生产力,效率和测试覆盖度。

  可操作性测试的内容是:

  可操作性测试验证应用程序或系统可以在生产环境中运行。这是一个动态的测试阶段,其中系统的所有验证操作都在真实或模拟出来非常真实的生产环境中发生。可操作性测试考虑的是性能,资源消耗和符合标准等因素。

  开始点:用户验收测试开始于成功的上一阶段的用户验收测试的结束,用户验收测试计划已经被有关各方已批准,并且在基线控制之下。

  结束点:一旦被测系统符合测试计划中规定的结束标准,测试便结束。

  用户验收测试的作用:确保软件产品的正确交付和直到软件产品的正确部署。避免在生产环境(内部和外部)中产生可操作性方面的业务缺陷。

  相关活动(由技术支持团队实施和验证如下活动):部署和备份计划;故障切换和恢复计划;紧急中断/修复计划;在run books中更新生产支持;更新帮助数据。

  系统测试的评估有:成本和进度偏差,缺陷,生产力,效率和测试覆盖度。

  用户验收测试(UAT)测试方面的知识,可以在网上找到很多。据我了解,很多公司和很多测试人员都知道这一测试阶段。包括我在内,UAT只是处 于一个系统集成测试之后的测试阶段,应该所有测试用例中涉及到和没涉及到的defect和bug和一切看不顺眼有问题的地方都可以当做测试得到的问题。 UAT是请实际的用户参与测试或者测试人员站在用户的角度去思考和测试系统,而很多时候并没请实际用户参与,只是测试人员站在用户角度去思考和测试。系统 测试和系统集成测试涉及到的很多测试类型,将不再在这个测试阶段进行。这个测试阶段结束的时候,将很接近实际生产中的软件情况啦,客户很可能就决定是否接 受这个软件结果。

  在前面章节中讲解测试阶段的时候没到可操作性测试,而我用介绍维护测试做了代替。可操作性测试应该是UAT结束后,从项目团队到系统部署的这个 过程,由测试人员和技术支持团队(也就是通常所说的售后技术工程师)在模拟的环境中进行部署操作或者直接到客户那边的实际环境中进行部署。这个阶段要做部 署、回复、故障切换、紧急中断和修复等在实际运行中的计划。而且这个阶段使用到的工具也是部署、监控和维护相关的工具。

  最后阶段当然是系统部署和交付给客户后的维护过程,维护测试就是在这个阶段之后。产品部署后,客户方面有人会用监控和管理系统的运行,当出现 defect或者异常等情况,售后技术支持工程师会到客户那边进行处理。当售后技术工程师解决不了的话,会交给项目相关的支持团队,这个团队中就包括维护 测试团队。所以很多很大的系统(比如银行的系统)都会有专人就行监控和管理,也会有一个专门的技术团队为这个系统服务。当系统出现defect的时候,交 给这个团队修改和回归测试,然后再以补丁的形式给系统更新。当系统有一些新的小需求的时候,由这个团队来开发和测试,然后交付。这个团队可以由原来开发时 候留下部分人员组成,当然也可以现招聘,可以在招聘中遇到招聘项目维护团队的职位。

 


 

IBM软件测试理论——功能测试和回归测试

 

  功能测试的内容是:功能测试,在每一个开发阶段,去验证在每个业务功能操作上都和设计文件(内部和外部)中规定的一样。

  开始点:功能测试开始于成功完成单元测试后,和功能测试计划已经被有关各方已批准,并且在基线控制之下。

  结束点:功能测试结束于执行完所有的计划的测试用例,结果中没严重性为1或者2的缺陷。如果未被测试的用例应该被记录下来,并标明原因;所有测试应该被记录下来;有相应的测试报告和总结。

  功能测试的作用:功能测试,验证了系统执行和设计中规定的功能一致。当功能测试正确后才能进入系统集成测试。确定关键功能缺陷和修复缺陷,以避免在系统集成和用户验收测试阶段出现缺陷进行昂贵的返工。

  相关活动:测试计划和测试用例审查,由有关各方批准的基线控制之下;按计划执行功能测试用例;通过跟踪需求变更来验证测试覆盖面;进行缺陷分析;完成功能测试报告。

  功能测试的评估有:成本和进度偏差,缺陷,生产力,效率和测试覆盖度。

  回归测试的内容有:

  回归测试验证,当系统某部分修改(增加新的功能或者修改bug)后,去验证这部分是否被成功修改和其他部分是否会被这部分的修改所影响。

要执行回归测试,应用程序必须运行相同的测试用例通过至少两次。

第一次测试是修改前应用程序的特定部分是否正确响应。

第一次测试获得的应用程序的正确反应做为第二次运行后判定程序是否正确运行的判定标准。

  开始点:因为增加新功能或者修改缺陷而对代码进行的修改后开始回归测试。

  结束点:回归测试结束于成功的执行相关的回归测试用例,并且修改后的程序相关部分没还未解决的缺陷。

  回归测试的作用:回归测试验证了系统的行为是不会受到由于修改系统而产生的影响。它减少了重新验证的时间消耗,它给与验收测试以可信任措施。当时间回归测试相关用例的执行是自动化的时候,显着的好处将被取得。

  相关活动:测试计划和测试用例审查,由有关各方批准的基线控制之下;确定修改的程序(必需的元素)结构属性,然后选择一个可重复执行的测试用例集去执行;制定一个回归测试执行和缺陷的详细报告。

  回归测试的评估有:缺陷评估,失败率,覆盖度。

  功能测试就是验证的系统功能,是软件测试中很重要的一部分。

  所有的defect被修改后,都会去验证这个bug是否成功被修复,而且会验证这个defect周围相关的一些功能是否出现了新的defect,这就是回归测试。

  当软件增加了一个比较大的新功能后,在这个新功能被测试完成后,一般都会有一个专门的回归测试阶段,来进行验证这个软件的其他主要功能是否受影 响,是否出现新defect。一般只测试主要功能的主要流程,不会像对待新功能那样详细的测试。在游戏测试中,当某一个功能模块被做了比较大的修改后,都 会进行一些主要功能模块的主要功能流程的测试,比如背包有比较大的更新,都会去测试背包相关的仓库、装备、生活技能等功能的主要流程。每次系统进行升级 前,都要进行开机测试,验证系统是否能够进行正常的升级,然后才放出来。

  某些回归测试是非常适合自动化测试的,出名的功能测试工具是QTP(quick test professional)和RFT(Rational functional tester)。这2个功能测试工具非常适合做功能方面的回归测试,核心思想就是一个录制和回放的过程,用在回归测试上面的话,录制就是录制被修改前系统 的正确反应,回放是回放被修改后的系统来观看系统的反应。我在后面的章节中会介绍这2个工具。


 


 

IBM软件测试理论——测试流程模型

字体:        | 上一篇 下一篇 | 打印  | 我要投稿  | 推荐标签: 软件测试 测试流程

  第一幅图图示化地展现了IBM测试流程模型。

   该流程模型中的第一排是一个典型的软件生命周期的过程,可以在很多资料中找到这一过程。该过程中每一阶段上的幅度长度和宽度代表在这一阶段所要花费的人 月。此IBM测试流程模型就是以此生命周期做对比基础来展示。测试阶段中的从左到右完全对比到软件生命周期中的整个过程,也就是说项目进行到软件生命周期 中某个位置时,垂直向下可以查找到测试处在测试生命周期的某个位置;测试处在测试生命周期的某个位置时候,垂直向上可以查找到项目处在软件生命周期的某个 位置。

  跟着软件生命周期过程后面的几行是质量管理(应该是QA)、测试项目管理和变更管理。

  这三个管理是要覆盖整个软件生命周期,也要覆盖到整个测试生命周期。

  紧接着是缺陷管理(defect management),缺陷管理覆盖到整个测试生命周期,因为整个测试生命周期都可能涉及到缺陷管理。

  静态测试可以贯穿于整个测试生命周期,和缺陷管理的长度一样。

  在整个软件项目在定义、设计和构建的过程中,都会涉及到测试计划,并不是等到构建块完成或者完成的时候才进行测试计划,因为IBM测试理论强调测试的早期介入(后面会讲到)。

  在做测试计划的时候,已经在为测试做测试准备,所以测试准备贯穿了项目定义、设计、构建和测试阶段。

  然后是测试生命周期中的各个测试阶段,可以看出各个测试阶段都有对应的软件生命周期的位置。测试阶段中的从左到右完全对比到软件生命周期中的整 个过程,也就是说项目进行到软件生命周期中某个位置时,垂直向下可以查找到测试处在测试生命周期的某个位置;测试处在测试生命周期的某个位置时候,垂直向 上可以查找到项目处在软件生命周期的某个位置。

  最后是配置管理、测试工具和管理为整个测试做支持和保障。

  这个测试模型清楚的介绍了测试的过程和测试的保障。这个测试模型中的一些管理和保障不只是为测试服务,而且也为整个软件项目周期做保障,比如配置管理、项目管理和变更管理。

  第二幅图展示了每个测试阶段的测试活动(测试评估和计划、测试准备、测试执行和报告),记住是每个测试阶段都会重复发生这些活动,也就是根据各 个测试阶段的需要,测试相关活动会发生多次。比如在系统测试阶段,就会做系统测试计划和系统测试的详细规格说明书;到下一阶段系统集成测试阶段的时候,再 做系统集成测试计划和系统集成测试的详细规格说明书;并不是一次把所有阶段的测试计划做完,再去做所有测试阶段的详细规格说明书。这只是理论,实际项目会 有变化和取舍。

  在测试准备中涉及到的“测试的详细规格说明书”中,应该包含测试用例设计结果和测试环境等说明。通常情况下测试用例都是在单独的文档中。

  测试评估和计划

  要做的事情有:

  1、评估目前的环境

  2、定义测试策略

  3、定义静态测试计划

  4、开发主要的测试计划:单元测试计划,集成测试计划,系统测试计划,系统集成测试计划,用户验收测试计划,可操作性测试计划,完成动态测试计划。

  5、完成动态测试计划

  输出的有:

  ◆ 测试过程评估报告

  ◆ 测试策略

  ◆ 静态测试计划

  ◆ 主要的测试计划

  ◆ 每阶段的细节性的测试计划

  测试准备

  要做的事情有:

  1、设计如下详细的测试计划:设计单元测试的详细规格说明书,设计集成测试的详细规格说明书,设计系统测试的详细规格说明书,设计系统集成测试的详细规格说明书,设计用户验收测试的详细规格说明书,设计可操作性测试的详细规格说明书。

  2、准备建立测试环境

  3、部署软件测试相关的配置管理

  4、为测试做准备

  5、进行静态测试

  输出的有:

  ◆ 测试的详细规格说明书

  ◆ 测试环境

  ◆ 详细的测试计划

  ◆ 测试执行计划

  ◆ 静态的测试结果

  测试进行和报告

  要做的事情有:

  1、建立测试环境

  2、进行测试

    ● 执行测试用例

    ● 记录问题和缺陷

    ● 记录测试结果

  3、完成测试报告

    ● 分析测试结果

    ● 完成测试报告

  输出的有:

  ◆ 每个阶段或测试的测试结果

  ◆ 每个阶段或测试的测试报告


 

posted @ 2011-10-13 16:49 顺其自然EVO| 编辑 收藏

用例级别和缺陷等级

用例级别 (level)  
   Level1 基本:
  1、该类用例设计系统基本功能,1级用例的数量应受到控制,防止工作量过大。
  2、划分依据:该用例执行的失败会导致众多重要功能无法运行的,如:表单维护中的增加功能、最平常的业务使用等。可以认为是发生概率较高的并经常这样使用的一些功能用例。
  3、该级别的测试用例在每一轮版本测试中都必须执行

  Level2 重要:
  1、2级测试用例实际系统的重要功能。2级用例数量较多。
  2、划分依据:主要包括一些功能交互相关、各种应用场景、使用频率较高的正常功能测试用例
  3、在非回归的系统测试版本中基本上都需要进行验证,以保证系统所有的重要功能都能够正常实现。在测试过程中可以根据版本当前的具体情况进行安排进行测试。

  Level3 一般:
  1、3级测试用例设计系统的一般功能,3级用例数量也较多。
  2、划分依据:使用频率较低于2级用例。例如:数值或数组的编辑情况、特殊字符、字符串超长、与外部件交互消息失败、消息超时、事物完整性测试、可靠性测试等等。
  3、在非回归的系统测试版本中不一定都进行验证,而且在系统测试的中后期并不一定需要每个版本都进行测试

  Level4 生僻:如果没有可以不适用该级别
  1、该级别用例一般非常少。
  2、划分依据:该用例对应较生僻的预置条件和数据设置。虽然某些测试用例发现过较严重的错误,但是那些用例的处罚条件非常特殊,仍然应该被植入4级用例中。如界面规范化的测试也可归入4级用例。在实际使用中使用频率非常低、对用户可有可无的功能。
  3、在版本测试中有某些正常原因(包括:环境、人力、时间等)经过测试经理同意可以不进行测试。

  软件的缺陷等级应如何划分:

  A类——致命错误,包括以下各种错误:
  1.由于程序所引起的死机,非法退出
  2.死循环
  3.数据库发生死锁
  4.因错误操作导致的程序中断
  5.功能错误
  6.与数据库连接错误
  7.数据通讯错误

  B类——严重错误,包括以下各种错误:
  1.程序错误
  2.程序接口错误
  3.数据库的表、业务规则、缺省值未加完整性等约束条件

  C类——一般错误,包括以下各种错误:
  1.操作界面错误(包括数据窗口内列名定义、含义是否一致)
  2.打印内容、格式错误
  3.简单的输入限制未放在前台进行控制
  4.删除操作未给出提示
  5.数据库表中有过多的空字段

  D类——提示错误,包括以下各种错误:
  1.界面不规范
  2. 辅助说明描述不清楚
  3. 输入输出不规范
  4. 长操作未给用户提示
  5. 提示窗口文字未采用行业术语
  6. 可输入区域和只读区域没有明显的区分标志

posted @ 2011-10-13 13:35 顺其自然EVO| 编辑 收藏

测试用例与输入数据的设计方法

 测试用例的设计是测试设计的重要内容,关于测试用例的设计方法,当前不少出版的测试书和发表的测试文章,不少存在着表述错误,主要是把测试用例中的输入数据的设计方法与测试用例的设计方法混为一谈,对测试初学者和测试用例设计人员产生误导。

  这种错误的主要表现举例如下:

  测试用例的设计方法包括:

  ◆ 等价类划分法

  ◆ 边界值法

  ◆ 功能图与判定表法

  ◆ 错误推测法

  ◆ 用户场景法

  ◆ ......

  其实,测试用例中输入数据的设计方法只是测试用例设计方法的一个子集,上面列出的集中方法都是确定黑盒测试用例的输入测试数据的一般方法,而不是测试用例的设计方法。

  除了确定输入数据之外,测试用例的设计还包括如何确定测试用例的设计策略,如何组织设计用例,如何从测试需求等文档创建完整的测试用例。

  对测试执行人员来说,测试用例的表示内容包括以下几个方面:

  ◆ 测试用例的测试目标

  ◆ 测试用例的被测功能点描述

  ◆ 测试用例的测试运行环境

  ◆ 测试用例的执行方法(包括测试步骤,输入测试数据或测试脚本)

  ◆ 测试期望的结果

  ◆ 执行测试的实际结果

  ◆ 其他辅助说明

  乍看起来有点像测试策划(计划)考虑的因素。但是测试用例的设计和测试计划的设计关注点不同,测试计划考虑的宏观和全面些,而测试用例考虑的更窄。

  设计测试用例首先要考虑以下几个问题:

  ◆ 为什么要设计测试用例?

  ◆ 谁来写测试用例?这些写测试用例的人的测试技术和对被测试产品了得有多深入?

  ◆ 测试用例写给谁看,多少人将试用测试用到?

  ◆ 分配给写测试用例的时间是多长?要安排几个人来写?

  ◆ 怎么在测试用例的成本、质量和效率方面达到平衡?

   只有回答了这些问题,才能确定测试用例的具体写作方法和表现形式。一般而言,公司里分配写作测试用例的时间并不长,而且提供的文档也不全面,所以写测试 用例要符合测试部门的当前现状和项目的测试特点,综合考虑,所以看起来有点像测试计划的某些内容,但是对问题的细化程度不一样。

  测试用例的设计是一项复杂的测试工作测试用例的设计方法需要考虑测试的目标,被测试软件的特性,测试者人力资源的技术和能力,测试组织形式,测试进度、测试成本等多个方面。

  在设计测试用例时,可以综合运用以下方法:

  ◆ 根据被测软件的功能和特性点设计测试用例:

    ● 根据被测试功能点设计测试用例

    ● 根据软件性能指标设计测试用例

    ● 根据软件的兼容性要求设计测试用例

    ● 根据软件的国际化用户要求设计国际化测试用例

    ● 根据...设计...用例

  ◆ 根据软件的组成元素设计测试用例

    ● 设计软件设计用例

    ● 设计联机帮助和文档手册的设计用例

    ● 设计软件的模版等数据文件的测试用例

  ◆ 根据软件的开发阶段(里程碑)设计测试用例

    ● 单元测试设计用例

    ● 集成测试设计用例

    ● 系统测试设计用例

    ● 验收测试设计用例

  ◆ 根据...设计测试用例

    ● ......

  具体到设计每个测试用例而言,可以考虑如下:

   ◆ 根据被测的最小目标,确定测试用例的测试目标

  ◆ 根据用户使用环境确定测试环境

  ◆ 根据以下因素确定测试用例的步骤

    ● 用户使用软件的步骤或者特定场景,确定测试执行步骤地具体内容

    ● 执行者对产品的熟悉程度确定步骤的详细或粗略程度

    ● 被测特性的复杂性也决定步骤的详细或粗略程度

    ● 测试用例的执行方法(手工测试或自动化测试)确定步骤地内容表示

    ● 自动测试用例要编写和调试测试脚本,手工测试给出执行步骤

    ● ......

  ◆ 根据设计规格说明书确定期望的测试用例执行结果

  ◆ ......

  确定测试用例的输入数据确实对于测试用例非常重要,它决定着测试用例的执行效果和效率,但是确定输入测试数据只是设计测试用例的一个步骤,而不是全部。因此,不能把测试用例的设计方法等同于测试用例数据的方法。


posted @ 2011-10-13 11:48 顺其自然EVO| 编辑 收藏

跟踪测试用例

测试过程计划确定后测试执行开始之前,测试组长应该能够回答下面的几个问题:

  ● 测试计划中需要执行哪些测试组件?

  ● 测试计划中有多少测试用例

  ● 在执行测试过程中,使用什么方法来记录测试用例的状态?

  ● 如何挑选出有效的测试组件和测试用例来着重测试某些模块?

  ● 上次使用的测试用例的通过率是多少?

  ● 在未通过的测试用例中,有多少是上次执行的时候也未通过的?

  准确地回答这些问题,需要对测试过程中测试用例进行跟踪。

   前面提到,测试过程中,测试用例有三种状态:通过、未通过和未测试。根据在测试执行过程中测试用例的状态,实现测试用例的跟踪,从而进行测试有效性的检 验。因此,测试用例的跟踪主要是针对测试过程中测试用例的执行和输出而进行的跟踪,从而达到测试过程的可管理性和进行测试有效性评估。

  跟踪测试用例包括两个方面的内容:

   ● 测试用例执行的跟踪:测试用例具有易组织性、可评估性和管理性,在测试用例执行过程中,实现测试用例执行过程的跟踪可以有效地将测试过程量化。例如,执行 一轮测试中,需要跟踪总共执行了多少测试用例,每个测试人员平均每天使用多少测试用例,测试用例中通过、未通过以及未使用的占多少,未使用的原因是什么, 当然,这是个相对的过程,测试人员工作量的跟踪不应该仅仅凭借测试用例的执行情况和发现的程序缺陷多少来判定,但至少,通过测试执行情况的跟踪可以大致判定当前的项目/软件和测试的质量与进度,并对测试的时间做出大致的推断。

  ● 测试用例覆盖率的跟踪:测试用例的覆盖率指的是根据测试用例进行测试的执行结果与实际的软件存在的问题的比较,从而实现对测试有效性的评估。

  跟踪测试用例的形式一般有几种:

  ● 记忆:顾名思义,凭借个人的记忆来跟踪测试用例,这是一种非常不可取的方法,除非是测试只是基于个人开发的小型软件上。

  ● 书面文档:在比较小规模的测试项目中,使用书面文档记录和跟踪测试用例也是可行的一种方法。测试用例清单的列表和图例也可以被有效地使用,但作为组织和搜索数据进行分析时,这种方法是很有局限的。

  ● 电子表格:一种流行而高效的方法是使用电子表格来跟踪和记录测试的过程。通过表格中列出的测试用例的跟踪细节,可以直观地看到测试的状态以及分析和统计测试用例的通过,与软件缺陷的关联等,这为测试中有效管理和分析测试过程以及软件的质量提供了有效的量化依据。

  ● 自定义数据库:最理想的方式是通过自定义的数据库来跟踪测试用例的执行和覆盖率,例如,测试人员通过特定的自定义程序如Web页面将测试的结果提交,通过自定义的数据库(Access、SQL Server、MySQLOracle等用户习惯的数据库系统)来存储这些测试结果,并通过自己编写的工具生成报表、分析图等,这样将更加有效地管理和跟踪整个的测试过程,当然,所花费的成本将也是最高的。

posted @ 2011-10-13 10:06 顺其自然EVO| 编辑 收藏

软件性能测试过程

  摘要:本文简单介绍软件的性能测试过程,将性能测试过程分为性能测试设计、性能测试执行、测试结果分析三个阶段,并介绍了每个阶段的主要工作内容和方法,配有简单的例子进行解释。

  关键字:性能测试 性能测试设计 测试场景 结果分析

   随着企业需求的日益增长以及计算技术的不断进步,企业级系统的应用已经从早期的单机时代转换到了服务成千上万个用户的因特网时代。随着企业业务量的增 加,企业的应用系统承载的负荷越来越重,对应用系统的要求越来越高。系统性能的好坏直接影响企业对外提供服务的质量,而性能测试在软件的质量保证中起着重 要的作用。

  本人结合自己的经验,从技术角度简单讨论一下软件性能测试的测试过程。软件性能测试过程分为三个阶段:

  ● 性能测试设计

  ● 性能测试执行

  ● 测试结果分析

  1.性能测试设计

  性能测试设计是性能测试过程中一个非常重要的环节,性能测试设计的好坏直接关系到测试的充分性和测试结果的有效性。

  性能测试设计阶段主要包括性能需求分析、测试场景制定等。

  1.1 性能需求分析

  性能需求分析主要包括测试目的和性能指标确定。

  进行性能需求分析,需要明确性能需求。性能需求可以从被测软件的相关文档中获得,也可以通过与用户沟通来获得。仔细阅读被测软件附带的相关文档,包括需求文档、使用文档、数据库设计文档等,提取有关软件性能相关的描述,例如“要求操作响应时间在……以内”、“要求……能够快速……”、“要求……能够支持……用户访问”、“要求……能快速稳定运行”、“要求系统连续……无故障运行”等,然后对提取的测试需求进行分析。

  (1)确定测试目的

  进行需求分析,首先要明确性能测试目的,测试目的不同直接影响后序的性能测试场景的制定。测试目的可以总结为三类:符合性验证、性能考察、性能调优。

  ● 符合性验证―主要验证软件是否满足规定的性能指标要求。如测试软件在某一条件下的平均响应时间,或者吞吐率,或者并发用户数等是否满足规定的要求。

  ● 性能考察―主要测试软件在某种条件下运行的性能状况。如测试软件所能支持的最大并发用户数或者最大数据量,软件在不同环境下的性能状况,随用户数量的变化或者数据量的变化情况下软件的性能变化状况等。

  ● 性能调优―主要是通过性能测试找出软件的性能瓶颈,分析出引起软件性能缺陷的原因,并进行针对性的性能优化,以改进软件性能。如对软件进行性能测试,确定是软件否存在性能方面的问题,并定位性能瓶颈,对其进行性能优化。

  将测试需求与上述目的进行比较,确定出本次测试的测试目的。

  (2)确定性能指标

   此处确定的性能指标指的是性能需求中要求的,且通过性能测试直接得到的性能指标,主要包括响应时间、吞吐率、资源利用率、交易成功率等,是测试结果分析 和判断的依据。性能测试需要有明确的性能指标,某些软件系统具有明确的性能指标,而有的软件系统则需要和用户一起,通过对软件系统的业务特点、技术特点、 应用情况等进行综合分析来获得。

  如,一软件系统,要求1个小时内必须完成7 200笔业务。可以得出每秒需要完成的业务为7 200/3 600=2笔,则可以得出该系统需要关注的性能指标为服务器处理请求的能力,即吞吐率,值为2笔/秒。

  1.2 测试场景制定

  测试场景是指导测试执行的依据。测试场景主要是模拟软件系统一些实际的应用情况,包括测试时执行的业务、每种业务执行的用户数量、模拟的总用户 数、数据库数据量、用户增长方式、测试循环方式、用户退出方式、执行过程中的相关参数设定等,还包括测试中需要监视的性能计数器,主要是服务器端操作系统 相关的计数器、应用服务器相关的计数器、数据库相关的计数器等。不同的测试目的,其测试场景是不同的。

  ● 符合性验证主要是验证软件性能是否符合用户使用的要求,则测试中应模拟软件系统的实际使用情况。如,在各功能操作中加入适当的思考时间和迭代间隔时间,用 户增长方式采用逐渐加压方式等。软件实际使用时,主要是多用户执行多项功能操作,所以测试场景主要是多用户、多任务的并发测试。当软件系统有长时间连续运 行的情况时,还需要有疲劳测试的测试场景。

  ● 性能考察中对于测试软件性能极限的情况,如支持的最大用户数、最大的数据量等,测试场景应该尽可能的模拟极限情况。为了保证测试中对软件施加足够的压力, 用户增长方式采用同时加载,思考时间、迭代间隔时间都忽略等。测试软件性能极限,需要不断调整影响软件性能的要素,并分别进行并发测试。如,测试软件支持 的最大并发用户数,应不断调整并发用户数,在每组用户数下对系统进行并发测试。对于有长时间运行要求的软件系统,则需要进行疲劳测试。

  性能考察中检测软件在不同条件下的性能状况时(非性能极限),测试场景应该尽可能与实际使用情况相接近,与符合性验证类似。

  ● 性能调优主要是为了软件实际应用中的性能优化,则测试中应模拟软件系统实际应用中的多用户、多任务的并发测试场景,与符合性验证类似。为了验证软件系统是否存在内存泄漏等问题,还需要对其进行疲劳测试。

  2.性能测试执行

  根据制定的测试场景,开始执行测试。测试执行不仅包括测试场景的执行,还包括测试场景执行前的一些准备工作,如,测试环境搭建、测试脚本准备、测试场景布置、测试场景执行等。

  2.1 测试环境搭建

  测试环境主要包括软件运行的软硬件环境和数据环境。

  首先,需要根据测试执行方案搭建测试环境。确保测试结果的有效性,要求搭建一个独立、无毒、逼真的软、硬件环境及网络环境,安装调试被测软件,安装测试工具等。

  其次,需要准备测试数据。以有利于测试为原则,可以自己准备,也可以从用户处获得满足要求的测试数据,或通过以上两种方式相结合获得。自己准备的数据要符合业务规范,同时避免增加垃圾数据。准备好测试数据后,应及时备份数据库。

  2.2 测试脚本准备

  根据测试执行方案中制定的测试功能,准备测试脚本。测试脚本可以通过测试工具来准备,也可以通过自己编写来完成。

  准备测试脚本前,首先确定测试功能运行无误,防止影响测试结果。测试脚本录制或编写完毕后,需要进行相应的编辑,如参数化、调试等,并需要验证测试脚本的有效性:

  (1)首先,进行单脚本单用户验证,验证每个测试脚本运行与实际功能操作是否相符。如增加功能的脚本,既要保证脚本可以成功运行,还要保证数据库中有相应的增加数据。

  (2)其次,进行单脚本多用户验证,验证每个测试脚本的数据池是否有效。

  (3)最后,进行多脚本多用户验证,验证测试脚本是否可以并发运行。

  2.3 测试场景布置

  根据制定的测试场景布置各测试场景,包括测试脚本及其对应的虚拟用户数、对应的运行参数、用户增长方式、测试循环方式、用户退出方式、需要监视的性能计数器等。

  2.4 测试场景执行

  测试场景布置完毕后,开始执行测试场景。测试中,测试人员要监视测试运行情况,如有过多错误,应及时停止方案的运行,查找错误原因。若是因为外 界原因(如网络不稳定等)或者运行参数设置问题,则需要进行相应的调整再运行方案。如果不是外界原因和运行参数设置问题,则保存测试结果,以便进行结果分 析,找出问题原因。执行所有的测试场景,及时汇总测试结果,为下一步结果分析做准备。

  为了保证方案运行的有效性,在执行测试前,要将数据库恢复到脚本准备前的原始状态。在运行中,所有相关设备不要进行与测试无关的操作,以避免影响测试结果。

  3.测试结果分析

  测试结果分析是性能测试中的一个重要部分,同时也是一个难点。不同的软件系统,不同的性能指标,结果分析方法都是不一样的。下面给出一个简单的结果分析方法。

  首先,查看运行结果中是否有错误出现,可以结合运行日志信息来查找。若有错误信息,则需要进一步分析,根据错误信息查找原因。如,测试结果中出现超时错误,可能的原因有:

  a. 硬件有瓶颈,如CPU、内存等;

  b. 程序算法有问题;

  c. 应用服务的相关参数设置有问题;

  d. 程序中处理有关表的时候检查字段太多。

  接下来,对这几个可能的原因进一步分析,以确定出具体的原因。

  若运行结果没有出现错误,则根据关注的性能指标进行分析。首先对网络进行分析,排除网络问题,对服务器硬件(CPU、内存、磁盘I/O)进行相 关分析,确定是否是硬件瓶颈引起的性能问题,然后对应用服务器配置进行分析,确认是否是由于应用服务器本身的配置引起的性能问题,然后对数据库进行性能分 析,重点是索引、数据库Cache、死锁等问题的分析,排除上述因素后,再对程序代码进行分析,找出导致性能问题的因素。

  测试结果分析是一项复杂而又重要的部分,涉及的内容比较多,需要根据实际测试情况来进行分析。


posted @ 2011-10-12 17:59 顺其自然EVO| 编辑 收藏

测试过程控制----如何开展性能测试

  性能测试的提前准备关注点:

  1、性能测试的环境配置需要能够尽可能的模拟版本的现场使用,包括外网的设备,软件网元,各种硬件平台,操作系统,软件平台;

  2、性能测试需要准备合适的模拟脚本来尽可能全真的模拟客户可能的操作,比如同时并行网页操作,同时进行socket连接等。而且要超出客户的真实可能情况。

  性能测试需要出两类数据:

  1、基准测试对比数据:比较本版本和前一版本的性能指标的情况。用以发现本版本的功能合入是否影响了基准的性能。基准测试的情况下,本版本的新增功能和特性默认都是不打开的,保持和前一版本一致。

  2、单个功能的性能对比数据:验证本版本中,新增的功能和特性打开的时候,此功能对于版本的性能的影响。

  性能测试的关注点:

  1、资源的占用情况:查看资源的使用情况。资源包括CPU,内存,硬盘等。

  2、资源的释放情况:查询系统在业务处理停止后是否可以正常的释放资源,以供后续业务使用。按道理业务停止,资源应该及时释放。常见问题,内存泄露,资源吊死,导致系统不能正常释放资源,严重情况导致宕机。可以用很多工具来检测资源情况。

  3、异常测试:性能测试的情况在一定的话务(一般是模拟现场的用户)的情况下,进行硬件倒换,双机倒换,业务切换等。包括破坏性的输入接入来验证系统在高负荷情况下的容错性。

  4、查询告警等信息:一般系统都会在出问题的时候,进行通知和告警,这些信息是暴露问题的最好手段,性能测试需要及时查看。

  5、长时间运行:性能测试是模拟设备长时间的运行,这个是很好的检查版本在外场测试的手段。可以检查出很多跟时间,定时器等相关的积累效应的故障。

  6、日志检查:性能测试需要经常的分析系统的日志,包括操作系统,数据库,软件版本等日志。

  7、查看业务响应时间:长时间的测试后,查看业务响应的时候是否在客户可以接受的范围。比如网页的响应时间,终端登录时长等。

  性能测试的人员要求:

  1、性能测试的人员必须是骨干,不能使用新人进行性能测试。

  2、性能测试的人员必须对全系统非常熟悉,对于问题定位手段使用熟练。能够牵头带领开发人员进行性能相关的问题排查。

  性能测试报告:

  1、性能测试报告要体现基准性能数据,单个功能的性能数据。用于评估版本是否可以在原有的硬件环境下保持同样的处理能力。

  2、性能测试报告需要满足各个测试利益相关者的要求。所以性能测试进行前需要获得测试利益相关者的要求,做成明细表,然后再开始性能测试。

  性能测试的工具要求:

  1、性能测试必须有一定的工具准备,包括LR等 。很多产品的性能测试需要自研性能测试工具,工具的最高境界是可以全真的模拟客户的操作。 特别说明,LR仅仅是一种工具,而性能测试是一套理论和方法。

  2、性能测试工具使用过程中,需要搀和手工操作。比如模拟客户购物的网购动作。工具和手工需要有效结合。用以弥补工具的某些不可预知的不足。

  性能测试是全系统的测试的关键点,需要从测试设计,测试执行,人员安排方面都万分重视。

posted @ 2011-10-12 15:34 顺其自然EVO| 编辑 收藏

关于性能测试模型的探讨

  关于性能测试模型的探讨如下:

  随着单位时间流量的不断增长,被测系统的压力不断增大,服务器资源会不断被消耗,TPS值会因为这些因素而发生变化,而且符合通常情况下的规律。以下是一个性能测试压力变化模型图:

TPS 每秒的吞吐量

  说明:

  a点:性能期望值

  b点:高于期望,系统资源处于临界点

  c点:高于期望,性能处于拐点

  d点:超过负载,资源不够用,系统处于崩溃

  通过如上模型图中的情况,我们大致可以将当前性能测试分成如下4类:

  1、性能测试

  2、负载测试

  3、压力测试

  4、稳定性测试

  》性能测试

  以上模型图为准则,在a点与b点之间的系统性能,表示以性能目标预期为前提,对系统进行施压,验证系统在资源可用范围内,是否能达到性能预期的目标。

  》负载测试

  b点的系统性能,表示在系统在一定的压力下持续一段时间,直到系统的某项或多项指标达到极限,比如系统资源CPU、Memory或者IO等达到饱和状态。

  》压力测试

  b点到d点的系统性能,表示在超过安全负载的条件下,不断对系统进行加压,直到系统不能再接受请求,并可以确定一个系统瓶颈的情况下,目的是为了找出系统的瓶颈,需要对系统进行调优。

  》稳定性测试

  a点到b点的系统性能,表示被测试系统在特定硬件、软件、网络环境条件下,给系统加载一定业务压力,使系统运行一段较长时间,以此检测系统是否稳定,一般稳定性测试时间为n*12小时

posted @ 2011-10-12 15:25 顺其自然EVO| 编辑 收藏

如何证明你的性能测试结果可信?

经常和一些同行在网上交流,了解到现在很多公司都在做性能测试,甚至有的在公司都没有成熟的性能测试人员情况下,就拉个稍微了解点性能测试工具的人员,跑个脚本就做起了性能测试。这时候都不约而同的抛出了一个问题,我们的性能测试结论是可信的吗?结合自己的性能测试经验,针对性能测试结论的可信度,谈谈个人的一点看法。

   确定测试结果可信度,指的是性能测试结果是否稳定可靠。也就是说,测试得到的各种指标数据是不是反映了系统真实性能的情况。例如,如果同一套脚本在对同 一测试对象(即被测对象本身没有变化,例如同一页面)进行的数次测试中,一般情况下页面响应时间指标忽高忽低的话,则说明该测试缺乏信度则得到的响应时 间并不能反映系统在真实生产环境的响应时间。测试的信度与测试的效度有着密切的关系。一般说来,只有信度较高的测试才能有较高的效度,效度较高的性能指标 才有较高的实际性能分析价值和对改进性能方案进行决策时的参考价值。测试的信度主要涉及到测试工具自身的可靠性和测试环境稳定性以及测试方案成熟性这三个 方面。

  第一,测试工具自身的可靠性。

  测试工具的可靠性,主要是指测试工具本身是否有Bug,性能计数器是否准确等和性能测试工具针对当前性能测试项目的场景进行的设置是否合理。

  解决办法:

   针对性能测试工具本身功能方面,要对要使用的性能工具进行评估,商业工具和开源工具以及自己开发的工具,甚至是一些简单插件,一些小的 Application等。虽然他们的性能测试原理都是相同的。但是还是要根据项目情况和工具情况进行整体评估,特别是一些特别项目,并不是一定商业工具 就更稳定可靠,但是相对而言,商业工具功能较为丰富,简单易学习,稳定性也可以。结合成本和项目情况可以选择自己开发工具,也可以定制工具,也可以对一些工具进行部分改进,例如自己做个更加精确的计数器。

   针对工具设置方面,结合项目情况选择最合理的设置,也许run脚本时候的很多问题,就是由于设置产生的。这部分需要对使用的工具很熟悉,清楚一些常用属 性的设置场景。例如一些基本的设置:Agent和Controller的设置,scenario设置,counter sets,run setting。

  第二,测试环境稳定性。

  测试环境的稳定性对性能测试结果的重要性,相信已经都深有感触。每个项目做性能测试方案时候都要梳理一遍可能影响request的开关,过期时间等设置。

  解决办法:

  首先要尽可能建立一个独立的性能测试环境,即使一些大型程序,例如大型的电子商务网站,数据库过于庞大,难以建立独立的性能测试数据库环境,也要对性能测试数据进行一些标识,建立环境时候,要确保web server上的版本和windows server版本相对应,即时根据测试方案要求更新测试版本。要对一些用的cache server、Application server,搜索引擎等server集群进行合理设置。以使其符合项目性能测试的要求。

  第三,测试方案成熟性。

  测试方案是对一个性能测试从始至终的所有工作的指导。性能测试相当于做一个精密的实验,方案的精密严谨性就直接会导致得到的性能测试指标准确性,合理性。

  解决办法:

   首先要熟悉该次性能测试的目的,和测试需求。深入分析需求,提取出一些关键点,熟悉涉及到相关部分的业务,特别是涉及到request的,是Html请 求,还是Ajax请求,请求中是否包含动态数据,例如一些cookie参数等。根据以上了解,提取出性能测试场景。给出详细的测试场景执行方案,以及测试 指标名称。给出性能指标分析策略。取数据的策略(例如重测法,交替形式法,对半法等)。

  测试执行过程中要时刻保持精密的思想,确保性能测试从始至终都要有据可依,有理论可考。最终才能得出具有很高参考价值的性能指标数据,这样才能得出有效的性能测试结论。

版权声明:本文出自 582357212 的51Testing软件测试博客:http://www.51testing.com/?305564

posted @ 2011-10-12 15:07 顺其自然EVO| 编辑 收藏

功能测试报告的编写(版本测试报告与总结测试报告的应用)

  测试报告是 测试人员在测试过程中用于反映测试状况的文档,其重要性通过网上哀求、跪求、旋转360度冰天雪地各种求测试报告模块的帖子中就可见一斑。其实测试报告的 内容基本都是模板的那些,只是在实际测试过程中,如何去整理内容结构,使得报告的通常阅读者:开发人员、测试经理、产品经理、项目负责人能够一目了然地查 看想要了解的内容才是测试报告最值得注意的地方。

  产品要想有广阔的市场,得需要切实了解用户的需求及感受,同理测试报告要想能够让阅读 者能够满意,也需要能将质量情况条理性地列出。通常来说,开发人员往往希望能从报告中了解缺陷的情况,而测试经理还关心用例的执行情况及覆盖率、项目责任 人则最关心还有多少问题,此次版本是否测试通过。因此测试报告根据内容的侧重点,分为『版本测试报告』和『总结测试报告』,目的也是希望不将所有内容列举 在一个报告中,造成内容臃肿繁杂。

  〖版本测试报告〗

  ● 主要反映开发人员提交的测试版本的质量状况。

  ● 测试用例设计与执行、缺陷概况及问题概要是版本测试报告中的主要内容。

  ● 测试人员在每个轮次测试结束时编写提交。

  其内容结构如下:

  对版本测试报告的每个章节的编写内容进行说明:

大纲

子章节

详细内容

测试简介

测试目的

本次测试的背景及主要内容

测试资源

测试人员、本次测试开始和截止日期、花费工作

测试环境

硬件环境

实际情况的详细列举,过低的配置、件版本的不匹配、网络拓扑的错误都会让提交的缺陷缺乏说服力,也会让开发人员对于某些缺陷是否由于环境因素导致而产生疑惑。

软件版本

网络拓扑图

测试方法

本次测试的功能点、各功能点对应的测试用例设计、测试用到的测试工具

测试用例

用例分析

测试用例维护记录

用例执行情况

用例执行总数、通过用例数、未通过用例数、阻塞用例数

测试执行率=(已执行的用例数)/用例总数

测试用例效率=发现的缺陷总数/测试用例的数量

测试过程

缺陷统计

新建bug数、修复bug数、未修复bug数、bug总数

问题摘要

遗留问题、拒绝问题、挂起问题、长期验证问题、待评估问题

测试结果

资源占用

测试项目的启动、退出时间

测试项目的CPU占用率初始值、峰值(如果项目启动会有多个进程,则分多个进程进行统计)

测试项目的内存占用初始值、峰值

测试结论

测试结论不论仅仅只是测试通过或不通过,应该使用详细的数据来支持测试结论,需要列举的数据有:

『测试用例通过率』

总用例

未通过用例

未通过比率

 

 

 

『遗留bug情况』

bug

未修复bug

遗留bug

 

 

 

备注

用例执行记录

插入测试用例的详细执行结果文档

资源监控记录

说明资源占用监控的场景,详细列举各场景的监控时长、监控内容,场景操作

  〖总结测试报告〗

  ● 主要偏重于各已测试版本的缺陷变化分析,风险预估。

  ● 各测试版本质量情况概况统计、缺陷分布统计、风险分析是总结测试报告中的主要内容。

  ● 测试人员在项目发布上线前编写提交。

  其内容结构如下:

  对总结测试报告的每个章节的编写内容进行说明:

标题

子章节

详细内容

测试简介

测试目的

本次测试的背景及主要内容

测试资源

测试人员、第一轮测试的开始日期和最后一轮测试的截止日期、总共花费工作日统计

测试环境

硬件环境

实际情况的详细列举,过低的配置、件版本的不匹配、网络拓扑的错误都会让提交的缺陷缺乏说服力,也会让开发人员对于某些缺陷是否由于环境因素导致而产生疑惑。

软件版本

网络拓扑图

测试过程

各版本测试状况

各测试版本的计划提交日期、实际提交日期、测试类型(回归或全量)、测试耗时、备注(被打回或提交补丁次数)

各版本bug统计

各测试版本的新建bug、修复bug、遗留bug数,表格统计、线形图或饼状图辅助表示

测试分析

缺陷分析

缺陷的总体分布情况,以线形图或饼状图辅助表示

根据功能模块进行划分

根据严重、较严重、普通、轻微级别进行划分

遗留问题

打开状态bug、长期验证bug、用户体验问题

测试小结

资源占用

测试项目的启动、退出时间

测试项目的CPU占用率初始值、峰值(如果项目启动会有多个进程,则分多个进程进行统计)

测试项目的内存占用初始值、峰值

风险分析

测试进度、人员安排导致的风险

测试内容考虑范围之外导致的风险

测试环境不全面导致的风险

其他因素导致的风险

  以上是对功能测试报告编写的总结,性能测试报告、兼容性测试报告因为内容的不同是不能套用以上测试报告的结构进行编写,功能测试报告的编写就是要做到简约而不简单。

posted @ 2011-10-12 14:46 顺其自然EVO| 编辑 收藏

仅列出标题
共394页: First 上一页 383 384 385 386 387 388 389 390 391 下一页 Last 
<2025年4月>
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜