自动化测试良好实践 v0.3

要编写多少自动化测试？

测试金字塔

• 用户界面测试
  • 只覆盖主流程，少而精
• 接口测试
  • 数量适中
• 单元测试
  • 数量最多。不能访问诸如数据库、网络、文件系统等外部系统，只测试待测代码的内部逻辑
• 用风险驱动自动化测试的编写，而不是所有需求都用自动化测试覆盖

自动化测试案例和代码该由谁编写？

• 先由开发、测试、业务人员共同讨论主流程（即用户旅程）验收条件，再由开发人员编写自动化测试代码

什么样的自动化测试会遭废弃？

• 运行时间太长、误报太多和缺乏维护的自动化测试，就会遭到废弃
  • 运行时间太长，就没人有耐心运行
  • 测试误报太多，就没人关注测试结果
  • 测试缺乏维护，就让人弃之不用

自动化测试该跑多久？

• 单元测试
  • 几分钟
• 接口测试
  • 十几分钟
• 用户界面测试
  • 几十分钟

如果自动化测试数量多到难以维护该怎么办？

• 一个系统要测试的功能太多，可视作该系统职责过多的坏味道，可以考虑进行架构演化，把系统拆分成几个微服务，让每个微服务的测试数量减少

没有自动化测试的遗留系统，该从何开始做自动化测试？

• 主流程的验收测试（回归测试）
  • 用户界面测试
  • 接口测试
• 严重的生产事故
  • 单元测试

自动化测试的格式是什么？

• 如果（准备测试条件）……，当（调用待测行为）……，则（判断实际结果是否符合期望）……
• Given..., when..., then....
• 例如：如果系统有10万注册用户， 当创建一个新用户后， 则能在5毫秒内进入该用户的管理页面。

编写自动化测试的原则是什么？

• 每个测试都能独立运行，不会依赖其他测试
• 每个测试即使重复运行，也不会影响测试结果
• 每个测试都有断言语句
• 每个测试都能自己准备测试数据，并在测试执行完成后，能自己清理数据
• 代码评审时要查看自动化测试代码
• 在CI流水线中频繁运行
• 改进架构，使其更具可测试性
• 频繁维护

自动化测试是否可以删除？

• 可以。要及时删除那些过时业务行为的自动化测试及其对应代码

何时更新自动化测试？

• 当业务行为和接口行为发生变化时，就及时更新相应的自动化测试及其对应代码

如何有效统计自动化测试的覆盖率？

• 在不及时删除过时业务代码的情况下，片面追求代码测试覆盖率是有害的。此时，业务主流程和生产事故的测试覆盖率，要高于已有代码的测试覆盖率。

搜集哪些有关自动化测试的数据？

• 自动化测试覆盖的主流程用例数占比
• 相同功能的手工测试与自动化测试用时对比
• 自动化测试运行的时长
• 自动化测试运行的频度
• 自动化测试维护的频度