自动化测试是在开发阶段就介入呢，还是等手工测试结束之后，系统功能稳定后，介入？
首先，搞清楚自动化的目的是什么？
提供运行的准确性和稳定性，避免外界因素的影响
避免重复劳动，防止大量的手工回归测试，节省成本
对测试人员而言，也是提高技能的一种手段
上面的4点，是对自动化测试目的一个总结，对自动化是否有意义的判断也是基于上面的认知。当然你也可能会有其它一些想法。
对于上面提到的那个问题, 还是不好解释，毕竟场景不同，其对应的方案也会不一样。从笔者现在所在的团队来看，这样的问题，我会从整个项目的周期来判断，下面是目前我们的一个做法，当然并不是很完整，我简单说一下过程。
软件开发流程，大家比较清楚的可能是瀑布流程，敏捷开发这些。不管采用什么样的流程，测试的工作如何接入配合到开发流程中才是最重要的，最关键的。而不是去考虑什么时间去做自动化测试，自动化测试应该是在合适的时间就得开展。
现在，我们不会去区分角色，功能测试人员和自动化测试人员应该就是一个人，测试人员应该对应于一个产品，而不是一种技能。
项目前期，kickoff结束，测试同学就应该参与到项目中，对项目的需求进行一定的把握。下面的流程是我们测试的一些关键时间点：
1. 需求评审
这个阶段可以了解项目的背景，并开始和开发，PD(Product Designer, 产品设计师)沟通一些功能上的设计问题。为后面设计case提供一些思路。
2. 开发设计&&测试用例设计
有些工作并不一定要等到开发全部完成再进行，紧密沟通合作，保证项目向前推进。在开发设计阶段就可以参与进来，并在开发设计完成后，对应完成测试用例的设计，明确哪些case可以实现自动化，并选择好测试框架和工具。
3. 分层测试&&可自动化的部分先行
在未得到稳定的测试版本之前，可以准备测试数据，一键部署的脚本，已经对应测试框架，测试代码的编写。不一定要全部完成，但至少准备工作都得做好。
4. 冒烟&&测试执行
提测之前，对部分重点功能进行常规冒烟测试。达到预期后，进行功能测试。这个测试工程中，即可以对一些自动化测试的case进行编码调试，后面这些功能可以在回归执行中有非常大的作用。
5. bugfix版本，自动化回归
对应一些bugfix的版本，除了验证bug之外，还得将之前的功能进行回归，这个阶段，自动化的case将节省不少的精力。
6. 稳定版本，自动化回归，预发环境自动化验证
在发布上线之前，会准备一个稳定的环境，做一次全量的测试执行，当然自动化case也是这个时候的重点。
7. 发布上线，冒烟
待上述测试执行都结束了，意味着项目也就安心上线发布了。这个时候需要简单的冒烟测试即可。
经历这么一个项目的过程，自动化的case肯定是需要占有一定的比例。当然，大家肯定还是存在下面的一些疑问
开发还未提交测试，或者功能也未稳定，如何进行自动化的测试？
这个问题，我从下面的2点进行解释，其实前面我也有提到这些。
a. 接口测试，待测的接口肯定需要事先定义好，这里更多的应该是测试数据的准备，已经测试类的编写，case的逻辑可以体现出来，当然调试case需要放到功能开发出来，但是我们的准备工作要都搞定。
b. UI自动化，大家都会说页面还没出来，怎么写？道理是一样的，设计出来的场景是事先通过需求文档，交互PRD(Product Requirements Document)这些进行确认过的，同样，需要的测试数据可以先准备出来，代码的逻辑也可以写出一部分，这个时候缺的应该就是页面元素。
如果设计的合理，我们的case应该做到测试数据和测试代码进行分离，这样你需要的部分可以配置为参数的形式，后期传入
现在，在大公司不管是接口测试还是UI自动化，基本上都是在与开发同步进行，我们需要将自动化的作用最大化，提高测试的效率。
所有，我最终的建议是尽量提前来做，将自动化的价值最大化。