要编写多少自动化测试？
测试金字塔
-
用户界面测试
- 只覆盖主流程，少而精
-
接口测试
- 数量适中
-
单元测试
- 数量最多。不能访问诸如数据库、网络、文件系统等外部系统，只测试待测代码的内部逻辑
-
用风险驱动自动化测试的编写，而不是所有需求都用自动化测试覆盖
自动化测试案例和代码该由谁编写？
- 先由开发、测试、业务人员共同讨论主流程（即用户旅程）验收条件，再由开发人员编写自动化测试代码
什么样的自动化测试会遭废弃？
-
运行时间太长、误报太多和缺乏维护的自动化测试，就会遭到废弃
-
运行时间太长，就没人有耐心运行
-
测试误报太多，就没人关注测试结果
-
测试缺乏维护，就让人弃之不用
-
自动化测试该跑多久？
-
单元测试
- 几分钟
-
接口测试
- 十几分钟
-
用户界面测试
- 几十分钟
如果自动化测试数量多到难以维护该怎么办？
- 一个系统要测试的功能太多，可视作该系统职责过多的坏味道，可以考虑进行架构演化，把系统拆分成几个微服务，让每个微服务的测试数量减少
没有自动化测试的遗留系统，该从何开始做自动化测试？
-
主流程的验收测试（回归测试）
-
用户界面测试
-
接口测试
-
-
严重的生产事故
- 单元测试
自动化测试的格式是什么？
-
如果（准备测试条件）……，当（调用待测行为）……，则（判断实际结果是否符合期望）……
-
Given..., when..., then....
-
例如：如果系统有10万注册用户，
当创建一个新用户后，
则能在5毫秒内进入该用户的管理页面。
编写自动化测试的原则是什么？
-
每个测试都能独立运行，不会依赖其他测试
-
每个测试即使重复运行，也不会影响测试结果
-
每个测试都有断言语句
-
每个测试都能自己准备测试数据，并在测试执行完成后，能自己清理数据
-
代码评审时要查看自动化测试代码
-
在CI流水线中频繁运行
-
改进架构，使其更具可测试性
-
频繁维护
自动化测试是否可以删除？
- 可以。要及时删除那些过时业务行为的自动化测试及其对应代码
何时更新自动化测试？
- 当业务行为和接口行为发生变化时，就及时更新相应的自动化测试及其对应代码
如何有效统计自动化测试的覆盖率？
- 在不及时删除过时业务代码的情况下，片面追求代码测试覆盖率是有害的。此时，业务主流程和生产事故的测试覆盖率，要高于已有代码的测试覆盖率。
搜集哪些有关自动化测试的数据？
-
自动化测试覆盖的主流程用例数占比
-
相同功能的手工测试与自动化测试用时对比
-
自动化测试运行的时长
-
自动化测试运行的频度
-
自动化测试维护的频度
网友评论