打破测试用例的成瘾（第1部分）

https://www.developsense.com/blog/2019/01/breaking-the-test-case-addiction-part-1/ 翻译： James Marcus Bach是软件测试人员、作家、培训师和顾问。他是探索性测试和上下文驱动的软件测试学派的支持者，并被认为开发了基于会话的测试

title: 打破测试用例的成瘾（第1部分） 最近，在一次培训课程中，一名测试人员正在努力解决她的一个疑问。 她问：为什么一些技术领导者(例如，cto、开发经理、测试经理和测试领导)想要提供可跟踪性、与涉众共享测试工作、与测试人员共享特性知识时，会直接跳到测试用例?

我不确定。我担心大多数时候，对测试用例的关注仅仅是由于无知。许多人实际上不知道其他任何思考测试的方法，并且从来没有尝试过。令人担忧的是，这似乎不仅适用于领导者，也适用于测试者。许多测试业务似乎是在神话、民间传说和惯性上蹒跚而行。

正如我们多次指出的那样 ，测试不是测试用例，而是测试用例。 测试是一种表现。 正如我们所指出的 ，测试是通过探索和实验来学习产品的过程，在某种程度上包括了提问，研究，建模，观察，推断等。您不需要测试用例。

对程序化脚本化的测试用例的痴迷是令人痛苦的，因为遵循脚本的命令消除了代理，将测试人员变成了机器人，而不是调查员。过于形式化的过程会带来过度关注测试和测试人员的严重风险。正如James Bach所说:“测试不应该太过专注……除非你想遗漏很多bug。”

我们可能希望在测试过程中检查某些特定条件， 产品元素， 质量概念 ，与其他产品的相互作用，或者可能会改变测试结果。 跟踪这些信息可能非常重要。 程序化脚本测试用例是否是唯一的跟踪方法？ 指导测试的唯一方法？ 最好的方法？ 甚至是一个好方法?

让我们看看解决领导者需求的替代方案(可跟踪性、测试工作的共享知识、共享特性知识)。

可追溯性。在我看来，可跟踪性的通常目标是能够通过将测试用例与需求相连接来描述和证明您的测试。从积极的角度来看，建立这些联系是一件好事，以确保测试人员不会在不重要的事情上浪费时间。

另一方面，测试不仅仅是确认产品是否符合需求文档。测试是关于发现与人们相关的问题。除此之外，这要求我们了解需求文档出错或根本没有讨论的地方。如果需求文档在给定的点上是不正确的或者是沉默的，那么“可跟踪的”测试用例就不能可靠地揭示问题。

因此，我们提出了一种更强大的可追踪性替代方法： 测试框架 ，它是建立和描述底部测试结果与顶部测试总体任务之间的逻辑联系的过程。

需求文档和测试用例可能出现在连接链中，也可能不出现在连接链中。只要测试人员能够明确地将测试与测试任务联系起来，就没有问题。在一个合理的工作环境中，很多时候，这种框架是默认的。如果您不相信，请暂停一下，并注意测试用例为测试人员提供一组指令的频率，但是不要描述测试的动机，或者提示它的风险。

一些测试人员可能没有足够的技能来描述他们的测试框架。如果是这样，以一种没有帮助和不可持续的方式将测试用例交给那些测试人员来掩盖问题。我认为，解决这个问题的一个更好的方法是培训和监督测试人员成为强大的、独立的、可靠的代理，可以自由地设计他们的工作，并有责任进行协商和解释。

与利益相关者共享成果。测试人员的一个关键职责是描述测试工作。同样，使用过程性脚本化的测试用例似乎是描述测试人员工作的一种特殊和有限的方法。测试人员最重要的事情是在他们的头脑中发生的:对产品建模、研究、观察、猜测、分析风险、设计实验……一组测试用例，以及某人已经完成它们的断言，并不能很好地代表测试的思考部分。

测试用例不能告诉人们关于您的建模和风险评估的太多信息。一组测试用例也不能做到这一点，典型的测试用例当然不能有效地做到这一点。谈话、列表、大纲、思维导图或报告可能是谈论风险模型或开发风险模型的过程的更合适的方式。

也许使用测试用例来描述工作最糟糕的方面是测试——测试活动的性能——变得具体化，变成了东西、小部件、testburgers。在计算测试用例方面，工作变成了重新调整，这将导致无休止的麻烦。

如果你想让人们知道你做了什么，就把你做过的事记录下来，并报告出来。讲述测试的故事，这不仅仅是关于产品的状态，还包括你是如何执行工作的，以及是什么让它变得更有价值和不那么有价值;困难或容易;慢或快。

与测试人员共享特性知识。测试人员有很多方法来学习产品，而且几乎所有的方法都比程序脚本化的测试用例更有助于学习。给测试人员一个脚本，往往会使测试人员关注于遵循脚本，而不是了解产品、人们如何评价它，以及价值如何受到威胁。

如果您想让测试人员快速地了解产品(或特性)，那么就为测试人员提供一些可以检查或交互的东西，并给测试人员一个任务。试着把测试器放在前面

##要测试的产品（如果有）

产品的旧版本（正在等待更新的版本） 产品的原型（如果有） 可比或具有竞争力的产品或功能（如果有） 要分析的规格（或与产品进行比较，如果有的话） 需要研究的需求文件 审查标准 要扩展的用户故事 本教程 摘录的用户手册 要解释的图表 接受采访的产品经理 与另一个测试器配对 领域专家概述业务流程

给测试人员一个任务，让他们基于这些事情中的一个或多个来学习一些东西。要求测试人员做笔记，然后提供一些额外的证据来证明他或她学到了什么。

（如果列出的项目均不可用，该怎么办？如果所有项目均不可用，那么是否正在进行任何开发工作？如果可以，那么指导开发人员的是什么？提示：这不是开发案例！）

也许有些人关心的不是信息太少，而是太多。一个相应的担心可能是可用的信息不一致。当关于产品的重要信息丢失，或者不清楚，或者不一致时，那就是测试结果与关于项目的重要信息。错误在那些遗漏或不一致中滋生。

什么可以作为测试人员学习的证据?补充测试人员的注释，测试人员可以

赋予测试人员基于其中一项或多项知识的知识。

# 与测试主管或测试经理进行对话

提供有关测试人员执行的活动以及测试人员所学到的内容的报告 （即测试报告 ） 产生产品或功能，错误以及所有内容的描述（请参见“诚实的手动编写器启发式” ） 提供以上列出的任何工件的建议修订，扩展或完善 确定测试人员遇到的有关产品的问题列表 制定测试人员可以识别产品与所需产品之间不一致之处的方法的列表（即，有用的预言列表） 报告测试人员在执行信息任务时遇到的问题列表 在思维导图中，概述有关测试人员如何学习更多有关产品的想法（即测试策略 ）。 列出有关产品潜在问题的一组想法（即风险列表） 针对在哪里寻找产品中的问题提出一套想法（即产品覆盖范围概述 ） 然后查看测试人员的工作。 提供反馈，指导和指导。 在测试人员学得很好的地方给予称赞； 测试人员没有的课程更正。 与遵循测试用例中的分步说明相比，测试人员从此交互过程中将获得更多收益。

我的指导客户有一些关于测试用例的问题。我们下次再讲。

我的个人主页：qaseven.cn

** [email protected] ** 我的微信: 15619208923