测试活动实施过程中，测试工程师发现缺陷后，需要根据企业所定义的缺陷报告格式进行缺陷登记。不同企业因缺陷流程及管理思路不同，可能有不同的缺陷报告形式，但基本都包含以下一些常见关键字段:
NO.1缺陷ID
缺陷ID用来唯一标识缺陷，在缺陷管理中，缺陷ID不可重复，且即使缺陷被删除，ID也不可复用。缺陷ID一般用阿拉伯数字标识即可，如1、2、3等。
NO.2概要描述
简要描述缺陷的存在形式及表象，通过概要描述，开发工程师能快速理解缺陷立生的现象，推测可能的缺陷诱因，以而提高缺陷处理的效率。例如，商品查询功能查出的商品标题信息显示为乱码。
NO.3发现人
缺陷的发现人，由谁发现对应的缺陷。缺陷发现人不一定是测试工程师，可能是开发工程师、维护人员，甚至是客户。
NO.4发现时间
缺陷发现时间，记录该时间便于后续的缺陷跟踪，该字段一般由缺陷管理工具自动记录。
N0.5修复时间
当缺陷修复时，开发工程师可记录该时间，统计缺陷的生命周期，以验证缺陷跟踪处理周期是否在合理的时间范围内。该字段一般由缺陷管理工具自动记录。
NO.6所属版本
发现缺陷时，缺陷所在的版本，记录该字段便于后期统计不同版本的缺陷数量及确定测试版本的发布风险。执行确认与回归测试时，需在缺陷所在版本的下个行生版本上进行，即缺陷在1.0版本上发现，确认与回归测试活动则不可能开展在1.0版本，一般在1.0后的版本上进行。
NO.7所属模块
缺陷所在的功能或业务模块，便于后期统计每个功能或业务模块的缺陷分布情况，从而利于回归投入确定或研发精力分配。
NO.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 状态。
NO.9缺陷严重度
缺陷严重程度是指缺陷引发不良影响的严重程度，针对缺陷而言，根据其引发后果的风险大小，确定其严重度级别，级别越高，越需尽快、尽早处理缺陷严重度一般分为Low、 Medium、High、Very High、Urgent这5个级别
(1)Low:缺陷产生的后果不严重，仅仅是导致用户感觉使用不方便，或者系统展示不人性化等。
(2) Medium:中级的缺陷，一般为错别字、字体错误、显示错误、子功能实现错误、冗余等。例如，需求规格说明定义用户输入错误时，系统提示“您输入的信息有误，请重试”，在实际实现时系统提示 对不起，输入错误”此种缺陷一般可定义为Medium级别。
(3)High:当缺陷因遗漏、冗余、错误等原因引起，导致当前功能无法正常使用时，即可定义为High级别，如查询功能未实现，默认降序功能实现成升序功能。
(4)Very high：当前缺陷引起了子功能无法正常使用，后产生了不可逆转的错误时，即可定义为Veryhigh，如查询功能错误导致编辑功能失效、编辑后信息丢失。
(5)Urgent:缺陷引发了大面积功能错误、业务中断、流程错误，甚至系统崩溃，产生初始化错误或终止性故障时，即为 Urgent级别。产生此种级别的缺陷时，测试活动可根据实际情况暂停，版本退回，需开发部门立即修复，重新发起系统测试申请。
ips:不同公司缺陷严重度的定义不同，但大体相同，现有的若干缺陷管理工默认提供了类似上述的缺陷严重度定义。
NO.10修复优先级
该字段由研发团队确定，根据缺陷的严重度，决定缺陷修复的先后次序，原则上修复优先级与缺陷严重度相同。严重度级别越高的缺陷，修复优先级也越高
NO.11下步处理人
下步处理人是当前缺陷下一责任人。当缺陷提出后，根据缺陷跟踪管理流程需经过若干环节流转，直至该缺陷成功修复。
NO.12详细描述
详细描述当前缺陷引发的原因，包括输人、环境、步骤、现象等若干便于描述该缺陷的信息。
NO.13附件
当缺陷表达需额外附件的证据信息时，可提交相对应的数据信息，如截图、系统运行目志等。(一般缺陷管理工具都有添加附件功能)
从上面两款具有代表性的项目管理软件可以看出，大部分的缺陷包含字段类似。
注：测试工程师编写缺陷报告时，需遵循以下几个原则：
（1）准确（Correct）：每个组成部分描述需准确，不会引起误解。
（2）清晰（Clear）：每个组成部分描述需清晰，易于理解。
（3）简洁（Concise )：只包含必不可少的信息，不包括任何多余的内容。
（4）完整（Complete )：包含复现该缺陷的完整步骤和其他本质信息。
（5）一致（Consistent）：按照一致的格式编写全部缺陷报告。
需要相关文档的可以斯信我关键词”bug文档“或者看下面
免责声明：文章内容来自互联网，本站仅提供信息存储空间服务，真实性请自行鉴别，本站不承担任何责任，如有侵权等情况，请与本站联系删除。
转载请注明出处：一份专业的软件缺陷bug报告该怎么写？（正确范式） https://www.znbgj.com/archives/12564.html