上一章介绍了测试覆盖率的概念，并重点介绍了代码覆盖率的应用价值以及局限性。下面介绍如何才能写出一份高效的软件缺陷报告。
测试工程师需要利用对需求的理解、高效的执行力以及严密的逻辑推理能力，迅速找出软件中潜在的缺陷，并以缺陷报告的形式递交给开发团队。
缺陷报告是测试工程师与开发工程师沟通的重要桥梁，也是测试工程师日常工作的重要“输出”。作为优秀的测试工程师，最基本的一项技能就是，准确、无歧义地表达发现的缺陷。“准确、无歧义地表达”意味着，开发工程师可以根据缺陷报告快速理解软件缺陷，并精确定位问题。同时，通过这个缺陷报告，开发经理可以准确预估缺陷修复的优先级和严重程度，产品经理可以了解缺陷对用户或业务的影响程度。
缺陷报告撰写的质量将直接关系到缺陷修复的速度以及开发工程师的效率，同时还会影响测试与开发人员协作的有效性。
那么，如何才能写出一份高质量的缺陷报告呢？或者说，一份好的缺陷报告需要包括哪些具体内容呢？
一些测试人员可能觉得这并不困难，毕竟软件企业通常都有缺陷管理系统，如典型的ALM（以前的Quality Center）、JIRA、Bugzilla、BugFree 和Mantis 等。当使用这类系统提交缺陷时，会自动生成报告模板，测试人员只要按照其中的必填字段提供缺陷的详细信息就可以了。很多时候，测试人员不用想应该提供什么信息，系统会引导测试人员提供相关的信息。但是，作为测试人员，你仔细想过为什么要填写这些字段，这些字段都起什么作用，以及每个字段的内容具体应该怎么填写吗？
必须牢牢记住的是，好的缺陷报告绝对不是大量信息的堆叠，而是提供准确有用的信息。接下来，就带读者一起看一份高质量的缺陷报告主要由哪些部分组成，以及每部分内容的关键点是什么。
2.1.1 缺陷标题
缺陷标题通常是别人最先看到的部分，是对缺陷的概括性描述，通常采用“在什么情况下发生了什么问题”的模式。
首先，对“什么问题”的描述不仅要做到清晰简洁，还要具体，不能采用过于笼统的描述。描述“什么问题”的同时还必须清楚地表述与问题相关的上下文，也就是问题出现的场景。“用户不能正常登录”“搜索功能有问题”和“用户信息页面的地址栏位置不正确”等，这样的描述会给人“说了等于没说”的感觉。这样的描述很容易引起开发工程师的反感和抵触情绪，从而造成拒绝修改缺陷的后果。同时，还会造成缺陷管理上的困难。比如，如果你发现了一个菜单栏上某个条目缺失的问题，在提交缺陷报告前，建议从缺陷管理系统搜索一下是否已经有人提交过类似的缺陷。当你以“菜单栏”为关键字搜索时，可能会得到一堆“菜单栏有问题”的缺陷。如果缺陷标题的描述过于笼统，你就不得不单击每个已知缺陷以查看细节，这就会大大降低你的工作效率。所以，如果缺陷标题本身就能概括性地描述具体问题，就可以通过阅读标题判断类似的缺陷是否提交过，大大提高测试工程师提交缺陷报告的效率。
其次，标题应该尽可能描述问题本质，而避免只停留在问题的表面。比如，“在商品金额输入框中，可以输入英文字母和其他字符”这个描述就只描述了问题的表面现象，而采用诸如“在商品金额输入框中，没有对输入内容做校验”的描述，就可以透过标题看到缺陷的问题，这样可以帮助开发人员快速掌握问题的本质。
最后，缺陷标题不宜过长，对缺陷更详细的描述应该放在“缺陷概述”里。
2.1.2 缺陷概述
缺陷概述通常会提供更多概括性的缺陷本质与现象的描述，是缺陷标题的细化。因为这部分内容通常是开发工程师打开缺陷报告后最先关注的内容，所以用清晰简短的语句将问题描述清楚是关键。
缺陷概述还会包括缺陷的其他延展部分，比如，可以在这部分列出同一类型的缺陷可能出现的所有场景，还可以描述同样的问题是否会在之前的版本中重现等。在这里，应该尽量避免以缺陷重现步骤的形式来描述，而应该使用概括性的语句。总之，缺陷概述的目的是，清晰简洁地描述缺陷，使开发工程师能够聚焦缺陷的本质。
2.1.3 缺陷影响
缺陷影响描述的是，缺陷引起的问题对用户或者对业务的影响范围以及严重程度。缺陷影响决定了缺陷的优先级（Priority）和严重程度（Severity）。开发经理会以此为依据来决定修复该缺陷的优先级；而产品经理会以此为依据来衡量缺陷的严重程度，并决定是否要等该缺陷被修复后才发布产品。测试工程师准确描述缺陷影响的前提是，必须对软件的应用场景以及需求有深入的理解，这也是对测试工程师业务基本功的考验。
2.1.4 环境配置
环境配置用于详细描述测试环境的配置细节，为缺陷的重现提供必要的环境信息。比如，操作系统的类型与版本、被测软件版本、浏览器的种类和版本、被测软件的配置信息、集群的配置参数、中间件的版本信息等。
需要注意的是，环境配置的内容通常按需描述。也就是说，通常只描述那些重现缺陷的环境敏感信息。比如，“菜单栏上某个条目缺失的问题”只会发生在Chrome 浏览器中，而其他浏览器中都没有类似问题。那么，Chrome 浏览器就是环境敏感信息，必须予以描述，而至于Chrome 浏览器是运行在什么操作系统上就无关紧要了，无须特意描述。
2.1.5 前置条件
前置条件是指测试步骤开始前系统应该处在的状态，其目的是减少缺陷重现步骤的描述。合理地使用前置条件可以在描述缺陷重现步骤时排除不必要的干扰，使其更有针对性。比如，某个业务操作需要先完成用户登录，你在缺陷重现步骤里就没有必要描述登录操作的步骤细节，可以直接使用 “前置条件：用户已完成登录”的描述方式。再比如，用户在执行登录操作前，需要事先在被测系统中准备好待登录用户，你在描述时也无须增加“用测试数据生成工具生成用户”的步骤，可以直接使用“前置条件：用户已完成注册”的描述方式。
2.1.6 缺陷重现步骤
缺陷重现步骤是整个缺陷报告中最核心的内容，其目的在于用简洁的语言向开发工程师展示缺陷重现的具体操作步骤。这里需要注意的是，操作步骤通常是从用户角度出发来描述的，每个步骤都应该是可操作并且是连贯的，所以往往会采用步骤列表的表现形式。
通常测试工程师在写缺陷重现步骤前，需要确保缺陷的可重现性，并找到最短的重现路径，从而过滤掉那些非必要的步骤，避免产生不必要的干扰。
对于缺陷重现步骤的描述应该尽量避免以下3 个常见问题。
- 笼统的描述，缺乏可操作的具体步骤。
- 出现与缺陷重现不相关的步骤。
- 缺乏对测试数据的相关描述。
2.1.7 期望结果和实际结果
期望结果和实际结果通常与缺陷重现步骤绑定在一起，在描述重现步骤的过程中，需要明确说明期望结果和实际结果。期望结果来自对需求的理解，实际结果则来自测试执行的结果。通常来讲，当描述期望结果时，需要说明应该发生什么，而不是什么不应该发生；而描述实际结果时，应该说明发生了什么，而不是什么没有发生。
2.1.8 优先级和严重程度
之所以将优先级和严重程度放在一起，是因为这两个概念看起来有点类似，而本质却完全不同。另外，很多入行不久的测试工程师，也很难搞清楚这两者的差异到底在哪里。根据百度百科的解释，缺陷优先级是指缺陷必须被修复的紧急程度，而缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。可见，严重程度是缺陷本身的属性，通常确定后就不再变化，而优先级是缺陷的工程属性，会随着项目进度、解决缺陷的成本等因素而变动。那么，缺陷的优先级和严重程度又有什么关系呢？
- 缺陷越严重，优先级就越高。
- 缺陷影响的范围越大，优先级也会越高。
- 有些缺陷虽然从用户影响角度来说不算严重，但是会妨碍测试或者自动化测试的执行，这类缺陷的严重程度低，但是优先级高。
- 有些缺陷虽然严重程度比较高，但是考虑到修复成本以及技术难度，同时存在变通方案的，也会出现优先级低的情况。
2.1.9 变通方案
变通方案（Workaround）是提供一种临时绕开当前缺陷而不影响产品功能的解决问题方式，通常由测试工程师或者开发工程师提出，或者他们一同提出。
变通方案以及实施方式，是决定缺陷优先级的重要依据。如果某个严重的缺陷没有任何可行的变通方案，那么不管修复缺陷的代价有多大，优先级一定会是最高的，但是如果该缺陷存在比较简单的变通方案，那么优先级就不一定会是最高的。
2.1.10 根原因分析
根原因分析（Root Cause Analysis）就是平时常说的RCA。如果你能在发现缺陷的同时，定位出问题的根本原因，清楚地描述缺陷产生的原因并反馈给开发工程师，那么开发工程师修复缺陷的效率就会大幅提升。
可以做好根原因分析的测试工程师，通常都具有开发背景，或者至少有较好的代码阅读以及代码调试能力。所以作为测试工程师，很有必要深入学习一门高级语言，这将帮助你系统地建立编程思想，这样在之后的工作中，无论是面对开发的代码，还是自动化测试代码和脚本，都能做到得心应手。
2.1.11 附件
附件（Attachment）通常为缺陷的存在提供必要的证据支持，常见的附件有界面截图、测试用例日志、服务器端日志、GUI 测试的执行视频等。
对于那些很难用文字描述清楚的界面布局的缺陷，可以通过截图和高亮显示相关区域的方式提交缺陷报告。
本文摘自刚刚上架不久的《测试工程师全栈技术进阶与实践》，作者： 茹炳晟
朱少民、周震漪、周枫，以及百度、阿里、腾讯、字节跳动、eBay、网易、美团、ThoughtWorks、京东、谷歌、华为等公司测试专家推荐
极客时间”软件测试52讲-从小工到专家的实战心法”专栏增补版图书
本书全面讲解了软件测试人员必知必会的测试知识、技术和工具。
全书分为12章。第1章和第2章用“用户登录”测试实例，讲解了软件测试基础知识，让读者快速学习关键的基础知识；第3章讲解了GUI测试框架设计、框架在大型电商网站的具体实践，梳理了影响GUI自动化测试稳定性的关键因素，并给出了切实可行的解决方案；第4章介绍了3类移动应用的测试方法与技术，以及如何在移动测试中应用Appium来帮助测试人员更好地实现自动化测试；第5章以循序渐进的方式，讲解了API测试的关键技术、微服务架构下的API测试挑战等；第6章讲解了代码级测试的基础知识、静态测试方法、动态测试方法、静态扫描工具Sonar、单元测试框架TestNG、代码覆盖率工具等内容；第7章和第8章系统地对性能测试的方法以及应用领域进行阐述，并基于LoadRunner讲解大型企业性能测试的规划、设计、实现的具体实例，还介绍了大型互联网产品的全链路压测的行业实践；第9章探讨了测试数据准备的技术，并讨论了很多准备测试数据的新方法；第10章结合主流的DevOps和CI CD，深入剖析了大型互联网企业的测试基础架构设计；第11章和第12章讲解了软件测试新技术，如探索式测试、测试驱动开发、精准测试、渗透测试、基于模型的测试，以及人工智能在测试领域的应用。
本书适合测试人员、开发人员、运维人员、测试经理和软件质量保证人员学习，也可以作为大专院校相关专业师生的学习用书和培训学校的教材。