软件缺陷报告
3.发现人 缺陷的发现人，由谁发现对应的缺陷。缺陷发现人不一定是测试工程师，可能是开发工程师、 维护人员，甚至是客户。 4. 发现时间 缺陷发现时间，记录该时间便于后续的缺陷跟踪，该字段一般由缺陷管理工具自动记录。 5. 修复时间 当缺陷修复时，开发工程师可记录该时间，统计缺陷的生命周期，以验证缺陷跟踪处理周期 是否在合理的时间范围内。该字段一般由缺陷管理工具自动记录。
（6）Reject：Reject状态一般由开发工程师使用，当缺陷指派给开发工程师进行确认修复时， 开发工程师需确认缺陷，如因需求、设计、功能、业务理解错误而误提缺陷或缺陷无法重现 时，开发工程师一般将其置为Reject状态，返回至缺陷发现人进行确认处理。
一般而言，缺陷从New开始，结束于Close状态。
问题答疑渠道
汇智动力软件测试技术交流群
汇智动力学院微信公众号
软件缺陷报告
软件缺陷报告
测试活动实施过程中，测试工程师发现缺陷后，需根据企业所定义的缺陷报告格式进行缺陷 登记。不同企业因缺陷流程及管理思路不同，可能有不同的缺陷报告形式，但基本都包含以 下一些常见关键字段。
1. 缺陷ID 缺陷ID用来唯一标识缺陷，在缺陷管理中，缺陷ID不可重复，即使缺陷被删除，ID也不可复 用。缺陷ID一般用阿拉伯数字标识即可，如1、2、3等。 2. 概要描述 简要描述缺陷的存在形式及表象，通过概要描述，开发工程师能快速理解缺陷产生的现象， 推测可能的缺陷诱因，从而提高缺陷处理的效率。例如，商品查询功能查出的商品标题信息 显示为乱码。
（2）Medium：中级的缺陷，一般为错别字、字体错误、显示错误、子功能实现错误、冗余等。 例如，需求规格说明定义用户输入错误时，系统提示“您输入的信息有误，请重试”，在实 际实现时系统提示“对不起，输入错误”，此种缺陷一般可定义为Medium级别。
（3）High：当缺陷因遗漏、冗余、错误等原因引起，导致当前功能无法正常使用时，即可定 义为High级别，如查询功能未实现，默认降序功能实现成升序功能。
软件缺陷报告
6. 所属版本 发现缺陷时，缺陷所在的版本，记录该字段便于后期统计不同版本的缺陷数量及确定测试版 本的发布风险。执行确认与回归测试时，需在缺陷所在版本的下一个衍生版本上进行，即缺 陷在1.0版本上发现，确认与回归测试活动则不可能开展在1.0版本，一般在1.0后的版本上进 行。 7. 所属模块 缺陷所在的功能或业务模块，便于后期统计每个功能或业务模块的缺陷分布情况，从而利于 回归投入确定或研发精力分配。
8. 缺陷状态
标识缺陷当前所在状态，以惠普（HP）公司研发的测试管理工具Application Lifecycle Management（简称ALM）为例，一般分为“New（新建）”、“Open（打开）”、“Fix（修 复）”、“Close（关闭）”、“Reopen（重新打开）”、“Reject（拒绝）”这6个状态， 不同的管理流程可能会有其他的状态，如“Postpone（延期）”、“Duplicate（重复）”等。
不同公司缺陷严重度的定义不同，但大体相同，现有的若干缺陷管理工具默认提供了类似上 述的缺陷严重度定义。
10. 修复优先级 该字段由研发团队确定，根据缺陷的严重度，决定缺陷修复的先后次序，原则上修复优先级 与缺陷严重度相同。严重度级别越高的缺陷，修复优先级也越高。 11. 下步处理人 下步处理人是当前缺陷下一责任人。当缺陷提出后，根据缺陷跟踪管理流程，需经过若干环 节流转，直至该缺陷成功修复。 12. 详细描述 详细描述当前缺陷引发的原因，包括输入、环境、步骤、现象等若干便于描述该缺陷的信息。 13. 附件 当缺陷表述需额外附件的证据信息时，可提交相对应的数据信息，如截图、系统运行日志等。 一般缺陷管理工具都有添加附件功能。
（1）New：缺陷未正式进入缺陷管理流程流转时，都可定义为New（新建）状态，一般ห้องสมุดไป่ตู้发现、 新提交的缺陷为New。
（2）Open：缺陷经过发现人自检确认为缺陷后，即可进入缺陷管理流程流转，此时缺陷需指 派给下一个处理人，其状态一般标识为Open。
（3）Fix：当开发工程师确认缺陷成立并进行成功修复后，需将缺陷状态标识为Fix，表示该 缺陷已被成功修复，缺陷校验人员可在后续版本中校验。
（4）Very High：当前缺陷引起了子功能无法正常使用，或产生了不可逆转的错误时，即可 定义为Very High，如查询功能错误导致编辑功能失效、编辑后信息丢失。
（5）Urgent：缺陷引发了大面积功能错误、业务中断、流程错误，甚至系统崩溃，产生初始 化错误或终止性故障时，即为Urgent级别。产生此种级别的缺陷时，测试活动可根据实际情 况暂停，版本退回，需开发部门立即修复，重新发起系统测试申请。
（4）Close：测试工程师对标识为Fix的缺陷开展确认测试活动，当该缺陷经过校验确认被成 功修复后，该缺陷状态标识为Close。一般的缺陷跟踪活动至此结束。
（5）Reopen：在确认测试过程中，当标识为Fix的缺陷仍然存在或未能彻底修复好时，缺陷 校验人员需将该缺陷置为Reopen，表明缺陷仍然存在，仍需经过缺陷跟踪流程处理。
示例
缺陷ID
1
概要描述 订单查询功能查询结果日期降序排列显示功能未实现
发现人
李四
下步处理人 张三
发现时间 2014-4-3 10:43:21 修复时间 2014-4-4 18:12:32
所属版本 OMS1.0
所属模块 订单查询
缺陷状态 Open
缺陷严重度 High
修复优先级
详细描述
订单查询功能处，选择起止日期后，查询结果未能以日期降序形 式显示
注意事项
测试工程师编写缺陷报告时，需遵循以下几个原则。 （1）Correct（准确）：每个组成部分描述需准确，不会引起误解。 （2）Clear（清晰）：每个组成部分描述需清晰，易于理解。 （3）Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容。 （4）Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息。 （5）Consistent（一致）：按照一致的格式编写全部缺陷报告
9. 缺陷严重度
缺陷严重度是指缺陷引发不良影响的严重程度，针对缺陷而言，根据其引发后果的风险大小， 确定其严重度级别，级别越高，越需尽快尽早处理。
缺陷严重度一般分为Low、Medium、High、Very High、Urgent这5个级别。
（1）Low：缺陷产生的后果不严重，仅仅是导致用户感觉使用不方便，或者系统展示不够人 性化等。例如，系统使用4号宋体显示可能更便于信息浏览。易用性方面的缺陷一般可定义为 Low级别。当然，设计繁琐、使用困难的缺陷级别可能会比较高。