自动化测试能否帮助我们我们提升开发效率,关键在于其有效性 。如果其有效性可能存在问题,那么可能是什么导致了这种问题的产生呢?对自动化测试产生作用的方式存在误解,对自动化测试能够产生作用所要求的条件存在误解,自动化测试分析设计的随意性,自动化测试开发维护的低标准,对自动化测试资产的低准出条件……本文将就自动化测试有效性简单阐述我自己的一点见解,抛砖引玉 。
观念之一:独木难生于漠,密植方育甘霖
沙漠中间栽下一棵树,枯死只是迟早之事;即便有足够的资源让它能够永久地生存下去,而它除了给路过的摄影师的构图上增添一分绿色气息,便再也没有其它存在的意义了 。如果要想它能够长久而有生命力地活下去,并期望它能够改善生态,那就需要将其根植在一片密林之中 。自动化测试,尤其是前端自动化测试,如若离开其他层次的自动化测试和技术手段与之相互配合,便会如同这棵沙漠中间的树一样,不久便灭 。
【迁移文章槽神也说自动化测试有效性】五一节后的周五下午和两个开发经理一起一个项目的性能测试需求,休息闲聊时顺道提到了其中一位开发经理所负责的公网系统CI连续飘红的问题 。他坦言自己对自动化测试是不信任的,认为自动化测试发现不了任何问题,从而对CI带来的帮助表示怀疑,因此不愿意在CI上投入过多的精力 。我理解这位经理的感慨,认同他对自动化测试有效性的担忧,但是这并不能使我认同他对CI和自动化测试的态度 。而对于软件开发来说,没有自动化测试、没有CI,我们可能无法期待更高效率的开发和更好的质量保证 。但他这是因为没有耐心地植下一片树林,才导致他心目中自动化测试这棵大树的死亡,进而却又否认这片树林存在的意义,是不妥的 。
观念之二:降低期望于心,提升目标于行
为什么有很多人对自动化测试的可信任程度表示怀疑呢?这源于一句看似真理的废话:自动化不是用来发现缺陷的,而是为了验证系统改动是否造成关联影响并用以增加质量信心的 。这话本意无非就是想告诉大家:不要对自动化测试的结果抱太高期望,对机器智能和人脑的差距要认清 。这个本意本无可厚非,但是这句话现在却逐渐成了自动化测试低质量的借口了 。
首先,很多人认为自动化测试无法发现缺陷是因为测试脚本无法代替人类的自主思考,无法灵活变通 。而我们之所以期望在测试执行时能够灵活变通,是因为测试分析设计时对被测应用设计细节的不确定性 。非探索式的脚本化测试设计就是要通过输入精确的操作和数据类型,从而得到精确的输出来和预期结果进行对比,在这种模式下,没什么问题是需要变通才能被发现的 。
其次,不得不说自动化测试分析设计的难点在于对输入条件分支和状态机组合的穷举和选择上,这需要很大的成本 。不幸的是,通常在做自动化测试分析设计时,我们习惯于用经验和主观感觉去做,不全面和主次不分的情况常常出现 。因而,自动化测试分析和设计的不严谨、不完整也是自动化测试不能被信任的原因之一 。
此外,自动化在那些已覆盖的测试上面表现的也不尽如人意,笔者观察到,大多数人并不是用自动化测试脚本去做测试或质量守护工作,而只是用来让他们运行通过,以获得KPI的达成和成就感 。自动化测试运行失败,不习惯于或不乐于使用它的同事就会很轻易忽略潜在的问题,所以漏测和封版延期是常有的事 。
最后打个比方,自动化测试就像是看门的狗,没有它,家里进贼未必发现不了,关键是发现的时候是否还来得及挽回损失,而狗狗能不能在有贼光顾的时候示警,取决于我们如何驯养它 。我们期望家里进贼的时候狗狗能够示警,但并不会期望它能够帮我们直接把小贼擒住;而且并非每次狗狗示警都意味着有贼入室,也有可能是阁下经过而已 。自动化测试与此类似,凡其所致,但有一点不一致便会得到失败的结果,而至于是不是发现了虫子却又是另外一码事,想用自动化帮你解决所有问题,那你还是洗洗睡吧 。
- 邮箱邮件服务器迁移服务器要多久生效,将设置从电子邮件路由器迁移到服务器端同步
- 贵阳甲秀楼简介
- 但是实际上端口并未被占用 一篇文章带你解决代理提示端口被占用
- 使用Docsify开启个人博客之旅
- 程序员的健康要重视起来了
- Dockerfile构建docker时apt
- 爬虫的风险
- 依靠积极因素克服消极因素又叫
- 得抑郁症有哪些情况?
- 六味地黄丸是什么