不断发掘自动化测试对各个团队的附加价值，这样才能得到来自四面八方的支持
没有将自动化加入项目过程的自动化都达不到预期的效果
UI自动化框架
把UI自动化框架设计成一个拼图性质的架构。把每个特性都设计成一个独立的部分，然后组装成UI自动化框架：
- （appium/webdriver）底层操作封装特性
- Page Object特性
- 测试用例管理特性
- 测试执行引擎特性
- 测试报告管理特性
- 测试数据管理特性
- keyword特性
自动化原则：
- 选择重点业务
- 选择较稳定的版本业务
- 目标是保证主要功能业务完整正常，而不是为了发现更多的bug
- 并不能减少人力成本，主要作用是加快测试反馈，提高测试质量
- 录制回放，关键字驱动，可视化等一般不是好的选择，因为他们会增加6.脚本维护的难度，增加维护成本
- 任何增加维护成本的自动化工作都是在耍流氓
如何减少自动化维护成本？
- 清晰、方便的日志查看
- 清晰整洁的测试报告
- 快速的脚本调试
- 快速的错误定位方式：如截图、错误日志、录屏
- 严格的脚本规范
- 在策略上，脚本慢慢上，要非常稳定了才能上线到正式环境
- 定时开展培训分享工作，提升大家的能力。写UI自动化不只是工作任务，更是自我提升的过程
- 要有稳定的环境、稳定网络，可以进行网络监控、定时重启等等
UI自动化框架优化方案：（在不增加维护成本前提下）
- UI自动化框架加入录屏模块
- UI自动化框架加入接口请求报错模块
- UI自动化框架加入接口流程对比模块
- UI自动化框架加入用例成功率、用例增长率等图表展示度量模块
- UI自动化框架加入web平台支持，如用例集管理，异步执行
- UI自动化框架加入监控核心场景的性能，如网络、启动速度、内存消耗等
- UI自动化框架加入报错时取内存快照、报错堆栈等信息
- 自动化测试环境一键搭建部署
UI自动化脚本可分为3种：
- 监控脚本，监控服务器是否正常，监控每个页面是否能正常显示
- 主流程脚本，监控主流程是否能正常运行
- 模块脚本，优先级较低，一般也是重点业务模块先做
已经实现自动化的模块可以不做手工测试了吗？
为了不做手工测试，就要多加很多验证点，特别是UI的验证点。验证点越多，就会导致自动化越不稳定，自动化的维护成本就会越高，
你对自动化的信心就会越低，自动化的成效也会越低。所以已经实现自动化的模块还是可能需要做手工测试。
那么自动化测试的意义何在呢？
- 自动化用执行次数来增加价值，执行次数越多，自动化价值越大。比如执行5次刚好成本和价值等价，那么每多执行一次，自动化的价值就越多。
- 特别是那些需要重复进行UI操作，比如适配测试，需要适配几十个机型，是自动化去执行好呢还是一个个的手工执行好呢。
- 我们不使用自动化去保证UI的准确性，而是去进行逻辑功能的测试。比如QQ的登录功能，我们只要验证点击登录后打开了好友列表，就说明登录成功了。就是要怎么稳定怎么弄。
- UI自动化主要作用是保证业务流程的贯通
- UI自动化能够帮助我们确保不会出现一些死人的问题，比如登录不成功，页面打不开等等。
UI自动化公式：
自动化收益 = 有效迭代次数 x 手工测试成本
自动化成本 = 脚本创建成本 维护次数 x 维护调试成本 脚本失败次数 x 脚本排错成本
其他
- 测试工具、框架和自动化测试脚本本身的质量是最需要保证的，需要对测试工具、框架做单元测试
- 自动化可以模拟用户真实的场景，如让用户在一个页面等待10分钟或锁屏、解锁，该app是否还生存
- 把手工用例与脚本生成的用例文档进行对比，提示当前有哪些用例需要维护
- 在代码集成到主干之前或之后先执行自动化，只要用例失败（可以设阈值），则不能集成或回滚
- 持续集成并不能消除bug，而是让它们非常容易被发现和修复
- 自动化要集成到持续集成过程中，目的是加快测试反馈，降低测试引入、发现到修复之间的时间间隔
- 速度是评估测试价值的最重要考虑因素之一
