文本
我们忘记了“测试设计”:基本的QA技能
在过去的15年中，业界对QA概念的关键发展之一是假设它由三部分技能组成，而只有三组。 这些是：
某种过程专业知识，不管它的定义是模糊的还是无用的。流程专业知识是否被实际实现似乎并不那么重要。
了解自动化测试工具及其相关脚本语言。
愿意承担所有的责任。
值得注意的是，它不仅没有出现在这份榜单上，在招聘经理的脑海中也没有出现，这可能是最明显的:
设计有效测试的能力。
几乎没有人再把这当作一项关键的QA技能了，如果这不是那么令人担忧的话，那就太可笑了。因为，无论测试是手动执行还是通过自动化执行，您首先必须知道如何首先设计一个测试。对吧?
排除测试设计方面的专业知识以支持流程和自动化存在一个明显的问题：
最重要的难道不是知道您的测试自动化要定义什么?自动化测试只是在不断的快速重复验证一些点?在做一些不称职的事情时表现出“敏捷”，我并不认为这是真正的进步。除了scrum管理员。
测试设计的重要性和原则的复兴姗姗来迟。这是我对这一努力的小小贡献。
测试并不像简单的“尝试一些东西看看会发生什么”。
一些测试人员在这种特别的、分散的方法上是成功的，至少在表面意义上“找到一个bug”——当您考虑到这一点时，这并不是对您的团队预算的有效利用，因为客户总是免费地找到bug。如果QA能够唯一地为开发和发布过程增加价值，“发现错误”就不能成为贡献，因为它是通用的。
这个特别的“过程”缺少的是关于您的“测试”是否已经完全执行了特性的功能信封的任何确定性——包括可能没有被产品正式指定或者甚至没有被工程在它的实现中预期的功能和行为。
它提出了这样一个问题，即您将如何以可靠的系统方式来派生这组测试用例/条件。
这真正触及了测试设计真正是什么，以及需要是什么的核心。
要做什么?
第一步是做出一些基本的区别，这些区别对于大多数QA人员来说已经很熟悉了，但是很少被系统地展示出来。
让我们试着做一下。
显式和隐式功能
让我们从显式功能和隐式功能之间的区别开始。
前者是我们大多数人认为的“功能性”。由产品正式指定的特性和能力，其正式规范在工程中指导其实现。
因此，如何测试它们似乎是老生常谈，但即使是定义良好的特性，情况也不是这样，我们稍后将看到。但是，至少显式功能所具有的特异性级别使围绕它构建测试脚手架(或脚手架的假象)变得更容易。 内隐功能则完全不同。
因为，根据定义，它由没有正式定义或预期的对用户或环境输入的行为和响应组成。到目前为止，在产品被QA批准发布后，没有对这个隐式功能进行充分的测试和概念化测试，是引入该领域的大多数bug的根源(另一个是在边缘硬件/软件/设备环境中进行的测试不足)。
换句话说:
测试隐式功能需要相当多的独创性和想象力。这是软件测试中真正具有创造性的部分。
测试隐式功能需要一定程度的聪明才智，才能真正擅长于此，遗憾的是，这是无法教会的。
再多的敏捷过程或自动化也不能教会你——但是可以鼓励你这么做。
那么如何定义隐式功能的测试呢?幸运的是，这可以做到。但在我们直接进入这个问题之前，让我们进一步探讨一些相关的区别。
正面测试与负面测试
大多数在质量保证部门工作了一段时间的人都知道阳性和阴性测试之间的区别。
肯定的测试正在使用设计要使用的产品。 负面测试正在使用该产品，而不是预期的那样。 就像在浴缸中使用手持式吹风机一样。
尽管这些区别在概念上很明确，但它们中的每一个都有细微差别，因此通常不予考虑。 最明显的是边缘情况，这两种情况都适用，即使是在积极测试方面也是如此。 阴性测试更明显。
但是，尽管两种测试类型之间存在明显差异，但它们对测试设计的要求相同。 一如既往，首要任务是将双方平等提出的问题参数化。
现在请注意，规范并没有提供完成此任务所需的所有信息。成为规格的奴隶——不管是产品的还是工程的——把你的注意力放在rails上。在这个过程中，过分依赖明确的定义是没有帮助的。这是我所谓的“经验谬误”的一个具体例子，也就是说，在你能理解它之前，等待某些东西明确地告诉你该做什么，或者正在发生什么。
正确的功能参数化对于成功的测试设计是至关重要的，然而这种技能很少被明确地传授。然而，这首先是一种逻辑练习，而不是观察。也就是说，您在这里的思考必须以一种清晰的意识为指导，即通过用户或环境交互作用，在系统上或系统内部可能发生什么，无论这些可能性是否在产品规范或实现的早期有意识地预想到。
在软件的白垩期(即80年代)，我对一款能够将文档从一种文字处理格式转换为另一种格式的产品进行了大量测试(它不是我们今天使用的微软word monoverse)。所以我不得不创建一个巨大的文档测试台来测试我们的转换。
这样做时，我发现这些程序中有许多非常奇怪的功能，很明显，他们自己的开发人员根本不知道这些功能的存在，更不用说我们了。举个例子:在WordPerfect中，过去完全可以在段落中插入一个行间距更改命令，而该命令只影响其后的同一段落的行。创建一种情况，即同一段落可以有两种不同的行间距。
当然，这个测试文档破坏了转换。这一次，我不能责怪我们的工程师没有预见到这种疯狂。
这就是我所说的聪明的想法。那么，让我们来讨论一些相关的参数，这些参数可以将这种聪明发挥到极致。
适用范围
就像上面给出的古老的WordPerfect例子一样，当一个特性在工程中被设计时，并不是所有相关的或可以想象的约束都必须被预见到。这意味着用户可能会在非常不合适的上下文中以非常不合适的方式部署某个特性。
这个想法类似于数据验证的概念，但适用于特性能力。例如，您不会期望能够在定义为只接受整数的数据库字段中输入文本字符串。在设计验证测试时，尝试考虑对应用程序特性范围的所有可能扩展。
工作流中断或转移
本主题假设您当然正在测试已定义的工作流。因为如果不是，那么您将面临比本文所能解决的更大的问题。
假设您是，请注意不要只测试所谓的“愉快路径”:用户描述或需求中规定的基本工作流。特别是，确保包含工作流被中断、取消和/或重新启动的测试用例。
例如，当安装被中断或取消，然后重新启动时，您可能会惊讶于有多少安装程序失败或变得非常混乱。如果您已经进行了大量的安装测试，那么也可能不会。
您还应该在用户回溯的地方添加测试用例，返回到先前的步骤以提供不同的输入。这也是缺陷的潜在来源。
另请参阅 简而言之，考虑所有可能导致流程或特性的基本工作流出现某种扭结或递归的条件。不要假设规范中已经包含了这些内容。 顺序性
特别是在高度复杂的软件系统中，其中多个并发的过程是活动的并进行交互的，理解许多严重的失败可能只会发生在某些其他事件或交互发生在失败的过程之前，这一点很重要。我们称这些为先行条件。并且检测到的问题可能仅会作为一组特定的先行条件、步骤或用户交互的结果而发生。
同样，可以预见的是，情况可能正好相反。特性或过程X的失败可能只会因为随后的步骤或交互而变得明显。也就是说，故障可能在发生的那一刻被掩盖，直到用户或系统稍后尝试做一些事情。只有在那时，它才会显现出来。
在内存管理中，这是非常常见和众所周知的。但在其他场合也同样常见。我们称这些为后续贡献条件。
为顺序性定义测试范围是测试设计中最大的挑战之一。
为什么?因为它需要深入了解复杂系统中的各种流程、服务和事件如何相互交互，以及交互的目的。
你必须为所有这些交互提出类似于状态转换模型的东西。因为其中一些本不应该在系统内实现，但最终却可能实现(造成严重破坏)。比如在同一个段落中有两个不同的行间距值。
然而，如上所述，在任何复杂的软件系统中，顺序性领域都是最丰富的严重错误来源之一，而现在，是所有这些错误的源头。所以请在你的测试设计分析中优先考虑它。
负载、复杂性、延迟
在测试设计中考虑系统负载、复杂性和延迟的宏观因素。所有这些都可能影响请求、流程或事件的执行或完成。
系统负载的相关性应该是显而易见的。在系统高负载压力期间处理请求或事务的方式显然可能会失败(在事务处理的任何阶段)。这应该是您测试计划的默认部分。我们都知道，Load也可以作为请求本身的结果生成——即。，该数据查询本身将触发处理和传输大量数据。
这里的复杂性主要指针对系统断言的请求的复杂性。这种复杂性可能包括指定条件的数量(以及它们的排除和异常)、请求中涉及的数据库(虚拟或其他)的数量，或者系统本身的处理拓扑。
在本讨论的上下文中，我使用延迟来表示在请求过程中引入的时间延迟，这不是它通常的意思。这里我指的是用户延迟，而不是系统本身的响应延迟。
换句话说，如果用户进入到流程中的某个步骤，然后暂停，什么也不做，该特性或功能将如何表现?系统超时了吗(可能应该)?它应该提示用户吗?它应该一直保持这种状态直到时间结束吗?
这些问题的答案可能在规范中提供，但是被测试的产品实际上可能没有那样的行为。这就是我们开始测试的原因。
用户角色
最终用户当然可以以各种角色与软件系统进行交互。 同一用户可以根据自己的工作以各种不同的角色与系统进行交互。
但是，流程和服务本身也可以具有不同的角色和关联的特权。 无论哪种情况，都要确保您的测试设计和计划（无论是功能还是功能）都考虑到并行使了所有可能的角色状态。
结论
测试设计词汇中的传统区别已经变得很习惯，即使对于QA之外的人也是如此。 当试图掌握胜任的，全面的测试设计所固有的复杂性时，他们的熟悉程度可能是绊脚石。 正测试与负测试都是这种情况。 因为上面讨论的所有重点领域都同样适用于这两个领域。 而且可能很难通过语言习惯的阴霾来辨别。
请注意，同样，我也没有讨论所谓的“烟雾测试”，这只是一个很好的说法，“我们不知道我们在做什么，但无论如何我们都在做。” 该概念不应在您的质量检查词汇或练习中占有一席之地。
我不会假装上面提出的讨论是详尽无遗的。 它只是目录简介的序言。 首先，这意味着激发您对主题的思考，以及如何提高测试设计的整体性。
我欢迎读者有任何见解或想法。 祝您质量检查工作一切顺利。
author
石头 磊哥 seven 随便叫
company
thoughtworks
大家好，本人不才，目前依旧混迹于thoughtworks，做着一名看起来像全栈的QA，兴趣爱好前端，目前是thoughtworks 西安QA社区的leader，如果有兴趣分享话题，或者想加入tw，可以找我
roles
QA（营生） dev（front-end dev 兴趣爱好）
联系方式
如果想转载或者高薪挖我 请直接联系我 哈哈
wechat:
qileiwangnan
email:
qileilove@gmail.com
