本文主要是介绍【原创】全自动化测试离我们还有多远？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
自动化测试是目前的趋势，这个大家肯定都有目共睹的了，很多公司的招聘现在也是直接用测试开发岗来替代测试岗。
而早在国内有这个变化前，国外的微软、Google 等大公司也在逐渐减少专职的软件测试岗，让开发承担起质量保证的主要职责。
那么问题来了，国内的全自动化测试离我们还有多远？
考虑自动化维护的成本
对于使用自动化的人来说，可能只是看到自动化用例执行的速度和覆盖度，但是对于维护自动化的人来说，时间的投入成本是绕不开的问题。
比如执行环境的维护，比如脚本的维护，比如问题的跟进修复等等都是需要时间投入，如果只是单纯的简单问题修复其实还好，一旦涉及到复杂问题的解决，更是耗时耗力。
所以，自动化并不是我们想象的那么美好，特别是在没有开发配合的情况下，有时候我们可能还需要去考虑怎么绕过我们软件自身的逻辑来保证自动化执行的效果。
那么在全力推进自动化之前，一定要考虑好基础设施、技术能力和人力成本，之后才去制定合理的计划。
自动化没法进行探索式测试
虽然现在的 AI 技术进行的如火如荼，但是自动化大部分都还是通过明确的输入来验证明确的输出，这个特性决定了他只能做回归测试。
但是有经验的测试人员都会发现，我们发现的很多 bug 其实都是意料之外的，既然是意料之外，就是我们可能没有这个预期到要去这么测试，只是测试过程中通过发散性思维进行了扩展测试，然后发现的问题，专业点的把这个过程叫做探索式测试。
打个简单的比方，前几天我测试一个逻辑 A，在检测日志信息时，偶尔发现了另一个逻辑的日志有点异常，于是就去跟进了一下，从而发现了一个问题，如果是自动化，他根本不可能在测试 A 逻辑的时候还去关注 B 逻辑的问题。
目前国内公司开发人员的质量意识，还没足够到修改 A 就保证只有 A 功能受影响的水平，同时产品人员的意识，也没有足够到提前把所有场景都细化成明确的需求，这就难免会出现需求转化为实现，以及实现转化为用户使用体验的不一致性，这部分目前都是通过人工来验证的。
目前的自动化实现，决定了它没法进行探索式测试，所以没有人工参与的自动化暂时肯定是无法完全取代人工的。
开发要具备质量思维
通过上面两点的说明，应该很容易看到，人在自动化测试过程中还是起关键作用。
微软和 Google 这些大公司之所以能减少专业的测试人员，是因为他们已经经过长时间的培养和灌输，让开发同学具备了很好的质量思维，开发同学已经可以取代之前专业测试人员在做的事情了。
比如可以支持测试工具、测试系统的维护，因为可以在需求实现过程中就考虑自动化的落实，所以让自动化实现的成本降低。
比如可以兼顾部分的探索式测试的职责，能够在代码编写和自测时都考虑到各种可能出现的场景，从而在编码阶段就可以规避问题的出现。
国内目前的环境看，如果要开发人员达到这样的思维，还是需要一段时间的过渡。
举个简单的例子，我看到很多开源的 Python 库，里面都是自带 unittest 集合的，国内有多少的开发人员会自己自觉的去写单元测试呢？何况还是开源的呢。
测试前移以及全面的自动化的前提，一定是开发人员的配合和支持，如果这个前提不在，测试人员自己再怎么努力也是事倍功半。
以上，之前我有写过几篇文章讨论测试人员学习编程的事情，测试人员会编程确实可以推动自动化测试的落实，但是都仅限于回归测试，如果要完全取代业务测试，还是需要天时、地利和人和三个要素齐备才行，不知道你是否也是这么认为的呢？欢迎留言说说你的看法。
当然，如果你认可我的观点，请帮忙转发 + 点个「在看」让更多人看到，谢谢。
本文首发于公众号「sylan215」，十年测试老司机的原创干货，关注送绝版资料
这篇关于【原创】全自动化测试离我们还有多远？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
