软件活动实施过程中，测试工程师发现缺陷后，需要根据企业所定义的缺陷报告格式进行缺陷登记。不同企业因缺陷流程及管理流程思路不同，可能有不同的缺陷报告形式，但基本都包含以下一些常见的关键字段。（建议大家利用禅道管理工具进行结合学习）
1、缺陷ID
缺陷ID用来唯一标识缺陷，在缺陷管理中，缺陷ID不可重复，即使缺陷被删除，也·不可·复用。缺陷ID一般用阿拉伯数字标识即可，如1、2、3等。
2、概要描述
简要描述缺陷的存在形式及表象，通过概要描述，开发人员能快速理解缺陷产生的的现象，推测可能产生的缺陷诱因，从而提高缺陷处理的
效率。列如，商品查询功能查出商品标签信息显示为乱码。
3、发现人
缺陷的发现人，由谁发现对应的缺陷。缺陷发现人不一定是软件测试工程师，可能是开发人员、维护人员，甚至是客户。
4、发现时间
缺陷发现时间，记录该时间便于缺陷跟踪，该字段一般由缺陷管理工具自动记录。
5、修复时间
当缺陷修复时，开发人员可记录该时间，统计缺陷的生命周期，以验证缺陷跟踪处理周期是否在合理的的时间范围内。该字段一般由管理缺陷工具自动记录。
6、所属版本
发现缺陷时，缺陷所属的版本，记录该字段以便后期统计不同版本的缺陷数量及确定测试版本的发布风险。执行确认测试与回归测试时，需在缺陷所在版本的下一个衍生版本上进行，即缺陷在1.0版本以上发现，确认与回归测试活动则不可能开展在1.0版本，一般在1.0后的版本上进行。
7、所属模块
缺陷所在的功能或业务模块，便于后期统计每一功能或业务模块的缺陷分布情况，从而利于回归投入确定或研发精力分配。
8、缺陷状态
bug提交到缺陷库中会自动的被设置成New状态 Assigned（已指派）： 当一个bug被认为New之后，将其分配开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned” Open（已打开）： 开发人员开始处理bug时，他将这个bug的状态设置为“Open”，表示开发人员正在处理这个“bug” Fixed（已修复）： 当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组Rejected(被拒绝)： 测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”Postponed（延期）： 有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed” Closed（已关闭）： 测试人员经过再次测试后确认bug已经被解决，将bug的状态设置为“Closed” 如经过再次测试发现bug仍然存在，测试人员将bug再次开发组，将bug的状态设置为“Reopen”。
9、缺陷严重程度
缺陷严重程度是指缺陷引起不良影响的严重程度，针对缺陷而言，根据其引发的后果的风险大小，确认其严重程度级别，级别越高，越需要尽早处理。缺陷可以概括为以下四种级别：
（1）微小的（Minor）。一些小问题如有个别错别字、文字排版不整齐等，对功能几乎没有影响，软件产品仍可使用。
（2）一般的（Major）。不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。
（3）严重的（Critical）。严重错误，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明。
（4）致命的（Fatal）。致命的错误，造成系统崩溃、死机，或造成数据丢失、主要功能完全丧失等。
10、修复的优先级
该字段由研发团队确定，根据缺陷的严重度，决定缺陷修复的先后顺序，原则上修复优先级与缺陷严重度相同。严重级别越高的缺陷，修复优先级也越高。
11、下一步处理人
下步处理人是当前缺陷下一责任人。当缺陷提出后，根据缺陷跟踪管理流程，需经过若干环节流转，直至该缺陷修复成功。
12、详细描述
详细描述当前缺陷引起的原因，包括输入、环境、步骤、现象等若干便于描述该缺陷的信息。
13、附件
当缺陷表述需要额外附件信息时，可提交相对应的数据信息，如截图、系统运行、日志等。一般管理工具都有添加附加功能。
本文来自投稿，不代表本人立场，如若转载，请注明出处：http://www.souzhinan.com/kj/264192.html