首先，衷心希望入行做测试的，对于技术类文章更要理性的去看和体会，这不是小说，文笔精彩就觉得好。每篇文章的发表都有其主观局限性，取其精华，去其糟粕，不能判断的可以通过多途径去佐证观点是否靠谱。特别对于刚入行的，要学会多问为什么，尽信书不如无书，可能轻信一个错误的观点，会让你走向错误的方向。
我对自动化的理解，也是随着行业的发展在改变，以下仅代表个人观点，是否有营养还请读者自己体会。

自动化的目的

• 把测试从枯燥的重复劳动中解放出来，例如：回归测试等；
• 协助手工测试完成很难模拟或无法模拟的的工作，例如：篡改服务返回的数据验证前端对各种数据场景的处理，弱网模拟、特殊协议数据包解析验证等；
• 尽早发现 Bug，例如：数据层的存储过程、Package 批量调用验证、接口自动化等偏底层的问题；
• 协助定位问题，现在的自动化提出了更高的要求，例如：接口层发现问题了，可以通过添加的 traceID 定位到日志错误或错误代码行，app 运行中异常可捕获错误日志等；
• 线上监控报警，现在的自动化不仅限于线下，线上的也已覆盖，测试和运维的工作可能存在交集，我们不能把质量问题寄托于他人，一旦发现问题，立即报警通知到人，让损失到最小。
• 提高工作效率，这个面有点广，例如，测试环境的自动化编译、打包、部署、持续集成甚至持续交付等。

关于自动化介入的若干问题

• 是否要考虑成本？ 当然要考虑，我们总会遇到在成本和质量之间找平衡点，可能一些特殊的行业，特殊的项目，质量的权重更高点，如果引入自动化能提高质量，该介入的还是要介入。
• 是不是只有大公司能做， 小公司和初创公司就不适合搞自动化？这不是绝对的，还是要看公司的资源和人员配备，如果有能力做为什么不？况且小公司的自动化不一定要做到大公司的程度，只要能提高工作效率，提高质量就可以，滴水穿石，聚沙成塔。
• 自动化何时介入？ 条件许可的还是尽早介入，越是底层的 Bug，影响面越广，修复成本也是最低的。但这不是硬性标准，一般公司都是从 UI 自动化开始积累经验的，拔苗不能助长。

如何开展自动化工作

这个信息量比较大，人才和技术就不多说了，我更关心的是做事的方式

• 抓住业务测试工作中的痛点和领导的痛点，多沟通多交流，优先解决基层的工作痛点，我相信一个好的领导会看到你的责任心和付出；
• 技术选型和方案可行性调研，多投入时间和精力，有的人性子急，前期做的很快，如果一开始的方向错了，最终会得不偿失；
• 如果是比较复杂的解决方案，尽量前后端分离、保证各模块的独立性、可融合性、解耦不解体，做到灵活可扩展，要有下一盘大棋的准备。