遗漏Bug之后你会怎么办？
本帖最后由 草帽路飞UU 于 2022-11-28 15:53 编辑一、背景
漏测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）精准化测试
精准测试的测试用例聚类分析功能，可以有效地发现“测试的错误”。例如一个用例执行步骤错误，它的聚类结果必然会发生变化，管理者通过系统分析的结果就可以发现并纠正这一类的错误，而之前可
能需要在现场回归反复的确认。
精准测试的核心技术要点是测试用例与代码的追溯技术。这项技术简单来说就是当功能执行完成以后对应的整体代码执行情况就会立即产生，即当点击一个测试用例，就立即追踪到对应的代码和模块。
精准测试测试漏洞分析功能，适用于敏捷测试。它可以基于程序静态数据和动态运行数据，自动分析软件缺陷最高风险的位置，引导首先对于高风险的模块完成覆盖，在有限时间内
完成最具有风险的模块的覆盖测试。
很棒
页:
[1]
