软件测试工作职责：一份专业的软件缺陷bug报告该怎么写？（正确范式）

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

【1】缺陷ID

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

【2】概要描述

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

【3】发现人

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

【4】发现时间

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

【5】修复时间

当缺陷修复时，开发工程师可记录该时间，统计缺陷的生命周期，以验证缺陷跟踪处理

周期是否在合理的时间范围内。该字段一般由缺陷管理工具自动记录。

【6】所属版本

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

【7】所属模块

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

【8】缺陷状态

缺陷状态是标识缺陷当前所在状态。以惠普（HP）公司研发的测试管理工具 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：缺陷产生的后果不严重，仅仅是导致用户感觉使用不方便，或者系统展示不人性化等。

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

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

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

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

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

【10】 修复优先级

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

【11】 下步处理人

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

【12】 详细描述

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

【13】附件

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

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

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

（1）准确（Correct)：每个组成部分描述需准确，不会引起误解。

（2）清晰(Clear)：每个组成部分描述需清晰，易于理解。

（3）简洁（Concise )：只包含必不可少的信息，不包括任何多余的内容。

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

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

最后： 如果你平时有很多问题想要解决，你的测试职业规划也需要一点光亮，你也想跟着大家一起分享探讨，我给你推荐一个 「软件测试学习交流群：746506216」 你缺的知识这里有，你少的技能这里有，你要的大牛也在这里……

---

资源分享

下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】