07 如何高效填写软件缺陷报告？
在上一篇文章中，我为你介绍了测试覆盖率的概念，并重点介绍了代码覆盖率的应用价值以及局限性。今天我会为你介绍如何才能写出一份高效的软件缺陷报告。
测试工程师需要利用对需求的理解、高效的执行力以及严密的逻辑推理能力，迅速找出软件中的潜在缺陷，并以缺陷报告的形式递交给开发团队，这看起来是不是有点像侦探柯南呢。
缺陷报告是测试工程师与开发工程师交流沟通的重要桥梁，也是测试工程师日常工作的重要输出。 作为优秀的测试工程师，最基本的一项技能就是，把发现的缺陷准确无歧义地表达清楚。
“准确无歧义地表达”意味着，开发工程师可以根据缺陷报告快速理解缺陷，并精确定位问题。同时，通过这个缺陷报告，开发经理可以准确预估缺陷修复的优先级、产品经理可以了解缺陷对用户或业务的影响以及严重性。
可见，缺陷报告本身的质量将直接关系到缺陷被修复的速度以及开发工程师的效率，同时还会影响测试工程师的信用、测试与开发人员协作的有效性。
那么，如何才能写出一份高效的缺陷报告呢？或者说，一份好的缺陷报告需要包括哪些具体内容呢？
你可能觉得这并不是什么难事儿，毕竟软件企业通常都有缺陷管理系统，比如典型的ALM（以前的Quality Center）、JIRA、Bugzilla、BugFree和Mantis等。当使用这类系统递交缺陷时，会自动生成模板，你只要按照其中的必填字段提供缺陷的详细信息就可以了。
很多时候，你不用想应该提供些什么信息，系统会引导你提供相关的信息。但是，你有仔细想过为什么要填写这些字段，这些字段都起什么作用，以及每个字段的内容具体应该怎么填写吗？
你必须牢牢记住的是，好的缺陷报告绝对不是大量信息的堆叠，而是以高效的方式提供准确有用的信息。
接下来，我就带你一起去看一份高效的缺陷报告主要由哪些部分组成，以及每部分内容的关键点是什么。
缺陷标题
缺陷标题通常是别人最先看到的部分，是对缺陷的概括性描述，通常采用“在什么情况下发生了什么问题”的模式。
首先，对“什么问题”的描述不仅要做到清晰简洁，最关键是要足够具体，切忌不能采用过于笼统的描述。描述“什么问题”的同时还必须清楚地表述发生问题时的上下文，也就是问题出现的场景。
“用户不能正常登录”“搜索功能有问题”和“用户信息页面的地址栏位置不正确”等，这样的描述会给人“说了等于没说”的感觉。这样的描述，很容易引发开发工程师的反感和抵触情绪，从而造成缺陷被拒绝修改（reject）。同时，还会造成缺陷管理上的困难以及过程的低效。
比如，当你发现了一个菜单栏上某个条目缺失的问题，在递交缺陷报告前，通常会去缺陷管理系统搜索一下是否已经有人递交过类似的缺陷。
当你以“菜单栏”为关键字搜索时，你可能会得到一堆“菜单栏有问题”的缺陷，如果缺陷标题的描述过于笼统，你就不得不点击进入每个已知缺陷点去看细节描述，这就会大大降低你的工作效率。
所以，如果缺陷标题本身就能概括性地描述具体问题，你就可以通过阅读标题判断类似的缺陷是否被提交过，大大提高测试工程师提交缺陷报告的效率。
其次，标题应该尽可能描述问题本质，而避免只停留在问题的表面。
比如，“商品金额输入框，可以输入英文字母和其他字符”这个描述就只描述了问题的表面现象，而采用诸如“商品金额输入框，没有对输入内容做校验”的方式，就可以透过标题看到缺陷的本质，这样可以帮助开发人员快速掌握问题的本质。
最后，缺陷标题不易过长，对缺陷更详细的描述应该放在“缺陷概述”里。
缺陷概述
缺陷概述通常会提供更多概括性的缺陷本质与现象的描述，是缺陷标题的细化。这部分内容通常是开发工程师打开缺陷报告后最先关注的内容，所以用清晰简短的语句将问题的本质描述清楚是关键。
缺陷概述还会包括缺陷的其他延展部分，比如你可以在这部分列出同一类型的缺陷可能出现的所有场景；再比如，你还可以描述同样的问题是否会在之前的版本中重现等。在这里，你应该尽量避免以缺陷重现步骤的形式来描述，而应该使用概括性的语句。
总之，缺陷概述的目的是，清晰简洁地描述缺陷，使开发工程师能够聚焦缺陷的本质。
缺陷影响
缺陷影响描述的是，缺陷引起的问题对用户或者对业务的影响范围以及严重程度。
缺陷影响决定了缺陷的优先级（Priority）和严重程度（Severity），开发经理会以此为依据来决定修复该缺陷的优先级；而产品经理会以此为依据来衡量缺陷的严重程度，并决定是否要等该缺陷被修复后才能发布产品。
测试工程师准确描述缺陷影响的前提是，必须对软件的应用场景以及需求有深入的理解，这也是对测试工程师业务基本功的考验。
环境配置
环境配置用以详细描述测试环境的配置细节，为缺陷的重现提供必要的环境信息。 比如，操作系统的类型与版本、被测软件版本、浏览器的种类和版本、被测软件的配置信息、集群的配置参数、中间件的版本信息等等。
需要注意的是，环境配置的内容通常是按需描述，也就是说通常只描述那些重现缺陷的环境敏感信息。
比如，“菜单栏上某个条目缺失的问题”只会发生在Chrome浏览器，而其他浏览器都没有类似问题。那么，Chrome浏览器就是环境敏感信息，必须予以描述，而至于Chrome浏览器是运行在什么操作系统上就无关紧要了，无需特意去描述了。
前置条件
前置条件是指测试步骤开始前系统应该处在的状态，其目的是减少缺陷重现步骤的描述。合理地使用前置条件可以在描述缺陷重现步骤时排除不必要的干扰，使其更有针对性。
比如，某个业务操作需要先完成用户登录，你在缺陷重现步骤里就没有必要描述登录操作的步骤细节，可以直接使用 “前置条件：用户已完成登录”的描述方式；
再比如，用户在执行登录操作前，需要事先在被测系统准备好待登录用户，你在描述时也无需增加“用测试数据生成工具生成用户”的步骤，可以直接使用 “前置条件：用户已完成注册”的描述方式。
缺陷重现步骤
缺陷重现步骤是整个缺陷报告中最核心的内容，其目的在于用简洁的语言向开发工程师展示缺陷重现的具体操作步骤。
这里需要注意的是，操作步骤通常是从用户角度出发来描述的，每个步骤都应该是可操作并且是连贯的，所以往往会采用步骤列表的表现形式。
通常测试工程师在写缺陷重现步骤前，需要反复执行这些步骤3次以上：一是，确保缺陷的可重现性；二是，找到最短的重现路径，过滤掉那些非必要的步骤，避免产生不必要的干扰。
对于缺陷重现步骤的描述应该尽量避免以下3个常见问题：
- 笼统的描述，缺乏可操作的具体步骤。
- 出现与缺陷重现不相关的步骤。
- 缺乏对测试数据的相关描述。
期望结果和实际结果
期望结果和实际结果通常和缺陷重现步骤绑定在一起，在描述重现步骤的过程中，需要明确说明期待结果和实际结果。期待结果来自于对需求的理解，而实际结果来自于测试执行的结果。
通常来讲，当你描述期望结果时，需要说明应该发生什么，而不是什么不应该发生；而描述实际结果时，你应该说明发生了什么，而不是什么没有发生。
优先级（Priority）和严重程度（Severity）
我之所以将优先级和严重程度放在一起，是因为这两个概念看起来有点类似，而本质却完全不同。而且，很多入行不久的测试工程师，也很难搞清楚这两者的差异到底在哪里。
根据百度百科的解释，缺陷优先级是指缺陷必须被修复的紧急程度，而缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
可见，严重程度是缺陷本身的属性，通常确定后就不再变化，而优先级是缺陷的工程属性，会随着项目进度、解决缺陷的成本等因素而变动。那么，缺陷的优先级和严重程度又有什么关系呢？
- 缺陷越严重，优先级就越高；
- 缺陷影响的范围越大，优先级也会越高；
- 有些缺陷虽然从用户影响角度来说不算严重，但是会妨碍测试或者是自动化测试的执行，这类缺陷属于典型的严重程度低，但是优先级高；
- 有些缺陷虽然严重程度比较高，但是考虑到修复成本以及技术难度，也会出现优先级较低的情况。
变通方案（Workaround）
变通方案是提供一种临时绕开当前缺陷而不影响产品功能的方式，通常由测试工程师或者开发工程师完成，或者他们一同决定。
变通方案的有无以及实施的难易程度，是决定缺陷优先级和严重程度的重要依据。如果某个严重的缺陷没有任何可行的变通方案，那么不管修复缺陷代价有多大，优先级一定会是最高的，但是如果该缺陷存在比较简单的变通方案，那么优先级就不一定会是最高的了。
根原因分析（Root Cause Analysis）
根原因分析就是我们平时常说的RCA，如果你能在发现缺陷的同时，定位出问题的根本原因，清楚地描述缺陷产生的原因并反馈给开发工程师，那么开发工程师修复缺陷的效率就会大幅提升，而且你的技术影响力也会被开发认可。
可以做好根原因分析的测试工程师，通常都具有开发背景，或者至少有较好的代码阅读以及代码调试的能力。
所以做为测试工程师，你很有必要去深入学习一门高级语言，这将帮助你体系化地建立起编程思想和方法，这样在之后的工作中，无论你是面对开发的代码，还是自动化测试代码和脚本都能做到得心应手，应对自如。
附件（Attachment）
附件通常是为缺陷的存在提供必要的证据支持，常见的附件有界面截图、测试用例日志、服务器端日志、GUI测试的执行视频等。
对于那些很难用文字描述清楚的GUI界面布局的缺陷，你可以采用截图并高亮显示应该关注的区域的方式去提交缺陷报告。
总结
缺陷报告是测试工程师与开发工程师交流沟通的重要桥梁，也是测试工程师日常工作的重要输出。
一份高效的软件缺陷报告，应该包括缺陷标题、缺陷概述、缺陷影响、环境配置、前置条件、缺陷重现步骤、期望结果和实际结果、优先级和严重程度、变通方案、根原因分析，以及附件这几大部分。
缺陷报告的每一部分内容，都会因为目的、表现形式有各自的侧重点，所以想要写出一份高效的软件缺陷报告，需要对其组成有深入的理解。
思考题
关于高效填写软件缺陷报告，你还有哪些好的实践？
欢迎你给我留言。
- 王大华 👍（26） 💬（2）
老师，我打算把52 讲写一些公开的读后感，不知道会不会影响您
2018-07-15 - 西海 👍（16） 💬（1）
感觉老师讲的是how to report or create bugs，相比这个，我更想了解如何对一个阶段的bug进行统计、分析并报告
2018-07-16 - 小琼😁 👍（3） 💬（1）
直接使用Bug管理工具不是更方便吗？
2018-08-21 - 优速网络 👍（1） 💬（1）
缺陷发现版本和缺陷模块也很重要
2018-08-10 - 丹丹 👍（0） 💬（1）
我一般能截图的还会附上缺陷截图，这样更直观
2018-07-27 - 涅槃Ls 👍（0） 💬（1）
打卡07
2018-07-16 - Adele 👍（0） 💬（1）
非常有价值，决定要把“缺陷”的最佳案例作为CheckList放入我们的改进项中
2018-07-15 - 丹丹兒🍥 👍（95） 💬（7）
我公司的开发，很复杂的问题，我写了很详细的复线步骤，他不看，直接来叫我复线
2018-07-13 - Cynthia🌸 👍（47） 💬（3）
优先级和严重程度那块，如果还是觉得太绕的话，我觉得还可以借用时间管理里面提到的 重要 和 紧急 的概念来进行解释。优先级 对应着 事情的紧急程度， 严重程度 对应着 事情的重要程度。 这么来对应的话，理解了重要紧急，也就理解了优先级和严重程度了！
2018-07-13 - 双子 👍（36） 💬（3）
个人觉得实际测试过程中bug经办人一栏也是一个问题所在，准确定位一个bug是该分配给前端后端还是客户也是测试需要注意的问题。
2018-07-13 - 捷后愚生 👍（20） 💬（0）
面试题：你认为好的缺陷报告是怎样的？ 首先，讲好的缺陷报告的总体特征。 好的缺陷报告需要准确无歧义描述缺陷。 “准确无歧义地表达”意味着，开发工程师可以根据缺陷报告快速理解缺陷，并精确定位问题。开发经理可以准确预估缺陷修复的优先级、产品经理可以了解缺陷对用户或业务的影响以及严重性。 其次，讲缺陷报告每一组成部分的注意点。 缺陷标题 对缺陷的概括性描述，通常采用“在什么情况下发生了什么问题”的模式。 1.对“什么问题”的描述需要清晰简洁，足够具体，同时要交代清楚发生问题的上下文，也就是问题出现的场景。 反面例子：“用户不能正常登录”、“搜索功能有问题”和“用户信息页面的地址栏位置不正确” 正面例子：自己补充 2.标题尽可能描述问题本质 比如，“商品金额输入框，可以输入英文字母和其他字符”这个描述就只描述了问题的表面现象，而采用诸如“商品金额输入框，没有对输入内容做校验”的方式，就可以透过标题看到缺陷的本质，这样可以帮助开发人员快速掌握问题的本质。 3.标题不宜过长 测试环境 描述关键的测试环境，如在chrome中发现了bug，在IE上没有发现bug，那chrome就要要描述的，或者是不同版本的chrome，有的有bug，有的没有bug。 比如，操作系统的类型与版本、被测软件版本、浏览器的种类和版本、被测软件的配置信息、集群的配置参数、中间件的版本信息等等。 测试数据 保留测试数据，开发可以使用测试数据直接复现bug 操作步骤 按照1、2、3这样的描述，描述操作步骤，开发能够根据操作步骤进行bug复现 测试结果 实际结果来自于测试执行的结果 预期结果 当你描述期望结果时，需要说明应该发生什么，而不是什么不应该发生；而描述实际结果时，你应该说明发生了什么，而不是什么没有发生。 严重程度与优先等级 严重程度是缺陷本身的属性，通常确定后就不再变化，而优先级是缺陷的工程属性，会随着项目进度、解决缺陷的成本等因素而变动。 缺陷的优先级和严重程度的关系： 缺陷越严重，优先级就越高； 缺陷影响的范围越大，优先级也会越高； 有些缺陷虽然从用户影响角度来说不算严重，但是会妨碍测试或者是自动化测试的执行，这类缺陷属于典型的严重程度低，但是优先级高； 有些缺陷虽然严重程度比较高，但是考虑到修复成本以及技术难度，也会出现优先级较低的情况。 根本原因分析 如果你能在发现缺陷的同时，定位出问题的根本原因，清楚地描述缺陷产生的原因并反馈给开发工程师，那么开发工程师修复缺陷的效率就会大幅提升，而且你的技术影响力也会被开发认可。 这个要求很高，能做到的测试人员真的很厉害。 附件 附件通常是为缺陷的存在提供必要的证据支持，常见的附件有界面截图、测试用例日志、服务器端日志、GUI 测试的执行视频等。 对于那些很难用文字描述清楚的 GUI 界面布局的缺陷，你可以采用截图并高亮显示应该关注的区域的方式去提交缺陷报告。
2020-11-07 - 红娟 👍（19） 💬（0）
首先，我觉得老师的缺陷格式很棒 回答问题 我的实践心得，我是在一家外企，一个项目通常是多个国家合作，一个bug也是，通常会涉及到很多沟通对象。我在jira系统里能看到各式各样的bug。最简单的就一句话，然后后面就跟随者各种conments，看时间记录，跨度几天几个星期都是正常的。严重的都有以月为单位。这是我看到的问题。这都是沟通成本啊😊，所以我在我们组内部规定一个模板。都按照模板来，标题，版本信息，环境描述，复现步骤，期望结果，出现问题的结果。严重程度，是否容易复现。还有系统的一些必填信息。
2018-07-13 - 捷后愚生 👍（10） 💬（1）
还有一点很重要的，是要附上测试数据。
2018-07-13 - 🦀Kevin Xiao🇨🇳 👍（9） 💬（0）
是否应该还个缺陷类型呢？便于定期统计分析
2018-07-16 - 008 👍（9） 💬（3）
作为主管研发的产品经理，一直都被bug标题太笼统所困扰，每次检索和分配bug都会耗费大量精力和时间。而这虽说有制定一些规范，但毕竟每个人的语义表达能力不一，的确很难达到一个比较高的水准。所以我在尝试将bug分配方式改成由bug对应研发主动认领的方式，去除中心点，但这要求每个研发有足够的责任心，以及相关奖惩制度来把控。
2018-07-13