包含内容

我们只自动化那些高频且稳定的部分。一味追求全覆盖,通常并不划算。

沟通服务内容

场景筛选

优先自动化哪些:业务关键且反复执行的场景。

编写测试

让脚本能容忍界面的小改动,否则维护成本会吃掉收益。

测试数据

准备与清理数据,确保各次执行互不影响。

构建时执行

测试随构建自动运行,而不是等谁想起来才跑。

结果报告

结论清晰:哪一步失败、附带截图。

持续维护

随产品变化更新脚本。这是长期工作,而不是一次性任务。

工作如何开展

两到三周后会有第一批脚本;覆盖到主要场景后效果才明显。

01

评估

测算目前人工回归要花多少时间,据此判断自动化是否划算。

02

搭建框架

执行环境、数据处理与报告机制。

03

逐步覆盖

按优先级编写脚本:先覆盖一旦出错影响最明显的部分。

04

维护

随改动更新脚本,并处理不稳定的用例。

不稳定的测试比没有测试更糟。一个时好时坏、原因不明的用例,会让团队干脆不再看结果,真正的失败也被一并忽略。这类脚本要么立即修好,要么删掉。

常见问题

不会。自动化验证的是已经写明的内容,胜在快且不知疲倦。要在陌生场景中发现新问题,只能靠人。自动化解放的是测试人员的重复劳动,而不是替代他们。

发布频率低、界面变动频繁,以及原型阶段。如果产品每月都要推倒重做,脚本的重写速度会赶不上它产生价值的速度。

要合理而不是最大。通常覆盖能带来收入的流程,以及历史上出过问题的地方就够了。一味追求覆盖率数字,只会写出为测而测的用例。

我们来实现自动化验证

请说明发布频率以及回归测试目前耗时多久。我们会测算自动化是否划算。