作者:测试奇谭
出处:https://gmentfault.com/a/1190000038989816
对于黑盒、白盒与灰盒测试方法的理解,几年前我在某乎做过一个概念性的回答,当时提问者询问:如何跟非技术人员解释黑盒、白盒、灰盒测试的区别?
我的回答原文如下:
既然是对非技术人员解释,就不能用专业术语。
这样说吧,有个打孔机,类似这样。
纸条从盒子左方插入,从右方出来时,分别打出圆形、正方形、三角形三个样式的孔。
某天,打出来的纸条,只有一种图形。
黑盒测试员只能说:“这个打孔机坏了!”
灰盒测试员把打孔机的盖子掀开,发现打孔机的造型原来是这样的。
于是他说:“机器仍能打孔,说明主机没坏;三个桩子也都是好的;但只打印出了圆形,可能因为连接正方形和三角形桩子的地方有问题。”
白盒测试员把机器拆开,查看内部的电线、电路、控制器等等,发现连接正方形和三角形的电线烧坏了,于是说:“原因找到了,换根电线吧。”
彼时,我还是一位测试小鸟,在研习了不少理论知识后,回答了这个问题。现在,我算不上测试老鸟,但能算个测试大鸟,在工作中,越发频繁地接触这三种测试方法。
如果你要问我哪种测试方法更好,我不置评价, 每个人的口味不一样,别人适合的不一定自己适合。
对于黑盒测试方法来说,是每一位测试的必备技术,没有谁不会:发现问题,抛出问题。
简单、轻松、快速,是黑盒测试的优点,特别是在项目特别赶,测试时间无限被压缩的时候——只需要抛给开发问题,剩下的让开发自个儿玩去吧。
但黑盒测试人员常常被人诟病只知道点点点,抛开此类“鄙视”不谈,接着上面继续,我们是不是忽略了一个事实:项目既然赶,那开发的时间亦不充足,如果恰好遇上稍稍复杂的bug,并搭配不靠谱的开发,一个bug的生命周期可能会拉得极长,效率特别低下。
这么说,那用白盒测试方法呗,看代码,查原因,丢给开发后,留下一个高大帅气的背影,让开发心里默念——这个测试不简单。
白盒测试可以,但使用它时,你需要盘算盘算:
是否有充足的时间研究代码以及和代码相关的环境部署、配置设置等?付出和产出是否成正比,如同自动化测试,能达到高性价比吗?白盒是一种选择,但同样是一个难题。更别说白盒对于测试技术的高要求。
废话了这么多,你一定会说:风风,你不就是拐弯抹角地推荐灰盒测试嘛。
我不知道该怎么回答你,就像刚开始说的, 每个人的口味不一样,适合自己的测试方法,最醇最香。
但说实话,日常工作中我使用灰盒测试方法的场景相对较多,总结来说,就这么一个流程:
发现问题-->我大概知道你是怎么玩的-->初步定位问题原因-->同开发确定问题-->接下来呢?
会分成两类:
1、我定位的原因并不是真正的原因。但我能通过这个过程学习到新知识、新业务,积攒个人经验(很多人往往弃步于此)
2、我定位的问题是真正的原因。就此打住吗?并不是。你能提出问题的解决建议吗?你的建议是否比开发的修改 or 产品给的方案更好,更具有可实施性?
合理地提出解决问题的建议,这才是你关注的重点,而不是因为找到问题原因而沾沾自喜,迷失于他人的赞许中。
作者:测试奇谭
出处:https://gmentfault.com/a/1190000038989816
本文发布于:2023-02-28 19:59:00,感谢您对本站的认可!
本文链接:https://www.wtabcd.cn/zhishi/a/167764780175874.html
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
本文word下载地址:白盒测试和黑盒测试(白盒测试和黑盒测试的概念).doc
本文 PDF 下载地址:白盒测试和黑盒测试(白盒测试和黑盒测试的概念).pdf
留言与评论(共有 0 条评论) |