本文正在参加「金石方案 . 瓜分6万现金大奖」
一、布景
漏测Bug是指产品逻辑缺点在测验过程中没有被发现（尤其是测验环境能够重现的缺点），上线版别发布后或许在用户运用体会后发现并反应回来的缺点。或许构成线上故障或许资损，在对产品测验过程中，自己也难免呈现一些Bug的漏测，因此对Bug漏测进行一些考虑，并进行总结。
二、原因剖析
Bug其实是任何应用产品都会有的一个问题，不是一切的Bug都能被发现，包括资深测验，或多或少的会呈现线上缺点，谁也不能把软件一切的功用操作、运用场景想周全。尽管不能做到彻底零缺点，但是每次发布的产品，咱们需求追求缺点越来越少，产品质量越来越高，减少线上问题的反应。
为什么会呈现缺点漏测，主要有以下几点：
2.1 需求评定阶段，对事务需求细节了解不明确，规划存在不合理，未深化发掘隐含拓展需求
-
问题剖析
在实践产品研制过程中，产品需求其实处于一个细化、优化、下钻过程中，在需求PRD文档交互文档输出进行评定时，未能把一些产品细节问题、隐含需求露出出来，而测验用例的编写是根据PRD、交互文档以及自己对该需求经验了解所触及测验用例。
-
改善办法
-
需求评定前，咱们应该先仔细阅读PRD及交互文档，先构成自己对产品的考虑，经过脑图的办法列出对产品规划的疑问点,从用户或许从职业视点找出产品规划缺点点。
-
需求评定会议中，带着列出的疑问点向产品、开发交流自己对产品的疑惑和质疑点，多提几个为什么？怎样完结？数据获取来源？超出预期的数据怎样处理？缓存处理机制怎样？数据保存何处？逻辑由前端处理仍是后端服务？后端服务逻辑是否跟第三方关联？
-
需求评定完结后，按照必定的功用，将需求拆分红若干大模块，大模块拆分红小功用点，然后考虑功用点的详细完结流程，经过思维导图细分模块功用、从页面、交互、鸿沟处理、接口逻辑、环境配置等维度进行梳理需求，尽或许发掘隐含可拓展需求点，然后进行一次测验组内需求评定和技能复盘，让协作成员一起弥补隐含需求，使得产品规划缺点尽早且最大化地露出出来。
-
在后期技能评定时，探讨逻辑交互以及上下游数据走向和消息发送流通，串联技能侧疑问点。
2.2 测验用例掩盖不全面，场景呈现遗失
-
问题剖析
在测验用例规划过程中，简略呈现思维受限或许需求盲区，咱们不或许彻底掩盖用户运用的一切场景，编写测验用例的时不或许把一切的场景都能想周全，把一切的场景下的状况都写成测验用例去模仿、去掩盖这也是不太实际的。
-
改善办法
-
用例规划开端之前，列思维导图
经过思维导图列出事务流程，前、后端接口逻辑。然后按照PRD和交互文档，按照UI界面切分红大的功用块，然后在大功用块，然后在大功用块再切成小功用块，最后到功用点，每个功用点经过UI、根本功用、鸿沟、内存、数据、交互、接口逻辑等维度展开用例规划导图，并列出需找产品、开发承认的疑点。
-
用例规划完结后组织用例评定
a. 组织开发、产品进行测验用例评定，并抛出用例规划时的疑问，经过产品完结视点、数据存储、用户、产品体会视点对用例进行评定完善弥补。
b. 组织测验组内提早预审测验用例也是十分有必要的，关于正式用例评定前会组内进行预审，在版别完毕后组织全量用例调集入也会进行串讲用例，特别是一些经验老道或许事务熟悉的老司机们，能够在用例评定上快速的帮忙指出用例的遗失点，有助于测验人员翻开思路，尽或许多的掩盖用户场景，值得留意的是用例评定上遇到不确定的，应立即记载下来作为待办项，完毕后及时找相关人员承认，防止猜想不确定。
-
总结用户反应、完善测验用例流程-下钻测验用例构建以未雨绸缪
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）找开发聊聊开发是怎样修正这个功用*
- 跟开发聊完结很简略从开发的规划中你能够把握到测验的留意点，并记载表现在用例中。例如Ａ开发从前用某种办法做了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 疑难问题考虑
-
时刻和进度太紧张，排期紧凑。
-
对自己代码过于自信，自以为有很强的健壮性，不忍心去修正。
-
以为这是测验的责任，多度依靠测验。
-
不知怎样有用的做好自测，掩盖全面。
-
开发冒烟测验关于QA创建指定的用例了解不透彻，履行精约。
3.3 思维转变
-
代码质量、项目质量均是咱们的责任。
-
测验和开发人员考虑问题不同，开发是在制造软件，测验是在损坏软件，想办法去找出问题。
-
任何功用都有正常场景和反常场景，多数运用等价类和鸿沟值去挑选数据，掩盖全面。
-
不要相信任何开发的代码是无Bug。
-
走出详细完结时用的开发思维，站在需求和用户的视点去自测是否经过，假如自己是用户去测验你的功用。
3.4 不仔细认真自测带来的痛处和危险
-
需求遗失：一旦被用户发现此问题，用户印象会大打折扣，或许直接从开端运用即放弃运用，将带来十分大的客户丢失。
-
功用事端：主流程功用没有测验到位，或许反常场景没有测验到位，导致线上频频报错，体会极度不好，直接以为便是事端。
-
需求延期上线：假如自测不充分，测验花大量的时刻去交流低等级bug，甚至主流程走不下去，这样无疑会给开发带来返工、重复测验、耗时、需求延期、项目延期等一系列问题。
3.5 拟定自测陈述规范
- 功用模块介绍及布景介绍
-
功用、布景介绍
-
运用用户群体介绍
- 环境信息
-
版别号
-
Hosts、代码发布分支
-
预发or正式
-
功用规划文档以及UI规划图等
-
数据库数据同步、环境配置、开关设定等
- 梳理好的自测点
-
编写代码时分记载的事务点和测验点
-
需求变更的自测点
-
正向、逆向、反常场景测验点
-
兼容性
-
开发此功用是否会对其他功用构成影响，一行代码是否会引发新的问题呈现
- 自测实践成果：
-
高等级Bug数量、影响冒烟核心流程
-
中等级Bug数量、串联流程链路
-
低等级Bug数量、页面展示UI作用
-
开发冒烟自测阶段掩盖率
-
一轮、集成阶段掩盖率
- 期望成果：
-
契合测验SOP规定准出规范
-
冒烟自测以及集成阶段掩盖率规范
-
测验阶段Bug数量的操控
-
上线后Bug数量的操控，质量月复盘满意数量操控规范
四、总结
缺点漏测发生后咱们需求深化剖析漏测的Bug，考虑哪方面做的不够，是事务逻辑了解误差？用例评测遗失？技能方案存在不合理？考虑规划用例方向呈现了误差？多问一些几个为什么，换位考虑视点想问题，合理规划评测。保证相似的Bug能被预防提早发现露出出来，然后尽或许的下降缺点的发生，进步产品质量。在每个不同阶段做好用例测验方案履行，添加精细化测验以及探究性测验环节，需求开拓新的测验思维思维，走出惯用惯例的测验思维。同时也要站在开发侧、编写代码规划的思维逻辑去考虑，下降或许在测验阶段呈现Bug漏测、遗失的呈现，开发侧也需严厉履行自测和掩盖率SOP要求准出。
*文 /Viki
要是觉得文章对你有协助的话，欢迎谈论转发点赞～
