先表明观点：自动化测试是手工测试的有效补充，这个观点我很认同。
但是自动化测试能主导甚至取代手工测试，我觉得是不可能的。
自动化测试是什么呢？
自动化测试是按照我们事先编写好的脚本，按照一定顺序或随机顺序，执行脚本步骤，并对比预期结果，得到测试实际结果的一种测试手段。
既然是事先编写好的脚本，那么自动化测试其实就是为了验证当前逻辑分支或黑盒功能是否存在问题。
用例覆盖代码分支，是存在一定遗漏的，在数家公司验证过，用例最多覆盖70%的代码逻辑；而用例发现bug的比例，不会超过60%。那剩下的40%，依赖于测试人员的经验和对业务的熟悉程度，所以手工的自由测试或者探索测试，仍然有必要存在。 这么说也没错，绝对可行。但是带来了第二个问题：自动化测试维护成本相比手工测试，会高多少？如果持平，那么你全部写成自动化脚本，还是很合理。如果过高，很多工程师只会把一些大量重复性的用例转换成自动化。
软件测试中手工测试重要还是自动化测试重要？
这个问题好像好多人都问过。手工测试、自动化测试哪个更重要❓ 答：都重要，不存在孰轻孰重的问题。
对软件测试而言，如果软件功能逻辑、界面等变更较频繁，自动化脚本往往不一定适配下一个版本，需要每个版本花时间进行调试，这样对测试工程师来说就叫维护成本。
如果调试时间太长，靠自己手工测试早就完成了，那么自动化测试的价值就不存在了。 所以综上所述，我认为自动化和手工测试，都同样重要，而且相对而言，在产品研发初期或者一些小公司，手工测试一定占据主导地位。 手工测试和自动化测试都基于对用户需求、功能需求的正确理解，对测试对象进行充分测试设计的基础上开展的。 按照测试阶段或者功能稳定程度来划分，手工测试更适合软件模块、集成测试阶段或者功能稳定性低（缺陷多、变动快等），如果这个时候开展自动化会引入过多的自动化开发、维护成本。
自动化测试更适合在产品迭代后期或者功能相对稳定的时候开展，通常应用于回归测试场景下 按照不同的测试对象来划分，如测试百万级的元数据迁移、汇聚处理时，由于数据的多样性，很难通过用手工测试保障质量，自然而然需要考虑自动化的方式提高测试效率，进而保障测试质量。时间有限的情况下，使用自动化尽可能覆盖重复性高的操作。 同时自动化并不是生搬硬套，根据不同的业务场景选择合适的自动化框架十分重要，可以有效的提高测试开发效率和降低维护成本。如，对于一个含有强流程的业务模块，采用关键字驱动测试框架更利于用例的组织和维护。通常常用的自动化框架还包含数据驱动测试框架、模块化测试框架。 自动化测试的类型也要因地制宜，如ui自动化、接口自动化等等，也需要结合业务特点、底层架构选择合适的类型开展。
软件测试中，手工测试是基础
自动化测试是提升效率的手段，也是未来的趋势。想要做好测试，二者都很重要，不可或缺。手工测试一次完整的测试行为中，可能不包含自动化测试，但一定会包含手工测试。
手工测试是对被测产品的总体需求进行全面验证，把真实用户所有可能输入的数据分类后进行等价测试，容易查出程序中的错误。 也就是说，手工测试是以用户的角度，从输入和输出的对应关系为出发点，进行测试的，注重软件的功能正确性。
手工测试主要试图发现以下几类错误：1、用户可能输入的数据千奇百怪，所以手工测试的时候，不仅要测试所有合法的输入，还要测试那些不合法，但是可能会出现的输入。这就需要引入测试用例，来量化管理这些输入的类型，比如等价类，边界值，因果图等，都是常见的用例设计方法。 但几个测试人员，在规定时间内，就算不吃不喝不睡的测试，也不能涵盖所有可能发生的用户使用场景，这个时候就要引入自动化测试的手段啦。 2、比如上线一个新版本，除了验证新功能的正确与否，还必须保证旧功能的正常运作。但是针对旧功能，没有必要每次都手工跑一遍测试用例，太费时间。
我们可以针对旧功能，写一个自动化脚本（比如登录注册页、用户反馈页这些很少去碰去改动的页面），每次都让脚本自己运行一遍，一般没什么大问题。 3、现在移动端测试，要涵盖的机型很多，苹果还好，安卓的机子简直数不过来，手工去兼容几个，再多就顾不过来了，耽误进度了。写一个自动化脚本，可以运行在所有你要兼容的机型上面，就会节省很多人力和时间。 自动化当然也有缺点，就是大多数时候，脚本只能是一次性的，如果针对某个功能写了一个脚本，下次这个功能改动了，这个脚本基本就作废了。
小tip：写自动化脚本，一定要到版本稳定了，再去写，跟性能测试道理是一样的。版本不稳定的时候，去测性能，去执行自动化，会造成大量的无用功。