合理的自动化切入点：通常，项目只有经历了完整的系统测试之后才算具备了基本的引入测试自动化的条件。
测试自动化分析：
（1）可行性分析
（2）抽样demo分析，demo一般选取冒烟测试用例，检查脚本是否能够成功运行通过，已设计的测试点是否全部执行
（3）测试需求分析，分析哪些功能点准备进行自动化
测试计划定制：自动化测试计划越全面，后期越能循规蹈矩的去实施，自动化测试的成功率越高
自动化测试设计阶段：主要分为自动化测试框架和自动化测试用例。
（1）自动化测试框架的设计，开发与搭建：应能保证测试的分布执行，脚本模块化，数据驱动，日志分析，错误截图，报表回收，共享对象库，公共函数库，环境配置，统一设计模式，异常处理，场景恢复的一个无人值守的，针对每个独立项目的测试框架
（2）自动化测试用例设计三部曲：手工测试用例是从无到有，然后自动化测试用例是根据手工测试用例来写的。首先，筛选手工测试用例。然后转换手工测试用例，最后新增&补充自动化测试用例。
为什么不能用手工测试用例完全替代自动化测试用例？
自动化测试用例的范围往往是核心业务流程或者重复执行率高的，自动化测试的覆盖率不能达到手工测试的覆盖率。自动化测试的用例选择一般以正向为主，而反向的情况却有很多，但是并不是所有反向情况自动化测试都会涵盖，而是有筛选的选取一部分。也并不是所有的手工测试用例都可以用来做自动化的，如页面布局的检查。手工测试可以不需要回原点，但是自动化测试往往是必须的。自动化测试用例与手工测试用例不同，不需要每个步骤都写预期结果。
测试脚本设计与开发：
测试脚本大致可划分为五种，
（1）线性脚本：通过录制直接产生的线性可执行的脚本
（2）结构化脚本：具有顺序，循环，分支等结构的脚本
（3）可共享脚本：可以被多个测试用例使用，被其他脚本调用的脚本
（4）数据驱动脚本：测试数据跟业务流程控制分离的脚本，通过读入数据文件来驱动流程进行的脚本
（5）关键字驱动脚本：脚本，数据，业务分离，数据和关键字在不同的数据表中，通过关键字来驱动测试业务逻辑。关键字驱动的特点是，它更像是描述一个测试用例在做什么，而不是如何做。
自动化测试执行：
（1）无人值守的测试：环境搭建，部署与配置；自动化测试用例与测试脚本相互绑定；自动化测试用例执行顺序排列与组合
（2）异常处理与场景恢复
提交自动化测试产物：大致需要提交执行情况，测试结果，分析报表，测试报告，质量情况等。
测试脚本维护：严格来讲，每个阶段都在做测试脚本维护。一个不值得维护的自动化测试项目是不值得立项的。