无力吐槽的自动化现状及自我感受

来源：51testing

前言

　　从2017年6月开始接触自动化至今，已经有2年多了，从17年接触UI自动化（unittest+selenium）到18年接触接口自动化（unittest+requests）再到18年自己编写自动化平台（后台使用python的flask，前端使用element+vue，没有第三方自动化框架），不断的学习成长，加深了对自动化测试的理解，这边就总结下自己对自动化测试的认识。

　　首先，吐槽一下很多实际自动化经验不到1年的而且停留在靠度娘抄袭demo的甚至度娘抄袭的代码都不知道问题出在哪的小白（大神忽略，本人小白，只是吐槽一下行业现状），相信很多人从度娘上抄袭个uniitest（下文简称ut）,pytest,testNG甚至是RF（robotframework）就说自己熟练使用自动化了，你们真的了解自动化么？笔者使用的是python语言（不鄙视其他语言，任何语言都可以做自动化，只要你有能力），现在随便找几个python自动化相关的问题问一下，很多是企业真实实战会遇到的场景或者企业领导的需求，也包含笔者面试的口述和手写题。

　　先来些个基础的问题，18年1月辞职面的UI自动化面试题，笔者使用ut+se，面试官的问题如下（注：不写答案，伸手党请自行百度或查询资料，这些基础问题丢群里问是会被人鄙视的。后面的内容可能很多人会玻璃心或者感到不适，如果感到不适，请自觉关闭本页面，喷子请绕道，没有必要和你争论）：

　　Q1：

　　请说出selenium常用的八大定位法。

　　Q2：

　　请描述Selenium的xpath的结构。

　　Q3：

　　请说明为什么不推荐使用xpath？

　　Q4：

　　当使用xpath无法定位到一个元素时，可能的情况有哪些？

　　注：前4个问题只是问个基础，最最基础的问题，如果前4个都回答不了，直接下一位，Q5开始的问题，是确定你有基础了，开始往深一点的问，确定你对自动化的了解程度。

正文

　　现在我们正式开始提问：

　　Q5：

　　你说你使用过ut，请描述一下ut加载用例为什么以test_开头。（此考验你对自动化框架的熟悉程度，某些领导就问你，测试用例为什么都是以test 开头的？你：这是这个框架的设计。 领导：不行，必须改成以我们公司名称的缩写开头。你：？？？？？ 领导：你明天不用来了。）

　　Q6：

　　ut执行用例的顺序是以什么规则执行的？

　　等等，什么？这就难了？这才刚起步歪 ~ ~ ~ 我天。。。整天说自己熟练甚至精通自动化的，连自动化框架原理都不知道？你好意思说你自己精通自动化？要是让你二次开发自动化框架，优化执行效率之类的，你是不是得上天？你来面的是自动化工程师岗位，不是黑盒点点点岗位歪 ~ ~ ~ （有人说钱不到位，你能力都不够，我怎么给你钱？不要把顺序搞返了，阿里P7的岗位，给你一年100万的总包，你能做的了P7做的事么？道理就是这样，先有能力，才有谈判的资本。ut虽然在一线鄙视链，但是我在度娘上看到过一个帖子，改ut源码，把执行效率提升了几十倍，你有那能力不？）

　　Ok，能看到这里的基本上也可以确定你不是玻璃心或者喷子了，现在我讲述一下我今年7月面试的几个岗位，这些岗位是真实要求你能做起自动化的，坐标杭州，起薪15K，7月面试5天，由于学历限制以及能力不足，总收获offer8个，岗位的面试题如下：

　　Q7：

　　你在上一家公司维护过多少自动化测试用例（看你简历上写的UI/API/APP任意一个）。小于100的基本上上不了场面，如果后面的问题回答不上来，你的定级就是初级自动化了。

　　Q8：

　　自动化用例，你们全用例执行一次需要多少时间（考验你框架设计时是否考虑到执行效率问题）？用例之间的关联怎么解决？调试单个用例或者选择某几个用例执行你是怎么进行的？数量100以内的测试用例，如果用例维护量翻5倍（100以上double或者3倍），你有什么方案优化执行时间和效率？

　　Q9：

　　如果被测试环境迁移了（例子：从本地环境迁移到阿里云机了），你用例是否要大量修改测试数据。（易维护性）

　　Q10：

　　编程语言问题：

　　Java一般问一些线程安全，数据类型的区别，设计模式等等问题，笔者是python，故只写python常问的问题：

　　Python列表和元组除了可变不可变以外的区别？

　　Python列表和字典的区别？

　　Python生成器和迭代器的区别？

　　请描述多线程，多进程，协程其中之一的工作原理。（后续追问一个三者的区别，主要是想听听你对这三者的优缺点的了解程度）

　　请描述Python的垃圾回收机制以及内存管理

　　Q11:

数据库相关问题（太泛，从基础理论到手写语句，不写了）：

　　多刷度娘，多看基础就是了。

　　Q12:

Linux基操

　　Q13:

　　网络相关(http/https)

　　Q14:

　　对接CI、CD，CI同时调用2个甚至多个环境的用例，用例数据会不会错乱。

　　Q15:

　　团队问题，这里重点描述一下，入职的岗位除了大厂高级自动化工程师以外，都要求带黑盒组一起进行自动化，所以团队问题会被着重提问：

　　编写用例的复杂程度？即一个用例需要多少行代码？（其实听到你回答多少行代码的时候，你已经降了一级，面试官更想要的是一个不懂代码的小黑盒也能轻松上手。）

　　组内用例的同步问题，如果N个组员同时编写自动化用例，组员间的用例同步问题怎么解决。

　　如果使用你的自动化，组员需要具备哪些能力和知识？如果要维护你的自动化，维护人员又要具备什么能力？（主要是看你的自动化是否简单易维护，面试官要的是哪怕你人走了，你的代码依然能稳定运行，维护也尽可能简单，而不是你一走，自动化就废了，这样的自动化毫无意义，你面试的成功率也会大大降低，稳定和易维护，至少得满足一个条件。）

　　以上，就是笔者7月面试的问题，看完这些问题，你真的还了解自动化么？有甚者甚至与笔者争论过使用工具做自动化，例如postman/jmeter，诚然，都可以做，笔者只有一个问题，你维护过下一家公司别人做的工具自动化么？没有的话，先去维护一次，体验一下什么叫一个头三个大的感觉，工具始终只是一个工具，笔者混迹在一些测试群里，每个月都能收到N个小白问这些工具要对数据进行md5/rsa加密，要base64编码解码，要怎么做？笔者只能说一句，自己写代码，随后会遭到不少小白怒喷“我要是会写代码，我还用毛线工具”，笔者：呵呵。还有小白还在问，jme数据关联怎么做？jme正则提取token怎么提取？连自己解决问题的能力都没有，更不用谈自动化了。

　下面笔者讲述一下笔者自己对于自动化的想法和感受：

　　1、UI自动化在很多小公司用于简单的回归是可以的，简单的回归其实单纯写几个小脚本，和你用什么po+ut+关键字驱动之类的，成本上没有多大区别，真正需要UI自动化的公司，起步也得有几百人上千人，且满足需要自动化的部分已经足够稳定的场景，这种规模的自动化，大多数人涉及不到，维护成本高，受环境影响因素大也是很多公司放弃UI自动化的原因，大环境因素上，UI自动化已经开始被AI自动化和图片识别自动化代替了，各大厂内部已经开始流行AI自动化和基于图片识别的自动化，例如网易开源的airtest，只需要截图即可生成自动化用例，脚本的维护也越来越简单。

　　2、App自动化和UI自动化差不多，app比ui多一个兼容问题（混合开发），维护同样非常复杂，单纯的selenium，appium，ua2实现自动化，要解决的问题非常多。

　　3、现在很多中小公司流行接口自动化，以及接口测试左移（在接口文档出来之后，后端开发完成之前，搭建mockserver，实现前端联调）接口自动化的执行速度快，回归效率高，是目前中小公司主流的喜爱。但是接口测试要想做好，对返回结果的断言是个非常高的要求，设计人员的能力和知识决定了断言的健壮性，对于设计人员的能力要求相对较高。

　　4、大厂目前主要流行的是拨测、图形识别、AI，拨测即录制和回放（很多小白看到这估计笑了，这不是早就被淘汰了么，笔者：呵呵，此操作非彼操作），笔者大概了解过阿里的doom系统（没有仔细研究，能力有限，说的不对的请忽略），通过中间件录制线上的流量数据储存起来，在被测试环境进行重放操作，以验证本次修改是否对线上数据产生影响，这中间涉及非常多的技术实现。图像识别可以参考airtest，AI测试目前几乎没有流出，测试之家里有一些理论文章可以参考。

　　5、性能自动化就不写了，笔者的能力有限，连性能测试都不敢说会更何况性能自动化。（要是会个工具随便打个压就算会的，当我没说，打个压看个报告啥的还是轻松的，代码写个性能脚本问题也不大，性能测试的精髓在于分析瓶颈、系统调优。）

　　写在最后，17年UI自动化刚兴起的时候，会个自动化脚本能评级到中级工程师，18年中级自动化需要自带框架了，到了19年，会个自动化脚本连初级都算不上，，用第三方框架的基本上要有成熟的方案了，19年的薪资高一点的测开岗位都要你会写测试平台了，19年测试平台已经开始流行了，技术行业，更新就是这么快，不学习，不进取，仅靠度娘那点基础的教程，在20年21年22年只会越来越难走，年纪越来越大，能力却没年轻的强，竞争力越来越弱，才是你跳槽涨薪的绊脚石，总有一些工作年限久的人，自以为自己经验老道而对工作年限低的人嗤之以鼻，笔者面过一个8年工作经验的人，只有一个总结，他的8年经验，只是在重复他第一年的事，只不过做的更熟练了一点，但是他又没能把第一年做的黑盒做到很好，这是很多老油条的常事，笔者只能送一句，要么把黑盒做好，要么发展自己的能力，大中华的行业情况就是如此，往后N年，好自为之。

星云测试

http://www.teststars.cc

奇林软件

http://www.kylinpet.com

联合通测

http://www.quicktesting.net