(一)缺陷报告

一、测试工程师的主要工作职责

1、理解、熟悉《需求文档》

2、阅读和编写《测试计划

说明:一般由测试负责人编写测试计划。普通测试工程师主要是阅读、理解清楚项目的测试计划。

3、编写《测试用例》指导测试工作

4、执行测试用例,发现缺陷--编写《缺陷报告

5、跟踪管理缺陷

6、编写《测试总结报告

    测试总结报告实际是由客观的测试数据组成,例如:缺陷总数,解决的缺陷数,未解决的缺陷数等。

二、缺陷报告

1、定义

  缺陷报告定义:发现缺陷后用缺陷报告记录缺陷→通过缺陷报告将缺陷告知给开发人员,以使开发方解决缺陷。缺陷报告是测试人员和开发人员之间沟通的重要工具。

2、缺陷报告的主要组成

  说明:不同公司可能使用不同的测试管理工具(如QC,禅道等),所以缺陷报告的组成部分不完全一致。缺陷报告的主要组成部分

1)缺陷编号

   记录发现缺陷的顺序号。在测试管理工具中,缺陷编号都是自动生成的。缺陷编号的生成是以项目为单位的(记录的是整个项目所有缺陷的统一编号)。

2)缺陷标题/描述

   说明:简明扼要的描述该缺陷。

3)缺陷发现者

   发现该缺陷的测试人员,一般就是测试人员自己(测试工具会自动填写当前登录的测试人员账号)。

4)指派给谁

    测试人员将缺陷指派给开发方的负责人,开发方负责人再根据产生缺陷的功能模块去找到对应的开发人员(程序员)。

5)缺陷提交的日期

   说明:发现缺陷要及时的提交缺陷。通常会将系统时间自动填写。

6)发现缺陷的版本

    版本不一定指的是最终版本,有可能是开发过程中的临时版本。

  回归测试在新版本中对上一个测过的内容再次测试

     为了提高回归测试的效率,现在的趋势是用自动化测试替代手工做回归测试。

7)缺陷所属功能模块

说明:在哪个功能模块中发现的该缺陷。

8)缺陷的状态【重点】

  描述缺陷此时所处的状态。

例如:

  新提交的缺陷——new

  打开的缺陷——open

  被拒绝的缺陷——rejected

  已经被修改完的缺陷——fixed

  重新打开的缺陷——reopen

  关闭的缺陷——closed

 

9)缺陷的严重程度(severity

    指明该缺陷对软件造成的影响程度有多大。

   例如:

 造成死机或影响开发、测试进度的问题——Urgent

   非常严重的功能问题——Very High

   大的功能问题——High

   中等程度的功能问题——Medium

   小的功能问题——Low

   注意:每个单词代表的具体含义每个公司可能不一样,应该在测试计划或是在专门的文档中定义好,以便测试人员和开发人员达成一致。

10)缺陷的优先级(Priority

     希望该缺陷在什么时间内或者哪个版本程序员可以解决。

例如:

  Urgent——立即修复

  Very High——本版本修复

  High——下一个版本修复

  Medium——发布之前修复

  Low——允许在发布产品中存在

  注意:同样,每个单词代表的具体含义每个公司可能不一样,应该在测试计划或是在专门的文档中定义好。

11)缺陷的描述

    把发现这个缺陷的具体步骤记录下来,以使开发人员通过你的描述可以看到这个缺陷,以便他去解决这个缺陷。

 要求:描述清晰、准确、易读,使开发人员容易读懂,并可以重现缺陷——重点、难点

说明

1、缺陷的严重程度和优先级是不是成正比例关系?

例如:

  界面问题的严重程度一般比较低,但优先级可能最高——立即修复。

  某些重大的功能问题可能暂时解决不了,但不影响其他功能的使用,这时优先级可能定义的比较低——发布之前修复。

2、缺陷的严重程度和优先级确定好以后,还会改吗?

    例如:

    测试人员确定一个缺陷为“立即修复”,但开发组认为这个缺陷不太好解决,而这个缺陷又不影响其他功能,这时可能要求在”下一个版本修改”或“发布之前修改”。

3、是不是所有已发现的缺陷都会被修复?

     有些缺陷修复的成本太高,或者由于进度压力可能在发布之前得不到修复,这样的缺陷一定要经过项目组的讨论,权衡成本和风险,要确保不会对用户造成重大的影响及法律纠纷。后面再通过升级软件或打补丁的方式修复缺陷或弥补缺陷。

3、缺陷报告的用途

  1. 记录软件缺陷
  2. 对缺陷进行分类
  3. 跟踪软件缺陷
  4. 用于缺陷的分析、总结

三、软件缺陷的识别

  1. 通过用例中的预期结果进行识别
  2. 通过需求规格说明书进行识别
  3. 通过和开发人员、需求人员、用户沟通进行识别

写缺陷报告时注意的问题

  1. 一个报告只提交一个缺陷
  2. 缺陷描述清晰、准确、易读,使用最少、必须的步骤保证缺陷可以再现
  3. 对缺陷的严重性、优先级的划分准确、客观
  4. 在缺陷报告提交之前一定要认真审核,确保提交的缺陷是有效的,而不是因为自己的疏忽或操作不正确造成的 “假缺陷”
  5. 不要为了引起开发人员的重视而夸大缺陷
  6. 小的缺陷也要报告
  7. 及时报告缺陷
  8. 对于不可重现的缺陷也要报告
  9. 不做任何评价

猜你喜欢

转载自www.cnblogs.com/vivih-y/p/11434499.html