引言

我在担心当前的一种趋势。我也感到沮丧。每个测试人员曾经在职业生涯的某个时刻都说过：“你无法测试一切。”
如果你留心的话，你只需要在职业生涯中完成一项测试任务就能意识到这一点。
在我看来，有些高级管理人员并没有说过这个和/或没有听他们雇佣的专家的话。

问题

我可以向你保证，任何认为自己是专业的测试人员都不会完全遵循测试脚本。也许他们只是在遵循一个一般想法的标题，事实就是这样。

现在，如果你确定你的团队没有偏离“测试剧本”，并且你强迫他们完全按照“剧本”的每一步来操作，那么你真的需要有人来帮你做一些改变了。

你应该进行横向思考（还有什么会影响这一点），纵向思考（如果我这样做会怎么样），综合分析（刚刚发生了什么，为什么），大胆假设（这个领域因为x而出现了这种问题，也许x在其他地方也造成了问题），好奇探索（如果我有这些先决条件，我想知道产品是如何表现的），提出疑问（它应该这样做吗？ ）。

过度膨胀的回归测试套件充满了没用的垃圾。自动化测试用例的百分比，代码覆盖百分比，种种这些都表明，一些人已经忘记了资源的根本限制：无论我们多么努力，即使在机器人的帮助下，我们也无法测试一切并确保一切都不会出错。

就测试本身而言，无论如何，上述指标或多或少都是无用的。
对我来说，很明显，即使是一瞬间的反思和与团队的交流，也能揭示测试环节的时间都花在了哪里。所以，这要么是故意的无知，要么就是缺乏意识。

一些参考

以下是我个人每天在用的一些建议，供做参考，以便给您一些不同的视角：

• 一致的理解。打断我的测试会议，向开发人员或产品负责人/客户澄清询问的问题。
• 环境的不足。设置测试需要很长时间；所需数据不明确；有人篡改了我的测试数据，我需要修复它。有人在我的会议中间启动了一个新的部署。它会抹去我所做的一切。
• 测试的范围。我应该看什么？其他人应该在看什么？在兔子洞里，我应该走多远？
• 第三方集成的不稳定。我再次被集成模块的问题所阻止。测试推迟了好几天。
• 测试的策略。我们测试的总体目标是什么？测试此功能的目标是什么？它如何适应大局？
• 可测试性。我应该测试的这个东西真的很难控制和观察。

有很多问题需要回答，有很多事情需要评估、分析、决定。让我再说一遍。问题不在测试脚本或“执行”它所需的时间。

“执行”这些脚本需要很长时间？那我们就让机器人来执行它们。

然而，不知何故，领导们形成了一个固定的思维：即如果我们自动化来点击按钮，我们就会以某种方式节省时间。
现在看来，这种固定思维已经达到了一个新的高峰，每个领导者都被新的“淘金热”蒙蔽了：都热衷于学习ChatGPT或CoPilot如何为我们创建测试。

“编写”这些脚本需要很长时间？那么我们就让机器人来创建它们。

这对更清晰的理解高优先级的测试要点绝对没有一点影响。它不会加快我的工作速度，如果有影响的话，那就是变得更加有破坏性，
因为我需要花更多时间评估脚本，并尝试给它更好的输入和/或修改脚本本身，或者至少以上这些都是我应该做的事情，而不是盲目地接受机器给的一切。

这确实会使问题变得更糟。更大的回归测试套件，没有人知道它们是做什么的，因为我们在制作无用的脚本方面效率更高。
人们不知道产品表现如何，因为没有人愿意尝试使用它。

结语

所以你的问题不在测试脚本，让软件为你创建脚本并不能解决你真正的问题。
它们也不会促进团队解决问题，因为团队的时间被用在修复代码、管理无用的组件等上面了。

所以，强烈恳请三思而行。同时请尊重自己和你所做的工作。

后记

当我正要完成这个帖子时，我突然又意识到了一点：你的测试脚本实际上可能正是你的问题。只不过不是在所花费的时间上。问题可能在于你固执于想用它们取代战略决策和规划。

‍