程序员自己写测试,还要测试人员做什么?

2021-02-21    分类: 网站建设

在向开发人员介绍单元测试或TDD等工程实践时,往往可以听到这样的疑问。比如:

自己写的程序,自己无法从另一个角度测出问题。

写bug的时间都不够了,哪有时间来写测试?

开发来写测试了,测试干什么?

除了核心代码,没有什么值得测试的。

……

本篇想要通过探讨这些问题背后的困难,来说明程序员怎样通过编写自测代码更有效率的进行开发。

一个例子

首先我们看一个例子。



全项目唯一的测试

不止一次,我在各种项目中看到这样的测试,往往这也是整个工程中唯一一个测试。

可以看出,开发者认为编写是有必要的。所以按照“标准”的做法建立了测试目录,引入JUnit依赖。并且利用它在开发的初期来验证某些技术疑问,一般是某些当时还不熟悉的第三方库,或者数据库、中间件等外部依赖。

项目初期技术调研阶段很快过去后,似乎没有更多需要验证的问题。因而也就再没有需要编写测试的地方。

简单而言:“写测试是应该,但我们的代码没什么好测的”

测试,不仅仅关于未知

说起测试,往往与未知相关联。我们通过测试、调试、检测来获取反馈,不断调整。



以上图为例,一般想到的测试,都集中在“已知的未知”这个象限。正如前面的示例代码,使用不熟悉的库带来未知。程序员通过在测试中调用和观察结果来消除未知。

然而,对于自动化测试来说,其实关注点在于已知。

“都已知了,还测试什么呀?”,也许你会有这样的疑问。

火柴问题



火柴,这种行将消失的物品。也许现在的小朋友只是在《卖火柴的小女孩》中才得知它的存在。在我小时候,还是时常用到的。那时,也许是工艺问题,或者存储条件有限,往往一盒火柴好多根都不能点着。记的那时听到的笑话:

小明的妈妈让他去买盒火柴,不一会功夫买回来了。妈妈问:“你试过没有,能点着吗?”

“试过啦”,小明很骄傲的说,“每一根我都试了一遍。”

我把这种问题称为“火柴问题”,往往传统的质量控制面临的都是这类问题,有如下限制:

•成本,显然现实中不会有人把所有的火柴拿来测试。不过问题的本质并没有变,在花费的成本和获得安全性之间取一个平衡。

•事后,造出火柴后才有能否点着的问题。

•一次性,成本换取的安全是一次性的,每当一个批次到来时,以前的测试的付出都成为了沉没成本。

另一种测试

让我们来看另一种关于已知的测试。



Checklist

检查清单。

比如每天出门的时候,我都会自然而然的检查一遍,手机、钥匙、钱包。就是个简单的清单。

清单是关于已知的,只有十分确定的事项才会列入在清单里。

清单本身很简单,并不能回答火柴问题这样的难题。但是不代表它没有作用。以出门为例子,有时出门是每天都在做的上班通勤,有时是去面临某个很大的未知,比如去见一个陌生的客户,进行重要谈判。

这时如果有个水晶球,告诉你会成功失败,甚至告诉你怎样做才能成功,那就太好了。

然而没有水晶球。

一个简单的清单至少保证你不会走在路上才发现忘带手机。无论未知的挑战是什么,忘带手机基本上不会产生任何帮助。

切换回软件开发的场景,程序员梦想中的好测试也许能告诉我们未知,甚至未知的未知结果。这在目前还不现实。那么写一个测试确保你在不断调整中不破坏正确的事情,仍是值得的。

可以看到,这种视角下的验证,与检查火柴有所不同:

•预防,这种校验着眼于未来,是为了避免更大的损失的投入。

•过程中,检查是做事情步骤中的一个环节。

•反复,越频繁的行为越有必要进行校验,校验的越频繁潜在收益越大。

假定你是独自居住,出门前还是锁门后发现没带钥匙的成本,会有一个巨大的飙升。往往检查列表都是在这种成本拐点前进行的。

网站栏目:程序员自己写测试,还要测试人员做什么?
地址分享:https://www.cdcxhl.com/news/102236.html

成都网站建设公司_创新互联,为您提供自适应网站网站内链微信公众号网站策划做网站服务器托管

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联

手机网站建设