实施过了web系统的ui自动化，回顾梳理下，想到什么写什么，随时补充。
首先，自动化测试不是手动测试的替代品，是比较好的补充，而且不是占大比重的补充。
70%的测试工作集中在底层接口测试和单元测试，20%的测试工作为集成测试，其他10%的测试即为界面测试。
尽可能的相通的模块，通用的封装
开发约定好，便于定位
适用兼容测试
无界面运行
快速定位问题：报错信息、错误截图
多环境
脚本开发时间和复用次数
快速验证，第一时间响应问题
兼容性
便于快速定位
提炼更多通用模块。
调研更优解决方案，比如：cypress等
case依赖优化
深度校验
系统稳定，太多的阻止程序或更改。
准备之前，先手工测试，确认自动测试可以涵盖的系统功能。
需要多系统，多浏览器兼容性测试
主业务流程
易于实现自动化的web元素、页面
重复量大的功能
页面元素验证
页面列表数据验证
页面元素属性？
ui的文本，图片显示正确性
ui的交互逻辑正确性测试
ui上的用户行为正确性测试
分布式执行，可以多机器，多浏览器同步执行脚本
适用于不同环境运行
分层设计，方便维护
生成测试报告
模块的复用
必要的日志搜集
回归测试需要定期运行，在自动化时，它们可以节省测试人员的时间，我们可以更专注于其他场景和探索性测试。
误报频率
不能快速反馈（相对于单元测试和api测试）
只会对于case已确定的内容进行校验
运行的稳定性
发现的错误不多，大多数错误似乎是通过“意外”或进行探索性测试而发现的。这可能是因为在每个探索性测试会话期间，我们可能以不同的方式测试应用程序，从而通过应用程序找到新的漏洞。
编写优秀且稳定的xpath / css定位器所花费的时间，并在底层html标记发生变化时更新它们。
ui本身的变化性，要想达到和手工测试相同的覆盖率，投入比较大。
不过，高频的集成，还是用接口更加合适，后面的工作会把系统的交互接口自动化，届时分享。