首先回答您的第二个问题：是的，您绝对需要测试用例设计标准。他们不必是怪物。与所有敏捷事物一样，它们必须足够。

对于您的第一个问题，没有“正确”的答案，但我可以给出一些指导。您的标准应该基于一种测试用例分类：首要任务是能够为每个故事设置和验证用户验收测试。其次是钢螺纹中的其他任何东西。之后，您将关注 80/20 规则和系统区域之间的关键边界。

您将需要一些指南/标准来了解如何将一个好的自动化测试用例添加到您现有的自动化中。只要您的测试团队中的每个自动化人员都可以根据需要选择并添加到任何自动化项目中，就可以拥有一系列不同的自动化方法。

我在工作时使用的一些标准（它并不完全敏捷，应用程序代码库大约有 200 万行代码，其中一些可以追溯到 1996 年，并且以令人难以置信的速度添加了新功能）是：

• 不管是什么，包括设置说明。你不能保证下一个处理这个问题的人知道如何配置它
• 无论您如何记录它，说明您期望发生什么以及什么构成失败。团队的其他人不是读心术的人。
• 首先专注于验证和验证预期的功能。然后检查您知道的任何相关内容并将其列出。之后遇到负面情况（需要注意“如果有时间”）
• 探索性测试在您完成后会得到总结，以便将您遇到的任何有问题或尴尬的案例添加到团队的知识库中。
• 尽可能多地交叉关联。如果您知道它涉及其他五个模块，请确保将它们全部列出，以便当有人去寻找涉及其中一个的测试用例时，他们会找到您的。
• 清晰而简单的节拍每次都花哨。
• 了解您的受众：在我工作的地方，我们假设我们对我们的应用程序有基本的了解，因为我们是一家企业对企业的商店，我们将始终拥有训练有素的用户。如果您正在处理一个面向公众的网站，您可能想假设不知道。这会影响您需要放入设计和文档的详细程度。
• 有一个商定的存储库。如果没有一个中央存储库，您拥有的所有测试用例都可以按模块、功能集和您认为需要的任何其他内容进行搜索，那么您就无法开始计算跨模块和模块内的覆盖率。
• 全局测试用例可能不需要在存储库中（例如拼写检查、表格上的制表符顺序等 - 测试这些是“每次都习惯性地做”的事情之一 - 或者它应该是。如果不是那么是的，毕竟全球案例确实需要在存储库中）
• 如果测试需要特殊设备，请确保安装和配置设备所需的一切都在测试用例中（包括在某些情况下从哪里获得设备）。
• 如果测试依赖于特定数据，包括在测试用例中从哪里获取数据。
• 有一个相互同意的模块列表。列表中的内容几乎没有团队中每个人都可以使用的列表那么重要。

有一些很好的免费工具，例如测试链接，可以让您按模块构建测试用例存储库，并识别您的核心回归用例、可自动化用例和差距。我不能提供更多，因为我的工作场所正在引入这个。我们一直在使用已被证明非常繁琐的目录结构 - 结果很糟糕。越早拥有存储库越好，知道没有它会是什么样子。

这距离完整的答案还有很长的路要走，但它是工作的起点。

我希望这会有所帮助。

我认为您自己正在发现第二个问题的答案，但是为了不那么神秘，是的，我认为测试用例设计标准是正确的方法。

对于测试用例设计，我们必须记住，当它们首次提出和使用时，绝大多数测试是使用传统的瀑布/分阶段方法进行的，这基本上意味着测试是在项目结束时完成的。因此，测试团队可以花时间（可以这么说）并思考最有效的方法来生成提供最大覆盖率的最小测试用例集。

然而，在我们今天生活的测试世界中，存在诸如敏捷之类的开发方法，它要求人们几乎在运行中识别、构建和验证解决方案——与分阶段的软件开发方法相比；因此，测试人员无法花费 2 或 3 天时间将测试套件微调为最小集合。

我要去哪里？

好吧，我仍然认为设计标准同样适用于敏捷方法，您只需要寻找不同的标志，并且可能使用适合敏捷的术语。例如，如果您使用故事卡来解释用户旅程，那么您可以在地上放一个赌注并声明“棒子”只会代表一个由真人执行的过程——因此您已经创建了一个设计标准每个人都可以与之相关。

我相信，无论使用哪种开发方法，您都应该能够定义和同意测试用例设计标准，这些标准有助于使人们更舒适，从而更有效。

希望这个相当长的答案在某种程度上有所帮助。

史蒂夫。

史蒂夫，

好问题。

有很多方法可以应对你提出的挑战。在我看来，您希望 (a) 避免过多的程序性内容，而且 (b) 在您的测试设计中引入一种在团队成员之间创建更多沟通的方法（并可能增加一致性和彻底性？）是正确的过程。凯特已经提到了很多重要的观点。为了提供额外的视角，

从“多少细节才合适？” 立场，

正确处理的关键之一是不要让您的测试因过多不必要的细节而陷入困境。在确定多少细节是合适的点时，我喜欢使用这个 2x2 网格来解释有用的注意事项：

从“在设计和记录测试用例时，我应该使用哪种方法来管理它们？” 立场，

我会提倡一种相当轻量级的方法，该方法适当地平衡清晰度（因此任何查看文档的人都可以快速了解所涵盖的内容）和灵活性（因此团队中的人员可以快速做出更改）。去年，我做了一个演示，介绍了一些团队使用的各种成功方法，如下所示（包括思维导图和类似看板的解决方案）。对于您，我建议您看看 Paul Holland 的方法以及 Mozilla 团队使用的方法/通过 Marlena Compton。演示文稿中的幻灯片可在此处获得：

从双重考虑“我怎样才能使我的每个测试尽可能地覆盖而不重复已经测试过的东西（并使每个组更容易看到其他组已经在测试什么）？” 和“如何避免创建一个系统的常见问题，该系统会导致越来越多的回归测试，每次迭代都需要更长的时间来测试？”，

披露：我创建了 Hexawise 测试用例生成工具。

我建议考虑使用像Hexawise或AllPairs这样的测试用例生成工具这将允许您通过在“模型”级别按下按钮来快速创建（和/或快速修改和重新生成）测试，而不是开发需要您和您的团队成员进行更改的测试设计方法单独的测试级别，因为：(a) 对单独的测试进行更改将花费更多时间，(b) Hexawise 生成的测试方法更适合像您这样需要定期更新测试的敏捷设置，以及 (c) Hexawise 类型的测试生成方法可能会阻止您的回归测试集扩展太多，因为使用 Hexawise 生成测试可以让您通过将大多数与功能相关的功能测试构建到现有测试集中来测试不断增长的新功能列表（例如，与通过添加越来越大的测试列表来测试新功能的更常见方法相比，在现有测试中执行的场景可以变得更加多样化并产生新功能）。

我不同意您对瀑布与敏捷测试质量的观察，虽然一般结论是正确的。迭代测试周期（敏捷或普通螺旋）为测试人员提供了更好的机会来完善他们的测试，我曾在瀑布、敏捷和迭代项目中工作，并且第一个测试版本总是相同的——混乱、混乱，没有任何结果开箱即用，但是当您还有时间直到最终版本发布时，您也有时间修复所有这些环境和测试问题。