Lee Copeland的“软件测试设计从业人员指南”于2003年出版。
从那时起，它牢牢地扎根在任何测试人员都必须阅读的书籍清单中。 值得一读。 读起来很不错：语言并不复杂，样式很简单。 在本书的写作过程中，作者对自己，他的学生，读者以及总体上在我们的活动范围内进行了讽刺。
以下不是翻译，而是“黑匣子测试技术”部分的详细摘要，该部分描述了测试设计技术的应用。
这本书是在一位前同事的建议下落到我手中的，对此特别感谢他。
为了设计出最有效，最有效的测试用例，而不仅仅是拍打在一起。
等效类测试
边值测试
决策表测试
成对测试
状态转换测试
用例测试
等效类测试
技术
- 定义等效类。
- 为每个等效类创建测试用例。
等效类是运行相同模块并应产生相同结果的数据集。
该类中的任何数据都是等效的，这意味着，如果等效框中的一个测试用例已发现/未发现缺陷，则此等效类中的所有其他测试用例将检测/未找到相同的缺陷。
一种替代方法是不将等价类用于输入，而应将其用于输出。 将输出变量分为等效类，确定哪些输入值可以触发此类输出。 优点是检查了所有可能的退出选项。 缺点是在输出等效类中，可以隐藏几个输入等效类。
如果有几个变量：
- 几个变量的有效类合并为一个测试用例；
- 无效的类分别进行测试。
让您的设计师和程序员知道他们何时对您有所帮助。 他们会欣赏这个想法，并可能会再做一次。
边值测试
技术
- 定义等价类
- 定义每个等效类的边界
- 为每个边界值创建测试用例，直接在边界上，边界的上方和下方选择一个点。
应当记住，边界上方或下方的点可以是另一个等效类的实例，在这种情况下，您无需重复测试。
值由类型确定。 如果边界是5，则对输入整数的字段测试点4和6，对于输入卢布和科比的数量的字段测试点4.99和5.01。
如果有几个变量：
- 有效边界的最小值合并为一个测试用例；
- 有效边界的最大值在另一个测试用例中组合；
- 无效边界将分别进行测试，无效类也是如此。
边界值测试关注边界，因为这是许多缺陷隐藏的地方。
决策表测试
技术
- 定义所有条件
- 进行条件的所有可能组合
- 删除不必要的组合。 那些更改值对结果无影响（无关紧要-DC）的变量将被删除
- 定义动作
- 为每个组合创建测试用例
决策表 -表示综合条件与结果动作之间的关系。
如果条件是值的范围，则将另外创建测试以检查边界上方和下方的值。
通过仔细查看表格，您可以在规则1、2、3、4中看到，如果股票代码无效，那么检查其余条件是没有意义的。 规则5和6可以合并，因为 检查资金的条件不影响结果。 不影响结果的条件标记为“ DC”。 该表将被转换：
因为 始终存在表可能无法正确转换或代码编写得不正确的可能性，因此原始表仍在手边。
著名的软件测试员Mick Jagger就此提供了极好的建议：“您无法总是得到想要的东西，但是如果有时尝试，您可能会发现，您会得到所需的东西。”
配对测试
技术
- 定义参数
- 确定每个参数的值数（选择变量）
- 构建一个数组，其中包含每个参数的列以及包含这些参数的值的所有组合的列中的值。
- 匹配结果正交数组以进行测试。
- 建立测试用例。
通过实验确定，大多数缺陷是单模缺陷或双模缺陷，即。 当单个参数仅与另一个参数组合时显示，而其余参数的值无关紧要。
如果变量值的组合数量很大，则不应尝试测试所有可能的组合，最好集中精力测试所有变量对。
两种成对测试方法：正交数组方法和allpair算法。
正交数组是具有特殊属性的二维数组：如果选择数组中的任意两列，则参数值的所有可能组合都会出现在其中，所有成对的列都具有相同的属性。
所有对 -创建数组时，使用的算法可直接生成对，而无需使用额外的平衡。 如果存在大量带有少量值的参数，则此方法更适合配对。
不需要手动进行成对组合，为此有很多工具 。
应该记住的是，由于某些参数的组合永远不会发生，因此可能会产生限制。
没有底层的“软件缺陷物理”可以保证成对测试将是有益的。 只有一种知道的方法-试试吧。
状态转换图
技术
状态 -系统预期一个或多个事件的状态，该状态会记住输入中收到的内容并确定应发生的响应。 该事件可以进入新状态和/或启动新动作。 状态通常反映系统中某些变量的值。 以圆形描绘。
过渡 -表示由于某些操作而从当前状态过渡到新状态的过程。 描述为箭头。
事件 -导致状态更改的事件。 通常，事件是通过某个接口从外界进入系统的。 有时，此事件是在系统本身内部触发的，例如计时器，低于某个特定级别的事件。 据认为该事件是立即发生的。 一个事件可以是独立的也可以是相关的。 当事件发生时，系统可以更改状态或保持相同状态和/或启动操作。 事件可能具有关联的参数（卡号，帐户中的金额）。 描述为过渡箭头的标题。
动作 -由于状态改变而启动的操作。 这通常是一些系统响应。 请记住，在状态之间的转换期间会发生动作。 状态本身是静态的。 事件发生后，过渡箭头的签名中以斜杠表示。
状态转换图是一个特定的实体（例如，备份过程）。 一个常见的错误是试图将一个图中的不同实体混合在一起（例如，预订和乘客以及与每个实体相关联的事件和动作）。
当系统需要了解背景或正确的操作顺序时，可以使用它。
基于状态转换图，编译状态转换表。 该表包含4列：当前状态，事件，操作，下一个状态。
状态转换表的优点是它是从状态到状态的所有可能转换组合的列表，包括无效的转换。 分析此类表时，可能会注意到需求差距。 使用状态转换表可以帮助您跟踪无效的状态转换。
您可以从以下四个选项中选择一个来创建测试用例：
- 创建测试用例集，以便所有状态至少完成一次。 在一个测试案例中，可以描述通过几种状态的过渡。 这是相当薄弱的测试范围。
- 创建测试用例集，以便所有事件至少触发一次。 同时涵盖所有事件的测试用例涵盖了所有条件。 再次测试覆盖范围较弱。
- 创建测试用例集，以便所有路径至少完成一次。 从测试覆盖率的角度来看，这种方法是好的，但是实际上是不可行的。 如果该图具有循环，则可能的路径数可以是无限的。
- 创建测试用例集，以便所有转换至少完成一次。 此方法提供了良好的测试覆盖范围，因此建议使用它。
创建测试用例的推荐策略是至少测试一次所有状态转换 。 在需要更可靠的测试覆盖范围的高风险系统中，可以为状态之间的每条路径（转换链）创建测试用例。
现在换个完全不同的东西。 蒙蒂·蟒蛇
用例测试
技术
用例 -这些场景描述了参与者（通常是一个人，但可能是另一个系统）如何使用该系统实现特定目标。 用例是从用户而不是系统的角度描述的。 维护系统健康的内部工作不是用例的一部分。
至少一个测试用例应检查主要方案，至少一个用例应在替代方案中。
用例测试用例建议
- 从有效数据和最常见的场景开始。
- 检查边界值和无效值（使用先前讨论的技术）。
- 对系统至关重要的很少使用的场景（所谓的“关闭核反应堆”）
- 测试每个步骤的每个扩展分支
- 尝试以不寻常的方式执行操作
- 如果确实可能发生变态的前提
- 如果事务有循环，请循环运行，而不要一次或两次-更加困难
- 找到一条漫长而曲折的道路，并遵循它
- 如果期望以逻辑顺序执行事务，请尝试以相反的顺序执行（例如，不是从上到下，而是从下到上填写字段）
- 创建简单测试
用例描述模板
如果您不尝试奇怪的事情。 您知道用户会的。