怎么写缺陷报告，撰写缺陷报告注意事项有哪些

1，撰写缺陷报告注意事项有哪些

缺陷报告是测试与开发沟通的桥梁，它记录了软件测试过程中发现的缺陷并能跟踪该缺陷从创建到关闭的全过程。错误的缺陷报告会误导开发人员，影响开发人员工作效率，进而加深开发与测试的敌对关系；错误的缺陷报告会影响测试人员的声誉（尤其是测试自身业务不熟悉提出的缺陷）。那么怎么写好一个缺陷报告呢，我们应该注意以下3点：1.尽量确保缺陷可以重现（注意标记上测试环境信息，如操作系统、浏览器等信息）2.简介、准确、完整3.一个缺陷一个报告当初在传智播客培训时候就讲过这个知识点特别重要，后来教别人也都会着重说一下。

撰写缺陷报告注意事项有哪些

2，缺陷报告

概述：标识并描述发现的缺陷，具有清晰、完整和可重现问题所需的信息的文档。理解：测试人员发现缺陷，将缺陷记录在《缺陷报告》中，通过缺陷报告将缺陷告知给开发人员，并对缺陷进行跟踪和管理。缺陷报告是测试人员与开发人员之间重要的沟通方式。软件缺陷就是通常说的Bug，它是指在软件中（包括文档和程序）存在的影响软件正常运行的问题。软件未达到产品说明书标明的功能，如一个即时通讯App不能聊天。软件出现了产品说明书指明不会出现的错误，如高考不带身份证。软件功能超出产品说明书指明的范围，如即时通讯App做了一个地图功能。软件未达到产品说明书虽未指出但应该达到的目标，如一个账号的密码是明文。软件难以理解、不易使用、运行速度缓慢或者从测试人员的角度看最终用户认为不好，如一个即时通讯App无法找不到聊天界面。需求不明确和变更软件需求不清晰或者开发人员对需求理解偏差，导致软件设计时偏离用户的需求目标，造成软件功能或特征上的缺陷。此外，开发过程中客户频繁更新需求也会影响软件最终的质量。软件结构复杂编码问题项目期限短使用新技术八项：缺陷编号、缺陷状态、缺陷标题、重现步骤、严重程度、优先级、缺陷类型、测试环境。缺陷编号缺陷的唯一标识符缺陷状态缺陷跟踪过程的进展情况新建：刚发现的缺陷已指派：已经由测试人员将缺陷指派给开发人员进行处理已打开：开发人员正在修复缺陷已修复：开发人员完成缺陷修复，还未进行回归测试已拒绝：发开人员拒绝修复已延期：对缺陷进行延缓处理已关闭：由测试人员回归测试后，缺陷不存在了重新打开：由测试人员回归测试后，发现缺陷任然存在，缺陷标题缺陷的概述，描述问题本质重现步骤 ①一步一步描述再现缺陷的操作步骤 ②预期结果 ③实际结果严重程度缺陷对软件系统的影响程度优先级修复缺陷的重要性或紧迫性缺陷类型根据缺陷产生的来源和根源划分出的缺陷种类功能、配置、安装、性能缺陷测试环境测试环境配置，包括软件环境和硬件环境 1、对错误的描述要做到简洁、准确、完整，揭示错误实质 2、尽量使用短语和短句，避免复杂句型句式 3、每个软件问题报告只书写一个缺陷或错误 4、明确指明错误类型和严重程度 5、每一个步骤尽量只记录一个完整操作 6、复现的操作步骤要完整，准确，简短 7、可以附加必要的错误特征图像 8、可以附加必要的测试用例

缺陷报告

3，软件测试缺陷报告

测试人员发现缺陷——>记录缺陷，并将缺陷告知开发人员缺陷报告是测试人员和开发人员沟通的重要渠道 1、缺陷编号（defect id） 2、缺陷标题（summary） 3、缺陷的发现者（detected by） 4、发现缺陷的日期（detected on date） 5、发现缺陷的功能模块（subject） 6、指派给（assigned to） 7、发现缺陷的版本（detected in release）（1）说明：不仅指最后的发布版本，也指软件开发过程中出现的“临时版本” （2）回归测试：在新版本中对原来版本测试过的内容再重新测试一遍原因：1、新功能对原有功能可能有影响 2、缺陷修改后也有可能对原有功能产生影响为了提高回归测试的效率，很多企业使用自动化工具做回归测试 8、缺陷的状态（status）最常见的考试题** （1）说明：指明缺陷当前所需什么处理和缺陷当前处于什么处理状况（2）缺陷的处理过程：重点步骤1：测试人员将缺陷报告提交给开发经理，将缺陷报告状态设置成：New（新的缺陷）步骤2：开发经理验证缺陷：情况1：如果验证是缺陷，将缺陷指派给相应的开发人员，并将缺陷状态设置成open open：（打开的缺陷，被开发方承认的缺陷）情况2：如果验证不是缺陷，开发经理会拒绝此缺陷，将缺陷状态设置成：rejected。（一般要汇报给测试组长或测试经理，有时会邀请开发人员参加，开讨论会解决）步骤3：开发人员要修改缺陷，修改完成后，将缺陷状态设置成：fixed fixed:（修改过的缺陷，即待返测的缺陷）步骤4：测试人员返测开发人员更改过的缺陷情况1：返测通过，将缺陷状态设置成：closed closed:（关闭的缺陷，可归档）情况2：返测没通过，将缺陷状态设置成：reopen reopen:（重新打开的缺陷）开发人员继续修改缺陷直到缺陷被返测成功为止。 9、缺陷的严重程度（severity）【说明缺陷有多糟糕或者对软件的影响有多大】严重程度的级别：（1）urgent：造成死机，系统崩溃等致命问题（2）very high：非常严重的问题（3）high：严重的问题（4）medium：中等程度的问题（5）low：小问题发现问题：级别定义是泛泛的笼统的，容易引发争议，需要制定详细的标准注意：每个级别的含义，不同企业、不同项目组都可能不同，需要在专门的文档中定义好细则，在缺陷报告中作为参考。 10、缺陷的优先级（priority）希望程序员在什么时间内或者在程序的哪个版本中解决该缺陷（Bug）优先级的级别：（1）urgent：立即修改，否则会影响开发或测试的进度（2）very high：本版本中解决（3）high：下一版本中解决（4）medium：发布之前解决（5）low：尽量在发布之前解决注意：对于每个级别的具体定义，不同公司不一定完全相同，实际工作中要注意参考公司的文档。影响优先级的因素：（1）考虑缺陷的严重程度：一般是越严重，优先级别越高（也不是绝对的，有时严重级别低，但优先级高，例如：界面错字）（2）缺陷影响的范围：一般影响范围越大，优先级越高（3）开发组的任务压力：进度压力越小，优先级越高（4）解决缺陷的成本(时间)：成本越低，优先级越高（例如:改错字） 11、缺陷的描述（description）描述缺陷产生的操作过程，使程序员能重现缺陷。（缺陷报告不是必须要遵守什么写法和规则，只要程序员能看明白能重现缺陷就可以） 1、缺陷报告的用途（1）记录缺陷（2）跟踪管理缺陷（3）可以对缺陷进行分类，并很容易实现对缺陷的总结，统计 2、怎样识别缺陷？（1）参考测试用例的预期结果，如果实际执行结果与预期结果不一致就是缺陷（2）参考需求文档-----与需求不符就是bug （3）参考缺陷定义的五条（4）与开发人员、产品人员、客户沟通确定是否是缺陷 3、写缺陷报告的注意事项（1）一个报告只提交一个缺陷（2）缺陷描述清晰、准确、易读，使用最少、必须的步骤，保证缺陷可以再现（3）对缺陷的严重性、优先级的划分准确、客观（4）在提交缺陷报告之前一定要认真审核，确保提交的缺陷是有效的，而不是因为自己的疏忽或操作不正确早成的“假缺陷” （5）不要为了引起开发人员的重视而夸大缺陷（6）小的缺陷也要报告（7）及时报告缺陷（8）对于不可重现的缺陷也要报告（9）不做任何评价 1、什么是随机缺陷：不可重现的缺陷也叫随机缺陷，按照指定的步骤执行时有时无。随机缺陷在提交时要明确说明这是不可重现的随机缺陷。尽量提供关于此缺陷的信息，包括提供截图、错误消息、还有缺陷所在模块如果确定不了所在模块，可以建议采用白盒测试确定。 2、缺陷的严重程度和优先级是不是严格的正比关系？答：不一定严格成正比关系。例如：界面错别字，严重级别低，但优先级别高 3、缺陷的严重程度和优先级确定之后，还可以改吗？答：严重程度一般不改；优先级有时会改，一般是拖延处理 4、是不是所有已发现的缺陷，在发布时都会被修复？答：在软件发布之前，不是所有已经发现的缺陷都被修复了；对于不予修复的缺陷，要通过全组的缺陷讨论，权衡解决缺陷的成本和不解决的风险。后期一般通过打补丁或升级的方式解决。

软件测试缺陷报告