缺陷报告：

项目：

测试策略 方法

用例

时间

测试环境 系统配置

测试人员 提交BUG 数量 ，等级，BUG的走势

每天的BUG数据

BUG 的状态 多少打开，多少关闭各种状态

系统还存在的问题。和以后可能有的问题

软件缺陷的状态有哪些

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”

软件测试中，测试报告和缺陷报告区别在哪？有模板吗？

　　软件测试报告是一个全面性的报告，而缺陷报告只是软件测试报告中有关缺陷部分的报告。

　　软件测试是软件开发过程中的一个重要组成部分，是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程。而测试报告就是把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。

　　测试报告应包括：引言（测试目的、测试背景、参与人员、参考文献等）、测试实施概要（测试的环境、测试用例、范围等）、测试结果以及缺陷分析、测试结论等。

软件缺陷分类的标准

软件缺陷(software defect)分类标准缺陷属性属性名称 描述 缺陷标识(Identifier) 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识 缺陷类型 (Type) 缺陷类型是根据缺陷的自然属性划分的缺陷种类。 缺陷严重程度 (Severity) 缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。 缺陷优先级(Priority) 缺陷的优先级指缺陷必须被修复的紧急程度。 缺陷状态(Status) 缺陷状态指缺陷通过一个跟踪修复过程的进展情况。 缺陷起源(Origin) 缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。 缺陷来源(Source) 缺陷来源指引起缺陷的起因。 缺陷根源(Root Cause) 缺陷根源指发生错误的根本因素。缺陷类型（Type）缺陷类型编号 缺陷类型 描述 10 F- Function 影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷。 20 A- Assignment 需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。 30 I- Interface 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。 40 C- Checking 提示的错误信息，不适当的数据验证等缺陷。 50 B Build/package/merge 由于配置库、变更管理或版本控制引起的错误。 60 D- Documentation 影响发布和维护，包括注释。 70 G- Algorithm 算法错误。 80 U-User Interface 人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。 90 P-Performance 不满足系统可测量的属性值，如：执行时间，事务处理速率等。 100 N-Norms 不符合各种标准的要求，如编码标准、设计符号等。缺陷严重程度（Severity）1.3.1 软件测试错误严重程度 # 缺陷严重等级 描述 1 Critical 不能执行正常工作功能或重要功能。或者危及人身安全。 2 Major 严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法） 3 Minor 严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法） 4 Cosmetic 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。 5 Other 其它错误。1.3.2 同行评审错误严重程度 # 缺陷严重等级 描述 Major 主要的，较大的缺陷 Minor 次要的，小的缺陷缺陷优先级（Priority）# 缺陷优先级 描述 1 Resolve Immediately 缺陷必须被立即解决。 2 Normal Queue 缺陷需要正常排队等待修复或列入软件发布清单。 3 Not Urgent 缺陷可以在方便时被纠正。缺陷状态（Status）缺陷状态 描述 Submitted 已提交的缺陷 Open 确认“提交的缺陷”，等待处理 Rejected 拒绝“提交的缺陷”，不需要修复或不是缺陷 Resolved 缺陷被修复 Closed 确认被修复的缺陷，将其关闭缺陷起源（Origin）缺陷起源 描述 Requirement 在需求阶段发现的缺陷 Architecture 在构架阶段发现的缺陷 Design 在设计阶段发现的缺陷 Code 在编码阶段发现的缺陷 Test 在测试阶段发现的缺陷缺陷来源（Source）缺陷来源 描述Requirement： 由于需求的问题引起的缺陷 Architecture： 由于构架的问题引起的缺陷Design： 由于设计的问题引起的缺陷 Code： 由于编码的问题引起的缺陷Test： 由于测试的问题引起的缺陷 Integration： 由于集成的问题引起的缺陷

参考资料：http://baike.baidu.com/view/107502.htm#2

一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

缺陷管理的作用在于，一是记录以便以后满足统计分析等需要，二是有助于重现问题以便定位及解决问题。从这个角度出发，缺陷报告自然是能够记录越多的细节越好，包括测试环境、软件版本、所用工具及版本号、测试用例的信息、出错前所执行的操作步骤、出错时相关信息和日志，等等很多。但是要真正做到捕获的都是有用的信息是非常困难的，因为我们只能从故障现象入手去记录相关信息，而问题的根源可能与之相隔甚远，来回折腾其实是非常耗时、耗资源的。最好的办法就是发现问题之后马上debug，开发测试在一块来解决问题，这是最经济实惠的办法。我个人非常喜欢敏捷软件开发的方式，开发测试在同一个团队里面。发现缺陷后可以即刻查看、定位、调试修复问题。而后在不得已的时候，例如短时间内无法解决此问题，再进行记录。

转载请注明出处51数据库 » 报告软件缺陷时有哪些要求 软件测试缺陷报告都要包括什么内容