在典型的分布式系统中，允许存在许多种受支持的硬件和软件组合。为了核实测试目标在不同的配置情况下（如不同的操作系统、浏览器或 CPU 的速度）能否正常工作或执行，应该对此进行测试。此外，测试还应涵盖构件的组合，以便检测在不同构件的交互中产生的缺陷。例如，确保由应用程序安装的 DDL 版本不会与另一个应用程序需要的相同 DDL 的版本发生冲突。
采用下列指南来生成用于配置测试的测试用例：
确保对每个关键配置，应至少存在一个测试用例可用于对其进行确定。这是通过确定测试目标的环境所要求的硬件和软件配置以及确定这些配置的优先级来完成的。应确保最先测试最常见的配置，包括： 打印机支持 网络连接 - 局域网和广域网 服务器配置 - 服务器驱动程序、服务器硬件 台式机和/或服务器上安装的其他软件 所有已安装软件的软件版本 确保对于每个可能有问题的配置至少存在一个测试用例。这些配置可能包括： 具有最低性能的硬件。 历史上存在兼容性问题的共驻内存的软件。 通过最慢的 LAN/WAN 连接访问服务器的客户机。 资源不足（缓慢的 CPU 速度、最小的内存或分辨率，磁盘空间不足等等） 为安装测试生成测试用例安装测试需要核实测试目标可以在所有可能的安装情况下安装。安装情况可以指首次安装测试目标，或是在装有较早版本的机器上安装测试目标的某个较新的版本或工作版本。安装测试还应确保在遇到异常情况时（如磁盘空间不足），测试目标的执行情况仍可接受。
测试用例应包含以下各种软件的安装情况：
分发介质，例如磁盘、CD-ROM 或文件服务器。 首次安装。 完全安装。 自定义安装。 升级安装。客户机服务器软件的安装程序具备一组特定的测试用例。不同于基于主机的系统，服务器和客户机上的安装程序是有所不同的。因而，安装测试应执行构成测试目标的所有构件的安装，包括客户机、中间层以及服务器，这一点至关重要。
为其他非功能性测试生成测试用例理论上,应找到所有必需的输入来生成测试用例模型、设计模型以及补充规约工件的测试用例。不过，如果此时您需要补充已有的输入，那也不足为奇。
示例如下：
操作测试（用以检验在某次故障发生后以及在下一次故障发生前“较长时间”内软件的运行情况）的测试用例。 对性能瓶颈、系统容量或测试目标的强度承受能力进行调查的测试用例。大多数情况下，您可以通过先前所确定的测试用例生成的某些测试用例来构建其变体或聚合关系体，借此来查找测试用例。
九、为单元测试生成测试用例
单元测试要求既测试单元的内部结构同时还要测试其行为特征。测试内部结构要求了解实施单元的方式，基于这种了解的测试被称为白盒测试。对单元行为特征的测试侧重于从外部可观察的单元行为，而不需要了解或考虑其实施方式。基于这种方法的测试称为黑盒测试。基于这两种方法所生成的测试用例的说明如下。
白盒测试
理论上，应通过代码测试每一条可能的路径。在所有这些非常简单的单元内实现这样的目标是不切实际或几乎是不可能的。作为最基本的测试，应将每个决定到决定路径（DD 路径）测试至少一次，这样可确保将所有语句至少执行一次。决定通常是指 if 语句，而 DD 路径是两个决定之间的路径。
要达到这种程度的测试覆盖，建议您在选择测试数据时应使每个决定都可以用每种可能的方法来评估。为达到上述目标，测试用例应确保：
每个布尔表达式的求值结果为 true 和 false。例如，表达式 (a<3) OR (b>4) 的求值结果为 true/false 的四种组合
每一个无限循环至少要执行零次、一次和一次以上。
可使用代码覆盖工具来确定白盒测试未测试到的代码。在进行白盒测试的同时应进行可靠性测试。
示例：
假设您对类 Set of Integers 中的 member 函数执行结构测试。该测试在二进制搜索的帮助下，将检查该集合是否包含了某个指定的整数。
成员 (member) 函数以及相应的流程图。虚线箭头指示出如何通过采用两个测试用例将所有语句至少执行一次。
理论上，对于彻底测试的某个操作，测试用例应遍历代码内路径的所有组合情况。在 member 函数的 while-loop 中存在三个可选择的路径。测试用例可以多次遍历该循环，或是根本就不遍历。如果测试用例根本就没有遍历循环，则在代码中只能找到一条路径。如果遍历循环一次，您将发现有三条路径。如果遍历两次，则您将发现存在六条路径，如此类推。因而，路径的总数应该是：1+3+6+12+24+48+...，在实际情况中，这个路径组合总数根本无法无法处理。这就是为什么必须选择所有这些路径的子集的原因。本示例中，可以采用两个测试用例来执行所有的语句。其中一个测试用例中，您可以选择 Set of Integers = {1,5,7,8,11}，而且测试数据 t = 3。在另一个测试用例中，您可以选择 Set of Integers = {1,5,7,8,11}，且 t = 8。
黑盒测试
黑盒测试的目的是为了在不了解单元将如何实施指定行为的情况下，对指定行为进行验证。黑盒测试侧重并依赖于单元的输入和输出。
等价类划分是一种用来减少所需测试数量的技术。对于每一个操作都应确定参数和对象状态的等价类。等价类是一组值的集合，对这组值来说，对象的行为应类似。例如，一个集合可有三个等价类：空、若干元素以及满。
可使用代码覆盖工具来确定白盒测试未测试到的代码。在进行黑盒测试的同时应进行可靠性测试。
接下来的两个小节说明了如何通过选择特定参数的测试数据来确定测试用例。
基于输入参数的测试用例
输入参数是由某个操作使用的参数。对于以下每个输入条件，都应通过使用每个操作的输入参数来编制测试用例：
每个等价类的正常值。
每个等价类的边界值。
等价类之外的值。
非法值。
请记住要将对象状态视作输入参数。例如：如果在对集合这个对象测试添加操作，您必须使用集合内所有等价类的值来测试添加操作。所有等价类的值指的是：充满元素的集合、有若干元素的集合、以及空集合。
基于输出参数的测试用例
输出参数是某个操作所改变的参数。某个参数既可以是输入参数也可以是输出参数。根据以下每个条件选择输入，以便获得输出。
每个等价类的正常值。
每个等价类的边界值。
等价类之外的值。
非法值。
请记住将对象状态视为输出参数。例如，假设您对某个列表测试删除操作，您必须选择输入值以便执行操作之后，列表为充满状态、具有若干元素或为空（采用它的所有等价类的值进行测试）。
如果对象受状态控制（根据对象的状态产生不同的反应），您应利用状态矩阵，如下图所示：
用于测试的状态矩阵。您可以在此矩阵的基础上测试激励和状态的所有组合。
十、为产品验收测试生成测试用例
产品验收测试是部署软件前的最后测试操作。验收测试的目标在于核实软件是否已经准备就绪，而且可以由最终用户按软件设计来执行功能和任务。产品验收测试通常不仅涉及执行软件以确认其是否准备就绪，还涉及交付给客户的所有产品工件，如培训、文档和包装。
为软件工件生成测试用例是按上文中说明的方式实现的。测试用例可与上面确定的测试用例（正式）或某个子集（非正式）相同或类似，这取决于产品验收测试的正式程度。不管测试用例的深度如何，应该在实施和执行产品测试之前对测试用例和产品验收计划达成共识。
对非软件工件的评估将随着被评估工件的不同而相去甚远。请参见每个特定非软件工件的指南以及核对清单，查看这些工件的评估内容和评估方式。
十一、为回归测试编制测试用例
回归测试比较同一测试目标的两个工作版本或版本，并将差异确定为潜在缺陷。据此可假定：新版本应该象早先版本一样操作，并确保并未因为版本的变化而带来缺陷。
理想状态下，您可能希望一次迭代内的所有测试用例都能在后续迭代内使用。应遵照下列指导原则来确定、设计并实施测试用例，这些测试用例可以最大限度地发挥回归测试和复用的价值，同时将维护的成本减至最低：
确保测试用例只确定关键的数据元素（创建/支持被测试的条件所需的数据元素）
确保每个测试用例都说明或代表一个唯一的输入集或事件序列，其结果是独特的测试目标行为
消除多余或等效的测试用例
将具有相同的测试目标初始状态和测试数据状态的测试用例组合到一起
文章来源于领测软件测试网 https://www.ltesting.net/
