规范测试流程

规范测试流程

需求分析：

　　需求分析由产品人员制定，他们要作的不是一份简单的文档，而是细化每个功能的细节，每个按钮的位置，对于稍大或复杂一点的需求都进行建模。

需求评审：

　　需求评审（产品需求人员、开发人员、测试人员、设计人员）前期需求进入会大大增长测试人员对产品的功能的总体把握，如今测试人员担任的是测试和产品体验员的身份。测试人员提出需求，开发人员考虑功能实现的方案与可行性、固然开发负责也是要参与的。测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例。QA人员是最终对软件质量进行验证的人，因此也需求了解需求

开发人员编写排期：

　　开发人员需求根据需求功能点进行排期。而后将开计划转交给测试人员。

测试计划排期：

测试人员根据开发计划，对测试具体测试时间，也就是开发功能完成后的时间，进行几轮测试等。而后，把项目的开发与测试计划发送给各部门负责人及参与项目的全部人员。

编写测试用例：

     根据详细的需求分档，开始进行用例的编写。

   【开发人员写开发计划--》测试人员编写测试计划--》邮件通知全部人员及部门负责人。】

用例评审：

      在用例进行评审之间，先以邮件形式将用例发送给相关人员，以便他们事先了解用例对哪些功能进行验证以及验证的细节。

而后，测试人员组进行用例评审，开发人员对用例与实际功能不符合有哪些，产品人员对会经过用例对功能的具体实现进行把握等等。

【测试用例评审（产品需求人员、开发人员、测试人员、QA人员）】

提交基线：

      开发人员完成全部功能后，会对本身的功能进行一个自测。自测完成后提交测试人员进行基线。【开发代码及自测---》编写测试用例】

具体测试流程：

      开发人员对于基到测试线的功能进行测式，发现的问题经过缺陷管理工具进行反馈，开发人员对问题进行修复，而后，准备第二轮测试。

测试人员完成第一轮测试后，须要写测试结论，发到相关人员。而后对基线后的第二轮进行测试，第二轮会对第一轮中发现的问题进行重点回归。

缺陷管理：

     使用bug缺陷管理工具，redmine项目管理，经过测试对发现的问题提交到redmine上并进行跟踪。视状况能够将比较简单的bug直接对接开发人员，经过当面交流的方式阐明简单bug的问题所在，提升开发人员修复bug的效率，同时要在redmine上作好bug记录，发布测试新的版本的时候复测问题。

测试经过：

　　通过两到三轮或四轮的测试后，直到没发现新的问题，或暂时没法解决，或不紧急的问题。经过上级确认，能够经过。编写测试报告与验收方案。

　　验收方案是交由QA进行验证的。在现公司的流程中是将测试与QA分开的，测试人员重点关注的是功能是否能够正常运行。QA关注的是整个流程的质量以及最终用户的质量。有些公司QA与测试是不区分的，但这对测试的要求会更高，除了关心功能，还须要关心总体流程与质量。

 上线后测试：

    产品上线后须要再次测试产品的功能性，确保发布线上的环境配置正确，产品功能流畅。这是咱们一个面向大众用户的网站，给于测试人员的定位是测试员兼用户体验员，测试员将发现的bug和体验问题提交到缺陷管理系统，由经理对问题进行分析，指派开发人员解决。按期对系统进行更新。（测试人员以用户的角度出发体验功能完整性和功能流畅度以及功能的体验，为产品的长期发展起到一个促进的做用！）

 

 

敏捷测试流程

　　

　　

　　前面讲的第一种流程，仍是第二种流程都是瀑布式的，严格来讲第一种简陋的都不能称为瀑布式，对于一个三个月的项目说，产品把需求分析完了给开发，而后产品就没事儿了；开发开发完成以后给测试，而后开发人员也不忙了。测试完成以后上线。那么在产品分析的阶段，开发和测试都是没事干的（这里只对单一项目）。开发阶段，产品和测试也基本没事儿。一样在测试阶段，产品与开发也是没什么事儿的。

　　敏捷测试的一个核心是迭代，在每一个时间点上，全部项目人员都是有事可作的。

一、下面是我理解中的敏捷测试流程图：

第一阶段：

　　经过上面的流程图，对于一个月的需求分析，在敏捷中，可能三五天就肯定下来。这个需求定得会很模糊，但总体框架肯定。产品对其中某一模块功能确认，开发人员开始对确认的功能编码，开发人员编码的过程当中，测试进行功能分解，由于根据模糊的需求很难写出具体的用例，因此，只能尽可能对功能进行分析得细些，标注须要验证的内容。

第二阶段：

　　开发完成后交给测试人员进行测试，开发人员继续开发新的功能。那么测试人员发现的问题怎么办呢？会从开发团队中抽出一我的员来用于解决测试发现的问题。但开发进度并无由于测试而中止。

 

流程分析：

　　在这个流程中弱化了文档，强调了各我的员的沟通，经过这种迭代的方式，三个月的项目，能够能两个月和两个半月就会完成。

二、对测试问题的处理

上面的图更能清晰看出对问题的处理过程。

　　第一块面板中是开发人员未实现的功能，第二块面板中是开发完成功能，测试人员对其进行测试，发现不经过的就放回未开发的面板中，测试经过的将放到第三块面板中。

      须要说明的是，敏捷测试在国外很流程，在国内，雷声大雨点小，推行的人不少，真正有公司引入的很少。咱们所在公司千差万别，测试流程也可能有很大的不一样。