自动化测试的根本目标：
测试环境中，保证新增接口功能正确性，原有接口的回归（保证原有接口不被修改“坏”）；
生产环境中，保证接口层面服务可用，功能的正确性（保证服务挂掉时，及时发现）
面对这个问题，首先要思考的是几个问题是：
第一、什么项目适合自动化？
业界普遍认为一下几种情况比较适合自动化测试：
回归测试为主的支持维护项目，即需要长期做支持维护的产品。或者有过去版本需要长期做支持维护的产品。这种产品（比如企业软件，操作系统等）一个版本在发布之后往往需要支持好多年，做bug fix和patch。这个时候每次小版本的开发都会增加迭代次数，并且每次产品变动都非常有限，维护成本相对偏低，自动化收益就非常好。这也是很多企业级软件或者硬件产品有专门自动化团队的原因。因为产品的支持维护开发的回归测试基本靠自动化接口比较稳定的产品，同上手动测试特别费时费力，甚至无法达到测试目的的项目。比如压力测试，大数据或者大量重复数据测试，必须有自动化工具的支持。
第二、什么时间点适合自动化介入？
一个项目的初期可能不太适合自动化，why?
因为项目初始阶段用户界面和接口没有稳定，自动化代码会被动的被要求频繁改变，维护成本非常高，自动化收益不好。而反而手动测试能够快速发现问题，反馈给开发人员。而到了项目后期和维护期，项目偏于稳定状态，测试用例会逐渐增加到很多，自动化再介入选取稳定的模块，为回归测试做准备，可以最大化自动化收益。
第三、团队成员的能力，使用的工具和硬件基础设施
其实这个因素是做所有事情都必须考虑的。自动化测试本身就是软件开发。好的自动化测试框架，架构设计很重要。这些会决定自动化的开发成本和维护成本。这些都要求很强的开发能力。如果你的团队只有很有限的开发能力，那么怎么去做自动化，是做最原始的录制回放，还是数据驱动。复杂自动化也需要良好的基础设施支持。比如你有很好的DevOps的虚机管理系统，就不用自己去开发，省下的资源和人力也是很可观的。
工具是另外一块，如果公司有实力支持商业测试软件和管理软件，就可以降低编程要求（当然这会带来一些其他问题）。如果没有办法用商业工具，只能考虑开源和自己开发，这个对自动化测试开发的能力要求就高。总之必须选择和团队，技能储备，基础设施与工具匹配的自动化策略。
思考完上述这个问题后，如何降低自动化维护成本？好像能得到一些答案了：
第一、在选取将用例 自动化时就要注意，尽可能的选取比较稳定的接口/内容做自动化测试；
第二、测试人员在编写测试脚本时对脚本质量的要求，重用性，复用性，搭建高质量的测试框架；
第三、测试工具的选取使用（比如选取专业的/商业话的测试软件工具），以及硬件服务的配套使用；
第四、加强提高测试人员的编码开发实力，这样能够创造出更多有用的测试工具, 所以有时间还是得多学学如何写代码呀。
