警告：我已经讨论并考虑过一些测试剧本 - 我不相信我一定和其他人有相同的解释，部分原因是没有足够的讨论这个想法（我知道，会如果人们有参考资料，则喜欢参考资料）以达成共识。这是我目前最好的尝试，它无疑会改变。

当我去年在 Twitter 上听到 James Bach 谈论它时，我喜欢测试剧本的想法：

• “测试手册是智能测试的工具”
• “我希望生产和维护成本更低，同时让我的测试方式更好。”
• “一组列表、表格、流程、组合——一个紧凑的参考，让我可以进行彻底的探索性测试。”
• “它有助于测试设计和测试性能。”

对我来说，这本质上是一种在我测试时收集信息的方式，所有可能在我测试时产生新的测试想法的东西，或者帮助我看到构建我正在做的测试的替代方法。当我在一个复杂的测试会话中时，我需要在脑海中保存大量信息——对我来说，将其中的一些信息从我的脑海中取出并放到纸上或 wiki 上有助于我更有效地进行测试。它还可以帮助我要求对我收集的一些内容进行审查，并与我的团队分享。

因此，我认为您的测试手册的内容将是高度特定于项目的。

但是，举几个例子：

对我来说，在一个项目中，如果我们从一开始就采用剧本的想法，那就是数据模型、映射、我们的业务场景草图、许多测试常见的 SQL 查询、如何设置我们的一些复杂的测试数据等等。- 上下文：数据仓库/商业智能、非常复杂的测试数据、遗留系统、需要与开发人员/架构师密切合作。

这是其他人在谈论他的测试人员的剧本：列表、测试人员的模型、场景、技术说明、环境说明和问题。同样，他将其用于协作目的，因此其中许多都作为讨论的结果进行了注释。

这里将脚本化方法与使用 playbook 的探索性方法进行了比较，很好地描述了编写 playbook 如何涉及与开发人员和架构师就风险领域、预言机、可测试性缺陷、依赖关系等进行大量讨论。