James Marcus Bach是软件测试人员、作家、培训师和顾问。他是探索性测试和上下文驱动的软件测试学派的支持者，并被认为开发了基于会话的测试
title: 打破测试用例的成瘾（第1部分） 最近，在一次培训课程中，一名测试人员正在努力解决她的一个疑问。 她问：为什么一些技术领导者(例如，cto、开发经理、测试经理和测试领导)想要提供可跟踪性、与涉众共享测试工作、与测试人员共享特性知识时，会直接跳到测试用例?
我不确定。我担心大多数时候，对测试用例的关注仅仅是由于无知。许多人实际上不知道其他任何思考测试的方法，并且从来没有尝试过。令人担忧的是，这似乎不仅适用于领导者，也适用于测试者。许多测试业务似乎是在神话、民间传说和惯性上蹒跚而行。
正如我们多次指出的那样 ，测试不是测试用例，而是测试用例。 测试是一种表现。 正如我们所指出的 ，测试是通过探索和实验来学习产品的过程，在某种程度上包括了提问，研究，建模，观察，推断等。您不需要测试用例。
对程序化脚本化的测试用例的痴迷是令人痛苦的，因为遵循脚本的命令消除了代理，将测试人员变成了机器人，而不是调查员。过于形式化的过程会带来过度关注测试和测试人员的严重风险。正如James Bach所说:“测试不应该太过专注……除非你想遗漏很多bug。”
我们可能希望在测试过程中检查某些特定条件， 产品元素， 质量概念 ，与其他产品的相互作用，或者可能会改变测试结果。 跟踪这些信息可能非常重要。 程序化脚本测试用例是否是唯一的跟踪方法？ 指导测试的唯一方法？ 最好的方法？ 甚至是一个好方法?
让我们看看解决领导者需求的替代方案(可跟踪性、测试工作的共享知识、共享特性知识)。
可追溯性。在我看来，可跟踪性的通常目标是能够通过将测试用例与需求相连接来描述和证明您的测试。从积极的角度来看，建立这些联系是一件好事，以确保测试人员不会在不重要的事情上浪费时间。
另一方面，测试不仅仅是确认产品是否符合需求文档。测试是关于发现与人们相关的问题。除此之外，这要求我们了解需求文档出错或根本没有讨论的地方。如果需求文档在给定的点上是不正确的或者是沉默的，那么“可跟踪的”测试用例就不能可靠地揭示问题。
因此，我们提出了一种更强大的可追踪性替代方法： 测试框架 ，它是建立和描述底部测试结果与顶部测试总体任务之间的逻辑联系的过程。
需求文档和测试用例可能出现在连接链中，也可能不出现在连接链中。只要测试人员能够明确地将测试与测试任务联系起来，就没有问题。在一个合理的工作环境中，很多时候，这种框架是默认的。如果您不相信，请暂停一下，并注意测试用例为测试人员提供一组指令的频率，但是不要描述测试的动机，或者提示它的风险。
一些测试人员可能没有足够的技能来描述他们的测试框架。如果是这样，以一种没有帮助和不可持续的方式将测试用例交给那些测试人员来掩盖问题。我认为，解决这个问题的一个更好的方法是培训和监督测试人员成为强大的、独立的、可靠的代理，可以自由地设计他们的工作，并有责任进行协商和解释。
与利益相关者共享成果。测试人员的一个关键职责是描述测试工作。同样，使用过程性脚本化的测试用例似乎是描述测试人员工作的一种特殊和有限的方法。测试人员最重要的事情是在他们的头脑中发生的:对产品建模、研究、观察、猜测、分析风险、设计实验……一组测试用例，以及某人已经完成它们的断言，并不能很好地代表测试的思考部分。
测试用例不能告诉人们关于您的建模和风险评估的太多信息。一组测试用例也不能做到这一点，典型的测试用例当然不能有效地做到这一点。谈话、列表、大纲、思维导图或报告可能是谈论风险模型或开发风险模型的过程的更合适的方式。
也许使用测试用例来描述工作最糟糕的方面是测试——测试活动的性能——变得具体化，变成了东西、小部件、testburgers。在计算测试用例方面，工作变成了重新调整，这将导致无休止的麻烦。
如果你想让人们知道你做了什么，就把你做过的事记录下来，并报告出来。讲述测试的故事，这不仅仅是关于产品的状态，还包括你是如何执行工作的，以及是什么让它变得更有价值和不那么有价值;困难或容易;慢或快。
与测试人员共享特性知识。测试人员有很多方法来学习产品，而且几乎所有的方法都比程序脚本化的测试用例更有助于学习。给测试人员一个脚本，往往会使测试人员关注于遵循脚本，而不是了解产品、人们如何评价它，以及价值如何受到威胁。
如果您想让测试人员快速地了解产品(或特性)，那么就为测试人员提供一些可以检查或交互的东西，并给测试人员一个任务。试着把测试器放在前面
要测试的产品（如果有）
产品的旧版本（正在等待更新的版本） 产品的原型（如果有） 可比或具有竞争力的产品或功能（如果有） 要分析的规格（或与产品进行比较，如果有的话） 需要研究的需求文件 审查标准 要扩展的用户故事 本教程 摘录的用户手册 要解释的图表 接受采访的产品经理 与另一个测试器配对 领域专家概述业务流程
给测试人员一个任务，让他们基于这些事情中的一个或多个来学习一些东西。要求测试人员做笔记，然后提供一些额外的证据来证明他或她学到了什么。
（如果列出的项目均不可用，该怎么办？如果所有项目均不可用，那么是否正在进行任何开发工作？如果可以，那么指导开发人员的是什么？提示：这不是开发案例！）
也许有些人关心的不是信息太少，而是太多。一个相应的担心可能是可用的信息不一致。当关于产品的重要信息丢失，或者不清楚，或者不一致时，那就是测试结果与关于项目的重要信息。错误在那些遗漏或不一致中滋生。
什么可以作为测试人员学习的证据?补充测试人员的注释，测试人员可以赋予测试人员基于其中一项或多项知识的知识。
与测试主管或测试经理进行对话
提供有关测试人员执行的活动以及测试人员所学到的内容的报告 （即测试报告 ） 产生产品或功能，错误以及所有内容的描述（请参见“诚实的手动编写器启发式” ） 提供以上列出的任何工件的建议修订，扩展或完善 确定测试人员遇到的有关产品的问题列表 制定测试人员可以识别产品与所需产品之间不一致之处的方法的列表（即，有用的预言列表） 报告测试人员在执行信息任务时遇到的问题列表 在思维导图中，概述有关测试人员如何学习更多有关产品的想法（即测试策略 ）。 列出有关产品潜在问题的一组想法（即风险列表） 针对在哪里寻找产品中的问题提出一套想法（即产品覆盖范围概述 ） 然后查看测试人员的工作。 提供反馈，指导和指导。 在测试人员学得很好的地方给予称赞； 测试人员没有的课程更正。 与遵循测试用例中的分步说明相比，测试人员从此交互过程中将获得更多收益。
上次外出时，我正在与一个培训客户沟通，一位正在致力于确定测试用例测试人员。 在这里，我称她为弗里达。 她还有更多关于如何回应经理的问题。
如果您不在家时他们希望另一个测试人员进行测试该怎么办？
我问：“您的测试”还是“您的测试工作”？
据我所知，你的测试。弗里达说:“我不同意这种看法，但是我试图从他们的角度来看问题。
我想知道如果我们问他们“如果你想让另一个经理来做你的管理，而你又没有时间，会发生什么?”或者“如果您想让另一个程序员来做编程，而这个程序员又不在，会发生什么?”“在我看来，他们最不可能提出的建议就是一套管理案例或编程案例。那么为什么要执着于测试用例呢?
我不确定。我担心大多数时候，对测试用例的关注仅仅是由于无知。许多人实际上不知道其他任何思考测试的方法，并且从来没有尝试过。令人担忧的是，这似乎不仅适用于领导者，也适用于测试者。许多测试业务似乎是在神话、民间传说和惯性上蹒跚而行。
固执是过度的，强迫性的专注于某件事而不顾其他。对测试用例的关注转移了人们对其他重要事情的注意力:理解测试如何映射到任务;测试人员是否有足够的技能来理解和执行测试;学习来自于测试，然后反馈给更多的测试; 正规化是否为时过早甚至是必要的……
正如我上次所建议的，一个大问题是管理人员对测试用例的替代方案缺乏意识。缺乏意识会导致缺乏想象力，更糟糕的是，许多测试人员都遇到相同的问题，因此无助于打破循环。 经理为什么要不断要求测试用例? 因为测试人员一直在提供它们。 测试人员为什么继续提供它们？ 因为管理人员不断要求他们，因为测试人员不断提供他们……，而且这个周期还在继续。
这个循环还在继续，因为测试用例有一个吸引人的，甚至是诱人的方面:它们可以使测试看起来清晰。正如文卡泰什?拉奥(Venkatesh Rao)在这里优美地表述的那样，易读性“平息了由明显的混乱引发的焦虑”。
测试用例有助于将开发和测试的混乱、复杂、易变的环境变得清晰、可读、可理解和可量化。 测试用例要么失败（问题！），要么通过（没问题！）。测试用例使测试人员的行为看起来是可预测和清晰的，清晰到甚至可以用机器代替测试人员。在项目开始时，我们开发了782个测试用例。当我们完成了其中的527个，测试就完成了67.39% ！
许多人认为测试是死板的，逐步的，重复的，机械的按键操作，以证明产品可以工作。 我们所处的领域强调了这一点：一个重视程序编写的领域。如果你认为键盘操作就是它的全部功能，那么编写供人跟随的程序来控制测试是有一定意义的。
这些程序成为“您的测试”。我们将这些称为“您的检查”——其中检查是将决策规则应用于软件观察的机械过程。
另一方面，如果您愿意承认并接受测试是对产品、问题和风险的复杂的、认知的调查，那么您的测试就是另外一种表现。没有人能像你一样做这件事。没人能再做你以前做过的事。你自己永远不会以同样的方式做两次。如果经理想让人们在你不在的时候做“你的测试”，那么把它想成“对你一直在调查的事情进行调查”可能更实际、更有力。
调查是有组织的，可以被引导，但是好的调查是不能照本宣科的。这是因为在真正的调查过程中，你无法确定你将会发现什么，以及你将如何应对。检查可以通过算法实现; 围绕并包含检查的测试无法进行。
可以通过替代测试用例的许多因素来影响或指导调查：
清单 覆盖范围 数据表 思维导图 风险清单 活动启发法 用户故事和叙述 现有的测试笔记或会话表 自动检查的源代码 会议章程 情景剧本 先前的测试报告 来自现场的错误报告
上一次，我提到了几乎所有这些，因为测试人员可以在了解产品或功能时进行开发。 这不是巧合。 测试发生在学习，分析，探索，实验，发现和调查的纠结循环和螺旋状中，彼此相互反馈。 随着测试的进行，这些工件以及（更重要的是）它们代表的学习可以得到进一步发展，扩展，提炼，过度生产，搁置，废弃，回收，重新研究……
测试人员可以将这类工件用作已完成测试，已发现问题以及已发生的学习的证据。 测试人员也可以在测试报告中包含这些工件。
