这是CC的第112篇原创。
最近在社区里做了一个关于自动化的调研，大部分同学认为自动化最大的价值在面试或者是KPI上。
为什么会出现这样的情况？我认为几个原因。
1.国内敏捷迭代的速度很快，时间有限。
- 并没有想清楚自动化能解决的问题是什么，管理者认为别人有的我们必须得也有，很多自动化case甚至是测试完成为了kpi补上的；
- 执行者为了kpi赶鸭子上架；事实上并没有时间做真正的自动化测试的设计和思考。
2.测试人员技能单一
以前是不会写自动化的很多，现在大家都知道多少要写了，哪怕去培训，上手python，pytest也不是啥难事；
可是吧，架不住代码能力有点稀烂，花了好久写的测试代码，自己写的bug比发现研发的bug还多。出了问题心虚，先看看是不是自己写的case出错，本来是想提高效率来着，结果等于测两个系统的bug。
3.组织上的割裂
几年前自动化测试，业务测试门儿拎的很清，功能的做功能，自动化的做自动化；自动化测试不是特别了解业务做的很表皮，有的甚至只校验到状态码或者类似于只检查success这样的关键字就结束，虽然运行起来很嗨，但这种方式做自动化可以说是极其粗浅了。你指望这样的自动化有什么价值是不太可能。这样的组织也算是几年前特有的模式了，目前的互联网公司，不做业务区去纯写自动化case的情况已经极少了。
4.认知误区
- 有了自动化测试就可以替代手工测试
认为自动化测试是万能的，从测试设计到场景以及结果分析都可以自动化完成，一揽子自动化测试方案，之后就可以减少测试人员的数量，这是管理者的思维，降本嘛。
事实上自动化测试在刚开始实施不会减啥工作量，你需要去设计，编码，运行，适用等。但这个是逐步减少重复劳动的过程，在后续的测试工作中增加对于测试设计的思考时间；至少在这个环节中，我认为本质上并不是为了是取代人力，而是为了工作结构更好的优化。
- 自动化测试为什么发现不了很多bug
自动化的特性是为了提高效率，可以用于回归测试场景，那提高效率了干什么呢？
这个问题跟上一问一脉相承，最终减少重复劳动，是为了有更多的时间去设计异常场景以及复杂场景。还是为了整体交付发现更多bug去提升质量，不在于说自动化这一环中发现更多bug，这对个人来说也是持续优化的过程。
对于上面两个问题，至少我从业近10年，说因为自动化技术的引入，大量削减测试人力还大幅度提升了产品质量的情况现实中我没见过。
任何一个团队对于新事物接受都需要过程，首先要取决于新事物是不是确实优秀，有没有经过充分考验；还是说你在做这个新事物的小白鼠，或者你把新事物作为你的谈资。
然后再说降本增效，团队的认知不会都处于一条水平线，都有适应期和学习期；直接说降本增效，这是宣传语，忽视了事物发展的客观规律是悖论，实际落地的效益需要时间证明。
- 流量回放是大趋势，很厉害？
其实流量回放不是什么新技术，从最早起的测试工具比如qtp，lr，jmeter都可以录制回放，但这玩意有多鸡肋用过的人都知道。
现在也有goreaply，jvmsandbox用于不同层面的录制，本质上来说也并不是原生爆炸性的自动化武器，一样需要去大量改造，根本没必要神化。
一些leader不是特别了解的情况下会认为这是一个很兜底的全场景方案，但我认为其实性价比不高。
怎么去衡量性价比高不高？你只要看这个技术是不是中小公司都能快速上手或者大量使用，如果只是大公司在讲ppt，那你就先听听吧。
- 热衷于自动化测试框架研究
- 这些同学特别喜欢聊自动化测试框架的优劣，讲起来如数家珍；
- 很少讲业务场景的适用性，舍本逐末；
- 对技术热衷的同学我建议还是做纯开发，只是代码好在测试行业能找到技术优越感但未必能有归属感。
怎么做更好？
1.改变认知
尤其对于两个极端的同学，认为自动化无用或是过度依赖自动化的都是需要改变的；最终还是要从业务本身出发，自动化本身就是工具，核心的是你的思考设计能力，这是一个内核的驱动，所有的自动化场景的设计，运行都需要在你的控制中。而不是自动化一跑几小时，出了问题两眼一抹黑。
所以说最终还是人的能力，两条腿走路，技术和业务都要抓牢，这个观点最近我和老张，CKL都经常聊到。说的更彻底一些，落脚点是个人综合素质而不是单纯的某一个技术的引入，你个人能够完成更多的scope才是降本增效；机械的引入技术平台，形成内耗只会适得其反。
2.自动化测试框架平台的选型
目前情况下，没必要造轮子，因为你造轮子不仅需要时间，可能还有很多bug；短时间内或者在不短的时间内都未必提升效率，反而形成内耗。
成熟的框架或者平台免费的开源的都很多，选择一个自己团队适用的；从目前的主流趋势看，越来越多的公司选择了测试平台，对于测试框架维护成本还是比较高的。市面上目前免费的测试平台如itestwork，metersphere等都可以用用。
3.专职的做基础架构，测试case交给业务测试
降本增效的核心就是增加能力。在正常情况下，自动化case应该由业务测试人员自己完成，对于平台的改造可以让技术能力强的同学去完成，一个测试团队配置1-2个这样的同学足以。前几年存在专职测试开发团队4-5个人，一年时间开发了接口测试平台，人力成本200w，做的东西还不如开源的稳定，后面这样的团队在中小公司将成为历史，除非你能够去大公司带领行业发展。
4.回到业务场景
注重测试的场景化设计，回归到质量本身，去固化重复劳动，形成自动化。
前几年的自动化存在一些同学在业务设计很浅的层次下对于框架做更多的技术设计。而一些技术设计也并非就能直接带来业务上的价值，这些是需要警惕的。
免费资料推荐：
测试各类自学成长笔记
CC简介：
目前在近70人测试团队担任质量经理，质量委员会负责人，曾就职于一线互联网公司，在知名App上发布过测试专栏，付费订阅人数10000
