这些隐藏在自动化测试中的坑,千万不要中招
发布时间:2019-09-18

       这篇关于自动化测试的文章,可能和你看到的大多数自动化的文章有所不同。我不是一位专职的自动化测试工程师,没有开发过自动化的工具或者框架,用的自动化的工具也不多,也没有做过开发,所以我讲不出那些现在很多人很看重的“很深”的东西。我只想在这篇文章中,给大家分享一下我这些年实践自动化的经历,特别是那些不是那么成功的经历,希望能够给你带来一些思考和共鸣。
 

       我的自动化历程
 

       1、初次接触自动化测试 
 

       初次接触自动化测试:我发现光靠工具和热情是做不好自动化测试的。
 

       我是自动化测试的簇拥者。记得刚做测试那会,一听到“自动化测试”这个概念,就觉得好神奇,当时就把“手头的工作都自动化了”。尽管当时做得非常粗糙,这也极大的鼓励了我,我每天跑着这样的脚本乐此不疲,想象着下一步这些脚本会变得很智能。
 

       接下来,我开始向公司的自动化测试前辈(本部门、外部门)学习,自己开始搞自动化。这时我又换了个产品,新的leader当时并不赞同做自动化(现在非常能够理解他当时为什么不赞成做自动化),我很沮丧。
 

       于是我决定加班来学习脚本语言和学习使用工具。我的进展不错,但很快我就开始感到,自动化测试并不像我想象的那么美:
 

       1、一个非常简单的功能,写好再调通,花费的时间并不少。别人5分钟就能做好的事情,我要花1个小时。

       2、脚本执行时一旦发现问题,排查起来花费的时间也不少。

       3、界面、环境稍微有点变化,脚本就不能用了。

       4、由于我们的产品经常会定制,版本的分支也很多,我发现如何把这些脚本管理起来,便于在不同的测试场景下测试也是个问题。
 

       这两个问题让我有些崩溃,大家都说的自动化测试反复执行是强项,为什么到我这里就不灵了呢。
 

       我开始意识到,自动化测试不是靠一个工具,然后靠一腔热情加个班就可以完成的事情。除了工具,如何设计函数,如何检查脚本的运行结果,如何做版本管理等等每一件事情的工作量都不小,需要有策略有规划,一步步的来完成。当然,如果你只是想写几个脚本玩玩除外。
 

       2、第二次进行自动化测试 
 

       第二次,没有做好自动化的准备,盲目追求自动化率。同样以失败告终。
 

       第一次的自动化测试就这样以失败告终了。但我也成长为了一名测试基层小leader,有了些可以“做主”的小权利。我认真总结了上次的经验,我决定重新规划设计,再来做一次自动化。
 

       但当时,由于我们并没有一个标准的回归测试用例集。那些简单的边界值脚本就自然而然的都成为了回归测试用例集。后来项目压力压下来,做自动化的时间变少了,为了达到自动化率的目标,我们甚至发展到把一个测试边界的脚本,拆成多个脚本(比如上面那个例子,测试数据为0、1、5、6,本来一个脚本就可以测试完,我们却偏要写4个脚本),这样,我们“很聪明”的达到了自动化测试的目标。
 

       由此,我们自己都不不太想去运行,因为我们自己心里清楚,这样的脚本,运行不运行又有多大的意义呢。
 

       这次经历,让我对自动化测试有了新的思考:
 

       1.自动化的脚本要开发哪些内容,不应该在自动化开发的时候才来决定,而应该是事先就确定好了的。换句话说,测试用例是自动化的基础,有明确的测试用例才能保证自动化测试的内容符合预期目标。

       2.没有考虑项目进度会影响到自动化测试这个风险,也没有考虑自动化实现时会不会有什么问题或困难,就轻易承诺100%的自动化率,盲目追求自动化率,使得最后大家花精力开发出来的自动化脚本没有太大的作用。
 

       归根到底,还是没有做好自动化的准备。
 

       总结:我们在做自动化测试的时候,很容易只是盯着自动化,仅从自动化这个方面去思考,把自动化当成了一种很高级的测试,去设计自动化的框架,组织等,却忽视了自动化测试的本质——自动化测试就是一种测试执行的方式。我们在手工测试时要如何准备测试执行,自动化测试的时候也需要考虑。
 

       3、第三次自动化测试 
 

       第三次自动化测试:自动化脚本的误判。
 

       第二次测试就这样也算是失败了(反正脚本几乎是都废了)。有了这两次的失败经验,俗话说事不过三,所以我准备再来一场。
 

       这时团队的测试能力已经有了长足的提升,我们已经有了一些测试用例,为了做好自动化测试,我专门组织大家把需要自动化测试的用例筛选出来了。
 

       既然目标是回归测试,用例的筛选标准也很明确,就是那些基础的,需要手工反复执行的用例。然后,我又对这些用例逐个进行了分析,把当前的自动化测试技术暂时不能支持的用例也标记出来。告诉大家不用担心,这些用例可以下一次再执行,我们就算是要追求100%的回归测试率,也是我们真正应该执行的,并且现在可以自动化测试的那些用例。
 

       我还记得当时我们的自动化测试平台稳定性也大大加强了,正所谓天时地利人和,我对这次的自动化测试实践充满信心。
 

       但很快,脚本被一批批的开发出来后,我们很快就发现新的问题出现了——自动化脚本结果出现了误判!
 

       什么叫自动化脚本的误判呢?就是自动化脚本在自动化平台上显示的结果和真实的结果不一致。比如脚本A在自动测试报告中显示的结果为PASS,但实际的功能却有可能有问题。在自动化测试报告中显示的结果为失败,但实际可能却是受到环境的影响造成的,功能却没有问题。
 

       换句话说,我们无法相信自动化测试的结果。
 

       我们想了很多办法去解决。但我们发现,其实这些问题,归根到底就是脚本的check部分写得有问题。
 

       如果我们把自动化测试比作一个机器人。让自动化测试来模拟执行某个功能并不难,这就像是机器人的手一样。难的是机器人的“脑子”,如何让自动化脚本来聪明的确认脚本的执行结果就变得非常重要,这才是自动化测试真正的难点。
 

       首先,我们要梳理自动化check的使用规范,根据的业务的实际情况和使用的自动化工具来确定要怎样进行check才不会遗漏,来最大程度的保证自动化测试在结果检查上的准确性。
 

       对high level的自动化测试来说(对low level的自动化测试,如接口、单元测试来说,这个问题并不明显),无论是UI界面的,还是CLI(命令行)的用户接口的,都隐含了一个情况,就是自动化测试只能check到预期有的东西,却不能check到预期外的东西。
 

       以下面这个web页面为例。假如我的自动化判定的是“秒杀”,但实际“秒杀”后面却多了一些别的东西,比如多了个“:)”。在手工测试下,我们很容易发现这个问题,但自动化测试却往往测不出这个问题。
 


 

       CLI也是同样的道理。比如我想得到的是arp的回显。如果系统在给出了arp回显的同时,又打出了“this callback has not been registed”,手工测试很容易就发现了这个问题,而自动化却往往测不出:
 


 

       4、第四次自动化测试 
 

       有了前三次的失败经验,第四次自动化测试顺畅多了。
 

       其实对我的产品来说,基本功能部分的质量还是有保证的。在没有自动化测试的时候,即使是做回归测试,我们不会去测试那些很基础的用例,而会把几个功能组合起来做场景的回归测试,这样如果基本功能有问题,也可以第一时间发现。
 

       自动化后,变成了先跑这些基础的回归测试用例,通过了,再去做场景回归。无论自动化测试的结果如何,都要投入一定的人力去运行维护自动化的环境,确认结果。
 

       我想过是不是回归测试的用例写得不对,我试过将手工执行的场景自动化,但是这对high level的自动化来说特别不现实。此时我的自动化测试仿佛进入了一个僵局,我不知道现在我做的事情的意义在哪里,是该停下来还是继续走,还有关键是怎么走。
 

       那段时间看了很多自动化测试的材料,看到这个著名的金字塔
 


 

      (PS:出自Martin Fowler的博客)
 

       我感到有点释然了,我觉得这真是道出了一个自动化测试的真相:1)自动化测试也需要分层;2)UI的自动化(也就是high level)的自动化本来就做不高;
 

       这个模型虽然没有解决我的问题,但让我不再纠结。后来,自动化测试组的leader在老板的支持下,真的做到了。
 

       在老板的支持下,他把流程改了,他把自动化测试明确的放在了流程中进行考虑。我们的产品是有CLI和UI的。以前CLI和UI是功能设计后期才输出,现在改为了在需求确定后就要输出相关的设计。对CLI要输出确定的界面回显。而且一旦评审通过,不允许随便修改。如果要修改,必须要通知自动化团队。
 

       自动化团队在CLI接口设计完成后,就会立即封装自动化的函数(我们内部叫AW,action word),自动化团队基本能够在用例输出的时候就可以完成所有的AW封装。产品团队可以在用例设计完就投入脚本的编写。然后我们真的做到了用脚本来做新功能的接收测试,功能测试!
 

       由于这个自动化团队是一个拉通了所有产品的资源部门,他们还尽量考虑了AW在不同产品的复用(在AW复用之前,我们的测试用例就已经复用了),后来进化为了脚本的复用。我感到这时的自动化,才是真正可以替代手工执行的自动化,我第一次真真实实的感到了自动化测试的好处。
 

       这段经历给我的触动是巨大的。
 

       1、我感到自动化测试,不是测试单方面能够搞定的事情,需要开发的理解和配合,更需要领导的支持。

       2、自动化测试的技术不是最重要的。我从感到自动化测试是种负担,到实实在在感到自动化的作用,我们的自动化测试平台,脚本语言,脚本的编写方式都没有变化。变的只是配合方式和做这件事情的时机,也就是自动化测试的策略。

       3、如何看待权威:Martin讲的金字塔,是Martin基于他的视野提出来的,是有上下文的,忽视上下文无异于断章取义。

       4、自动化测试除了脚本,还有很多上下游相关的工作,比如用例,比如需求。
 

       至于“自动化测试真的可以提高效率吗?我觉得不行”,我觉得这是对自动化测试意义的最大的误解。那我们为什么又要做自动化测试?我认为最大的意义在于,对测试人员的能力的固化。脚本可以代表测试人员的测试方法,通过脚本就把在原来在人身上的能力,固化为组织的资产。不同的团队即使没有懂这个功能的人,也可以通过脚本来分享这种能力,这才是自动化的意义。
 

文章来源:网络  版权归原作者所有
上文内容仅作为交流使用,不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8103),我们将立即处理。

相关阅读
/