自动化测试为何被诟病?

当前位置: 首页 > 新闻动态 > 公司新闻

从一些渠道获知,某些公司的自动化测试成为领导所诟病的对象。之所以被诟病,原因大概有如下几点:

这些公司雇佣了数百人的外包来专门写作/调试自动化测试脚本;外包团队规模庞大;

发现的所有版本缺陷中,自动化测试发现的问题所在的比例太低;

简而言之,就是自动化测试的投资收益不符合预期。

但是,自动化测试又不得不做。否则以手工的方式来反复执行海量测试用例,这个成本是不可接受的。那改进自动化测试工作本身的效率,就成了一项很急迫的任务。

有人开出了如下的药方:

智能的生成测试脚本。编写和调试自动化脚本的门槛不是挺高的吗?如果做一个工具,能够自动的生成测试脚本,那门槛不就降低了?

智能的制定测试策略、选择测试用例脚本。

智能的分析测试报告。现在自动化运行结束之后分析执行报告的工作量不是很大吗?那做个工具来自动的分析执行结果,如果工具确定是产品问题,那就自动的提交问题单。

看 ,工具又成了一个背锅侠。并且我们总是很快的找到了问题的解决之道,那就是不断的改进工具,不断的做出新的工具。尤其是在阿尔法狗取得骄人战绩的今天,人工智能也成了我们挂在嘴边的热词,哪个工具不粘上点智能的边,都不好意思拿出去和别人打招呼。

但,这些措施真的能够解决自动化测试所面临的问题吗?

我认为,以上措施根本就没有触及问题的核心。单纯谈工具,不仅不能解决当前自动化测试的问题,还会让效率更加的低下。

以智能/自动生成脚本为例。我知道该公司当前的自动化测试,是基于 Ruby 脚本的所谓的“第三代自动化测试体系”,也就是说,用例脚本与底层支撑脚本是分层的,归属不同的责任人来编写和维护;测试用例设计者只需要用所谓的 ActionWord 就可以写出逻辑清晰且结构简单的脚本;而自动化工程师则负责实现和维护 ActionWord,也就是我们俗称的支撑库。

测试脚本和 ActionWord 都是用 ruby 写成,我认为,一个合格的测试工程师,掌握好简单的 Ruby 语法,并且使用封装好的 ActionWord 来写出测试脚本,是理所当然的必备技能。Ruby 相比 C/C++,要简单不知哪儿去了,但是即使如此简单的语言,居然成了“极高的门槛”,成为编写脚本的“障碍”?这实在难理解。如果这就是极高门槛,那些用 C/C++ 做产品开发的开发人员,岂不都上天了?

现在一些公司的做法是,测试工程师专门负责设计用例,然后交给外包团队来将这些用例再翻译成测试脚本,这样的做法,效率不低下才怪。正确的姿势是:测试工程师自己就将测试脚本交付出来。对于那些全栈工程师而言,最正确的姿势是:开发人员自己就动手将测试脚本写出来。根据我对微软的了解,微软的 Visual Studio 团队,就是这么做的,他们根本就不区分开发和测试。

再说说,“智能的生成测试脚本”真的可行吗?

首先我要明确一个观点,使用所谓的 DSL (Domain special Language) 来描述测试用例,同时这个用例又可以被直接执行,这种做法和“智能生成测试脚本”是不沾边的。其本质上,仍然是基于 ActionWord 的脚本描述。当前我们基于 Ruby 的 TDL 体系,以及 Ruby 自带的 rspec 等,都是属于这种 DSL 描述的用例脚本。这种做法,并没有绕过学习某种语法的所谓“门槛”。该掌握的 Actionword 以及其参数格式等知识,一个都省不了。

其次,怎样才算智能生成?我有一个标准,将测试需求描述文档扔给这个工具,然后这个工具就输出了高质量的可执行测试脚本,做到这一点,才算是做到了“智能生成测试脚本”,达不到这个标准的“智能或者自动生成”方案,都是忽悠领导的做法。

最后,有可能我们拿出“模型生成脚本”重新包装一下,然后对外宣称:这就是我们革命性的“智能生成用例脚本”技术,有了它,测试人员以后再也不用学习脚本语法了,只要画画图、拖放一下节点、连连线,画个模型出来就可以自动生成脚本了。画模型来生成代码这种搞法具有极其悠久的历史,上个世纪九十年代就出现了,可惜这么多年了,除了传说中的波音、洛克希德马丁似乎在用这种东西之外,我就从来没有见过软件行业的巨头们的哪个产品的代码,是画好模型后自动生成的,也许我孤陋寡闻,如果您知道,请一定告诉我。

测试脚本就是一个简单的程序,对于程序,一行行的字符组成的代码,才是最简单、最清晰、最直观的终极表达形式。代码语言从低级到高级在不断发展,层次越来越 High,描述能力越来越强,现在新语言也层出不穷,但是,代码行这种形式是不变的。模型图现在不会,将来也不会出现在语言的发展趋势的主线上。模型图对于描述系统架构、逻辑过程等是在行的,但是在描述具体的代码执行过程上,是不在行的。这一点,历史已经帮我们做出了选择。画模型图,并不能节约工作量和降低门槛,相反还是一个坑,根因在于,它把简单的事情给复杂化了。

提升脚本开发 IDE 的易用性,是更加可取的道路,比如更好的参数提示、及时的帮助信息获取,及时的错误提示和重构提示等。参考 Excel 中公式输入的做法:

还有“智能分析执行结果”的做法,为什么现在分析执行结果的工作量很大,有两个主要原因:第一、因为脚本质量差,执行结束之后,有大量的报错不是因为是产品 bug,而是因为脚本本身的错误,根本解决办法是提高脚本本身的质量。第二,就是产品规格或者接口发生了变更,但是脚本却没有做同步的更改。从管理手段上来提升脚本质量,才是最终解决之道,要达到的理想的情况就是,脚本报错了,那就是被测试系统出了 bug。

动化测试本身就是一套的软件系统,软件的本质特征是其复杂性,这也是 Brooks 在人月神话里面反复强调的。自动化脚本,尤其不能搞的太复杂,这也是我们选择脚本来做自动化的原因。如果因为自动化的效率出了些问题,就要做更多的更复杂的工具,那只会让自动化测试越来越复杂,最终受损的还是效率。

应该从哪些角度来解决自动化测试的问题?工具当然有不断改进的空间,但是,自动化的效率当前之所以被诟病,本质还是疏于管理所导致。应该从如下几个方面来着手:

一方面,加强对外包的管理。这两年很多 IT 公司对外包放得太开,各公司敞开了搞外包,在成本和收益方面没有进行精细的控制,结果就弄成了现在的局面。

另一方面,提高测试人员的技能和输出效率,提升对测试人员的技能要求。若干年前,我们都是测试人员自己写脚本,不知什么时候起,这个要求就越来越低了。测试设计人员就应该自己动手来写自动化脚本,将那些专门负责将用例翻译成脚本/调试/归档的合作人员都裁掉。业界有一句话:高级的程序员都是以一当十,这样的程序员都是具备扎实全面的技术功底和编程技能,能够熟练掌握各类工具。我们的测试工程师为何就不能做到以一当十?连写测试脚本这样的事情不能掌握,或者没时间去写,那还能宣称自己是“海盗派”?

最后,也是最重要的,加强自动化本身的质量控制和系统维护。自动化测试体系,就好比一套高铁系统,乘客看到的就是日行千里,但是我们知道每天夜晚有多少人在进行线路检修、动车养护吗?对于自动化测试而言,提高脚本的质量(可移植性、容错性、可维护性、可读性)至关重要,同时,还得降低脚本的数量。我们现在的自动化有一个不好的苗头,就是为了防止漏测,自动化脚本库总是在不断的做加法,导致脚本数量庞大。为自动化脚本建立老化和退出机制也是提高效率的一个重要方面。

自动化测试就和农民伯伯种地一样,如果疏于管理,那就必然会杂草丛生;即便是全机械化耕种的年代,田间管理也是不可或缺的。想搞种一劳永逸的智能化系统,那要么是浮躁和天真,要么就是在忽悠领导。