一、背景

漏测 Bug 是指产品逻辑缺陷在测试过程中没有被发现（尤其是测试环境可以重现的缺陷），上线版本发布后或者在用户使用体验后发现并反馈回来的缺陷。可能造成线上故障或者资损，在对产品测试过程中，自己也难免出现一些 Bug 的漏测，因此对 Bug 漏测进行一些思考，并进行总结。

二、原因分析

Bug 其实是任何应用产品都会有的一个问题，不是所有的 Bug 都能被发现，包括资深测试，或多或少的会出现线上缺陷，谁也不能把软件所有的功能操作、运用场景想周全。虽说不能做到完全零缺陷，但是每次发布的产品，我们需要追求缺陷越来越少，产品质量越来越高，减少线上问题的反馈。

为什么会出现缺陷漏测，主要有以下几点：

2.1  需求评审阶段，对业务需求细节理解不明确，设计存在不合理，未深入挖掘隐含拓展需求

• 问题分析

在实际产品研发过程中，产品需求其实处于一个细化、优化、下钻过程中，在需求 PRD 文档交互文档输出进行评审时，未能把一些产品细节问题、隐含需求暴露出来，而测试用例的编写是基于 PRD、交互文档以及自己对该需求经验理解所涉及测试用例。

• 改进措施

1. 需求评审前，我们应该先仔细阅读 PRD 及交互文档，先形成自己对产品的思考，通过脑图的方式列出对产品设计的疑问点,从用户或者从行业角度找出产品设计缺陷点。

2. 需求评审会议中，带着列出的疑问点向产品、开发沟通自己对产品的疑惑和质疑点，多提几个为什么？如何实现？数据获取来源？超出预期的数据怎么处理？缓存处理机制如何？数据保存何处？逻辑由前端处理还是后端服务？后端服务逻辑是否跟第三方关联？

3. 需求评审完成后，按照一定的功能，将需求拆分成若干大模块，大模块拆分成小功能点，然后考虑功能点的具体实现流程，通过思维导图细分模块功能、从页面、交互、边界处理、接口逻辑、环境配置等维度进行梳理需求，尽可能挖掘隐含可拓展需求点，然后进行一次测试组内需求评审和技术复盘，让协作成员一起补充隐含需求，使得产品设计缺陷尽早且最大化地暴露出来。

4. 在后期技术评审时，探讨逻辑交互以及上下游数据走向和消息发送流转，串联技术侧疑问点。

2.2  测试用例覆盖不全面，场景出现遗漏

• 问题分析

在测试用例设计过程中，容易出现思维受限或者需求盲区，我们不可能完全覆盖用户使用的所有场景，编写测试用例的时不可能把所有的场景都能想周全，把所有的场景下的情况都写成测试用例去模拟、去覆盖这也是不太现实的。

• 改进措施

用例设计开始之前，列思维导图

1. 通过思维导图列出业务流程，前、后端接口逻辑。然后按照 PRD 和交互文档，依照 UI 界面切分成大的功能块，然后在大功能块，然后在大功能块再切成小功能块，最后到功能点，每个功能点通过 UI、基本功能、边界、内存、数据、交互、接口逻辑等维度开展用例设计导图，并列出需找产品、开发确认的疑点。

用例设计完成后组织用例评审

1. 组织开发、产品进行测试用例评审，并抛出用例设计时的疑问，通过产品实现角度、数据存储、用户、产品体验角度对用例进行评审完善补充。

2. 组织测试组内提前预审测试用例也是非常必须的，对于正式用例评审前会组内进行预审，在版本结束后组织全量用例集合入也会进行串讲用例，特别是一些经验老道或者业务熟悉的老司机们，可以在用例评审上快速的帮忙指出用例的遗漏点，有助于测试人员打开思路，尽可能多的覆盖用户场景，值得注意的是用例评审上遇到不确定的，应立即记录下来作为待办项，结束后及时找相关人员确认，避免猜测不确定。

总结用户反馈、完善测试用例流程-下钻测试用例构建以有备无患

1. 产品测试发布上线后，对于用户反馈的缺陷，如果缺陷是因为场景设计不全引起的，我们先分析出现问题的场景是必现还是偶现，如果是必现，我们可以通过和技术同学沟通，确认该场景的一些具体复现步骤，确认引入原因，解决方案。

2. 对于线上如果出现缺陷需要对测试用例完善：除了补充该场景 case 外，考虑一些和该场景相关联的场景，将多种场景下测试用例及时完善、评审，增加到用例库中去。

3. 针对线上缺陷分析其具体原因做复盘总结，关注线上问题反馈群，及时发现问题、定位问题、分析原因，判断是否为老逻辑引入还是新功能引发问题，精准化补充对应的用例，针对特别场景补充接口自动化、防资损数据狗校验、全量用例集合 BVT 用例。

2.3  测试阶段未严格按照测试用例执行

• 问题分析

按照测试用例执行测试，可以让我们尽可能的不出现遗漏一些测试点。不能因为某一个人或者对某一块业务熟悉简化其测试用例，不严格按照测试用例来执行测试，这样出现了一些遗漏 Bug 实在是不应该。

• 改进措施

1. 测试用例不一定能保证所有的场景和功能点都能覆盖到，但是严格按照测试用例执行测试，能最大程度上保证产品质量，尽量避免出现缺陷。

2. 养成测试纪录习惯：对于测试阻塞用例、测试 Fail 用例，应该重点关注并记录，在回归测试阶段进行精准回归测试，确保修复 Bug 导致关联功能引入的新 Bug 也能被发现。

虽然测试流程很规范，但是软件质量还是不如意。

2.4  测试环境、测试资源受限，导致缺陷漏测

• 问题分析

对于现阶段得物的测试环境问题是及其复杂的，业务系统不是孤立存在的，关联方环环相扣，而且关联系统常常出现不稳定的情况，另外涉及身份证、银行卡等稀缺资源的使用有限，往往测试完一个有效数据废弃一个有效数据，所以我们可以尽可能通过 mock、还原客户的实际环境问题。

现实毕竟不是真实的环境，由于环境的差异，可能出现很多意想不到的问题，例如：配置问题、数据源问题、以及数据同步问题，这些都是可能只在特性的环境、特定的操作步骤下才会暴露出来，在我们的测试环境还原不出来，只能基于预发环境或者生产环境来验证问题，导致质量可能出现风险隐患。

• 改进措施

1）引入灰度发布测试

测试组在预发布环境上进行回归测试，能基本模拟真实环境执行测试环境无法测试的用例，又不影响线上用户的正常使用。

2）生产验证环节做好 case 筛选

首先进行生产验证 case 梳理，生产验证 case 除了筛选 p0+p1 级别 case 进行回归外，还应该包含测试环境 mock or 挡板阻塞的测试 case，以及后端接口对前端响应的 case，在生产回归阶段严格按照生产验证 case 执行去覆盖真实线上环境场景。

3）加强后端以及关联方业务逻辑的了解

前端不仅需要了解前端与后端接口的交互业务逻辑，还需了解后端接口与其它关联方的接口交互逻辑，校验判断其给的接口数据是否正确，对测试环境测试用例的覆盖程度有整体的把控度，以确保生产环境的测试用例覆盖做到全面性。

2.5  开发人员引入的新 Bug

• 问题分析

有一些开发人员只会针对你所提交的 Bug 中问题的描述步骤解决，并不会去排查该问题有可能涉及的所有点，有可能出现解决了这个问题，而引入了一个新的问题。一个不熟悉功能模块的开发人员来修复 Bug，因为业务不熟悉，考虑不周全导致无意识的引入新的 Bug。

• 改进措施

1）代码 review

从代码管理层面：开发修复一个 Bug 提交代码自测通过准备提测时，开发团队提交代码进行代码 review，引入新 Bug 的可能性概率就会较小，降低风险存在。

2）精准回归测试

从测试自我修养层面：在开发提测后，了解代码改动点，精准分析改动点对相关联的功能点的影响，将开发人员修复的 Bug 确认验证，并将相关联的功能点尽可能的遍历回归测试到

3）找开发聊聊开发是如何修复这个功能*

跟开发聊实现很容易从开发的设计中你可以把握到测试的注意点，并记录体现在用例中。例如Ａ开发曾经用某种方式做了 B 功能，出现了某个 Bug，现在 B 功能用了同样方式实现，那么极有可能之前的 Bug 还会出现在 C 功能。

4）覆盖率的实践和应用

增加开发冒烟执行代码覆盖率，根据覆盖率数据分析有那些冒烟用例未覆盖到，是方法未覆盖到、还是类未覆盖到或者是异常逻辑的校验未回归到，用开发自测和覆盖率的方式降低其新 Bug 的引入。

2.6  探索性测试环节欠缺

• 问题分析

我们发现的很多 Bug 都不是按测试用例执行发现出来的，都是在测试过程中随意测试发现的，而这些步骤在测试用例中并未体现，我们的测试用例不可能覆盖所有的场景。

• 改进措施

1）准入测试通过后进行 ET 测试

在测试准入测试完成进入 SIT 测试阶段：一般来说，ET 测试是最容易发现 Bug 的，所以在测试准入测试完成进入 SIT 测试阶段，先进行一轮探索性测试，使的大部分的 Bug 先在测试前期暴露出来，让 Bug 累计数量达到一定的峰值，尽早发现 Bug，质量越高。

2）UAT 测试之前进行组内 ET 测试

SIT 测试进入尾声，UAT 测试之前组织一次组内 ET 测试，让组内不同的测试用不同的测试方式，测试思维，测试经验，测试习惯进行探索测试，能发现一些由于思维定势局限原因导致漏测的 Bug、诡异的 Bug 或者使用不合理的地方。

3）精准化测试

• 精准测试的测试用例聚类分析功能，可以有效地发现“测试的错误”。例如一个用例执行步骤错误，它的聚类结果必然会发生变化，管理者通过系统分析的结果就可以发现并纠正这一类的错误，而之前可能需要在现场回归反复的确认。

• 精准测试的核心技术要点是测试用例与代码的追溯技术。这项技术简单来说就是当功能执行完成以后对应的整体代码执行情况就会立即产生，即当点击一个测试用例，就立即追踪到对应的代码和模块。

• 精准测试测试漏洞分析功能，适用于敏捷测试。它可以基于程序静态数据和动态运行数据，自动分析软件缺陷最高风险的位置，引导首先对于高风险的模块完成覆盖，在有限时间内完成最具有风险的模块的覆盖测试。

三、对于开发角度侧思考

3.1  自测背景

开发人员做好自测，非常必要，也是大趋势。前期都是开发自测，后期才是用户体验方面的测试。从成本和时间上分析，Bug 越晚发现修复成本越高；从修改的效率来讲，越早处理会越快。一个优秀的开发者，自测的 Bug 一定会多于测试发现的 Bug，也就是轮到测试的时候 Bug 数量相当少。

3.2  疑难问题思考

1. 时间和进度太紧张，排期紧凑。

2. 对自己代码过于自信，自认为有很强的健壮性，不忍心去修改。

3. 认为这是测试的责任，多度依赖测试。

4. 不知如何有效的做好自测，覆盖全面。

5. 开发冒烟测试对于 QA 创建指定的用例理解不透彻，执行简约。

3.3  思维转变

1. 代码质量、项目质量均是我们的责任。

2. 测试和开发人员思考问题不同，开发是在制造软件，测试是在破坏软件，想办法去找出问题。

3. 任何功能都有正常场景和异常场景，多数使用等价类和边界值去选择数据，覆盖全面。

4. 不要相信任何开发的代码是无 Bug。

5. 走出具体实现时用的开发思维，站在需求和用户的角度去自测是否通过，假如自己是用户去测试你的功能。

3.4  不仔细认真自测带来的痛处和隐患

1. 需求遗漏：一旦被用户发现此问题，用户印象会大打折扣，可能直接从开始使用即放弃使用，将带来非常大的客户流失。

2. 功能事故：主流程功能没有测试到位，或者异常场景没有测试到位，导致线上频繁报错，体验极度不好，直接认为就是事故。

3. 需求延期上线：如果自测不充分，测试花大量的时间去沟通低等级 bug，甚至主流程走不下去，这样无疑会给开发带来返工、重复测试、耗时、需求延期、项目延期等一系列问题。

3.5  制定自测报告规范

• 功能模块介绍及背景介绍

1. 功能、背景介绍

2. 使用用户群体介绍

• 环境信息

1. 版本号

2. Hosts、代码发布分支

3. 预发 or 正式

4. 功能设计文档以及 UI 设计图等

5. 数据库数据同步、环境配置、开关设定等

• 梳理好的自测点

1. 编写代码时候记录的业务点和测试点

2. 需求变更的自测点

3. 正向、逆向、异常场景测试点

4. 兼容性

5. 开发此功能是否会对其他功能造成影响，一行代码是否会引发新的问题出现

• 自测实际结果：

1. 高等级 Bug 数量、影响冒烟核心流程

2. 中等级 Bug 数量、串联流程链路

3. 低等级 Bug 数量、页面展示 UI 效果

4. 开发冒烟自测阶段覆盖率

5. 一轮、集成阶段覆盖率

• 期望结果：

1. 符合测试 SOP 规定准出标准

2. 冒烟自测以及集成阶段覆盖率标准

3. 测试阶段 Bug 数量的控制

4. 上线后 Bug 数量的控制，质量月复盘满足数量控制标准

四、总结

缺陷漏测发生后我们需要深入分析漏测的 Bug，思考哪方面做的不够，是业务逻辑理解误差？用例评测遗漏？技术方案存在不合理？思考设计用例方向出现了偏差？多问一些几个为什么，换位思考角度想问题，合理设计评测。确保类似的 Bug 能被预防提前发现暴露出来，从而尽可能的降低缺陷的产生，提高产品质量。在每个不同阶段做好用例测试计划执行，增加精细化测试以及探索性测试环节，需要开拓新的测试思想思维，走出惯用常规的测试思想。同时也要站在开发侧、编写代码设计的思维逻辑去考虑，降低可能在测试阶段出现 Bug 漏测、遗漏的出现，开发侧也需严格执行自测和覆盖率 SOP 要求准出。

作者：得物技术

原文链接：https://xie.infoq.cn/article/8f76b602e0018bb2c617326f5