先抛出我的2个观点:
1、漏测不一定是测试的锅。但当问题发生时,测试第一时间不要去拒绝推卸责任,而是要先去解决漏测问题。
2、漏测问题的及时处理很重要,但是避免再次漏测更重要。
为了将此问题阐述的更清楚,我将通过下面几个方面来论述:
1、“漏测”的原因分析
2、如何第一时间去解决“漏测”问题
3、如何避免自己无辜背锅“漏测”
4、如何避免再次“漏测”的建议(重点)
5、如何在消灭“漏测”的基础上还能保证测试效率
6、消灭“漏测”相关的学习视频推荐
一、“漏测”原因分析
近几年,发生了好几起互联网圈的“漏测”事件:
2011年淘宝一元门事件,单个商家预计损失在几百到上百万之间;
2014年刀塔传奇母亲节事件,2万金币变钻石(价值2000元人民币),该福利全服推送;
2015年携程瘫痪门事件,致使携程盘前股价暴跌11.67%;
2017年初阴阳师“业原火”事件,无敌体力无限制刷副本,还能刷到顶级材料,多少大R的噩梦;
2018年王者荣耀test邮件事件,安卓QQ区喜获“天美史上最强福利”,英雄沈梦溪、棒球奇才、英雄李信和灼热之刃四个永久道具随便用;
2019年拼多多优惠券事件,传言该BUG使拼多多一夜损失200亿。
…
那么,漏测了一定是测试的锅吗? 其实不然,导致漏测的原因有很多,随便举例,就会有这么些情况:
① 需求规格不明确,导致测试用例编写过于粗犷。产品和测试的责任。
② 需求规格变更但未通知测试,导致测试用例未及时更新,产品责任。
③ 测试用例覆盖不全面,场景出现遗漏,测试主责,产品、研发负责(参与用例评审)。
④ 测试过程中未严格按照测试用例执行,测试责任。
⑤ 时间不充足,经项目组达成一致后仅执行了部分优先级较高的模块测试,导致一些功能点在测试过程中被忽略,那么项目、研发、产品、测试都有责任。
⑥ 测试环境受限,导致缺陷漏测。
⑦ 开发人员解决bug时引入的新BUG等等。
可以看出以上情况都会导致系统在上线之后出现异常,而且并不都是测试的责任。产品、研发、项目、测试环境都可能要担责。
所以再仔细的测试,都无法避免漏测,简直是防不胜防。
所以”漏测”这口锅全部扣测试身上,明显是不能接受的,关键在于测试人员需要找出足够的证据来保护自己。
但出现bug后,也不要直接甩锅,这样让人感觉在逃避问题。第一要紧事情是处理bug,尽量减少对用户的影响;只要用户影响不大,即便有责任后果也不会太严重。
如何第一时间处理好bug呢?
二、如何第一时间去解决“漏测”问题
相比“漏测”的归责,我们更应该关注的是如何去解决漏测问题。如何处理呢?一般分为下面2步:
①问题发生时,拒绝推卸责任,第一时间解决用户使用问题。当问题出现后测试应该立即记录,确认影响范围,并尽快找到恢复方法。优先保证用户使用恢复正常。
②缩短问题修复时间,尽快推送修复后的版本给用户。确认问题复现步骤,并紧急协调研发人员进行修复。
三、如何避免自己无辜背锅“漏测”
“漏测”问题解决了,但“漏测”这口锅就会全部扣测试身上呢,这样明显也是不能接受的,测试人员需要找出足够的证据来保护自己。
所以,我们一定要对测试后出现的bug做好总结,事后组织反思会,进针对本次事故问题原因进行追溯,通过回溯确定问题的产生原因,问题的责任认定基本就清楚了。
问题回溯一般从bug的引入阶段,bug的产生原因,bug的遗漏原因等几个方面去分析。例如:
1)Bug如果是需求阶段引入的,需求本身有遗漏/描述不清楚,那么主要是产品人员的责任,但是设计、开发、测试人员没有评审出问题,同样也有责任
2) Bug 如果是开发阶段引入的,测试人员设计用例的时候没有考虑到,那么主要是测试人员的责任,但是测试用例同样是要经过开发、产品的评审才会使用的
3)bug同样是开发阶段引入的,如果bug是由于开发修改bug的时候引入了新的bug,恰好那个用例之前测试过,不会再重新测试了,这样的遗漏主要责任就在开发,修改bug控制影响范围是开发必须做到的,但是测试人员可以没有做到代码看护的事情
4) 再或者产品人员变更需求后,只是告诉开发要改,但是没有同步给测试,造成测试漏测,这就是项目研发流程有问题了,项目经理要负主要责任。
通过上面几个例子也可以看出,bug的产生有很多种可能的原因,一般情况下,在项目组中不会刻意的强调谁要负主要责任。为了团队的团结,大部分情况下都是产品、开发、测试共同承担责任。
四、如何避免再次“漏测”的建议(重点)
一坑绝不二踩,一个坑绝不摔两次跤。如何避免漏测?送你下面6条建议:
①规范工作流程,制定标准。可以主动推动项目团队就项目工作流程认知达成一致,明确项目排期,严格按照项目计划时间进行,需求lackdown后禁止再改动需求或者增加新需求。避免打出现信息同步不及时或者不同步问题。若必须改动则必须通过项目会议全员通过后才可。
②规范测试计划,做好Plan B。计划要明确测试范围、测试方法,以及准入准出标准;同时要考虑项目过程中的可能风险问题,做好Plan B。
③统一用例编写规范,选好回归用例。可以统一团队用例编写标准,明确优先级并得到项目团队的认可。P0优先级的用例可用于回归测试,确保功能可用(一般影响功能正常使用的均为P0)。
④严格执行用例、拒绝模糊验收。可以将用例上传至同一平台进行管理,执行时直接在平台做好记录,避免执行过程中遗漏或者测试人员“偷懒”导致执行不完全。而且执行失败的用例可跟bug关联起来,最终输出报告。此时验收标准可具体化到用例执行无遗漏,缺陷无遗留或者解决率达到XX%,甚至可以按照优先级、严重程度再具体到每个级别的解决率。例如:严重程度S0、S1级别解决率100%、S2级别解决率98%等等。
⑤拒接口头需求,拒提口头Bug。所有工作对接需要有文字形式的记录,包括提测、提bug、上线通知。不要觉得大家关系很好,有的东西说一声即可。当事故来临时你可以再看看关系好还有没有用。做好文字形式的记录既是保护自己也是约束各方,为自己的一言一行负责。
此外,测试还可以推动一下项目上线策略的制定,例如:可推动灰度发布策略,明确灰度范围,可选一些容忍度较好的客户群加入灰度名单,上线前先进行灰度试用,若规定时间内有异常,随时回滚修复;若规定时间无异常问题上报,即可全量推送。
若是为了避免“漏测”事故,就一味降低测试效率,这当然也是不允许的。
判断一个测试团队强不强,会至少两个维度:是不是快(效率),是不是好(没有漏测)。
强悍的测试团队应该是又快又好。
所以也给广大测试同学一些工作建议,提升测试质量(消灭“漏测”)的同时,如何提升团队质量和效率。
五、如何在消灭“漏测”的基础上还能保证测试效率
(1)善用平台统一管理(用例、Bug):可以借助一些好用的平台,推动项目团队使用。公共平台数据清晰透明,方便团队各方随时查看测试进度、bug解决进度。
(2)善用工具完善测试: 可以借助一些测试工具的使用,来弥补人为做不到的监控,比如可以在测试途中开着抓包工具,对于所有的请求和响应均做好监控,以防发生不明确复现手段导致bug滞留问题,也能给研发提供一个初步的定位,帮助研发缩短问题排查流程,从而提高bug解决效率。
(3)规范用例编写标准,团队达成统一。这里要明确到标题格式、前置条件、操作步骤、预期结果,最重要的是要明确用例优先级。
(4)引入自动化,让测试更高效。众所周知,自动化测试可以很好的提升效率,那么我们的回归用例明确后,这部分回归工作可以通过自动化来实现,找个“工具人”24小时不眠不休干活,岂不是可以在有效时间内更充分的测试。
(5)多看代码,理解研发所想。工作之余建议大家多看看研发的代码,看不懂可以让研发讲解大致思路,但是我相信最简单if else还是可以看懂的,找到里面的逻辑处理关系,可以明白开发实现某个功能都考虑了哪些场景,再结合用户使用场景就知道哪里会有可能出问题,测试的时候可以着重测试,效率会更高哦。
六、消灭“漏测”相关的学习视频推荐
回看与“漏测”的原因,凡是与测试人员相关的,我们发现都和测试用例有关。若测试用例覆盖能跟全面,更细致,执行更到位,则会大大提升消灭“漏测”的概率。
最后:
如果你平时有很多问题想要解决,你的测试职业规划也需要一点光亮,你也想跟着大家一起分享探讨,我给你推荐一个 「软件测试学习交流群:746506216」 你缺的知识这里有,你少的技能这里有,你要的大牛也在这里……
资源分享【这份资料必须领取~】
下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码,朋友们如果需要可以自行免费领取 【保证100%免费】
版权声明:本文为博主作者:测试界的飘柔原创文章,版权归属原作者,如果侵权,请联系我们删除!
原文链接:https://blog.csdn.net/m0_67695717/article/details/128443997