场景筛选
优先自动化哪些:业务关键且反复执行的场景。
我们只自动化那些高频且稳定的部分。一味追求全覆盖,通常并不划算。
优先自动化哪些:业务关键且反复执行的场景。
让脚本能容忍界面的小改动,否则维护成本会吃掉收益。
准备与清理数据,确保各次执行互不影响。
测试随构建自动运行,而不是等谁想起来才跑。
结论清晰:哪一步失败、附带截图。
随产品变化更新脚本。这是长期工作,而不是一次性任务。
两到三周后会有第一批脚本;覆盖到主要场景后效果才明显。
测算目前人工回归要花多少时间,据此判断自动化是否划算。
执行环境、数据处理与报告机制。
按优先级编写脚本:先覆盖一旦出错影响最明显的部分。
随改动更新脚本,并处理不稳定的用例。
不稳定的测试比没有测试更糟。一个时好时坏、原因不明的用例,会让团队干脆不再看结果,真正的失败也被一并忽略。这类脚本要么立即修好,要么删掉。
不会。自动化验证的是已经写明的内容,胜在快且不知疲倦。要在陌生场景中发现新问题,只能靠人。自动化解放的是测试人员的重复劳动,而不是替代他们。
发布频率低、界面变动频繁,以及原型阶段。如果产品每月都要推倒重做,脚本的重写速度会赶不上它产生价值的速度。
要合理而不是最大。通常覆盖能带来收入的流程,以及历史上出过问题的地方就够了。一味追求覆盖率数字,只会写出为测而测的用例。
申请已受理
我们已经收到。我们会在一个工作日内回复,紧急问题将立即安排值班工程师处理。
未找到该城市,请检查拼写。