移动APP测试过程中对于BUG漏测的思考

上一篇 / 下一篇  2018-06-13 19:18:20 / 个人分类:缺陷管理

1、背景
漏测,指在产品缺陷在测试过程中没有被发现(尤其是测试环境可以重现的缺陷),而是在版本发布后或者在用户使用后发现并反馈回来的缺陷。
生命不息,BUG不止,在对产品测试过程中,自己也难免出现一些BUG的漏测,因此,对BUG漏测进行一些思考,并进行总结。
2、原因分析
BUG其实是任何产品都会有的一个问题,不是所有的BUG都能被发现,包括资深测试,或多或少的会出现线上缺陷,谁也不能把软件所有的功能操作、运用场景想周全。虽说不能做到完全零缺陷,但是每次发布的产品,我们需要追求缺陷越来越少,产品质量越来越高。
为什么会出现缺陷漏测,主要有以下几点:
2.1需求评审阶段,对业务需求细节理解不明确,未深入挖掘隐含拓展需求
问题分析
在实际产品研发过程中,产品需求其实处于一个细化过程中,在需求prd文档交互文档输出进行评审时,未能把一些产品细节问题、隐含需求暴漏出来,而测试用例的编写是基于prd交互文档。
改进措施
需求评审前,我们应该先仔细阅读prd及交互文档,先形成自己对产品的思考,通过脑图的方式列出对产品设计的疑问点,从用户或者从行业角度找出产品设计缺陷点;
需求评审会议中,带着列出的疑问点向产品、开发沟通自己对产品的疑惑和质疑点,多提几个为什么?如何实现?数据获取来源?超出预期的数据怎么处理?缓存处理机制如何?数据保存何处?逻辑由前端处理还是后端服务?后端服务逻辑是否跟第三方关联?
需求评审完成后,按照一定的功能,将需求拆分成若干大模块,大模块拆分成小功能点,然后考虑功能点的具体实现流程
通过思维导图细分模块功能、从页面、交互、边界处理、接口逻辑等维度进行梳理需求,尽可能挖掘隐含可拓展需求点,然后进行一次测试组内需求评审,让组内成员一起补充隐含需求,使得产品设计缺陷尽早且最大化地暴露出来。
2.2测试用例覆盖不全面,场景出现遗漏
问题分析
在测试用例设计过程中,容易出现思维受限或者需求盲区,我们不可能完全覆盖用户使用的所有场景,编写测试用例的同事不可能把所有的场景都能想周全,把所有的场景下的情况都写成测试用例这也是不大现实的。
改进措施
用例设计开始之前,列思维导图
通过思维导图列出业务流程,前后端接口逻辑。然后按照prd和交互文档,依照ui界面切分成大的功能块,然后在大功能块,然后在大功能块再切成小功能块,最后到功能点,每个功能点通过ui、基本功能、边界、内存、交互、网络、异常、接口逻辑等维度开展用例设计导图,并列出需找产品、开发确认的疑点。
用例设计完成后组织用例评审
(1)组织开发、产品进行测试用例评审,并抛出用例设计时的疑问,通过产品实现角度、数据存储、产品体验角度对用例进行评审完善。
(2)如时间充裕,组织测试组内用例评审也是非常必须的,特别是一些经验老道或者业务熟悉的老司机们,可以在用例评审上快速的帮忙指出用例的遗漏点,有助于测试人员打开思路,尽可能多的覆盖用户场景,值得注意的是用例评审上遇到不确定的,应立即记录下来,结束后及时找相关人员确认,避免猜测。
根据线上用户反馈缺陷完善用例
产品测试发布上线后,对于用户反馈的缺陷,如果缺陷是因为场景设计不全引起的,我们先分析出现问题的场景是必现还是偶现,如果是必现,我们可以通过和技术接口人沟通,确认该场景的一些具体复现步骤,确认引入原因,解决方案。然后进行测试用例完善:除了补充该场景case外,考虑一些和该场景相关联的场景,将多种场景下测试用例及时完善、评审,增加到用例库中去。
2.3测试阶段未严格按照测试用例执行
问题分析
按照测试用例执行测试,可以让我们尽可能的不出现遗漏一些测试点。但是我们一些同学,不严格按照测试用例来执行测试,这样出现了一些遗漏BUG实在是不应该。
改进措施
测试用例不一定能保证所有的场景和功能点都能覆盖到,但是严格按照测试用例执行测试,能最大程度上保证产品质量,尽量避免出现缺陷。
另外养成测试纪录习惯:对于测试阻塞用例、测试fail用例,应该重点关注并记录,在回归测试阶段进行精准回归测试,确保修复bug导致关联功能引入的新bug也能被发现。
2.4测试环境、测试资源受限,导致缺陷漏测
问题分析
互联网金融类产品的环境是及其复杂的,业务系统不是孤立存在的,关联方环环相扣,而且关联系统常常出现不稳定的情况,另外涉及身份证、银行卡等稀缺资源的使用有限,往往测试完一个有效数据废弃一个有效数据,所以我们可以尽可能通过mock、还原客户的实际环境(比如联网核查mock,银行卡鉴权mock),但是毕竟不是真实的环境,由于环境的差异,可能出现很多意想不到的问题,这些问题可能只在特性的环境、特定的操作步骤下才会暴露出来,在我们的测试环境还原不出来,只能基于生产环境来验证问题。
改进措施
引入灰度发布(预发布)测试
测试组在预发布环境上进行回归测试,能基本模拟真实环境执行测试环境无法测试的用例,又不影响线上用户的正常使用。
生产验证环节做好case筛选
首先进行生产验证case梳理,生产验证case除了筛选p0+p1级别case进行回归外,还应该包含测试环境mock or挡板阻塞的测试case,以及后端接口对前端响应的case,在生产回归阶段严格按照生产验证case执行去覆盖真实线上环境场景
加强后端及关联方业务逻辑的了解
前端不仅需要了解前端与后端接口的交互业务逻辑,还需了解后端接口与其它关联方的接**互逻辑,对测试环境测试用例的覆盖程度有整体的把控度,以确保生产环境的测试用例覆盖做到全面性。
2.5开发人员引入的新BUG
问题分析
有一些开发人员只会针对你所提交的BUG中问题的描叙步骤解决,并不会去排查该问题有可能涉及的所有点,有可能出现解决了这个问题,而引入了一个新的问题。
另外,一个不熟悉功能模块的开发人员来修复BUG,因为业务不熟悉,考虑不周全导致无意识的引入新的BUG。
改进措施
代码review
从代码管理层面:开发修复一个bug提交代码自测通过准备提测时,开发团队提交代码进行代码review,引入新BUG的可能性较小。
精准回归测试
从测试自我修养层面:在开发提测后,通过diff代码的方式,了解代码改动点,精准分析改动点对相关联的功能点的影响,将开发人员修复的BUG确认验证,并将相关联的功能点尽可能的遍历回归测试到。
找开发聊聊开发是如何修复这个功能。
跟开发聊实现很容易从开发的设计中你可以把握到测试的注意点,并记录体现在用例中。例如A开发曾经用某种方式做了a功能,出现了某个bug,现在b功能用了同样方式实现,那么极有可能之前的bug还会出现在b功能。
2.6、ET测试(探索性测试)环节欠缺
问题分析
我们发现的很多BUG都不是按测试用例执行发现出来的,都是在测试过程中随意测试发现的,而这些步骤在测试用例中并未体现,我们的测试用例不可能覆盖所有的场景
改进措施
准入测试通过后进行ET测试
在测试准入测试完成进入SIT测试阶段:一般来说,ET测试是最容易发现bug的,所以在测试准入测试完成进入SIT测试阶段,先进行一轮探索性测试,使的大部分的bug先在测试前期暴露出来,让bug累计数量达到一定的峰值,尽早发现bug,质量越高。
UAT测试之前进行组内ET测试
SIT测试进入尾声,UAT测试之前组织一次组内ET测试,让组内不同的测试用不同的测试方式,测试思维,测试经验,测试习惯进行探索测试,能发现一些由于思维定势局限原因导致漏测的bug、诡异的bug或者使用不合理的地方
3、总结
缺陷漏测发生后我们需要深入分析漏测的BUG,思考自己哪方面做的不够、确保类似的BUG都能已经被预防而不容易产生,从而尽可能的降低缺陷的产生,提高产品质量。

TAG: Bug 缺陷管理 BUG

pmw的个人空间 引用 删除 pmw   /   2018-06-14 18:57:28
5
 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

用户菜单

日历

« 2018-11-14  
    123
45678910
11121314151617
18192021222324
252627282930 

数据统计

  • 访问量: 3717
  • 日志数: 13
  • 建立时间: 2018-06-13
  • 更新时间: 2018-11-13

RSS订阅

Open Toolbar