前几天在技术交流群里，大家讨论了很多关于自动化测试落地面临的痛点和如何创造价值的话题，颇有感触。
自动化测试这个话题，从出现到在国内大规模开展实践，有很长的一段时间了。早期，大家对自动化测试的理解和使用目的很简单，就是通过机器自动执行，替代人的手工执行，寄期能提高效率，降低成本，同时降低人手工执行带来的误差和遗漏，想法很美好。后来在国内各大小公司大规模开始实践，就开始变形了。
这个变形过程，大致分为这几个阶段：
1、以工具为载体，将测试用例从人工执行变成机器执行。在这个过程中，工具的不断迭代和演进帮了大忙，同时在某段时期造就了自动化测试工程师这样一个专项岗位。
2、以平台为载体，通过标准化的平台来降低功能测试人员的上手难度，主打一个人人都可以自动化，为研发测试赋能。这个大饼让很多管理心动不已，投入大量资源支持，也寄托了很高的期待。
3、以工程师为载体，号称一栈到底。就是说只要你是一个测试工程师，就应该搞定自己负责部分的所有测试工作，包括自动化、性能、安全各种，这也是当前市场对测试工程师的定义和要求。
这个过程背后体现了这几个趋势：
对测试岗位的专业程度要求变高；
对测试产出的结果预期开始挤泡沫；
从工具平台的高大上思维转变为能落地创造成果的接地气行为；
总的来说，这个过程演变至今，对产品质量的要求开始落于实处，花样秀技术而无法真正创造符合预期价值的人和工具，开始被淘汰。剩下的，就是能实际解决问题的人，至于用什么手段和工具，已经不重要了。
自动化的概念，来自于传统的制造业流水线作业，背后的原因是对生产力和生产效率的大规模革新。制造业的自动化流水线能不断演变优化的原因在于工业品都是模块化标准化的产品，自动化相比人类手工确实效率和良品率高了不少。
而软件行业先天讲究的小步快跑和快速迭代基因，和自动化流水线的本质是矛盾的。
近十年来的各个技术热门话题，诸如敏捷、devops、自动化测试等等，最终能真正落于实地且被大规模应用和认可的，也就devops了，为什么？因为devops的对象，是对软件研发交付流程过程的标准化和优化，诸如代码管理、变更和验证都是可以标准化的，且这些流程的标准化都是大家认可的。
而自动化测试的痛点在哪里呢？主要体现在如下几点：
自动化测试的对象是需求和业务场景；
自动化测试的动作是机器执行测试用例；
自动化测试的结果受多种因素制约和影响；
其中，需求和业务场景本身的不确定性更高变化更快，环境、网络、测试数据和断言都可能影响测试结果。截至目前来看，业内大部分人对自动化测试的理解和实践都是如何利用工具和平台来执行测试用例，却对需求和场景的变化以及改善影响测试结果的因素投入太少。
如此这般，长期下来就导致了投入大量资源却没拿到预期结果，最终自动化测试这一技术实践变成了测试自动化的手段。
测试的本质是度量，是对质量进行全方位的定量评估。无论是性能还是自动化，最终的目的是要对每次迭代和变更带来的质量变化有一个定量的结果，然后针对性改进，这也是质量保障的目的。
自动化测试要想真正落地拿到好的结果，一定要对测试对象进行标准化，否则自动化测试只能是测试自动化，从结果变成手段。
为什么这几年业内大家更多的开始提倡测试左移和质量门禁？因为相比于自动化测试这一技术手段，测试左移能更好的发现风险，质量门禁能更好的对质量在每个环节的变化给出精确的度量，这些反应在具体的质量保障方面有更直观的结果，无论是说服领导还是工作产出，都更有力度。
那自动化测试未来的发展趋势是什么呢？我的观点如下：
回归技术手段本身的定位，做辅导而不是做主导(造数据/线上定时巡检)；
做好基础技术设施和流程规范的标准化，再考虑扩大自动化测试的应用场景；
深入理解测试对象，基于需求和场景开展测试，放下技术鄙视链(自动化优于点点点)；
能控制风险精准度量的才是质量，至于哪个框架优秀哪个技术更牛，交给时间来评判。
感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
