哎呀,当时怎么没有想到 | 京东云技术团队

京东云开发者
• 阅读 86

在我们的测试工作中,是不是经常遇到这样的情形,发生了线上问题,产品、研发或者测试同学一拍脑袋:当时怎么没有想到,怎么给漏掉了呢?明明是一个非常简单的事情,用大拇指都能想到的验证场景,为何当时就漏测了呢?但实际情况是,逃逸到线上的缺陷,疑难杂症式的极端异常的问题很少,大部分都不复杂且可以在设计和开发中规避,或者在测试过程中被识别出来。针对此类问题,从测试覆盖度的角度,本文试图解释一下为何会发生这样的事情,以及如何有效规避。

一. 为什么经常会发生测试场景覆盖不全的问题

高质量的测试覆盖率是确保产品质量和用户体验的关键因素,但为何会经常发生测试场景覆盖不全的问题,这里面既有主观因素的缺失,也有客观因素的限制,具体包括:

1. 主观原因

粗心大意:认为需求非常简单,没有认真分析验证场景及异常流程、分支流程,没有识别隐藏的细节,或者对于存在的风险,存在侥幸心理,不去进一步求证或验证。

经验主义:思维固化,认为老办法同样可以解决新问题,没有进一步思考对测试场景、测试数据、验证方式的不同之处。

需求理解不充分:测试用例只覆盖到了产品PRD里的显式功能,没有覆盖隐性需求,只进行了黑盒测试或者黑盒测试覆盖的场景不足。

业务知识不足:只看到了需求本身,没有看到背后隐藏的业务的真正诉求,知其然不知其所以然。

开发知识欠缺:无法熟读代码,无法通过参加代码评审识别出研发代码改动之处及可能影响的范围,望码兴叹,无法熟练进行白盒测试,或者自动化测试代码健壮性较差,无法起到自动化回归的作用。

信息互通不到位:与项目组其他成员沟通不到位,遗漏重要信息或没有对齐颗粒度,你以为的实际不是你以为,导致遗漏重要验证场景。

用例颗粒度太大:编写用例的过程也是自己梳理信息的过程,用例颗粒度大,自然梳理的过程就不会太精细,自然遗漏验证场景的几率就会更大_(虽然探索式测试的理念是不要求编写详细的测试用例,而是在测试过程中不断调整、优化或细化,但目前我们目前的环境不太适合探索式测试,因为绝大部分需求都要求快速上线,大部分需求都存在挤压排期的现场,在测试阶段很难有充足的时间进行探索式测试)_。

测试专业技能薄弱:测试专业技能、经验不足,力所不及,自然无法保证测试的充分性及验证场景的全面性。

2. 客观原因

项目周期紧凑:目前很多需求都无法按照研发测试的正常排期进行交付,倒排期和赶工是常态,测试很难有充分的时间思考验证场景,新功能的测试往往只能覆盖主要路径,而忽略了一些边界情况和异常情况。

需求变更频繁:迭代快、变更快也是产品常态,往往一期还没有上线,二期三期就要评审了,没有经过线上真实环境、数据和客户的反馈,产品方案、技术方案存在的缺陷可能无法识别到。

投放渠道众多:尤其是针对C端用户的拉新和促活活动,投放渠道非常多,涉及到不同在不同的环境运行,如App环境(iOS、安卓、鸿蒙)、H5环境、小程序环境,同时涉及到不同设备、不同环境、不同操作系统版本、不同浏览器的打开、回流、引导下载等操作,兼容性测试覆盖不足可能导致在某些环境下出现问题。

流量情况悬殊:各个投放渠道流量差异较大,若上线前没有对各渠道的流量有充分的预估,没有进行压测,在高并发、大数据量或复杂业务场景下,性能问题可能无法被及时发现,从而导致线上问题。

测试环境仿真度低:目前普遍存在系统之间测试环境不联通、测试环境数据不全等问题,导致测试环境的仿真度较低,可能出现测试环境无法模拟真实环境,或测试环境无法覆盖全部验证场景的情况。

二. 如何提升测试覆盖度

为了解决测试场景未覆盖导致线上问题的情况,进一步提升测试覆盖度,需要针对以上客观原因及主观原因进行分析,形成有针对性的对策。总结来说,在测前、测中及测后,提升"内因",把控“外因”,避免“三拍”。

哎呀,当时怎么没有想到 | 京东云技术团队

1. 内因

提升测试覆盖度,“内因”是关键,即可以通过积极的质量策略以及专业能力的提升,大大减少测试覆盖度不足的情况。

测前:**充分理解,**不盲目拍胸脯保证

◦测试工作不是始于测试执行之时,而应前置到需求阶段,测试同学应具备基本的业务Know-How,充分理解业务逻辑及研发逻辑,面对具体的业务需求,不仅停留在功能实现层面,更应理解此需求背后的业务诉求。在前置编写及评审测试用例的时候,与产品、研发充分沟通产品逻辑及技术实现方案是否与业务逻辑及真正的业务诉求保持一致,充分讨论业务风险和技术风险。总之,绝不能不求甚解、掉以轻心,应不懂就问,多沟通,多讨论风险,敢于发问,敢于质疑。

◦在测试专业能力方面,采用灵活的质量策略,如进行代码覆盖率分析,实时精准测试和探索式测试,贴近生产的测试环境和测试数据、更高覆盖率的的自动化测试,以及适合业务特点的测试工具等等。

测中:充分识别,**不草率拍脑袋决策**。在测试执行阶段,按照我们前置测试用例的逻辑,此时应该大部分需求的测试用例已经编写完毕,但随着交付进度的进行,各方对需求的理解不断加深,可能会识别出新的范围、风险或问题,因此,在进行测试用例评审时,应再次就验证范围、风险、异常场景等进行确认,并标注出核心验证点,注测试过程中的问题和风险,及时调整和改进测试策略。还应共识双向的影响范围,即该需求是否影响了其他业务功能或技术模块,其他功能或技术模块是否影响该需求。

测后:充分总结,**不惊慌拍大腿懊悔**。测试完成及上线不是终点,除了配合业务进行线上验证及观察线上数据、进行线上巡检之外,还应花点时间回顾一下交付的过程,总结经验教训,主动分享。对于核心的用例,看能否沉淀为自动化的回归及巡检用例。万一出现了线上问题,先尽快恢复业务,再分析原因,进行复盘,总结教训和改进方案。

2. 外因

提升测试覆盖度,“外因”是基础,即通过流程机制的约束及全流程的质量把控,层层把关,互相补位,从机制上降低测试场景遗漏发生的概率。通过规范化的质量活动对需求交付的各个阶段进行质量准入和准出,步步为营,形成强制性的“七道关卡”,只要是严格遵守这套流程机制,上一道关卡遗漏下来的问题,可能会被下一道关卡识别出来,因此,遗漏验证场景的从而导致缺陷逃逸到线上的概率会被大大降低。

总结一下,针对如何提升测试覆盖度,“内因”是关键,基本可以解决上述“主观原因”导致的测试覆盖不足的问题,“外因”是基础,基本可以解决上述“客观原因”导致的测试场景覆盖不足的问题。

三. 综述

总结来说,防止线上问题不能停留在口头上,或者简单粗暴地要求测试同学提升测试覆盖度,应该给与更加具体的要求、指导及评价的标准。其关键要素是流程机制确保基本的质量,专业能力进一步增进质量,主观能动性构建持续的高质量,只有不断提升“内因”并把控好“外因”,才能有效防范“漏测”问题的发生,持续交付稳定可靠的产品,并提供更好的用户体验。

作者:京东科技 王先科

来源:京东云开发者社区 转载请注明来源

点赞
收藏
评论区
推荐文章
待兔 待兔
3年前
一个免费的开源的html转markdown语法的工具
一个免费的开源的html转markdown语法的工具大家好,我是待兔,今天为大家分享一个由www.helloworld.net网站开发并开源的一个非常好用的工具html2md现在好的技术文章确实多,每天各种技术群里,各种技术社区,有很多质量非常好的技术文章,于是我们就收藏了,可是问题来了,我们收藏到哪呢?怎么收藏呢?1.微信群里发的文
liam liam
2年前
与Fiddler旗鼓相当的mock工具!
前言一大早测试部的老大就召集我们开了个会——原因是我们组负责的业务除了个线上漏测,用户的投诉跟雪花似的纷至杳来。公司门口那个巨大的显示屏就在那轮播着用户反馈,好几屏都是用户在吐槽这个bug。没啥可说的,该背的锅还是要背的,那个漏测也不算冤,测试同事造不出那个异常场景,心中侥幸,觉得不至于异常会导致客户端出现啥问题。偏偏它就出了问题!后来组里开会复盘了下,决定
初识VUE响应式原理
自从Vue发布以来,就受到了广大开发人员的青睐,提到Vue,我们首先想到的就是Vue的响应式系统,那响应式系统到底是怎么回事呢?接下来小编就给大家简单介绍一下Vue中的响应式原理。
Stella981 Stella981
2年前
Charles 使用教程
我们在开发网站项目的时候,我们可以通过浏览器的debug模式来看request以及response的数据,那么如果我们开发移动端项目没有网页呢?如何抓取数据呢?前几天有个做服务端的师弟跟我说他不用抓包工具,遇到问题直接debug代码,那我问他,如果线上服务的话,你怎么调?在实际项目中,没有遇到跟客户端相互扯皮的事情吗?我觉得很正常啊,客户端说他没问题,服
Stella981 Stella981
2年前
Redis源码入门
sds,全称SimpleDynamicStrings,是Redis自定义的一个字符串类型。typedefcharsds;看到这你肯定内心觉得Redis在逗你,这不就是一个字符数组么,怎么就SimpleDynamicStrings了呢!没错,我当时也是这么觉得的,但是仔细阅读源码后发现sds并不是一个人在战斗,它还有战
Stella981 Stella981
2年前
Spring Boot中建议关闭Open
前言一天,开发突然找过来说KLock(https://gitee.com/kekingcn/springbootklockstarter)分布式锁失效了,高并发情况下没有锁住请求,导致数据库抛乐观锁的异常。一开始我是不信的,KLock是经过线上大量验证的,怎么会出现这么低级的问题呢?然后,协助开发一起排查了一下午,最后经过不懈努力和一探到
Stella981 Stella981
2年前
CSS实现文字两端对齐
最近的项目遇到了这样的需求:(要求标题部分不管文字多少,都必须两端对齐)如下图:!(https://oscimg.oschina.net/oscnet/6e151291c0c55e2a231d00ec198d6c5be11.png)当时也没有多想直接使用‘ ’进行代替,毕竟产品同学想快一点看到效果,不敢怠慢!不过到第二个页面就傻眼了
Wesley13 Wesley13
2年前
MySQL 快速创建千万级测试数据
备注:此文章的数据量在100W,如果想要千万级,调大数量即可,但是不要大量使用rand()或者uuid()会导致性能下降背景在进行查询操作的性能测试或者sql优化时,我们经常需要在线下环境构建大量的基础数据供我们测试,模拟线上的真实环境。废话,总不能让我去线上去测试吧,会被DBA砍死的创建测试数据的方式
京东云开发者 京东云开发者
7个月前
MySQL innoDB 间隙锁产生的死锁问题 | 京东云技术团队
背景线上经常偶发死锁问题,当时处理一张表,也没有联表处理,但是有两个mq入口,并且消息体存在一样的情况,频率还不是很低,这么一个背景,我非常容易怀疑到,两个消息同时近到这一个事务里面导致的,但是是偶发的,又模拟不出来什么场景会导致死锁,只能进行代码分析,问
京东云开发者 京东云开发者
4个月前
测试环境使用问题及其优化对策实践 | 京东物流技术团队
一、前言我们经常听到研发人员和测试人员抱怨:“测试环境怎么又不能用了!”、“测试环境现在部署的是master包!”、“测试环境数据又被人改了?”、“测试环境怎么部署的这么慢!”、“测试环境里的公共服务,你用的时候我只能等着?”、“测试环境挂了,我自动化脚本