关于bug:一个漏测Bug能让你想到多少

一、背景

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

二、起因剖析

Bug 其实是任何利用产品都会有的一个问题，不是所有的 Bug 都能被发现，包含资深测试，或多或少的会呈现线上缺点，谁也不能把软件所有的性能操作、使用场景想周全。虽说不能做到齐全零缺点，然而每次公布的产品，咱们须要谋求缺点越来越少，产品质量越来越高，缩小线上问题的反馈。
为什么会呈现缺点漏测，次要有以下几点：

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

• 问题剖析

  在理论产品研发过程中，产品需要其实处于一个细化、优化、下钻过程中，在需要 PRD 文档交互文档输入进行评审时，未能把一些产品细节问题、隐含需要裸露进去，而测试用例的编写是基于 PRD、交互文档以及本人对该需要教训了解所波及测试用例。

• 改良措施

1. 需要评审前，咱们应该先仔细阅读 PRD 及交互文档，先造成本人对产品的思考，通过脑图的形式列出对产品设计的疑难点, 从用户或者从行业角度找出产品设计缺点点。
2. 需要评审会议中，带着列出的疑难点向产品、开发沟通本人对产品的纳闷和质疑点，多提几个为什么？如何实现？数据获取起源？超出预期的数据怎么解决？缓存解决机制如何？数据保留何处？逻辑由前端解决还是后端服务？后端服务逻辑是否跟第三方关联？
3. 需要评审实现后，依照肯定的性能，将需要拆分成若干大模块，大模块拆分成小性能点，而后思考性能点的具体实现流程，通过思维导图细分模块性能、从页面、交互、边界解决、接口逻辑、环境配置等维度进行梳理需要，尽可能开掘隐含可拓展需要点，而后进行一次测试组内需要评审和技术复盘，让合作成员一起补充隐含需要，使得产品设计缺点尽早且最大化地裸露进去。
4. 在前期技术评审时，探讨逻辑交互以及上下游数据走向和音讯发送流转，串联技术侧疑难点。

2.2  测试用例笼罩不全面，场景呈现脱漏

• 问题剖析

  在测试用例设计过程中，容易呈现思维受限或者需要盲区，咱们不可能齐全笼罩用户应用的所有场景，编写测试用例的时不可能把所有的场景都能想周全，把所有的场景下的状况都写成测试用例去模仿、去笼罩这也是不太事实的。

• 改良措施

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

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

2. 用例设计实现后组织用例评审

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

   b. 组织测试组内提前预审测试用例也是十分必须的，对于正式用例评审前会组内进行预审，在版本完结后组织全量用例汇合入也会进行串讲用例，特地是一些教训老道或者业务相熟的老司机们，能够在用例评审上疾速的帮忙指出用例的脱漏点，有助于测试人员关上思路，尽可能多的笼罩用户场景，值得注意的是用例评审上遇到不确定的，应立即记录下来作为待办项，完结后及时找相干人员确认，防止猜想不确定。

3. 总结用户反馈、欠缺测试用例流程 - 下钻测试用例构建以有恃无恐

   a. 产品测试公布上线后，对于用户反馈的缺点，如果缺点是因为场景设计不全引起的，咱们先剖析呈现问题的场景是必现还是偶现，如果是必现，咱们能够通过和技术同学沟通，确认该场景的一些具体复现步骤，确认引入起因，解决方案。

   b. 对于线上如果呈现缺点须要对测试用例欠缺：除了补充该场景 case 外，思考一些和该场景相关联的场景，将多种场景下测试用例及时欠缺、评审，减少到用例库中去。

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

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

• 问题剖析

  依照测试用例执行测试，能够让咱们尽可能的不呈现脱漏一些测试点。不能因为某一个人或者对某一块业务相熟简化其测试用例，不严格依照测试用例来执行测试，这样呈现了一些脱漏 Bug 切实是不应该。

• 改良措施

  • 测试用例不肯定能保障所有的场景和性能点都能笼罩到，然而严格依照测试用例执行测试，能最大水平上保障产品质量，尽量避免呈现缺点。
  • 养成测试纪录习惯：对于测试阻塞用例、测试 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）找开发聊聊开发是如何修复这个性能 *

• 跟开发聊实现很容易从开发的设计中你能够把握到测试的留神点，并记录体现在用例中。例如A开发已经用某种形式做了 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）精准化测试

1. 精准测试的测试用例聚类分析性能，能够无效地发现“测试的谬误”。例如一个用例执行步骤谬误，它的聚类后果必然会发生变化，管理者通过系统分析的后果就能够发现并纠正这一类的谬误，而之前可能须要在现场回归重复的确认。

1. 精准测试的核心技术要点是测试用例与代码的追溯技术。这项技术简略来说就是当性能执行实现当前对应的整体代码执行状况就会立刻产生，即当点击一个测试用例，就立刻追踪到对应的代码和模块。

1. 精准测试测试破绽剖析性能，实用于麻利测试。它能够基于程序静态数据和动静运行数据，主动剖析软件缺陷最高危险的地位，疏导首先对于高风险的模块实现笼罩，在无限工夫内实现最具备危险的模块的笼罩测试。

三、对于开发角度侧思考

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 要求准出。

* 文 /Viki 

要是感觉文章对你有帮忙的话，欢送评论转发点赞～