下面将介绍白盒测试用例设计方法。既然是白盒，那么肯定站在代码的角度设计测试用例。根据测试方法，测试分为静态检查和动态测试。目前广泛使用的一种静态检查方法就是CodeReview，所以这方面并不涉及测试用例的设计。动态测试主要站在逻辑覆盖的角度设计测试用例，以满足覆盖率的要求。动态测试主要遵循以下原则。
保证一个模块中的所有预期路径至少使用一次。
对所有逻辑判定条件都测试真和假。
在上下边界及可操作范围内运行所有循环。
检查内部数据结构以确保其有效性。
为了满足上述原则，白盒测试用例设计方法也遵循科学的方法，具体如图1-6所示。
图1-6 白盒测试用例设计方法
白盒测试用例设计的重点是满足覆盖率。其中，语句覆盖法重点关注是否覆盖了每一条程序语句；判定覆盖法重点关注每个逻辑判断分支是否都至少取了一次真值和一次假值；条件覆盖法重点关注每个判定语句是否都至少取了一次真值和一次假值；判定/条件覆盖法要求每个判断分支及每个判断语句都至少取了一次真值和一次假值；而条件组合覆盖法则要保障各种分支组合都至少出现一次。
从上述描述中就可以知道，白盒测试用例设计方法之间的关系如图1-7所示。
图1-7 白盒测试用例设计方法之间的关系
1.3.3 测试用例也要分级
没有任何一款软件系统是完美无缺的，任何系统都有缺陷。但是每一次迭代都会有一个期望，测试工程师需要知道本次迭代的项目干系人的预期，通过项目干系人的预期管理测试的风险。Sue Bartlett在“How to Find the Level of Quality Your Sponsor Wants”一文中描述了如何实现上述目标和降低风险。
该文章指出，在开始详细的计划、设计或者编码前就明确质量目标，这样会更好地保证交付一个满足预期质量目标的交付物。Ross Collard指出，通过10%～15%的测试用例发现被测系统中75%～90%的缺陷。
这也符合二八原则，二八原则对软件测试的影响很深。在面对成百上千的测试用例时，测试工程师要挑选出一个最小的、最重要的、优先级最高的测试用例集并不容易，且往往没有头绪。对测试用例进行优先级定义并不容易，而且优先级定义在每一次迭代中或者迭代后都有可能修改，因此测试用例的优先级是动态的。具体测试用例的优先级划分如下所示。
1．测试用例的优先级
测试用例的优先级如下。
构建验证测试（Build Verification Test，BVT，也称为P0）。BVT也称为冒烟测试用例集，是每次测试开始投入前最希望运行并得以确认的测试用例集。冒烟测试用例集的规则是如果一个测试用例无法正确执行，则其他测试用例同样无法正确执行。满足该规则的测试用例都应该纳入冒烟测试用例集。
高优先级（P1）。高优先级测试用例集是按照执行频度和业务功树的根部分支的条件选入的。高优先级测试用例是在BVT中加入的常用测试用例，用来验证重要或者主干流程的功能是否稳定、是否正确。测试用例既包含正确的数据流，也包含错误的数据流。
中优先级（P2）。中优先测试用例集是按照执行频度和业务功树的主要分支的条件选入的。中优先级测试用例更加详尽地验证新迭代影响域（新功能区域）或者功能。测试用例包含大多数的功能，其中不仅包含正确数据流和错误数据流，还应包含一些配置方面的测试。
低优先级（P3）。低优先测试用例集是按照执行频度和业务功树的根部分支的条件选入的。低优先级测试用例是最不频繁执行的测试用例。但是低并不是说不执行，不测试，只是在迭代的过程汇总，执行频率比较低，不常执行。这部分测试用例涉及错误消息、可用性、压力测试和性能测试等。
2．划分优先级
首先，进行粗略划分，任意标注。将验证全部功能的正确性的测试用例指定为高优先级的；将全部有错误或者有边界值验证的测试用例指定为中优先级的；将其他测试用例指定为低优先级的（这里面主要是非功能测试用例）。
其次，评审每一个测试用例，升级或者降级。通过对每一个测试用例及其优先级的重新评审，划分测试的重要性及执行频度等，按照下述原则进行降级处理。将功能验证测试分为两组（重要和非重要），将“不太重要”的功能验证测试降级为中优先级；将错误和边界测试分为两组（重要和非重要），将“重要”错误和边界测试提升到高优先级。将非功能性测试分为两组（重要和非重要），将“重要”非功能性测试提升到中优先级。对每组高、中和低优先级测试用例重复划分并升级/降级，直到在优先级之间移动的测试用例数量变为0为止。
最后，确定BVT。将高优先级测试分为两组，分别为致命和严重（如果出现缺陷就是致命缺陷，则这条测试用例也是致命的）。将致命的测试用例归并到BVT优先级。
优先级分布为BVT占?10%～15%，高优先级占?20%～30%，中优先级占40%～60%，低优先级占10%～15%，但是这并不是一个绝对要遵循的比例。测试用例的分级还要以实际项目的需求为准。
1.3.4 测试用例的形式
自从测试从开发工程师的调试工作中分离出来，测试用例的形式逐渐开始多样化。在传统的瀑布模式交付流程中，主要以操作步骤的形式描述测试用例。图1-8所示是一种典型的测试用例模板。
图1-8 测试用例模板
测试用例编号是唯一的，并且在全部的测试用例管理体系中也是唯一的，因此多个系统间的测试用例编号也不会重复，大部分情况下，通过在测试用例编号中加入系统缩写字段确保测试用例全局的唯一性。如果存在自动化测试脚本，那么该唯一标号也可作为自动化测试脚本的标号，这样就建立了测试用例和自动化测试脚本的映射关系，即映射矩阵。
组件/模块部分主要说明测试用例属于哪个组件或者模块，这样不仅可以粗略地给测试用例和系统实现建立一种映射关系，还可以建立一种基于系统组件/模块的测试用例分类方式。
级别即测试用例的分级。这里就涉及前面描述的测试用例分级的内容，一般包含P0级（构建验证测试）、P1级（高优先级）、P2级（中优先级）、P3级（低优先级）。
测试描述主要是测试流程的简单说明，主要作用是帮助测试工程师快速理解测试用例，而不需要阅读详细的测试步骤。
先决条件指开始执行测试步骤前必须要满足条件，否则后续测试步骤无法执行，也就无法开始测试。
测试步骤就是测试用例的具体操作步骤，每一步都要简单明了地说明具体操作和内容。
期望结果指前序测试步骤中每一步对应的系统反馈，而非全部业务执行完的最终结果。
实际结果指测试过程中实际的系统交互结果。这部分有两种描述，一种是将实际的内容记录下来，另一种是输入“与预期结果一致”，但是这里一条预期结果对应一个实际结果。
状态指执行测试用例后的结论，当实际结果和预期结果一致时，测试用例的状态为通过，否则为失败。
测试执行人指执行测试用例并记录实际结果、状态的测试工程师。
这是一种原始的测试用例模板，后续的很多测试管理系统借鉴了这种测试用例模板的原型，只是留存形式不再是电子表格，而是由管理系统员在关系数据库中维护。
在瀑布交付模式的团队中，这种记录详细的电子表格类的测试用例模式是有优越性的。传统质量保障团队是完全按照瀑布模式交付的，测试流程中的各个环节具备明显的交接界限，如图1-9所示。
图1-9 瀑布交付模式的团队合作方式
这种传统质量保障团队角色分工明确，角色间交集相对较少，项目交付以“面向测试的开发”为主，团队交付的最终质量全部依靠集成测试阶段测试工程师对系统的理解和了解程度。
因此，步骤详尽的测试用例有助于将测试过程解释清楚，这样在测试用例评审过程中，开发工程师站在已经实现的系统角度评价测试用例写得完不完善，产品经理站在系统设计的角度评价测试用例写得对不对，同时评审开发工程师实现的是否是需求文档中所描述的功能。
这种测试用例模式对于测试工程师也是有帮助的，其中既详细记录了系统的操作过程，也帮助测试工程师深入了解了实现的系统。同时，在生产出现问题时，我们可以通过测试用例是否覆盖、测试过程是否执行确定测试工程师在项目测试过程中是否有遗漏。
随着敏捷实践的不断完善，按照上述测试用例模板撰写测试用例逐渐不再适用于对应的敏捷交付团队。这是因为对于交付结果已经从对线上问题的团队追责转变成对制品交付团队问题的追责，所以并不需要某一个人或者某一个角色承担对应的责任，若团队交付的产品发生问题，这是交付团队整体的问题，并非某一个人的失误造成的。
因此，测试用例也逐渐地转变成这样一种业务梳理模式，测试工程师通过测试业务逻辑建模，整理测试业务，并在团队内部分享。目前，大部分团队以思维导图的形式完成业务逻辑的梳理工作。思维导图工具既有单机版本也有Web版本，目前开源的Web版本类似于测试用例工具，以滴滴的敏捷测试用例管理平台（AgileTC）为代表，具体可以参考对应项目在GitHub上的开源代码。
在实践测试左移时，提倡在需求进入迭代计划之前就讨论每一张需求卡片，参与每一个故事的讨论，完善每一个故事卡片的验收条件（Acceptance Criteria，又称为“验收准则”，简称AC）。在研发工程师开始满足需求之前和完成需求开发之后，测试工程师都在参与故事卡片的验收条件讨论。测试工程师开始测试之前需要根据一些常规的测试用例设计方法补充异常用例。
在整个过程中，团队都以交付高质量的项目为中心，而不再使用缺陷数、测试用例数、代码行数等不科学和不客观的考核指标。
