一、回归本源，框架是为了支撑我们测试，所以我们对框架的要求

1.框架满足我们的测试需求

• UI框架有对象识别能力
• API框架有http原语封装，对xml json支持
• 单元测试框架有mock能力

2.框架应有广泛的同行用户、持续更新、成熟的社区和积极的客户响应

（这里只是抛出话题，不要着急，稍后会进行对应框架的对比）

二、选定框架后，进行代码编写，什么样的代码才值得写？

1.做值得做的工作，最重要的是降级风险带来的变动

最大的风险是：维护工作量

维护工作主要体现在：

• 被测截面发生变化带来的工作量
• 诊断自动化测试的工作量（真假阴阳）
  • 通知：从错误世纪发生到我们知道错误发生
  • 诊断：开始诊断错误到定位出错误
  • 修复：修复错误喝验证修复方案
  • 确认：修复后上线，跑出第一轮测试结果

所以我们要尽可能减少维护的工作量：

1. 缩小通知时间：实时通知（Log规范+elk+grafana 实现告警实时传达）
2. 诊断越快越好，发现后优先修复（检查点+日志+必要的屏幕截图/视频）
3. 修复要彻底，自动化测试结果可信（高内聚低耦合的模块化设计，隔离错误，缩小影响范围，快速修复）
4. 修复后尽快上线（自动化测试上下线标准和流程的建立）

2.写可以多处使用的代码，提高复用率

• 一行代码，多浏览器运行（UI）
• 一行代码，多数据运行
• 一份代码，多环境运行
• 一份代码，多语言（Language）运行

选择合适的框架，实现高复用率的代码，尽量减少维护工作量，可以大大提高我们的ROI。