软件测试设计--判定表法

测试用例

• 测试用例是软件测试的核心
• 如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。

测试用例的重要性

• 有效性
• 测试用例是测试人员测试过程中的重要参考依据，准确的测试用例的计划、执行和跟踪是测试的有效性的有力证明
• 可复用性
• 设计良好的测试用例可以重复执行，能节约时间，提高测试效率
• 易组织性
• 清晰详细的测试用例能够便于测试执行的开展
• 可管理性
• 测试用例也可以作为检验测试人员进度、工作量以及跟踪管理测试人员工作效率的因素
• 可评估性
• 测试用例的通过率是检验代码质量的保证

测试用例的特征

1、最有可能抓住错误的
2、不是重复的、多余的
3、一组相似测试用例中最有效的
4、既不是太简单，也不是太复杂
5、模板可以根据所测对象的不同对模板内容进行调整

编写测试用例的优缺点

• 优点
• 便于梳理需求
• 验证产品的需求是否合理
• 监督产品对需求做出更加详细的设计
• 记录产品的设计细节，保障以后的查阅
• 加深测试人员对产品的认识和印象
• 反映测试进度
• 帮助发现拓展测试范围，扩大测试覆盖面，发现软件中潜藏的缺陷
• 方便回归测试，复查bug是否还会出现
• 为紧急情况下的测试提供参考信息
• 培训新人，提高新人测试效率，节省对新人的指导时间

• 缺点
耗费时间

测试用例的用途

核实需求：每一个需求点都会设计测试用例
评估结果：对产品进行评估，对测试完成情况进行评价
准确回归：快速正确的进行版本重复测试
防止遗漏：使软件测试的实施重点突出、目的明确，确保需求功能不被遗漏
提高效率：避免盲目测试
缩短周期：版本更新和升级时，只需修正少部分测试用例，资源复用

准备编写测试用例
• 收集资料
• 需求文档
• 设计文档
• 遗留系统相关文档
• 与相关人员讨论
• 探索性测试
• 可以通过探索性测试来获得更多的需求。可以把软件当产品说明书来对待，分步骤地逐项探索软件特性，记录软件执行情况，详细描述功能。
• 探索性测试与经过深思熟虑的、计划好的测试过程有所不同，它并不预先设计测试用例或者精确地按照一个计划来执行，它依靠的是测试人员的知识水平和创造力。
• 可用于重现和分析缺陷、研究缺陷和程序其他模块的相关性
• 是测试用例有利的补充
• 具体问题具体分析

设计测试用例的基本准则

• 测试用例的代表性

能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
测试结果的可判定性

即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。

• 测试结果的可再现性
即对同样的测试用例，系统的执行结果应当是相同的。
设计测试用例的着眼点
• 根据产品规格，测试基本功能；
• 考虑设计一般用户（非专业人员）的使用方案；
• 与系统其他组成部分的配合（如移动网络和wifi，测试中考虑对设备的共享）；
• 好的测试用例集能花费最小的代价（人力、物力、财力、时间）做最好的测试。

测试用例设计书写标准

用例标题——惟一标识每一个测试用例

测试项——准确的描述所需要测试的项及其特征
输入步骤和数据——执行测试用例的输入需求（这些输入可能包括数据、文件或者操作）

预期结果——按照指定的环境和输入标准得到的期望输出结果
测试用例之间的关联——标识该测试用例与其它的测试（或其它测试用例）之间的依赖关系

在ANSI/IEEE829-1983标准中列出了和测试设计相关的测试用例编写规范和模板。标准模板中主要元素如下：

测试用例的模板
• Excel模板
• Word模板
• 测试用例模板可以根据所测对象的不同对模板内容进行调整。

测试用例的更新与维护
• 需要更新和维护的原因
• 功能变化
• 需要不断完善，是个循序渐进的过程
• 通过测试实践检验测试用例并添加、修改、删除测试用例
• 测试用例要经过正式、有效的评审
• 利用工具（配置管理系统）来维护测试用例

如何选择测试方法

• 在任何情况下都必须使用边界值分析方法

• 用等价类划分方法补充一些测试用例

• 涉及到业务流程的软件，应采用场景法

• 用错误猜测法再追加一些测试用例

• 如果程序的功能说明中含有输入条件的组合情况，则应在一开始就选用判定表法

• 如果程序某功能适合自动测试，可以采用自动测试以及随机测试

• 测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

错误猜测法

• 错误猜测

•错误猜测是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

• 需要测试人员具备的技术

•有关被测系统的知识，如设计方法或实现技术

•有关的早期测试阶段的结果的知识

•测试类似或相关系统的经验

•典型错误的知识

•通用的测试经验规则

判定表法

• 在所有的黑盒测试方法中，基于判定表（也称决策表）的测试是最为严格、最具有逻辑性的测试方法。

• 判定表的概念：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

• 判定表的优点：能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。

• 在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

组成

条件桩

列出问题的所有条件，通常认为列出得条件的次序无关紧要

条件项

针对条件桩给出的条件列出所有可能的取值，在所有可能情况下的真假值

动作桩

列出问题规定的可能采取的操作，这些操作的排列顺序没有约束
动作项
指出在条件项的各组取值情况下应采取的动作

规则

将任何一个条件组合的特定取值及相应要执行的动作称为一条规则。在判定表中贯穿条件项和动作项的一列就是一条规则

构造步骤
（1）列出所有的条件桩和动作桩。
（2）确定规则的个数。有n个条件的判定表有2n个规则（每个条件取真、假值）。
（3）填入条件项。
（4）填入动作项，得到初始判定表。
简化判定表，合并相似规则。
• 若表中有两条以上规则具有相同的动作，并且在条件项之间存在极为相似的关系，便可以合并。
• 合并后的条件项用符号“-”表示，说明执行的动作与该条件的取值无关，称为无关条件。
判定表应用
• 判定表测试法适用于具有以下特征的应用程序：

if-then-else逻辑突出；输入变量之间存在逻辑关系；涉及输入变量子集的计算；输入与输出之间存在因果关系
• 适用于使用判定表设计测试用例的条件：
• 规格说明以判定表形式给出，或较容易转换为判定表
• 条件的排列顺序不会也不应影响执行的操作。
• 规则的排列顺序不会也不应影响执行的操作。
• 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
• 如果某一规则的条件要执行多个操作，这些操作的执行顺序无关紧要