如何编写脚本化的手动测试用例，尽管你讨厌它们？

我喜欢测试，但不喜欢编写脚本化的手动测试用例。但事实上，每个工作都有你不喜欢的部分，而不同的环境需要不同的解决方案。有时，脚本化的手动测试用例是唯一的选择，或者客户就是想要它们。那么，当你不喜欢编写脚本化的手动测试用例时，该如何处理呢？

将测试用例融入你的测试策略/计划

凡事有其道理，每件事都要有其归属。为什么在这种特定环境下需要测试用例？它们将何时被使用？谁来编写和执行它们？它们一直都要这样吗？

搞清楚测试用例在整个大局中的位置，并将它们作为你策略/计划的一部分。这甚至可能帮助你确定它们是否真的需要，或者它们所起的作用/带来的价值。

专注于好处

编写脚本化的测试用例其实也有一些好处。专注于这些好处，而不是你对它们的厌恶，会帮助你编写更高质量的测试用例，因为你会更有动力去优化它们以充分发挥其优势。

潜在的好处包括：

• 系统待测单元（SUT）的预期行为是清晰且集中的
• 复杂/冗长的测试步骤无法自动化时，可以通过脚本减少错误
• 来自其他业务部门/团队/外部人员也可以轻松理解和执行脚本化测试
• ……

使用测试套件作为模型

我喜欢使用诸如功能图和架构图这样的工具来理解和可视化一个系统。同样，结构良好的测试套件也可以帮助你计划哪些测试应该在何时执行。它还可以帮助你更好地理解你的测试覆盖率，不仅可以看到套件覆盖了什么，还可以了解哪些测试已经执行过。这对于提供我所称的“质量声明”和对评估信心水平的描述非常有用。

测试套件对新成员入职也非常有帮助，因为关键功能、用例等被分组和明确描述。通过执行测试套件，可以快速学习和了解系统。

让测试用例激发探索

这也可能是一个探索的好机会。有时，把事情按这种显式、逻辑的方式布局出来，会帮助我们发现空白，并激发我们去思考其他场景或我们想要进一步了解的缺失信息。或许事情并不是那么清晰，编写这些测试用例会让你意识到这一点，并促使你找到所需的清晰度。

在执行测试时，我们也不必盲目接受脚本中的内容。我们可以质疑所述内容的有效性；为什么测试用例指示你以某种特定方式设置某些东西？为什么要在这个级别上执行测试（脚本化测试用例不一定总是在UI级别执行）？

采用基于风险的测试并增加价值

决定编写哪些脚本化手动测试用例是一个很好的机会来考虑风险。你想先编写哪些测试，为什么？执行这个测试会为我们带来什么价值？不执行这个测试我们会面临什么风险？如果该领域存在问题，对我们最重要的质量特性会造成怎样的威胁？深入思考这些问题，以确保你的测试套件能尽快为团队带来实际利益。

编写可维护且长期有效的测试用例

考虑你每个测试真正想要确定的内容。如果具体的用户身份并不重要，但账户类型却很重要，那么在测试用例中只需指定账户类型。这样，如果用户被删除或由于某种原因不再适合测试，你的测试用例仍然有意义，不需要不必要的维护。要确保步骤足够明确，以便其他人也可以成功地执行测试步骤，但又不要过于具体，以至于每次系统变化时都需要频繁调整。

如果你的测试管理平台允许，请考虑如何“复用”测试步骤或序列，以减少在多个地方进行相同更新的次数。这样可以节省你未来的大量时间（和无聊的工作）。

保持开放的心态

当我们面临一项不想做的任务时，很容易带着偏见（不喜欢）去做，变得缺乏动力，结果做得不够好。学会欣赏测试用例在你所处环境中的价值，可以帮助你增加另一项技能，并让你成为一名更全面的测试人员。所以，如果你需要编写脚本化的手动测试用例，不妨给它们一个机会，并尽可能编写出高质量的测试用例。、明白了，但还是不想

用测试用例？那看看我这个实用的替代方案：介绍 HISToW。

你对那些讨厌编写测试用例的人有什么其他建议吗？请在评论中分享吧。