有关缺陷的生命周期描述

发布: 2016-01-01 14:13 作者: webmaster 来源: 本站原创 [浏览次数:5 ]

简述一下缺陷的生命周期

·软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。

简单的软件缺陷生命周期:

1、发现——打开:测试人员找到软件缺陷并将软件缺陷提交给开发人员;

2、打开——修复:开发人员再现、修复缺陷,然后提交测试人员去验证;

3、修复——关闭:测试人员验证修复过的软件,关闭已不存在的缺陷。

但是这是一种理想的状态,在实际的工作中是很难有这样的顺利的,需要考虑的各种情况都还是非常多的。

复杂的软件缺陷生命周期:

1、新建一个软件缺陷,这个软件缺陷是(open)状态,进行bug审查,不是代码问题,就是设计需要修改;

2、新建一个软件缺陷,这个软件缺陷是(open)状态,进行bug审查,以后修改的,就可以延期;

3、新建一个软件缺陷,这个软件缺陷是(open)状态,进行bug审查,实际没有这个bug,可以将其关闭;

4、新建一个软件缺陷,这个软件缺陷是(open)状态,看是否清楚可重现,如果不能重现,就是缺少信息,需要返回到(open)状态;如果能够重现,就进行修正,修正后关闭,进行回归测试。

13.测试分析测试用例注意(事项)?

1.为什么要写用例:

我们编写测试用例,有如下的好处:

便于团队交流:假如说一个测试团队有10个成员,大家测试的时候都各自为政,没有统一的标准,测试的效率无疑会大打折扣;如果大家都遵循统一的用例规范去写,就会解决这一问题。

便于重复测试 :大家知道,软件在实际开发过程中是会有不同版本的,比如会从1.0升级到10.0,那么如果不写测试用例的话,在测试10.0版本的时候,你能完全记得1.0版本时你做过哪些测试吗?测试用例就像一个备忘录一样,便于重复测试。

便于跟踪统计:这一点是针对测试经理或是项目经理来说的,项目负责人通过看测试用例的执行情况,就能了解到项目目前的概况,比如已经执行了哪些测试,还有哪些测试没有执行,测试没有通过的地方主要集中在哪些模块等。

便于用户自测:尤其是项目软件,有的时候用户希望自己测试一下软件产品,但是用户大都

是非专业人士,他需要根据你写好的用例来更好的检验产品的质量

说了这么多编写测试用例的优点,那它有没有缺点呢?有一个明显的缺点就是需要花费大量的时间,通常编写测试用例的时间比实际执行测试的时间还要长,这一点大家会在实际工作中有深刻的体会

2.什么时候写用例:

什么时候写用例?这个问题没有统一的标准答案,但有一点可以肯定,就是测试用例要尽早编写。大家认为在哪个阶段开始写用例比较好呢?

通常,我们都会在测试设计阶段来写用例,即《需求规格说明书》和《测试计划》都已完成之后

3.由谁来写测试用例

有的读者会说,当然是测试人员来写用例了!

可是测试人员又会有不同的角色,一般分为测试经理,测试设计人员,测试执行人员和测试工具开发人员等,一般测试用例是由测试设计人员来编写,由测试执行人员来执行,这就要求测试设计人员有一定的用例设计经验,并对被测试的系统有深入的了解。

但是在很多小公司里面,区分的不是这么明显,一个测试人员往往会身兼数职,既是测试组长,又是测试设计人员,又是测试执行人员。项目组里就你一个测试工程师,你不写用例谁写啊!

4.根据什么写测试用例

我们编写测试用例的唯一标准就是用户需求,具体的参考资料就是《系统需求规格说明书》和软件原型,其中软件原型指的是没有嵌入全部源代码的软件界面,比如我做一个电子商务网站,为了尽快能给用户演示,我只是用html语言作一些静态页面,并没有编写动态的程序,这就是一个软件原型,它也看作是需求的一部分。




文章“有关缺陷的生命周期描述”由 软件测试 整理发布
转载请注明 http://www.testtimes.net/html/52/n-5952.html

Tag: 软件 修复

 

评分:0

我来说两句:


培训  课程
师资  联系我们

1694083235@QQ.Com

北京市通州区弘祥文化园A座