自动化测试项目

存在问题

• 中断和突发事件无法处理，直接报错
• 测试用例部分未实现

做了什么

• 了解测试方式和流程，熟悉项目技术和特点
• 完善部署文档
• 新增错误处理工具类（找出所有错误情况并解决，并回到初始已登陆状态）

进度如何

• 基本能独立开发并排错
• 文档完成
• 写了4种错误弹窗的用例并成功处理

接下来做什么

1. 错误处理工具类加到主程序并测试（0.5D）
2. 其它测试用例的实现（2D）
3. 文档更新，重读代码（1D）

（思路向）接到新项目的思考

1. 测试 工作上 的思考

• 界面功能测试占比小，以 发现问题 为主

  -> 优先解决问题，保证可读性

• 测试：输入能不能得到预期结果。
      而 UI 测试重点在 描述测试 。不同于单元测试 和API 测试（输入输出明确且易验证）

2. 测试 技术上 的思考

• CSS 选择器、id、xpath方案 ，例如 WebDriver 库。只能采用定位元素的方式，界面元素依赖性比较大

  -> 后续了解下自动遍历测试框架？

  -> 测试方式使用 BDD（ Behavior-Driven Development行为驱动开发 ) 方式？

  • 逻辑更清晰。而且分层过程不需要口头约定，比较符合逻辑。（如最后图片）

3. 报错处理上的方案：

   • 用 ts 实现状态机，报错时回滚上一个状态
     麻烦，投入大收益不大。

   • 该测试用例直接标记为失败后，继续执行下一个用例
     简单明了

（思路向）为什么没有继续改代码架构

    目前的分层已经足够目前的场景使用 + 产出效率问题

输入 -> action -> 大致动作逻辑 -> 工具类（真机连接，定位元素，格式化等能复用的组件） -> 输出