白盒测试究竟怎么做

大家好,我是洋子

在进行日常测试的时候,我们大部分时间花在手动的功能测试上,功能测试又可称为手工测试,官方一点的学名叫黑盒测试,当然作为测试工程师,我们一般俗称点点点

黑盒测试是一种软件测试方法,它的主要目的是检查软件的功能和性能,而不考虑软件的内部实现和代码。在黑盒测试中,测试人员不了解软件的内部结构和实现,只能根据软件的需求文档(PRD)、用户手册或其他相关文档,来设计测试用例和执行测试

在进行黑盒测试时,不需要看代码,而是直接根据需求文档编写黑盒测试用例,根据测试用例就可以进行业务测试

在IT行业不断发展过程中,白盒测试逐渐走进了我们的视野

白盒测试是一种软件测试方法,它通过检查和评估软件代码的内部结构和实现细节来测试软件的功能、安全性和稳定性。在白盒测试中,测试人员通常具有软件开发和编程的知识,可以访问代码和系统的内部结构,以检查代码是否符合规范和标准,是否遵循最佳实践和设计原则

对比黑盒测试和白盒测试的最大区别,就是测试工程师能否看到开发写的代码

白盒测试究竟该怎么做,在一直做点点点的同学心里一直是一个谜,其实白盒测试本来在工业界并没有完整的方法论标准

看过许多软件测试相关书籍以及博客,大家了解到的白盒测试理论一般局限在白盒测试的分类以及6种常用白盒测试的覆盖方法

白盒测试的分类

  • 静态分析:不需要执行程序代码,就可以进行的测试,例如:Code Review(代码走查)、静态代码扫描
  • 动态分析:需要执行程序代码,才可以进行的测试,例如:单元测试,Debug测试,打桩测试等

6种白盒测试的覆盖方法

  • 语句覆盖:每条语句至少执行一次
  • 判定覆盖:每个判定的每个分支至少执行一次
  • 条件覆盖:每个判定的每个条件应取到各种可能的值
  • 判定条件覆盖:同时满足判定覆盖条件覆盖
  • 条件组合覆盖:每个判定中各条件的每一种组合至少出现一次
  • 路径覆盖:使程序中每一条可能的路径至少执行一次

若按照覆盖严格程度来看,语句覆盖< 判定覆盖 < 条件覆盖 < 判定条件覆盖 < 条件组合覆盖 < 路径覆盖,即在这6种覆盖方法中最严格的是路径覆盖,

在这篇文章当中《互联网大厂服务端测试流程》,我对语句覆盖/判定覆盖/条件覆盖,这3种覆盖方法进行了举例探讨,感兴趣可以阅读

看到这里对于新人小白来说,可能就会产生疑问了,做好白盒测试,是不是只要达到最严格的路径覆盖就行

理论能够指导实践,我们可以根据覆盖方法进行白盒测试,但不管是黑盒还是白盒测试,测试的目的都是在有限的测试时间内,尽量发现更多的Bug,而不是追求更加严格的测试覆盖率

做好白盒测试的关键点

那么做好的白盒测试的关键点到底是什么呢,抛出一个观点就是理解代码,换句话说就是能看懂开发写的每一行代码,并定位到有问题的代码行,至于是否要达到白盒测试中的非常严格的覆盖程度是次要的

为什么会这么说,主要是因为看懂代码是发现Bug的最快方式,扫一眼就能知道这里会不会有Bug,当然想拥有这样过眼就能发现问题的能力,需要掌握扎实的计算机基础以及看过几万甚至几十万行代码

另外开发写的代码当中,有的逻辑并没有分支,所以达到语句覆盖就行,个别存在多个分支的情况可以考虑加大覆盖程度,如到达条件覆盖,但达到更高的覆盖率意味着测试时间会拉长

测试是否要去看开发的代码,是一个长久以来比较有争议的话题,持反对意见的同学认为没必要看,公司没要求,自己也看不懂,有问题直接抛给开发

但从目前测试行业来看,以及微服务架构和前后端分离的流行,互联网大厂的测试早已经划分出一种测试角色,叫服务端测试,也称SQA(Server QA),这种工种承接的日常测试工作,基本以接口测试,Code Review,以及后端代码的白盒测试为主,也是目前在测试行业里面发展相对前景较好的岗位

综上,能够看懂代码对于我们测试来说,只有好处没有任何坏处,在就业环境如此差的今天,测试能看懂代码就是一道分水岭

白盒测试举例

从看懂代码语法,再到理解代码,再到定位Bug到代码行,提供修改建议,是一个循序渐进的过程

代码究竟怎么看才能快速发现问题,应该关注哪些测试点,拿一个比较典型的接口来举例子,下面是一段伪代码,描述了一个很常见的业务场景,如果Redis缓存中有数据,则读取Redis当中的数据,没有数据则读取数据库DB里面的数据

在这里插入图片描述
如果要测试这段代码,需要检查Redis里面有数据的情况下,是否能正常从Redis当中读取数据。同理,需要检查在Redis没有数据的情况下,能否正常从MySQL当中读取数据

为了便于验证数据,我们可以使用编程语言自带的打印函数,如各大编程语言当中的print函数,PHP当中的var_dump,或者调用代码框架当中已经封装好打印日志函数
在这里插入图片描述
测试这段代码的核心关键是在于理清数据流,变量var从哪里来,接下来又会在哪些地方去使用,理清数据流同样也是白盒测试当中的关键点

留一个思考题,假设在测试过程当中,发现Redis里面有数据,但是经过Debug后发现,代码逻辑走到了读取数据库当中的数据,这个问题产生的原因是什么

结束语

在白盒测试当中,理解代码和理清数据流是做好白盒测试两个关键点,至于能够在白盒测试当中发现多少问题,取决于测试工程师对于技术的理解深度

  • 1
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Bug 挖掘机

支持洋子

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值