再聊测试充分度

961 篇文章 1 订阅
555 篇文章 1 订阅

2024软件测试面试刷题,这个小程序(永久刷题),靠它快速找到工作了!(刷题APP的天花板)-CSDN博客文章浏览阅读2.2k次,点赞85次,收藏11次。你知不知道有这么一个软件测试面试的刷题小程序。里面包含了面试常问的软件测试基础题,web自动化测试、app自动化测试、接口测试、性能测试、自动化测试、安全测试及一些常问到的人力资源题目。最主要的是他还收集了像阿里、华为这样的大厂面试真题,还有互动交流板块……https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502

01/为什么再聊测试充分度?

为什么说是再聊,是因为22年写过一篇测试充分度的文章《对测试充分度的思考》,当时从整个测试流程(宏观)角度切入,例如 单元测试、集成测试、全链路测试以及非功能测试,以及从代码覆盖率(微观)角度,分析哪些代码行/分支等没有测试用例覆盖到,力求每个环节都做到尽善尽美,没有遗漏。

第二个原因就是测试充分度确实太重要了,不是说老板经常在夜深人静的时候走到你身边问上几句“xx,怎么样,测完了吗?测试的怎么样?”,对你来说有压力,不知道怎么回答。而是传统意义上来讲,测试充分度非常依赖测试人员业务经验,精通业务的测试老鸟熟知业务代码,自然在设计用例场景的时候考虑比较全面。反之,而测试新人则出现遗漏测试场景的概率比较大。

而如何回答“测够了吗?”。代码覆盖率是衡量测试充分性的起点,但远远不是终点。要回答”测够了吗”,至少还要考虑是否测了所有的场景、所有的状态转移路径等等。即便如此,我们可能还是无法100%确信我们已经测够了,可能我们最终只能做到非常趋近于测够了。

02/为什么说100%代码覆盖率不是终点?

1. 代码覆盖率不等于测试质量;

2. 即使代码覆盖率达到了 100%,测试也都通过了,也不代表就完全涵盖了现实使用中所有可能的情况。

举个最简单的例子,即使我们从测试代码里删除了所有的断言,我们的代码覆盖率是会保持不变的,因为其只会统计应用在测试期间执行了多少代码行。详情推荐阅读这篇文章《The 100% code coverage problem》链接如下↓

https://jeroenmols.com/blog/2017/11/28/coveragproblem

代码覆盖率只是推进测试充分度的一种手段,它不是测试质量(测试充分度则与测试质量有直接联系,一般来说测试充分度越高,测试质量越高),因此100%的代码覆盖率并不一定带来100%的测试质量。

03/对测试充分度的再思考

分析任何事物都有宏观层面与微观层面,例如《宏观经济学》从整个经济整体层面研究这台机器如何运转的,它主要关注国家范围内的经济现象和趋势;而《微观经济学》则是研究个体经济行为,它关注的是个体经济单位在资源分配和决策制定方面的行为和选择。虽然二者研究对象有所区别,但最终目的都是研究如何促使经济机器健康运转,可以说只是切入点不同。

当然这个思想对于研究测试充分度来说也是适用的,下面我就从宏观层面与微观层面分享下观点。

图片

04/微观【接口】与宏观【业务场景】建立联系

从接口微观层面看,一个接口(以http接口为例)包含methodType、请求参数、请求头等关键信息,我们深入一个接口内部的实现,通常是基于请求参数里的某些关键字段做if...else判断,然后走不同的逻辑。

图片

因此我认为接口测试重点是找到关键字段,覆盖关键字段的所有场景,才是提高测试充分度的关键,也可以是说测试用例的有效的,而不是对一个非关键字段设计各种无效测试用例(少投入时间到无关紧要的事物上)。

上述可以得到一个结论:接口参数里关键字段 和 业务场景是强相关的。根据关键字段得到的所有业务场景就是测试充分度的分母。

核心公式:

测试充分度 = 测试用例中覆盖到的关键字段值的业务场景/关键字段所有取值的业务场景

再回过头看代码覆盖率,分析代码覆盖率则不一定能推导出有哪些业务场景。

图片

业务场景A,走代码块A

业务场景B,走代码块B

业务场景C,走代码块A+B

则100%的代码覆盖率不能推导出100%业务场景

因此从理论上讲,我们只需要分析关键字段,其实就可以分析出有哪些测试场景。最happy的情况就是,一个接口就一个关键字段,那么很容易分析出有哪些业务场景。但是如果只是一个接口的关键字段比较多怎么办,难道要做笛卡尔积,似乎又陷入了无法穷尽的境地(测试是无法穷尽的)。

但似乎还有转机,既然理论上做笛卡尔积的业务场景无法得到,我们能否根据线上真实运行的业务场景作为测试充分度的分母?

答案当然是可以的。

因此我们可以分析线上用户发起服务请求的(当然是非敏感)日志,来计算出线上真实的业务场景,然后反过来推动补充线下测试用例未覆盖业务场景。

推论公式:

测试充分度 = 测试用例中覆盖到的关键字段值的业务场景/线上关键字段有取值的业务场景

这样我们就把一个非常依赖测试人员业务经验的问题转化成了一个技术问题,即便业务经验不足也可以通过分析关键字段来设计测试场景。

哈哈,看到这里,是不是觉得测试充分度也不过如此?的确,有时候我们在专注一件事情毫无头绪的时候,不如换个角度去思考这件事情。

今天就聊到这里了,关于测试充分度度量如何实现我们后面有机会再聊。

行动吧,在路上总比一直观望的要好,未来的你肯定会感谢现在拼搏的自己!如果想学习提升找不到资料,没人答疑解惑时,请及时加入群: 786229024,里面有各种测试开发资料和技术可以一起交流哦。

最后: 下方这份完整的软件测试视频教程已经整理上传完成,需要的朋友们可以自行领取【保证100%免费】

在这里插入图片描述

软件测试面试文档

我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。在这里插入图片描述
在这里插入图片描述在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值