我想实现某种标准，而又不会使测试人员陷入测试用例的困境设计。我宁愿他们比在编写测试用例上花更多的时间在产品探索性测试上。我是否可以实施一个轻量级的设计标准，以便任何人都可以推荐它适合敏捷商店？
第二个问题是，标准首先是正确的方法吗？我担心尝试在整个组织中强制执行此行为。
#1 楼
首先回答第二个问题：是的，您绝对需要测试用例设计标准。他们不必是怪物。与所有敏捷一样，它们需要足够。对于第一个问题，没有“正确”的答案，但是我可以给出一些指导。您的标准应基于一种测试案例分类：首要任务是能够设置和验证每个案例的用户接受测试。其次是钢丝上的其他东西。之后，您将查看80/20规则和系统区域之间的关键边界。
您将需要一些指导方针/标准，以使好的自动化测试用例添加到您现有的自动化中。只要您的测试团队中的每个自动化人员都可以选择并添加到需要的任何自动化项目中，就可以采用各种不同的自动化方法。
我在哪里使用的一些标准我正在工作（这并不完全敏捷，它的应用程序代码库大约有200万行代码，其中一些可追溯到1996年，并且以令人难以置信的速度添加了新功能）是：
不管是什么，都包括安装说明。您无法保证下一个要解决的人知道如何配置它。
无论如何记录下来，说出您期望发生的事情以及什么构成失败。团队的其余成员都不介意读者。
首先关注验证和验证预期功能。然后检查您知道的任何相关内容并将其列出。在遇到负面事件之后（警告：“如果有时间的话”）
对探索性测试进行汇总后，您可以将遇到的任何有问题或尴尬的案例添加到团队的知识库中。
跨关联尽可能多。如果您知道它涉及其他五个模块，请确保将它们全部列出，以便当有人去寻找涉及其中一个的测试用例时，他们会找到您的模块。
每次都清楚而简单的节奏。
了解您的听众：在我工作的地方，我们假设我们对应用程序有基本的了解，因为我们是一家企业对企业的商店，并且我们将始终拥有受过培训的用户。如果您要处理的是面向公众的网站，则可能不愿承担任何知识。这会影响您需要在设计和文档中添加的详细程度。
拥有一个已达成共识的存储库。如果没有一个中央存储库，您可以通过模块，功能集以及您认为需要的其他任何内容来搜索您拥有的所有测试用例，则无法开始计算跨模块和模块内的范围。 br />全局测试用例可能不需要存储在存储库中（诸如拼写检查，表单上的制表顺序之类的东西-测试那些是“每次都习惯”的事情之一-或者应该如此）。如果不是，则必须将全局用例毕竟放在存储库中。
如果测试需要专用设备，请确保测试用例中安装和配置设备所需的所有内容（包括安装位置）。
如果测试取决于特定的数据，则包括在测试用例中从何处获取数据。
具有双方同意的模块清单。列表中的内容与团队中每个人都可以使用的列表无关紧要。
有一些很好的免费工具，例如测试链接，可让您构建一个测试用例存储库（按模块），并确定您的核心回归用例，可自动化用例和差距。我不能提供更多，因为我的工作场所正在对此进行介绍。我们一直在使用目录结构，事实证明该目录结构非常麻烦-结果很丑陋。您越早拥有存储库，就越容易知道没有存储库的情况。
距离完整的答案还有很长的路要走，但这是工作的起点。
希望对您有帮助。
#2 楼
我认为您是在自己找到第二个问题的答案，但是要避免含糊不清，是的，我认为测试用例设计标准是正确的方法。对于测试用例设计，我们必须记住最初提出并使用它们时，绝大多数测试是使用传统的瀑布/分阶段方法进行的，这实际上意味着测试是在项目结束时完成的。因此，测试团队可以花时间（可以这么说）并思考最有效的方法，以生成最小的测试用例集，以提供最大的覆盖范围。
然而，我们今天生活在测试世界中与分阶段的软件开发方法相比，诸如敏捷之类的开发方法要求人们几乎实时地识别，构建和验证解决方案。因此，测试人员无法花2或3天的时间将测试套件微调成最小的组合。
我打算在哪里使用它？
我仍然认为设计标准在敏捷方法论中同样适用，您只需要寻找不同的信号，并可能使用适合敏捷的术语即可。例如，如果您使用故事卡来解释用户的旅程，那么您可以放下赌注，并声明“火柴人”将永远只代表真实人物执行的过程-因此，您已经制定了设计标准每个人都可以联系到的。
我相信，无论使用什么开发方法，您都应该能够定义并同意测试用例的设计标准，这些标准将使人们更加舒适并因此更加有效。 。
希望这个较长的答案在某种程度上有所帮助。
史蒂夫。
#3 楼
史蒂夫，很好的问题。
有很多方法可以应对您提出的挑战。我认为，您既要（a）避免过多的程序性工作，又要（b）引入一种在测试设计中创建团队成员之间更多交流的方式（也许可以增加一致性和完整性？）是正确的。处理。凯特已经提到很多要点。为了提供另一个视角，
从“多少细节合适？”开始。立场，
要正确做的一件重要事情就是不要让测试陷入不必要的细节。我喜欢使用2x2网格来解释确定适当的细节点时的有用注意事项：
从“我应该使用哪种方法来管理测试用例它们是经过设计和记录的？”立场，
我主张一种轻量级的方法，该方法可以适当地兼顾清晰度（以便查看文档的任何人都可以快速了解所涵盖的内容）和灵活性（以便团队中的人员可以快速进行更改） ）。去年，我在下面的演讲中介绍了一些团队使用的各种成功方法（包括思维导图和类似看板的解决方案）。对于您来说，我建议您看看Paul Holland的方法以及Mozilla团队（通过Marlena Compton）使用的方法。演示文稿的幻灯片可在此处找到：
出于双重考虑，“我如何使我的每个测试尽可能地覆盖而不重复那些已经进行了测试（并使每个小组都可以轻松查看已经进行了测试的其他小组）？”和“如何避免创建一个导致越来越多的回归测试的系统的普遍问题，而每次回归都需要花费更长的时间进行测试？”，
披露：我创建了六方测试用例生成工具。
我建议考虑使用像Hexawise或AllPairs这样的测试用例生成工具，该工具允许您通过按“模型”级别的按钮来快速创建（和/或快速修改和重新生成）测试，而不是开发一个测试用例。要求您和您的团队成员在单个测试级别进行更改的测试设计方法，因为：（a）对单个测试进行更改将花费更多的时间，（b）十六进制生成的测试方法更适合于诸如您的测试需要定期更新的地方；以及（c）一种Hexawise类型的测试生成方法可能会阻止您的回归测试集扩展太多，因为使用Hexawise生成测试可以允许您通过构建测试来测试不断增长的新功能列表与功能相关的大多数功能测试都已包含在一组现有的测试中（例如，在现有测试中执行的场景可能会变得更加多样化并影响新功能，而测试新功能的方法则更为常见通过添加越来越多的测试列表）。
#4 楼
我不同意您对瀑布式测试与敏捷测试质量的观察，尽管总体结论是正确的。迭代测试周期（敏捷或普通螺旋）为测试人员提供了更好的机会来提高他们的测试水平，在瀑布，敏捷和迭代项目中，要测试的第一个发行版始终是相同的—混乱，混乱，没有现成的可用方法，但是当您仍有时间发布最终版本时，您也有时间修复所有这些环境和测试问题。
评论
史蒂夫（Steve），您提到了对与我正交的三个问题的担忧：测试范围，GUI自动化和跨团队测试。这些都是很好的主题，但可能有助于将它们分解为单独的问题。在每个问题中，它也可能有助于描述（或举例说明）该区域如何变得难以管理。感谢您的所有回复。我知道确实没有一个明确的答案，每个人都给我提供了创建标准时要考虑的好主意。