软件测试设计指南.docx

测试设计指南自 2005 年 6 月 1 日起正式生效XXX 公司编制：审批：文档修改历史日期版本作者修改内容评审号变更控 制号发布日期2005-6-1301.00.000目录1 摘要 42 测试用例设计 42.1 概述 42.2 测试用例分类 52.3 测试用例组成 52.4 功能测试用例 62.5 性能测试用例 62.6 安全性/访问控制测试用例 72.7 配置测试用例 72.8 安装测试用例 72.9 其他非功能性测试用例 82.10 单元测试用例 82.10.1 白盒测试 82.10.2 黑盒测试 92.11 开发场所的产品验收测试用例 102.12 回归测试用例 103 测试数据设计 113.1 概述 113.2 深度 113.3 宽度 123.4 范围 143.5 构架 153.5.1 不稳定性/隔离 153.5.2 初始状态 16测试设计指南1摘要本文档主要介绍测试设计，包括测试用例、测试数据设计的方法，提供参考 测试脚本的设计在测试执行指南中描述2测试用例设计2.1概述要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐 述，以便对这些期望进行核实并确认其有效性。

测试用例反映了要核实的需求 然而，核实这些需求可能通过不同的方式并由不同的测试员来实施例如，执行 软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来 实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率 和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或 最关键的需求则关系到项目的成败选中要核实的需求将是对成本、风险和对该 需求进行核实的必要性这三者权衡考虑的结果确定测试用例之所以很重要，原因有以下几方面口 测试用例构成了设计和制定测试过程的基础口 测试的“深度”与测试用例的数量成比例由于每个测试用例反映不同的 场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产 品质量和测试流程也就越有信心口 判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成95 %的测试”更 有意义口 测试工作量与测试用例的数量成比例根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。

口 测试设计和开发的类型以及所需的资源主要都受控于测试用例2.2测试用例分类测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型 和需求进行相应地改变最佳方案是为每个测试需求至少编制两个测试用例：口 一个测试用例用于证明该需求已经满足，通常称作正面测试用例；口另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只 有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例测试用例已被确定用来执行测试目标中所有的产品需求行为，包括（视情况而 定）：1） 功能2） 数据确认3） 业务规则实施4） 测试目标工作流程或控制5） 数据流6） 对象状态7） 性能（包括工作量、配置和强度）8） 安全性/可访问性9） 兼容性2.3测试用例组成测试用例最基本的元素包括：测试用例ID、测试优先级、被测试对象介绍、测 试范围与目的、测试环境、测试步骤、输入测试数据、期望输出结果1） 所有的测试用例名称和/或ID都与测试工件命名约定一致2） 每个测试用例都应该权衡成本、风险和对该需求进行核实的必要性，确定其 优先级，保证优先级高的测试用例得以执行和验证3） 每个测试用例都应该对应特定的测试对象，例如同一个测试用例对不同版本 的同一测试对象其预期结果都未必相同。

4） 每个测试用例（或每组相关的测试用例）确定初始的测试目标状态5） 测试环境描述测试用例运行所基于的软硬件环境条件6） 测试步骤描述执行该测试用例的详细动作及操作序列7） 测试输入数据描述在执行该测试用例时，由主角输入的与之交互的对象、字 段和特定数据值（或生成的对象状态）8）预期结果描述执行该测试用例完毕后得到的状态或数据2.4功能测试用例用于功能性测试的测试用例来源于测试目标的用例应该为每个用例场景编制测 试用例用例场景要通过描述流经用例的路径来确定，这个流经过程要从用例开 始到结束遍历其中所有基本流和备选流在确定功能性测试用例时，确保满足下列条件：口 已经为每个用例场景确定了充足的正面和负面测试用例口 测试用例可以处理用例所实施的所有业务规则，确保对于业务规则，无论是在内部、外部还是在边界条件/值上都存在测试用例口 测试用例可以处理所有事件或动作排序（如在设计模型的序列图中确定的内容），还应能处理用户界面对象状态或条件口 测试用例可以处理为用例所指定的任何特殊需求，如最佳/最差性能，有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一 起2.5性能测试用例性能测试用例的主要输入是补充规约，补充规约中包含了非功能性需求。

为性能 测试生成测试用例时，请使用下列指南：口 对于补充规约内阐明性能标准的各条说明都应确保至少要确定一个测试用例性能标准通常表示为时间/事务、事务量/用户或百分数的形式口 对每个关键用例，都应确保至少要确定一个测试用例关键用例是在上述说明中和或在测试计划文档中确定的、必须采用性能评测方法来评估的用例与功能性测试的测试用例类似，通常对于每个用例/需求都会存在不止一个测试 用例常见的情况是：存在一个低于性能阈值的测试用例、一个处于阈值上的测 试用例，还有一个测试用例高于阈值除了以上性能标准以外，确保已确定影响响应时间的特定条件，包括：口 数据库的大小-存在多少个记录？口 工作量-同时执行操作的最终用户的数量和类型，以及要同时执行的事务的数量和 类型口 环境特征（硬件、网件以及软件配置）将用于性能测试的测试用例记录在类似于功能测试所使用的矩阵中2.6安全性/访问控制测试用例角色和用例一同说明系统外部用户与系统所执行的动作之间的交互，以便为特定 主角生成测试结果复杂系统包含许多角色，所以我们编制测试用例时必须确保 只有指定执行用例的角色可以进行此操作，这一点非常关键在基于角色类型的 用例事件流存在差别时，尤其如此。

2.7配置测试用例在典型的分布式系统中，允许存在许多种受支持的硬件和软件组合为了核实测 试目标在不同的配置情况下（如不同的操作系统、浏览器或CPU的速度）能否 正常工作或执行，应该对此进行测试此外，测试还应涵盖构件的组合，以便检 测在不同构件的交互中产生的缺陷例如，确保由应用程序安装的DDL版本不 会与另一个应用程序需要的相同DDL的版本发生冲突采用下列指南来生成用于配置测试的测试用例：口 确保对每个关键配置，应至少存在一个测试用例可用于对其进行确定这是通过确定测试目标的环境所要求的硬件和软件配置以及确定这些配置的优 先级来完成的应确保最先测试最常见的配置，包括：打印机支持网络连接-局域网和广域网服务器配置-服务器驱动程序、服务器硬件台式机和/或服务器上安装的其他软件 所有已安装软件的软件版本口 确保对于每个可能有问题的配置至少存在一个测试用例这些配置可能包括：具有最低性能的硬件历史上存在兼容性问题的共驻内存的软件通过最慢的LAN/WAN连接访问服务器的客户机资源不足（缓慢的CPU速度、最小的内存或分辨率，磁盘空间不2.8安装测试用例安装测试需要核实测试目标可以在所有可能的安装情况下安装。

安装情况可以指 首次安装测试目标，或是在装有较早版本的机器上安装测试目标的某个较新的版 本或工作版本安装测试还应确保在遇到异常情况时（如磁盘空间不足），测试 目标的执行情况仍可接受测试用例应包含以下各种软件的安装情况：口 分发介质，例如磁盘、CD-ROM或文件服务器口 首次安装口 完全安装口 自定义安装口 升级安装客户机服务器软件的安装程序具备一组特定的测试用例不同于基于主机的系 统，服务器和客户机上的安装程序是有所不同的因而，安装测试应执行构成测 试目标的所有构件的安装，包括客户机、中间层以及服务器，这一点至关重要2.9其他非功能性测试用例理论上，应找到所有必需的输入来生成测试用例模型、设计模型以及补充规约工 件的测试用例不过，如果此时您需要补充已有的输入，那也不足为奇示例如下：口 操作测试(用以检验在某次故障发生后以及在下一次故障发生前“较长时间”内软件的运行情况)的测试用例口 对性能瓶颈、系统容量或测试目标的强度承受能力进行调查的测试用例大多数情况下，您可以通过先前所确定的测试用例生成的某些测试用例来构建其 变体或聚合关系体，借此来查找测试用例2.10单元测试用例单元测试要求既测试单元的内部结构同时还要测试其行为特征。

测试内部结构要求了解实施 单元的方式，基于这种了解的测试被称为白盒测试对单元行为特征的测试侧重于从外部可 观察的单元行为，而不需要了解或考虑其实施方式基于这种方法的测试称为黑盒测试基 于这两种方法所生成的测试用例的说明如下2.10・1白盒测试理论上，应通过代码测试每一条可能的路径在所有这些非常简单的单元内实现 这样的目标是不切实际或几乎是不可能的作为最基本的测试，应将每个决定到 决定路径(DD路径)测试至少一次，这样可确保将所有语句至少执行一次决 定通常是指if语句，而DD路径是两个决定之间的路径要达到这种程度的测试覆盖，建议您在选择测试数据时应使每个决定都可以用每 种可能的方法来评估为达到上述目标，测试用例应确保：口 每个布尔表达式的求值结果为true和false例如，表达式(a<3) OR(b>4)的求值结果为true/false的四种组合口 每一个无限循环至少要执行零次、一次和一次以上可使用代码覆盖工具来确定白盒测试未测试到的代码在进行白盒测试的同时应 进行可靠性测试2.10.2黑盒测试黑盒测试的目的是为了在不了解单元将如何实施指定行为的情况下，对指定行为 进行验证黑盒测试侧重并依赖于单元的输入和输出。

等价类划分是一种用来减少所需测试数量的技术对于每一个操作都应确定参数 和对象状态的等价类等价类是一组值的集合，对这组值来说，对象的行为应类 似例如，一个集合可有三个等价类：空、若干元素以及满可使用代码覆盖工具来确定白盒测试未测试到的代码在进行黑盒测试的同时应 进行可靠性测试接下来的两个小节说明了如何通过选择特定参数的测试数据来确定测试用例2・10・2・1基于输入参数的测试用例输入参数是由某个操作使用的参数对于以下每个。