漏测Bug是指产品逻辑缺陷在测试过程中没有被发现(尤其是测试环境可以重现的缺陷),上线版本发布后或者在用户使用体验后发现并反馈回来的缺陷。可能造成线上故障或者资损,在对产品测试过程中,自己也难免出现一些Bug的漏测,因此对Bug漏测进行一些思考,并进行总结。
Bug其实是任何应用产品都会有的一个问题,不是所有的Bug都能被发现,包括资深测试,或多或少的会出现线上缺陷,谁也不能把软件所有的功能操作、运用场景想周全。虽说不能做到完全零缺陷,但是每次发布的产品,我们需要追求缺陷越来越少,产品质量越来越高,减少线上问题的反馈。
为什么会出现缺陷漏测,主要有以下几点:
用例设计开始之前,列思维导图
通过思维导图列出业务流程,前、后端接口逻辑。然后按照PRD和交互文档,依照UI界面切分成大的功能块,然后在大功能块,然后在大功能块再切成小功能块,最后到功能点,每个功能点通过UI、基本功能、边界、内存、数据、交互、接口逻辑等维度开展用例设计导图,并列出需找产品、开发确认的疑点。
用例设计完成后组织用例评审
a. 组织开发、产品进行测试用例评审,并抛出用例设计时的疑问,通过产品实现角度、数据存储、用户、产品体验角度对用例进行评审完善补充。
b. 组织测试组内提前预审测试用例也是非常必须的,对于正式用例评审前会组内进行预审,在版本结束后组织全量用例集合入也会进行串讲用例,特别是一些经验老道或者业务熟悉的老司机们,可以在用例评审上快速的帮忙指出用例的遗漏点,有助于测试人员打开思路,尽可能多的覆盖用户场景,值得注意的是用例评审上遇到不确定的,应立即记录下来作为待办项,结束后及时找相关人员确认,避免猜测不确定。
总结用户反馈、完善测试用例流程-下钻测试用例构建以有备无患
a. 产品测试发布上线后,对于用户反馈的缺陷,如果缺陷是因为场景设计不全引起的,我们先分析出现问题的场景是必现还是偶现,如果是必现,我们可以通过和技术同学沟通,确认该场景的一些具体复现步骤,确认引入原因,解决方案。
b. 对于线上如果出现缺陷需要对测试用例完善:除了补充该场景case外,考虑一些和该场景相关联的场景,将多种场景下测试用例及时完善、评审,增加到用例库中去。
c. 针对线上缺陷分析其具体原因做复盘总结,关注线上问题反馈群,及时发现问题、定位问题、分析原因,判断是否为老逻辑引入还是新功能引发问题,精准化补充对应的用例,针对特别场景补充接口自动化、防资损数据狗校验、全量用例集合BVT用例。
测试用例不一定能保证所有的场景和功能点都能覆盖到,但是严格按照测试用例执行测试,能最大程度上保证产品质量,尽量避免出现缺陷。
养成测试纪录习惯:对于测试阻塞用例、测试Fail用例,应该重点关注并记录,在回归测试阶段进行精准回归测试,确保修复Bug导致关联功能引入的新Bug也能被发现。
虽然测试流程很规范,但是软件质量还是不如意。
对于现阶段得物的测试环境问题是及其复杂的,业务系统不是孤立存在的,关联方环环相扣,而且关联系统常常出现不稳定的情况,另外涉及身份证、银行卡等稀缺资源的使用有限,往往测试完一个有效数据废弃一个有效数据,所以我们可以尽可能通过mock、还原客户的实际环境问题。
现实毕竟不是真实的环境,由于环境的差异,可能出现很多意想不到的问题,例如:配置问题、数据源问题、以及数据同步问题,这些都是可能只在特性的环境、特定的操作步骤下才会暴露出来,在我们的测试环境还原不出来,只能基于预发环境或者生产环境来验证问题,导致质量可能出现风险隐患。
1)引入灰度发布测试
测试组在预发布环境上进行回归测试,能基本模拟真实环境执行测试环境无法测试的用例,又不影响线上用户的正常使用。
2)生产验证环节做好case筛选
首先进行生产验证case梳理,生产验证case除了筛选p0+p1级别case进行回归外,还应该包含测试环境mock or 挡板阻塞的测试case,以及后端接口对前端响应的case,在生产回归阶段严格按照生产验证case执行去覆盖真实线上环境场景。
3)加强后端以及关联方业务逻辑的了解
前端不仅需要了解前端与后端接口的交互业务逻辑,还需了解后端接口与其它关联方的接口交互逻辑,校验判断其给的接口数据是否正确,对测试环境测试用例的覆盖程度有整体的把控度,以确保生产环境的测试用例覆盖做到全面性。
有一些开发人员只会针对你所提交的Bug中问题的描述步骤解决,并不会去排查该问题有可能涉及的所有点,有可能出现解决了这个问题,而引入了一个新的问题。一个不熟悉功能模块的开发人员来修复Bug,因为业务不熟悉,考虑不周全导致无意识的引入新的Bug。
1)代码review
2)精准回归测试
3)找开发聊聊开发是如何修复这个功能*
4)覆盖率的实践和应用
我们发现的很多Bug都不是按测试用例执行发现出来的,都是在测试过程中随意测试发现的,而这些步骤在测试用例中并未体现,我们的测试用例不可能覆盖所有的场景。
1)准入测试通过后进行ET测试
2)UAT 测试之前进行组内ET测试
3)精准化测试
开发人员做好自测,非常必要,也是大趋势。前期都是开发自测,后期才是用户体验方面的测试。从成本和时间上分析,Bug越晚发现修复成本越高;从修改的效率来讲,越早处理会越快。一个优秀的开发者,自测的Bug一定会多于测试发现的Bug,也就是轮到测试的时候Bug数量相当少。
缺陷漏测发生后我们需要深入分析漏测的Bug,思考哪方面做的不够,是业务逻辑理解误差?用例评测遗漏?技术方案存在不合理?思考设计用例方向出现了偏差?多问一些几个为什么,换位思考角度想问题,合理设计评测。确保类似的Bug能被预防提前发现暴露出来,从而尽可能的降低缺陷的产生,提高产品质量。在每个不同阶段做好用例测试计划执行,增加精细化测试以及探索性测试环节,需要开拓新的测试思想思维,走出惯用常规的测试思想。同时也要站在开发侧、编写代码设计的思维逻辑去考虑,降低可能在测试阶段出现Bug漏测、遗漏的出现,开发侧也需严格执行自测和覆盖率SOP要求准出。
*文 /Viki
要是觉得文章对你有帮助的话,欢迎评论转发点赞~
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。