开发者社区> 寒凝雪> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

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、完成测试报告

    ● 分析测试结果

    ● 完成测试报告

  输出的有:

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

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


本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
合作开发——设计阶段
            最近一直在做合作开发的图文档什么的,刚开始的时候是很纠结的,纠结的原因就是怕自己做不好,想的太多。回想下自己第一次做个人版画图的时候,也没有这么前思后想的,也许是因为这次深感责任重大的原因吧,总想着不能让我一个人的错误耽误大家的时间,所以设计的时候,尤其是在复用性上面,特别小心翼翼。
640 0
小型团队的测试该何去何从
小型团队的测试该何去何从
0 0
+关注
文章
问答
文章排行榜
最热
最新
相关电子书
更多
中小企业如何实现在家研发软件
立即下载
反思:移动平台应用软件行为管控机制
立即下载
团队和工程管理的取舍
立即下载