前言
测试的工作的很重要的一个部分就是报告缺陷，并伴随着测试的进行不断地更新。因为缺陷报告是给开发，项目负责人，等相关人员看的，所以需要把尽可能的信息涵盖在缺陷报告中去，比如环境的详细信息，测试的重现步骤，等，帮助相关人员可以快速的重现描述的缺陷。
缺陷报告模板
下面会给大家介绍一下，常用的缺陷报告的模板，希望可以帮助大家写出一个好的缺陷报告。
缺陷ID：
按照项目约定的命名添加缺陷ID。缺陷管理工具会自动生成缺陷标识。通常会包括项目名称的简写，例如INVGEN-0001。
标题：
标题应该简短。它应该包含与实际问题相关的具体术语。写标题时要具体，尽量描述清楚需要阐述的缺陷。
例如：假设您在上载具有特定文件格式（即jpeg文件）的个人资料图片时，在注册页中发现了一个错误。那标题可以写“上载JPEG文件时系统崩溃”。不太好的例子是“系统崩溃”。
缺陷提交者：
发现缺陷的人的姓名（通常是测试人员的姓名，但有时可能是开发人员、业务分析师、主题专家（SME）、客户）。这样便于后期确认缺陷时，方便找到缺陷的提交者。
缺陷报告日期：
注明发现缺陷的日期。
发现者类型：
指定发现缺陷者的所属角色。例如：质量保证、开发人员、业务分析师、中小企业、客户。通常对于客户的问题，项目会比较重视。
项目名称：
有时，测试人员可能同时处理多个项目。因此，正确选择项目名称，会有助于快速定位出问题的项目。（如果是产品，请指定产品名称）。
发布版本：
发布/生成版本：发生此问题的发布版本。清楚地提到构建版本的详细信息。这样有助于开发迅速切换到对饮的版本进行重现和调试。
缺陷类型：
缺陷/增强：如果系统未按预期运行，则需要将其指定为缺陷。如果只是对新功能的请求，则必须将其指定为增强功能。
环境：
必须说明操作系统的详细信息、浏览器的详细信息以及与遇到错误的测试环境相关的任何其他信息。
例子:Window 10的Microsoft Edge 44.18362.387.0
优先等级：
优先等级定义修复错误的时间。通常，bug的优先级由管理者设置。根据优先级，开发人员可以了解修复的时间，并设置错误的解决顺序。通常分为高，中等，低。
严重等级：
严重等级是指错误对客户业务的影响。通常，错误的严重性由管理者设置。有时，测试人员会选择bug的严重性，但在大多数情况下，它将由经理/主管选择。
通常分为：阻滞，非常重要，重要的，一般的，不严重的。
状态：
指定错误的状态。如果你刚刚发现了一个bug并准备发布它，那么状态将是“new”。在bug修复过程中，bug的状态将改变。
例如，新的/分配的/打开的/已修复的/测试的/验证的/关闭的/重新打开的/重现的/延迟的/拒绝的/无法修复的/不可重现的/需要更多信息，等。
描述：
在“描述”部分中，必须简要说明在面对错误之前所做的工作。
重现步骤：
描述如何一步一步地重现缺陷。方便重现的步骤为开发人员提供了在不出现任何干扰项的情况下解决缺陷。这些步骤应该能够很好地描述缺陷，并允许开发人员理解缺陷并对其进行操作，而无需与报告缺陷的人进行讨论。可以从“打开应用程序”开始，如果有“先决条件”，则包括“先决条件”，并一直写到“导致错误”的步骤。
好的案例：
- 打开网址“你的网址”
- 点击“注册页面”
- 在个人资料照片栏上传“jpeg”文件
坏的案例：
- 在注册页上载文件。
预期结果：
当您执行导致失败的操作时，应用程序的预期输出是什么。
好的案例：消息应显示“成功上载个人资料图片”
不好的案例：系统应接受配置文件图片。
实际结果：
当您执行导致失败的操作时，应用程序的预期输出是什么。
好的案例：“在注册页面上传jpeg文件（个人资料图片）会导致系统崩溃”。
不好的案例：系统不接受配置文件图片。
附件：
附上当你面对错误时捕捉到的截图或者视频。它帮助开发人员看到您所面临的缺陷。
缺陷关闭日期：
“缺陷关闭日期”是在确保缺陷不可重现缺陷后需要更新的日期。
缺陷关闭版本：
“缺陷关闭版本”是在确保缺陷不可重现缺陷后需要更新的对应的应用程序的版本。
自动化脚本测试：
如果缺陷已经添加了相应的自动化案例，通常需要关联自动化对应的测试用例。
总结
好的缺陷报告会方便开发或者相关人员重现对应的缺陷，帮助我们快速定位缺陷并且解决缺陷，同时提高整个项目的开发效率。作为一个合格的测试人员，必须将编写测试报告作为一个需要锻炼的技能。
