一、自动化测试落地状况
如果让两个相互不认识的、来自于不同公司的测试工程师自由讨论，我猜他俩寒暄的第一个问题会是：你们公司的自动化是怎么做的？
如果你去问一个来自于大厂的质量部门的测试架构师：你家的测试平台有什么功能？你能听各种天花乱坠的功能、自动化能力，让你叹为观止。
而同时让你去问该厂的某个业务测试工程师：你们的自动化测试做的怎么样？对方很有可能会告诉你：啥？自动化？哪有什么自动化！
很有意思的现象，是吧？今天我不谈怎么写代码了，来聊个在绝大多数公司都存在的、而且很可能不愿意被外人知晓的问题：为什么我们公司/产品/项目的自动化测试做不起来？
上面提到的自动化测试做不起来，本质上就是自动化测试体系难以落地，那怎么才叫落地呢，以我的经验来看，需要同时具备以下四点：
1、有统一的测试框架、平台
2、有基本的CI、CD流程，具备自动、定时触发执行的能力
3、自动化测试用例覆盖度高，能切实有效地帮助测试人员回归，明显地提高测试效率
4、测试、开发人员认同自动化测试执行的结果
难吗？感觉要求其实并不高，但你跟同行去聊聊的话，你会发现要完成这四点是件不容易的的事情。
下面我尝试从测试人员、研发体系（公司）维度来剖析下，来讲讲为什么难，为什么自动化测试体系落地这么困难。
二、测试工程师
2.1 编码能力是稀缺技能
中国软件测试起步比较晚，测试工程师这个职业很有可能是伴随着“软件外包”兴起的（请勿考古）。
早期的测试工程师清一色地做着功能（手工）测试，不需要有编码能力，甚至觉得不用会编码是理所应当的。（2019年我校招时发现还有这样的论调）
之后逐渐出现了能用QTP或者Rational Robot做自动化的人，这些人几乎站在了那时测试职业食物链的顶端，睥睨群雄。
我还记得，十几年前读大学那会，我在一家软件公司实习的时候，当时的主管向我介绍QTP，一脸的崇拜的样子。
那时能应用QTP主要依赖它强大的录制、回放能力，大部分人自动化测试依然不需要会写代码，能简单修改简单生成的vbs即可。
测试人员逐渐接受编码技能，应该是从web2.0概念盛行后，大量的项目需要使用开源的selenium、watir进行自动化测试，自动化测试的需求越来越旺盛，一些有好奇心的测试人员开始学习编码做自动化测试，也有部分开发人员选择转行做专职的自动化测试。
不过十年过去了，时至今日，编码能力依然是普通测试工程师的稀缺技能：目前软件测试从业人员中，还是有非常大比例的纯功能测试，虽然他们大部分都想学一门编程语言，但是大多就是停留在想学的程度，所付出的努力并没有带来实质的改变。
现如今的自动化测试技术栈，不管是接口、web、移动端，绝大多数都是基于开源项目来构建，不再有QTP那样 的录制回放能力，没有编码能力自然无法实施自动化测试。
2.2 找不到切入点
当测试工程师掌握编码能力后下场写自动化测试了，会面临下一个问题：我该怎么从头开始做自动化？
困惑于不知道选什么样的测试框架、工具，困惑于不知道从接口、Web、移动端哪一层入手。简言之，找不到切入点。
2.2.1 框架选型
先提一个很不好的现象：很多测试人员学习编码是从学习测试框架切入的，比如selenium、appium，他们所具备的编码能力只局限于这些框架API；而不是先学习编程语言、再学习测试类库这样的路径。
所以这样来，测试人员大多只能从自己熟悉的框架着手，而不能全盘考虑各类框架优劣势：
做web自动化，只能想到Selenium
做移动端，大概率会选appium
做接口，postman、jmeter
所以这样来，其实也不存在框架选型的困扰：技能点就点了一下，没得选。
2.2.2 分层选型
然后是测试分层，其实测试分层是个比较大的话题，单元、集成、接口、UI都可以切入。大部分测试文章都推崇金字塔分层模型，一张经典的图：
在你具备足够的能力下，我当然建议你把自动化测试下沉到底层去，实现更高的ROI。
不过我觉得金字塔分层模型过于理想化，单元测试的难度也不小，在微服务架构下，我更推崇的是橄榄球分层模型，即尽可能接口测试先行：
2.3 重视框架、平台开发，不重用例覆盖率
再来说一个怪像：如果你留意下一些测试社区，里面有非常多讨论开发测试框架、平台的帖子，也会有很多分享自造轮子的帖子，但如果你想找一些自动化用例设计的帖子，却发现非常的少。
我面试过很多写过测试平台的候选人，这样的面试里我很喜欢问：你的平台上有多少用例？测试覆盖率怎么样？这个时候大部分人就卡壳了，有些支支吾吾说不上来，有些能说上来，只是自动化用例的数量比较少，几十、一两百，整体的测试覆盖率非常低。
似乎大多数测试开发工程师的心态是：我能写代码我厉害，测试框架、平台信手拈来，至于填充用例这种体力活跟我没关系。
殊不知，自动化测试体系的核心资产绝对是测试用例，而不是那些烂代码堆砌出来的测试框架、平台。
2.4 用例代码Bug比项目Bug还多
这又是一个让测试工程师很尴尬的事情，因为代码功底问题，有时候一个简单的用例几行代码里能出一堆Bug，结果测试结果完全没有可信度。
不要不信，我抛一个简单的问题：如果一个分页查询接口，它的响应报文中total字段表示匹配记录总数，data字段值是一个数组，返回当前页匹配记录条数，你会怎么校验total的值的正确性？
对于这种情况，也没什么太多可说的，不断去强化你的代码能力，而且心态上有改变：不要觉得自己是会写代码的测试，觉得比功能测试强；当你在写代码了， 应该像开发一样要求自己，要求自己的代码。
不仅去学测试框架，更要去学数据结构、设计模式、数据库、中间件…另外，在开发测试用例时，严格遵守FIRST原则：
严格遵守FIRST原则
2.5 自动化测试用例缺少有效维护
在完成自动化测试用例的早期积累后，你也把用例执行整合进一些CI系统中了，开始进入收获季节了，享受自动化测试带来的测试效率提升的红利了。
在这个时候千万不要觉得自动化测试落地成功了，这个时候很像在魔兽世界里把一个职业练到60级，你不是走到了终点，而是终于跨进了真实世界的大门了。
产品、功能每个版本都发生着变化，自动化用例的期望值也随之变化，如果不能及时、有效跟进这些变化，无效用例就像滚雪球越滚越大，让你无法维护。
