欢迎大家一起共同探讨软件测试发展!

测试工作基础流程概述

上一篇 / 下一篇  2011-07-21 14:21:16 / 个人分类:软件测试技术与方法

开发与测试工作平台划分:开发本地环境,开发集成环境,测试环境,实际环境。

开发本地环境:开发人员各自执行工作的环境;

开发集成环境:开发人员完成工作后将程序上传到此环境做最后确认。

测试环境:此环境为测试唯一环境。其软硬件条件及实际程序与当前实际产品一致,产品完成前以此环境的实现为最后结果。

实际环境:完成后并上线的实际产品。

 

1.项目立项:

 从项目立项之初就需要测试人的参与,在此过程中需要测试人员产品部门了解到此项目实施的目的和用户角度的要求,以通过这些材料为需求评审作为依据,以及规划测试工作的侧重点。

 

2.初步需求评审:

 经由产品部门首先提交概述需求说明书,由产品,开发,测试部门部分人员在一起,根据之前立项时所提出的要求对此进行初步需求评审。如符合要求,产品部门将继续进行详细需求编写,开发和测试部门以此为依据编写计划和策略。

 

3.测试计划及策略制定:

--确定测试人力资源,预估时间;

--软硬件资源需求及申请;

--需要配合的部门和人员;

--测试工作的内容和步骤;

--依据需求可能产生的风险等;

将此提交给项目负责人,然后与开发部门协调,将2部门的计划做到最大优化和整合,以提高效率。尤其在测试过程中有可能存在不能实现测试结果的问题,进行调整。其次将产品划分为多个模块,这样将保证单个模块的质量,再将关联模块进行集成,有利于保证产品质量。避免由于整体模块提交,其中部分存在问题影响其他功能,浪费测试资源。

 

4.详细需求评审:

 根据之前的要求查看内容是否完整,一致。功能实现正确。业务逻辑兼容性强,避免造成不同概念使用户理解和使用不一致。如有问题及时反馈给产品部门作出调整。建立反馈信息跟踪记录,催促信息反馈。因为有关细节问题或不能及时反馈的问题,经常出现口头答复的现象,需完全避免。由于需求说明书是开发和测试工作的最终依据,如果不能及时有效的给予书面记录,对以后的项目实施会产生不利影响。应做到产品,开发,测试信息及时,一致。执行定期例会,由产品,开发,测试人员对不一致问题进行调整,做到尽可能在需求评审阶段尽量将风险降到最低。个人负责需求评审完毕,组内互换,做到对产品功能和业务了解的完整性以及评审质量提高。

 

5.测试用例编写:

 经过1-2轮的需求评审后,需求说明书基本完整和稳定,然后开始进行测试用例的编写。在需求评审过程中,对可测试功能点,逻辑分析点作出标记及测试方法。如页面测试--注意显示方式,间距,字体,颜色等。数据测试-注意数据约束,极限值等。平级多选测试--正交排列法等。业务逻辑测试--注意进入途径,不同状态实现方式,结果唯一性,结果调用等。兼容性测试--适合系统,浏览器等。最后做到测试用例对需求说明书内容的完全覆盖性,实现过程和数量的最低性。个人负责用例完成后,在组内互换,提高测试用例质量。(白盒测试--逻辑覆盖,路径覆盖等。)

 

6.实际测试工作:

 开发部门提交单个模块,首先进行接收后的冒烟测试,如程序正常打开,需求中要求的主功能可以一般性使用,再按照测试用例进行详细测试。发现bug后详细描述问题及重现方式提交到缺陷管理平台与开发人员沟通。测试过程实现整体轮次,也就是一次提交,一次测试,如果开发修改完bug后,不马上提交,在下次版本时一同提交,避免在测试过程中对测试环境更改,影响测试结果。待下次提交后测试人员首先对bug进行反侧,之后对模块进行回归测试。当相关联模块之间全部完成提交,对其进行集成之后的数据交换测试。最后将全部模块整合进行系统测试。定期与开发部门举行例会,互相说明工作进度,以及存在的问题,相互协调。

 

7.bug评审:

 在项目后期,对现存bug进行评审,以需求为依据,判断bug的优先级和严重程度,如果时间不允许,对级别较高的bug进行优先修改。其他问题在不影响用户需求的情况下在以后版本再次修复。

 

8.产品评估/验收测试:

 提交测试报告,表述产品存在的风险。最后由各部门做最后的产品验收,评估。测试部门和产品部门对产品是否通过有决定权。

 

9.跟踪反馈:

 产品通过后,测试部门与市场,及客服部门建立联系,定期接受反馈,参与后期的维护和升级工作。

 

贯穿发起会议:

 在不定期由测试发起组织会议对相关部门说明目前进度和实际情况。使各部门了解当前项目情况,完善产品思路,进行调整。

 

 

 附:此流程为之前工作本人建立的基础制度,可以使整个项目有条理性,连贯性,形成链条,连续作业,避免一方紧急,一方闲置。将测试工作贯穿整个项目始终,能够体现测试工作的价值和作用,对成个项目的质量做得到可控性,进而提高客户满意度。也能够让公司各部门了解测试工作存在的必要性,以及避免对测试工作了解过于片面。

 此流程适合较大项目,对于小项目来说,在初步需求评审,计划策略制定方面,以及在详细需求评审和测试用例编写,以及实际测试工作中间的过程可以根据实际情况进行整合和穿插。


TAG:

激流勇进的个人空间 引用 删除 激流勇进   /   2014-05-13 11:29:59
3
 

评分:0

我来说两句

Open Toolbar