我们在考虑做自动化测试之前，一定要先分析一下，这个项目到底适不适合做自动化测试，避免在不太适合自动化测试的项目中痛苦挣扎，既浪费了大量的人力和时间，又收效甚微。下面简单列举一下评估一下项目是否适合做自动化的一些考虑因素：
- 需求变动不频繁
自动化测试脚本变化的大小与频率决定了自动化测试的维护成本。如果软件需求变动过于频繁，那么测试人员就需要不断地更新自动化测试用例，从而适应新的功能，提升脚本的稳定性。而脚本的维护本身就是一个开发代码的过程，需要不断的扩展、修改、调试，有时还需要对架构做出调整。如果所花费的维护成本高于利用其节省的测试成本，那么自动化测试就失去了他的价值与意义。
一种折中的做法就是先对系统中相对稳定的模块与功能进行自动化测试，变动较大的地方进行手工测试。 - 项目周期较长
由于自动化测试需求的确定、自动化框架的设计、脚本的开发与调试都需要一定的时间，而这个过程本身就是一个软件的开发过程，如果项目周期比较紧张，没有足够的时间去支持这样一个过程的话，就不要进行自动化测试。 - 自动化脚本可以重复使用
自动化测试脚本的重复使用要从三个方面来考虑：
1.所测试的项目之间是否存在有很大的差异性（如C/S系统架构与B/S系统架构的差异）
2.所选择的测试技术和工具是否适应这种差异
3.测试人员是否有能力设计开发出适应这种差异的自动化测试框架
目前常见的自动化测试工具非常多 ，比如 UFT (以前的名称是QTP)、Robotframework、Airtest、Cypress等，涉及到APP的自动化的话，一般用Appium的多一些，这里建议有编程基础的朋友，自己选择框架进行二次开发，可能使用的会习惯点，开源框架可能功能强大，但是工具学习也需要成本，有时候也会有局限性，而且自动化底层原理都差不多，自己封装的话，便于扩展，可以自己将框架中比较好的功能单独剥离出来。
那么，如果是自学的自动化，没有项目实战经验的时候，怎么衡量自己是否能独立承担UI自动化测试的工作呢？可以从以下几点去思考：
- 如何去设计测试场景
- 如何提高元素操作的成功率
- 如何提升脚本的稳定性
- 如何提升脚本的执行效率
- 脚本可扩展性、代码可复用性
- 如何去管理你的测试用例、执行测试用例
- 如何生成测试报告
- 脚本执行报错后能否快速定位到问题
- 一些复杂的元素定位不到或者通过传统的元素定位无法进行操作时该如何处理（比如canvas、）
如何设计高质量自动化脚本
- 实现业务逻辑、脚本、数据分离。
- 使用PO设计模式，将一个页面用到的元素和操作步骤封装在一个页面类中。如果一个元素定位发生了改变，我们只用修改这个页面的元素属性
- 对于页面类的方法，我们尽量从客户的正向逻辑去分析，方法中是一个独立场景，例如：登录到退出，而且不要想着把所有的步骤都封装在一个方法中。
- 测试用例设计中，减少测试用例之间的耦合度。
