技术文章

软件测试——软件缺陷报告

测试活动实施过程中,测试工程师发现缺陷后,需根据企业所定义的缺陷报告格式进行缺陷登记。不同企业因缺陷流程及管理思路不同,可能有不同的缺陷报告形式,但基本都包含以下一些常见关键字段。

 

1. 缺陷ID

缺陷ID用来唯一标识缺陷,在缺陷管理中,缺陷ID不可重复,即使缺陷被删除,ID也不可复用。缺陷ID一般用阿拉伯数字标识即可,如1、2、3等。

 

2. 概要描述

简要描述缺陷的存在形式及表象,通过概要描述,开发人员能快速理解缺陷产生的现象,推测可能的缺陷诱因,从而提高缺陷处理的效率。例如,商品查询功能查出的商品标题信息显示为乱码。

 

3. 发现人

缺陷的发现人,由谁发现对应的缺陷。缺陷发现人不一定是测试工程师,可能是开发人员、维护人员,甚至是客户。

 

4. 发现时间

缺陷发现时间,记录该时间便于后续的缺陷跟踪,该字段一般由缺陷管理工具自动记录。

 

5. 修复时间

当缺陷修复时,开发人员可记录该时间,统计缺陷的生命周期,以验证缺陷跟踪处理周期是否在合理的时间范围内。该字段一般由缺陷管理工具自动记录。

 

6. 所属版本

发现缺陷时,缺陷所在的版本,记录该字段便于后期统计不同版本的缺陷数量及确定测试版本的发布风险。执行确认与回归测试时,需在缺陷所在版本的下一个衍生版本上进行,即缺陷在1.0版本上发现,确认与回归测试活动则不可能开展在1.0版本,一般在1.0后的版本上进行。

 

7. 所属模块

缺陷所在的功能或业务模块,便于后期统计每个功能或业务模块的缺陷分布情况,从而利于回归投入确定或研发精力分配。

 

8. 缺陷状态

标识缺陷当前所在状态,以惠普(HP)公司研发的测试管理工具Application Lifecycle Management(简称ALM)为例,一般分为“新建(New)”、“打开(Open)”、“修复(Fix)”、“关闭(Close)”、“重新打开(Reopen)”、“拒绝(Reject)”这6个状态,不同的管理流程可能会有其他的状态,如“延期(Postpone)”、“重复(Duplicate)”等。

 

(1)New:缺陷未正式进入缺陷管理流程流转时,都可定义为新建(New)状态,一般新发现、新提交的缺陷为New。

 

(2)Open:缺陷经过发现人自检确认为缺陷后,即可进入缺陷管理流程流转,此时缺陷需指派给下一个处理人,其状态一般标识为Open。

 

(3)Fix:当开发人员确认缺陷成立并进行成功修复后,需将缺陷状态标识为Fix,表示该缺陷已被成功修复,缺陷校验人员可在后续版本中校验。

 

(4)Close:测试工程师对标识为Fix的缺陷开展确认测试活动,当该缺陷经过校验确认被成功修复后,该缺陷状态标识为Close。一般的缺陷跟踪活动至此结束。

 

(5)Reopen:在确认测试过程中,当标识为Fix的缺陷仍然存在或未能彻底修复好时,缺陷校验人员需将该缺陷置为Reopen,表明缺陷仍然存在,仍需经过缺陷跟踪流程处理。

 

(6)Reject:Reject状态一般由开发人员使用,当缺陷指派给开发人员进行确认修复时,开发人员需确认缺陷,如因需求、设计、功能、业务理解错误而误提缺陷或缺陷无法重现时,开发人员一般将其置为Reject状态,返回至缺陷发现人进行确认处理。

 

一般而言,缺陷从New开始,结束于Close状态。

 

9. 缺陷严重度

缺陷严重度是指缺陷引发不良影响的严重程度,针对缺陷而言,根据其引发后果的风险大小,确定其严重度级别,级别越高,越需尽快尽早处理。

 

缺陷严重度一般分为Low、Medium、High、Very High、Urgent这5个级别。

 

(1)Low:缺陷产生的后果不严重,仅仅是导致用户感觉使用不方便,或者系统展示不够人性化等。例如,系统使用4号宋体显示可能更便于信息浏览。易用性方面的缺陷一般可定义为Low级别。当然,设计繁琐、使用困难的缺陷级别可能会比较高。

 

(2)Medium:中级的缺陷,一般为错别字、字体错误、显示错误、子功能实现错误、冗余等。例如,需求规格说明定义用户输入错误时,系统提示“您输入的信息有误,请重试”,在实际实现时系统提示“对不起,输入错误”,此种缺陷一般可定义为Medium级别。

 

(3)High:当缺陷因遗漏、冗余、错误等原因引起,导致当前功能无法正常使用时,即可定义为High级别,如查询功能未实现,默认降序功能实现成升序功能。

 

(4)Very High:当前缺陷引起了子功能无法正常使用,或产生了不可逆转的错误时,即可定义为Very High,如查询功能错误导致编辑功能失效、编辑后信息丢失。

 

(5)Urgent:缺陷引发了大面积功能错误、业务中断、流程错误,甚至系统崩溃,产生初始化错误或终止性故障时,即为Urgent级别。产生此种级别的缺陷时,测试活动可根据实际情况暂停,版本退回,需开发部门立即修复,重新发起系统测试申请。

 

不同公司缺陷严重度的定义不同,但大体相同,现有的若干缺陷管理工具默认提供了类似上述的缺陷严重度定义。

 

10. 修复优先级

该字段由研发团队确定,根据缺陷的严重度,决定缺陷修复的先后次序,原则上修复优先级与缺陷严重度相同。严重度级别越高的缺陷,修复优先级也越高。

 

11. 下步处理人

下步处理人是当前缺陷下一责任人。当缺陷提出后,根据缺陷跟踪管理流程,需经过若干环节流转,直至该缺陷成功修复。

 

12. 详细描述

详细描述当前缺陷引发的原因,包括输入、环境、步骤、现象等若干便于描述该缺陷的信息。

 

13. 附件

当缺陷表述需额外附件的证据信息时,可提交相对应的数据信息,如截图、系统运行日志等。一般缺陷管理工具都有添加附件功能。

 

缺陷报告示例如表5-1所示。

 

软件缺陷报告

 

测试管理工具ALM中新增缺陷报告示例如图5-3所示。

 

软件缺陷报告

 图5-3 ALM新增缺陷报告示例

 

国产开源项目管理软件禅道添加缺陷界面如图5-4所示。

 

软件缺陷报告

 图5-4禅道添加缺陷界面示意图

 

从上面两款具有代表性的项目管理软件可以看出,大部分的缺陷包含字段类似。

 

测试工程师编写缺陷报告时,需遵循以下几个原则。

 

(1)Correct(准确):每个组成部分描述需准确,不会引起误解。

(2)Clear(清晰):每个组成部分描述需清晰,易于理解。

(3)Concise(简洁):只包含必不可少的信息,不包括任何多余的内容。

(4)Complete(完整):包含复现该缺陷的完整步骤和其他本质信息。

(5)Consistent(一致):按照一致的格式编写全部缺陷报告。