高效的缺陷报告和测试计划的编写

文章目录

缺陷报告
- 缺陷标题
- 缺陷概述
- 缺陷影响
- 环境配置
- 前置条件
- 缺陷重现步骤
- 期望结果和实际结果
- 优先级 (Priority) 和严重程度（Severity）
- 变通方案 (Workaround)
- 根原因分析 (Root Cause Analysis)
- 附件 (Attachment)
测试计划
- 测试范围
- 测试策略的话题
- - 第一，功能测试
  - 第二，兼容性测试
  - 第三，性能测试
- 测试资源
- 测试进度
- 测试风险预估
小结

缺陷报告

缺陷报告的生成是测试人员利用对需求的理解、严密的逻辑推理能力，迅速找出软件中的潜在缺陷，并以缺陷报告的形式递交给开发团队，开发工程师可以根据缺陷报告快速理解缺陷，并精确定位问题。同时，通过这个缺陷报告，开发经理可以准确预估缺陷修复的优先级、产品经理可以了解缺陷对用户或业务的影响以及严重性。

常见的写法：

缺陷标题

对缺陷的概括性描述，通常采用“在什么情况下发生了什么问题”的模式。楚地表述发生问题时的上下文。尽可能描述问题本质，

“搜索功能有问题”和“用户信息页面的地址栏位置不正确”等，这样的描述会给人“说了等于没说”的感觉。这样的描述，很容易引发开发工程师的反感和抵触情绪，从而造成缺陷被拒绝修改（reject）

避免只停留在问题的表面。

比如，“商品金额输入框，可以输入英文字母和其他字符”这个描述就只描述了问题的表面现象，而采用诸如“商品金额输入框，没有对输入内容做校验”的方式，就可以透过标题看到缺陷的本质，这样可以帮助开发人员快速掌握问题的本质。

最后，缺陷标题不易过长，对缺陷更详细的描述应该放在“缺陷概述”里。

缺陷概述

更多概括性的缺陷本质与现象的描述，是缺陷标题的细化。这部分内容通常是开发工程师打开缺陷报告后最先关注的内容，所以用清晰简短的语句将问题的本质描述清楚是关键。

还会包括缺陷的其他延展部分，比如你可以在这部分列出同一类型的缺陷可能出现的所有场景；再比如，你还可以描述同样的问题是否会在之前的版本中重现等。在这里，你应该尽量避免以缺陷重现步骤的形式来描述，而应该使用概括性的语句。

缺陷概述的目的是，清晰简洁地描述缺陷，使开发工程师能够聚焦缺陷的本质。

缺陷影响

缺陷引起的问题对用户或者对业务的影响范围以及严重程度。
缺陷影响决定了缺陷的优先级（Priority）和严重程度（Severity），开发经理会以此为依据来决定修复该缺陷的优先级；而产品经理会以此为依据来衡量缺陷的严重程度，并决定是否要等该缺陷被修复后才能发布产品。

测试工程师准确描述缺陷影响的前提是，必须对软件的应用场景以及需求有深入的理解，这也是对测试工程师业务基本功的考验。

环境配置

环境配置用以详细描述测试环境的配置细节。比如，操作系统的类型与版本、被测软件版本、浏览器的种类和版本、被测软件的配置信息、集群的配置参数、中间件的版本信息等等。

需要注意的是，环境配置的内容通常是按需描述，也就是说通常只描述那些重现缺陷的环境敏感信息。

比如，“菜单栏上某个条目缺失的问题”只会发生在 Chrome 浏览器，而其他浏览器都没有类似问题。那么，Chrome 浏览器就是环境敏感信息，必须予以描述，而至于 Chrome 浏览器是运行在什么操作系统上就无关紧要了，无需特意去描述了。

前置条件

指测试步骤开始前系统应该处在的状态，其目的是减少缺陷重现步骤的描述。

比如，某个业务操作需要先完成用户登录，你在缺陷重现步骤里就没有必要描述登录操作的步骤细节，可以直接使用 “前置条件：用户已完成登录”的描述方式；

再比如，用户在执行登录操作前，需要事先在被测系统准备好待登录用户，你在描述时也无需增加“用测试数据生成工具生成用户”的步骤，可以直接使用 “前置条件：用户已完成注册”的描述方式。

缺陷重现步骤

是整个缺陷报告中最核心的内容，其目的在于用简洁的语言向开发工程师展示缺陷重现的具体操作步骤。操作步骤通常是从用户角度出发来描述的，每个步骤都应该是可操作并且是连贯的，所以往往会采用步骤列表的表现形式。

在写缺陷重现步骤前，需要反复执行这些步骤 3 次以上：一是，确保缺陷的可重现性；二是，找到最短的重现路径，过滤掉那些非必要的步骤，避免产生不必要的干扰。

对于缺陷重现步骤的描述应该尽量避免以下 3 个常见问题：

笼统的描述，缺乏可操作的具体步骤。
出现与缺陷重现不相关的步骤。
缺乏对测试数据的相关描述。

期望结果和实际结果

期望结果和实际结果通常和缺陷重现步骤绑定在一起，在描述重现步骤的过程中，需要明确说明期待结果和实际结果。期待结果来自于对需求的理解，而实际结果来自于测试执行的结果。

通常来讲，当你描述期望结果时，需要说明应该发生什么，而不是什么不应该发生；而描述实际结果时，你应该说明发生了什么，而不是什么没有发生。

优先级 (Priority) 和严重程度（Severity）

缺陷优先级是指缺陷必须被修复的紧急程度，而缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。

可见，严重程度是缺陷本身的属性，通常确定后就不再变化，而优先级是缺陷的工程属性，会随着项目进度、解决缺陷的成本等因素而变动。那么，缺陷的优先级和严重程度又有什么关系呢？

缺陷越严重，优先级就越高；
缺陷影响的范围越大，优先级也会越高；
有些缺陷虽然从用户影响角度来说不算严重，但是会妨碍测试或者是自动化测试的执行，这类缺陷属于典型的严重程度低，但是优先级高；
有些缺陷虽然严重程度比较高，但是考虑到修复成本以及技术难度，也会出现优先级较低的情况。

变通方案 (Workaround)

提供一种临时绕开当前缺陷而不影响产品功能的方式,变通方案的有无以及实施的难易程度，是决定缺陷优先级和严重程度的重要依据。如果某个严重的缺陷没有任何可行的变通方案，那么不管修复缺陷代价有多大，优先级一定会是最高的，但是如果该缺陷存在比较简单的变通方案，那么优先级就不一定会是最高的了。

根原因分析 (Root Cause Analysis)

如果你能在发现缺陷的同时，定位出问题的根本原因，清楚地描述缺陷产生的原因并反馈给开发工程师，那么开发工程师修复缺陷的效率就会大幅提升。

附件 (Attachment)

是为缺陷存在提供必要的证据支持，常见的附件有界面截图、测试用例日志、服务端日志、GUI 测试的执行视频

测试计划

软件测试计划的制定通常是在需求分析以及测试需求分析完成后开始，并且是整个软件研发生命周期中的重要环节。

采用了敏捷开发模式，较少去制定传统意义上的测试计划了，而测试计划的表现形式已经不再是传统意义上庞大的、正式的测试计划文档了，而更多的是体现在每个迭代（sprint）的计划环节，而且这样的短期测试计划可以非常迅速地根据项目情况实时调整。

测试计划依旧存在，只是从原来的一次性集中制定测试计划，变成了以迭代的方式持续制定测试计划。

测试范围

被测对象以及主要的测试内容。比如，对于用户登录模块，功能测试既需要测试浏览器端又需要测试移动端，同时还考虑登录的安全和并发性能相关的非功能性需求的测试等。

测试范围的确定通常是在测试需求分析完成后进行，所以确定测试范围的过程在一定程度上也是对测试需求分析的进一步检验，这将有助于在早期阶段就发现潜在的测试遗漏。

同时，由于不可能进行穷尽测试，而且测试的时间和资源都是有限的，所以必须有所取舍，进行有针对性的测试。因此，测试范围中需要明确“测什么”和“不测什么”。

测试策略的话题

需要明确“先测什么后测什么”和“如何来测”这两个问题。还要说明采用什么样的测试类型和测试方法。需要注意的是，不仅要给出为什么要选用这个测试类型，还要详细说明具体的实施方法。

测试策略会要求我们明确测试的重点，以及各项测试的先后顺序。对用户登录模块来讲，“用户无法正常登录”和“用户无法重置密码”这两个潜在问题，对业务的影响孰轻孰重一目了然，所以，应该按照优先级来先测“用户正常登录”，再测“用户重置密码”。

还需要说明采用什么样的测试类型和方法，要详细说明具体的实施方法。

第一，功能测试

根据测试需求分析的思维导图来设计测试用例。主线业务的功能测试由于经常需要执行回归测试，所以需要考虑实施自动化测试，并且根据项目技术栈和测试团队成员的习惯与能力来选择合适的自动化测试框架。

通常应该先实现主干业务流程的测试自动化。实操时，通常需要先列出主要的功能测试点，并决定哪些测试点适合采用自动化测试，并且决定具体使用什么样的框架和技术。对于需要手工测试的测试点，要决定采用什么类型的测试用例设计方法，以及如何准备相关的测试数据。

另外，你还要评估被测软件的可测试性，如果有可测试性的问题，需要提前考虑切实可行的变通方案，甚至要求开发人员提供可测试性的接口。

第二，兼容性测试

Web 测试需要确定覆盖的浏览器类型和版本，移动设备测试需要确定覆盖的设备类型和具体 iOS/Android 的版本等。

怎么确定需要覆盖的移动设备类型以及 iOS/Android 的版本列表呢？

如果是既有产品，你可以通过大数据技术分析产品的历史数据得出 Top 30% 的移动设备以及 iOS/Android 的版本列表，那么兼容性测试只需覆盖这部分即可。
如果是一个全新的产品，你可以通过 TalkingData 这样的网站来查看目前主流的移动设备，分辨率大小、iOS/Android 版本等信息来确定测试范围。

兼容性测试的实施，往往是在功能测试的后期，也就是说需要等功能基本都稳定才会进行

当然也有特例，比如，对于前端引入了新的前端框架或者组件库，往往就会先在前期做兼容性评估，以确保不会引入后期无法解决的兼容性问题。

兼容性测试用例的选取，往往来自于已经实现的自动化测试用例。道理很简单，因为兼容性测试往往要覆盖最常用的业务场景，而这些最常用的业务场景通常也是首批实现自动化测试的目标。

所以，我们的 GUI 自动化框架，就需要能够支持同一套测试脚本在不做修改的前提下，运行于不同的浏览器。

第三，性能测试

需要在明确了性能需求（并发用户数、响应时间、事务吞吐量等）的前提下，结合被测系统的特点，设计性能测试场景并确定性能测试框架。

比如，是直接在 API 级别发起压力测试，还是必须模拟终端用户行为进行基于协议的压力测试。再比如，是基于模块进行压力测试，还是发起全链路压测。

如果性能是背景数据敏感的场景，还需要确定背景数据量级与分布，并决定产生背景数据的技术方案，比如是通过 API 并发调用来产生测试数据，还是直接在数据库上做批量 insert 和 update 操作，或者是两种方式的结合。

最后，无论采用哪种方式，都需要明确待开发的单用户脚本的数量，以便后续能够顺利组装压测测试场景。

性能测试的实施，是一个比较复杂的问题。首先，需要根据你想要解决的问题，确定性能测试的类型；然后，根据具体的性能测试类型开展测试。

性能测试的实施，往往先要根据业务场景来决定需要开发哪些单用户脚本，脚本的开发会涉及到很多性能测试脚本特有的概念，比如思考时间、集合点、动态关联等等。
脚本开发完成后，你还要以脚本为单位组织测试场景（Scenario），场景定义简单来说就是百分之多少的用户在做登录、百分之多少的用户在做查询、每个用户的操作步骤之间需要等待多少时间、并发用户的增速是 5 秒一个，还是 5 秒 2 个等等。
最后，才是具体的测试场景执行。和自动化功能测试不同，性能测试执行完成后性能测试报告的解读，是整个测试过程中最关键的点。

测试资源

包括测试人员和测试环境，这两类资源都是有限的。测试计划的目的就是，保证在有限资源下的产出最大化。所以，测试资源就是需要明确“谁来测”和“在哪里测”这两个问题。测试人员的资源通常有两个维度：一是，测试工程师的数量；二是，测试工程师的个人经验和能力。

测试环境对于不同的项目，可能会使用共享的测试环境，也可能使用专用的测试环境，甚至还会直接使用生产环境。另外，对于目前一些已经实现容器化部署与发布的项目，测试环境就会变得更简单与轻量级。

测试进度

测试进度主要描述各类测试的开始时间，所需工作量，预计完成时间，并以此为依据来建议最终产品的上线发布时间。

比如，版本接受测试（Build Acceptance Test）的工作量，冒烟测试（Smoke Test）的工作量，自动化脚本开发的工作量，缺陷修复的验证工作量，需要几轮回归测试、每一轮回归测试的工作量等等。

在传统瀑布模型中，测试进度完全依赖于开发完成并递交测试版本的时间。如果开发提交测试版本发生了延误，那么在不裁剪测试需求的情况下，产品整体的上线时间就同样会延期。

然而在敏捷模式下，测试活动贯穿于整个开发过程，很多测试工作会和开发工作同步进行，比如采用行为驱动开发（Behavior-Driven Development）模式，这样测试进度就不会完全依赖于开发递交可测试版本的时间。

行为驱动开发，就是平时我们经常说的 BDD，指的是可以通过自然语言书写非程序员可读的测试用例，并通过 StepDef 来关联基于自然语言的步骤描述和具体的业务操作，最典型的框架就是知名“Cucumber”。

测试风险预估

预估整个测试过程中可能存在的潜在风险，以及当这些风险发生时的应对策略
对于需求变更，比如增加需求、删减需求、修改需求等，一定要重新进行测试需求分析，确定变更后的测试范围和资源评估，并与项目经理和产品经理及时沟通因此引起的测试进度变化

小结

一份高效的软件缺陷报告，应该包括缺陷标题、缺陷概述、缺陷影响、环境配置、前置条件、缺陷重现步骤、期望结果和实际结果、优先级和严重程度、变通方案、根原因分析，以及附件这几大部分。
缺陷报告的每一部分内容，都会因为目的、表现形式有各自的侧重点，所以想要写出高效的软件缺陷报告，需要对其组成有深入的理解。
一份成功的测试计划，必须清楚地描述：测试范围、测试策略、测试资源、测试进度和测试风险预估这五个最重要的方面。
测试范围需要明确“测什么”和“不测什么”；
测试策略需要明确“先测什么后测什么”和“如何来测”；
测试资源需要明确“谁来测”和“在哪测”；
测试进度是需要明确各类测试的开始时间，所需工作量和预计完成时间；
测试风险预估是需要明确如何有效应对各种潜在的变化。