软件测试基础教程杜文洁 景秀丽 主编中国水利水电出版社第五章 软件测试用例设计第五章 软件测试用例设计
5.1测试用例概述
5.2黑盒测试用例设计
5.3白盒测试用例设计习题本章概要
测试用例概述
利用黑盒测试的各种具体策略设计实例
利用白盒测试的逻辑覆盖和路径分析方法设计实例第五章 软件测试用例设计
5.1测试用例概述
1．测试用例的定义
测试用例（ Test Case）是为了高效率地发现软件缺陷而精心设计的少量测试数据。实际测试中，由于无法达到穷举测试，所以要从大量输入数据中精选有代表性或特殊性的数据来作为测试数据。好的测试用例应该能发现尚未发现的软件缺陷。
2．测试用例的特性
有效性：
测试用例是测试人员测试过程中的重要参考依据。不同的测试人员根据相同的测试用例所得到的输出应该是一致的。准确的测试用例可以保障软件测试的有效性和稳定性。
可复用性：
良好的测试用例具有重复使用的功能，这样就可以大大地节约测试的时间，提高测试的效率。
易组织性：
在一个软件测试流程中测试用例可能有成千上万个，但是好的测试计划可以有效地组织
这些测试用例，分门别类地提供给测试人员参考和使用。
特别对于测试人员中的新手，好的测试用例可以帮助他们更好地完成复杂的测试任务，提高测试工作的效率。
可评估性：
从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标
准。
可管理性：
测试用例可以作为检验测试人员进度、工作量以及跟踪 /管理测试人员工作效率的因素。
第五章 软件测试用例设计
5.1测试用例概述
3．测试用例的编制要素
编写测试用例文档应有文档模板，须符合内部的规范要求。这方面可以参考一些基本的测试用例编制标准，例如 ANSI/IEEE829-1983标准中列出的关于软件测试用例的相关编制规范和模板。
测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。 软件测试用例的基本要素包括测试用例编号、测试标题、测试模块、
用例级别、测试环境、测试输入、执行操作、预期结果。
第五章 软件测试用例设计
5.1测试用例概述
在书写测试用例时，相关的编制要素如下：
用例编号：每个测试用例都有唯一的标识号，用以区别其他测试用例。测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则：
PROJECT1-ST-001,命名规则是项目名称＋测试阶段类型（系统测试阶段）
＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题,对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如,测试用户登录时输入错误密码时，软件的响应情况,。
测试模块：指明并简单描述本测试用例是用来测试哪些项目、子项目或软件特性的。
用例级别,定义测试用例的优先级别，可以粗略地分为,高,和
,低,两个级别，也可以分为“高”、“中”、“低”三个级别。一般来说，软件需求的优先级和测试用例的优先级一致。即如果软件需求的优先级为,高,,那么针对该需求的测试用例的优先级也为,高,；
反之亦然。
第五章 软件测试用例设计
5.1测试用例概述
测试环境：描述执行测试用例所需要的具体测试环境，包括硬件环境和软件环境。通常，在整个测试模块中需要对应说明整个测试的特殊环境要求，在单个测试用例的测试环境需要表述该测试用例所单独需要的特殊环境要求。
测试输入：用来执行测试用例的输入要求。这些输入可能是数据、文件或具体操作（例如单击鼠标，在键盘做按键处理等）。有时候相关的数据库或文件也要作具体说明。通常，根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
执行操作：执行本测试用例所需的每一步操作。对于复杂的测试用例，
测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果：描述被测项目或被测特性所希望或要求达到的输出或指标。
一般来说，预期结果主要根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；
反之则测试通过。
第五章 软件测试用例设计
5.1测试用例概述第五章 软件测试用例设计软件测试用例的设计主要从上述 8个方面考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。通用的测试用例模板如下：
表 5-1 测试用例软 件 测 试 用 例元 素 含 义 给出定义的测试角色用例编号 被标识过的测试需求测试标题 测试用例的描述测试模块 指明测试的具体对象用例级别 指明测试用例的优先级别测试需求分析测试环境 进入测试实施步骤所需的资源及其状态。
测试输入 运行本测试所需的代码和数据，包括测试模拟程序和测试模拟数据 测试设计（描述性定义）
执行操作 建立测试运行环境、运行被测对象、获取测试结果的步骤序列预期结果 用于比较测试结果的基准 测试实现（计算机表示）
评价标准 根据测试结果与预期结果的偏差，判断被测对象质量状态的依据
5.1测试用例概述
4．测试用例的设计原则
测试用例除了应该符合基本的测试用例编写规范，还要遵守以下几条基本设计原则：
（ 1）保证测试用例的明确性。
测试人员要尽量避免测试用例存在含糊的因素，否则会影响测试工作的进行，
影响测试结果的准确性。清晰的测试用例会使测试人员在测试过程中不会出现模棱两可的测试结果。在测试过程中，测试用例的测试结果是唯一的，即通过、没通过或未进行测试。如果测试没有通过，一般会生成相应的测试错误报告；如果测试没有进行，也会生成相应的原因说明报告，如测试用例本身具有错误性、测试用例的不适用性等等。
例如，测试用例这样描述：
用户正确操作，系统正常运行；
用户进行非法操作，系统不能正常运行。
在这里，测试用例没有具体说明什么是正确的操作，什么是非法的操作。另外，从测试用例描述中也无法知道什么是系统的正常或不正常的运行状态。
这就必然导致测试人员对测试用例的不确定理解，从而引发测试中的错误问题。
第五章 软件测试用例设计
5.1测试用例概述
（ 2）保证测试用例的代表性。
尽量将具有相似功能的测试用例抽象合并。这样，
每一个测试用例都具有代表性，可以测试一类或一系列的系统功能。
（ 3）保证测试用例的简洁性。
冗长和复杂的测试用例是不应该出现的，因为这样的用例可读性差、不利于测试人员理解和操作。
简洁的测试用例可以让测试过程目的明确，让测试结果具有唯一性。
第五章 软件测试用例设计
5.1测试用例概述
5．测试用例的设计过程
（ 1）分析系统程序的工作流程该步骤的目的在于确定并说明用户与系统交互时的操作和步骤。这些测试过程说明将进一步用于确定与描述测试系统程序所需的测试用例。
这些初期的测试过程说明应是较概括的说明，即：对操作的说明应尽可能笼统，而不应具体引用实际构件或对象。制定测试用例时应该参考如下主要文档：
在某一点可遍历测试对象（系统、子系统或构件）的用例。
设计模型。
任何技术或补充需求。
测试对象应用程序映射表（由自动测试脚本生成工具生成）。
第五章 软件测试用例设计
5.1测试用例概述
（ 2）确定并制定测试用例该步骤的目的是为每项测试需求编写适当的测试用例。编写测试用例文档应有文档模板，须符合内部的规范要求。
软件测试用例主要根据前面介绍过的测试用例编写要素来设计，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例，
并且生成规范的测试用例表。
如果已测试过以前的版本，则测试用例已经存在。应复审这些测试用例，供回归测试及其设计使用。回归测试用例应包括在当前迭代中，并应与处理新行为的新测试用例结合使用。
第五章 软件测试用例设计
5.1测试用例概述
（ 3）确定测试用例数据根据测试用例表的内容，复审测试用例，并确定支持这些测试用例的实际值。本步骤将确定用于以下三种目的的数据：
用作输入的数据值
用作预期结果的数据值
用作支持测试用例所需的数据
（ 4）测试用例的修改更新测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：
第一、在测试过程中发现设计测试用例时考虑不周，需要完善；
第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；
第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。
第五章 软件测试用例设计
5.2黑盒测试用例设计
NextDate 函数包含三个变量,month（月份）,day（日期） 和 year
（年），函数的输出为输入日期后一天的日期。 例如，输入为 2007
年 9月 9日，则函数的输出为 2007年 9月 10日 。要求输入变量
month,day 和 year 均为整数值，并且满足下列条件：
（ 1） 1≤month≤12
（ 2） 1≤day≤31
（ 3） 1912≤year≤2050
此函数的主要特点是输入变量之间的逻辑关系比较复杂。复杂性的来源有两个：一个是输入域的复杂性，另一个是指闰年的规则。例如变量
year和变量 month取不同的值，对应的变量 day会有不同的取值范围，
day值的范围可能是 1～ 30或 1～ 31，也可能是 1～ 28或 1～ 29。
下面根据黑盒测试中几种常见的测试方法为 NextDate函数设计测试用例。
第五章 软件测试用例设计
5.2黑盒测试用例设计
1．等价类划分法设计测试用例
（ 1）简单等价类划分测试 NextDate函数有效等价类简单等价类划分测试 NextDate函数可以划分以下三种有效等价类：
M1＝ {month,1≤month≤12}
D1＝ {day,1≤day≤31}
Y1＝ {year,1912≤year≤2050}
无效等价类若条件 （ 1）～（ 3）中任何一个条件无效，那么 NextDate 函数都会产生一个输出，指明相应的变量超出取值范围，例如 month 的值不在 1～ 12 范围当中。显然还存在着大量的 year,month,day 的无效组合,NextDate 函数将这些组合统一输出为：“无效输入日期”。其无效等价类为：
M2＝ {month,month<1}
M3＝ {month,month>12}
D2＝ {day,day<1}
D3＝ {day,day>31}
Y2＝ {year,year<1912}
Y3＝ {year,year>2050} 第五章 软件测试用例设计
5.2黑盒测试用例设计第五章 软件测试用例设计一般等价类测试用例如表 5-2所示。
表 5-2 NextDate函数的一般等价类测试用例测试用例输入 期望输出
month day year
Test
Case
1
9 9 2007 2007年 9月 9日健壮等价类测试中包含弱健壮等价类测试和强健壮等价类测试。
弱健壮等价类测试弱健壮等价类测试中的有效测试用例使用每个有效等价类中的一个值。弱健壮等价类测试中的无效测试用例则只包含一个无效值，其他都是有效值，
即含有单缺陷假设。如表 5-3所示。
5.2黑盒测试用例设计第五章 软件测试用例设计表 5-3 NextDate函数的弱健壮等价类测试用例测试用例 输入 期望输出month day year
Test Case
1 9 9 2007 2007年 9月 10日
Test Case
2 0 9 2007 month不在 1～ 12中
Test Case
3 13 9 2007 month不在 1～ 12中
Test Case
4 9 0 2007 day不在 1～ 31中
Test Case
5 9 32 2007 day不在 1～ 31中
Test Case
6 9 9 1911 year不在 1912～ 2050中
Test Case
7 9 9 2051 year不在 1912～ 2050中
5.2黑盒测试用例设计第五章 软件测试用例设计
强健壮等价类测试强健壮等价类测试考虑了更多的无效值情况。强健壮等价类测试中的无效测试用例可以包含多个无效值，
即含有多个缺陷假设。因为 NextDate函数有三个变量，所以对应的强健壮等价类测试用例可以包含一个无效值
，两个无效值或三个无效值。 如表 5-4所示。
表 5-4 NextDate函数的强健壮等价类测试用例测试用例 输入 期望输出month day year
Test Case 1 -1 9 2007 month不在 1～ 12中
Test Case 2 9 -1 2007 day不在 1～ 31中
Test Case 3 9 9 1900 year不在 1912～ 2050中
Test Case 4 -1 -1 2007 变量 month,day无效变量 year有效
Test Case 5 -1 9 1900 变量 month,year无效变量 day有效
Test Case 6 9 -1 1900 变量 day,year无效变量 month有效
Test Case 7 -1 -1 1900 变量 month,day,year无效
5.2黑盒测试用例设计
（ 2）改进等价类划分测试 NextDate函数
在简单等价类划分测试 NextDate函数中，没有考虑 2月份的天数问题，
也没有考虑闰年的问题，月份只包含了 30天和 31天两种情况。在改进等价类划分测试 NextDate函数中，要考虑 2月份天数的问题。
关于每个月份的天数问题，可以详细划分为以下等价类：
M1＝ {month,month有 30天 }
M2＝ {month,month有 31天 }
M3＝ {month,month是 2月 }
D1＝ {day,1≤day≤27}
D2＝ {day,day＝ 28}
D3＝ {day,day＝ 29}
D4＝ {day,day＝ 30}
D5＝ {day,day＝ 31}
Y1＝ {year,year是闰年 }
Y2＝ {year,year不是闰年 }
第五章 软件测试用例设计
5.2黑盒测试用例设计第五章 软件测试用例设计改进等价类划分测试 NextDate函数如表 5-5所示。
表 5-5 改进等价类划分法 测试用例测试用例 输入 期望输出month day year
Test Case 1 30 6 2007 2007年 7月 1日
Test Case 2 31 8 2007 2007年 9月 1日
Test Case 3 2 27 2007 2007年 2月 28日
Test Case 4 2 28 2007 2007年 3月 1日
Test Case 5 2 29 2000 2000年 3月 1日（ 2000是闰年）
Test Case 6 31 9 2007 不可能的输入日期
Test Case 7 2 29 2007 不可能的输入日期
Test Case 8 2 30 2007 不可能的输入日期
Test Case 9 15 9 2007 变量 month无效
Test Case 10 9 35 2007 变量 day无效
Test Case 11 9 9 2100 变量 year无效
5.2黑盒测试用例设计
2．边界值分析法设计测试用例在 NextDate函数中，规定了变量 month,day,year的相应取值范围。在上面等价类法设计测试用例中已经提过，具体如下：
M1＝ {month,1≤month≤12}
D1＝ {day,1≤day≤31}
Y1＝ {year,1912≤year≤2050}
第五章 软件测试用例设计
5.2黑盒测试用例设计表 5-6为 NextDate函数边界值法测试用例。
测试用例输入期望输出
month day year
Test Case 1 -1 15 2000 month不在 1～ 12中
Test Case 2 0 15 2000 month不在 1～ 12中
Test Case 3 1 15 2000 2000年 1月 16日
Test Case 4 2 15 2000 2000年 2月 16日
Test Case 5 11 15 2000 2000年 11月 16日
Test Case 6 12 15 2000 2000年 12月 16日
Test Case 7 13 15 2000 month不在 1～ 12中
Test Case 8 6 -1 2000 day不在 1～ 31中
Test Case 9 6 0 2000 day不在 1～ 31中
Test Case 10 6 1 2000 2000年 6月 2日
Test Case 11 6 2 2000 2000年 6月 3日
Test Case 12 6 30 2000 2000年 7月 1日
Test Case 13 6 31 2000 不可能的输入日期
Test Case 14 6 32 2000 day不在 1～ 31中
Test Case 15 6 15 1911 year不在 1912～ 2050中
Test Case 16 6 15 1912 1912年 6月 16日
Test Case 17 6 15 1913 1913年 6月 16日
Test Case 18 6 15 2049 2049年 6月 16日
Test Case 19 6 15 2050 2050年 6月 16日
Test Case 20 6 15 2051 year不在 1912～ 2050中
5.2黑盒测试用例设计
3．决策表法设计测试用例
NextDate函数中包含了定义域各个变量之间的依赖问题。等价类划分法和边界值分析法只能“独立地”选取各个输入值，不能体现出多个变量的依赖关系。决策表法则是根据变量间的逻辑依赖关系设计测试输入数据，排除不可能的数据组合，很好地解决了定义域的依赖问题。
NextDate函数求解给定某个日期的下一个日期的可能操作
（动作桩）如下：
变量 day加 1操作；
变量 day复位操作；
变量 month加 1操作；
变量 month复位操作；
变量 year加 1操作。
第五章 软件测试用例设计
5.2黑盒测试用例设计根据上述动作桩发现 NextDate函数的求解关键是日和月的问题，通常可以在下面等价类（条件桩）的基础上建立决策表：
M1＝ {month,month有 30天 }
M2＝ {month,month有 31天,12月除外 }
M3＝ {month,month是 12月 }
M4＝ {month,month是 2月 }
D1＝ {day,1≤day≤27}
D2＝ {day,day＝ 28}
D3＝ {day,day＝ 29}
D4＝ {day,day＝ 30}
D5＝ {day,day＝ 31}
Y1＝ {year,year是闰年 }
Y2＝ {year,year不是闰年 }
输入变量间存在大量逻辑关系的 NextDate函数决策表如表 5-7所示。
决策表共有 22条规则：
第 1~5条规则解决有 30天的月份；
第 6~10条规则解决有 31天的月份（除 12月份以外）；
第 11~15条规则解决 12月份；
第 16~22条规则解决 2月份和闰年的问题。
不可能规则也在决策表中列出，比如第 5条规则中在有 30天的月份中也考虑了 31日。
第五章 软件测试用例设计
5.2黑盒测试用例设计 表 5-7 NextDate函数的决策表规则选项
1 2 3 4 5 6 7 8 9 10 11
条件：
C1,month在 M1 M1 M1 M1 M1 M2 M2 M2 M2 M2 M3
C2,day在 D1 D2 D3 D4 D5 D1 D2 D3 D4 D5 D1
C3,year在 － － － － － － － － － － －
动作：
A1,不可能 √
A2,day加 1 √ √ √ √ √ √ √ √
A3,day复位 √ √
A4,month加 1 √ √
A5,month复位
5.2黑盒测试用例设计
A6,year加 1
规则选项 12 13 14 15 16 17 18 19 20 21 22
条件：
C1,month在 M3 M3 M3 M3 M4 M4 M4 M4 M4 M4 M4
C2,day在 D2 D3 D4 D5 D1 D2 D2 D3 D3 D4 D5
C3,year在 － － － － － Y1 Y2 Y1 Y2 － －
动作：
A1,不可能 √ √ √
A2,day加 1 √ √ √ √ √
A3,day复位 √ √ √
A4,month加 1 √ √
A5,month复位 √
A6,year加 1 √
5.2黑盒测试用例设计表 5-8 简化的 NextDate函数决策表选项规则
1,
2,
3
4 5
6,
7,
8,
9
10
11,
12,
13,
14
15 16 17 18 19 20 21,22
条件：
C1,month在 M1 M1 M1 M2 M2 M3 M3 M4 M4 M4 M4 M4 M4
C2,day在
D1,
D2,
D3
D4 D5
D1,
D2,
D3,
D4
D5
D1,
D2,
D3,
D4
D5 D1 D2 D2 D3 D3 D4,D5
C3,year在 － － － － － － － － Y1 Y2 Y1 Y2 －
动作：
A1,不可能 √ √ √
A2,day加 1 √ √ √ √ √
A3,day复位 √ √ √ √ √
A4,month加 1 √ √ √ √
A5,month复位 √
A6,year加 1 √第五章 软件测试用例设计
5.2黑盒测试用例设计第五章 软件测试用例设计根据简化的决策表 5-7，可设计如表 5-9所示的测试用例。
表 5-9 NextDate函数的测试用例组测试用例 month day year 预期输出
Test Case 1~3 6 15 2007 2007年 6月 16日
Test Case 4 6 30 2007 2007年 7月 1日
Test Case 5 6 31 2007 不可能的输入日期
Test Case 6~9 1 15 2007 2007年 1月 16日
Test Case 10 1 31 2007 2007年 2月 1日
Test Case 11~14 12 15 2007 2007年 12月 16日
Test Case 15 12 31 2007 2008年 1月 1日
Test Case 16 2 15 2007 2007年 2月 16日
Test Case 17 2 28 2000 2000年 2月 29日
Test Case 18 2 28 2007 2007年 3月 1日
Test Case 19 2 29 2000 2000年 3月 1日
Test Case 20 2 29 2007 不可能的输入日期
Test Case 21,22 2 30 2007 不可能的输入日期
5.3白盒测试用例设计实例 1 运用逻辑覆盖的方法测试程序程序 5-1：
1 If (x>1&& y＝ 1) then
2 z=z*2
3 If (x=3|| z>1) then
4 y++
运用逻辑覆盖的方法设计测试用例组，如表 5-10所示。
第五章 软件测试用例设计
5.3白盒测试用例设计第五章 软件测试用例设计逻辑覆盖方法 测试用例组 执行路径语句覆盖 x=3,y=1,z=2 1,2,3,4
判断覆盖 x=3,y=1,z=2x=1,y=1,z=1 1,2,3,41,3
条件覆盖 x=3,y=0,z=1x=1,y=1,z=2 1,3,41,3,4
判断 /条件覆盖 x=3,y=1,z=2x=1,y=0,z=1 1,2,3,41,3
条件组合覆盖
x=3,y=1,z=2
x=3,y=0,z=1
x=1,y=1,z=2
x=1,y=0,z=1
1,2,3,4
1,3,4
1,3,4
1,3
路径覆盖
x=3,y=1,z=2
x=3,y=0,z=1
x=2,y=1,z=1
x=1,y=1,z=1
1,2,3,4
1,3,4
1,2,3
1,3
表 5-10 测试用例组 10
5.3白盒测试用例设计实例 2 运用路径分析的方法测试程序程序 5-2：
1 main ()
2 {
3 int flag,t1,t2,a=0,b=0;
4 scanf (“%d,%d,%d \n”,&flag,&t1,&t2);
5 while (flag>0)
6 {
7 a=a+1;
8 if (t1=1)
9 then
10 {
11 b=b+1;
12 flag=0;
13 }
14 else
15 {
16 if (t2=1)
17 then b=b-1;
18 else a=a-2;
19 flag--;
20 }
21 }
22 printf(“a=%d,b=d% \n”,a,b);
23 } 第五章 软件测试用例设计第五章 软件测试用例设计程序 5-2的流程图如图 5-3所示：
图 5-3 程序 5-2的流程图
5.3白盒测试用例设计
5.3白盒测试用例设计第五章 软件测试用例设计程序的控制流图如图 5-4所示，其中 R1,R2,R3和 R4代表控制流图的 4个区域。 R4代表的是控制流图外的区域，也算作控制流图的一个区域。
图 5-4 程序 5-2的控制流图
5.3白盒测试用例设计下面运用路径分析的方法设计测试用例组：
（ 1） 根据程序环形复杂度的计算公式，求出程序路径集合中的独立路径数目。
V(G)=4，其中 4是控制流图 G中区域的数目。
因此，控制流图 G的环形复杂度是 4。
（ 2） 根据上面环形复杂度的计算结果，源程序的基本路径集合中有 4条独立路径：
path1,5->22
path2,5->7,8->11,12->21->5->22
path3,5->7,8->16->17->19->21->5->22
path4,5->7,8->16->18->19->21->5->22
（ 3）设计测试用例组 11如表 5-11所示。根据上述 4条独立路径设计出了这组测试用例，其中的 4组数据能够遍历各个独立路径，也就满足了路径分析测试的要求。需要注意的是，对于源程序中的循环体，测试用例组 11中的输入数据使其执行零次或一次。
第五章 软件测试用例设计
5.3白盒测试用例设计第五章 软件测试用例设计表 5-11 测试用例组 11
测试用例输入 期望输出执行路径
flag t1 t2 a b
Test Case 1 0 1 1 0 0 路径 1
Test Case 2 1 1 0 1 1 路径 2
Test Case 3 1 0 1 1 -1 路径 3
Test Case 4 1 0 0 -1 0 路径 4
习题
1,简述测试用例的定义。
2,概括测试用例的设计过程。
3,下面是某股票公司的佣金政策，根据决策表方法设计具体测试用例。
4,如果一次销售额少于 1000元，那么基础佣金将是销售额的 7%；如果销售额等于或多于 1000元，但少于 10000元，那么基础佣金将是销售额的 5%，外加 50元；如果销售额等于或多于 10000元，那么基础佣金将是销售额的 4%，外加 150元。另外销售单价和销售的份数对佣金也有影响。如果单价低于 15元 /份，则外加基础佣金的 5%，此外若不是整百的份数，再外加 4%的基础佣金；若单价在 15元 /份以上，但低于 25元 /份，则加 2%的基础佣金，若不是整百的份数，再外加 4%的基础佣金；若单价在 25元 /份以上，并且不是整百的份数，
则外加 4%的基础佣金 。
第五章 软件测试用例设计习题
5,利用逻辑覆盖的方法测试下列源代码。
void TEST(int x,int A,int B)
{
if((A>2)&&(B=0))
X=X/A;
if((A=3)||(X>1))
X=X+1;
}
第五章 软件测试用例设计
5.1测试用例概述
5.2黑盒测试用例设计
5.3白盒测试用例设计习题本章概要
测试用例概述
利用黑盒测试的各种具体策略设计实例
利用白盒测试的逻辑覆盖和路径分析方法设计实例第五章 软件测试用例设计
5.1测试用例概述
1．测试用例的定义
测试用例（ Test Case）是为了高效率地发现软件缺陷而精心设计的少量测试数据。实际测试中，由于无法达到穷举测试，所以要从大量输入数据中精选有代表性或特殊性的数据来作为测试数据。好的测试用例应该能发现尚未发现的软件缺陷。
2．测试用例的特性
有效性：
测试用例是测试人员测试过程中的重要参考依据。不同的测试人员根据相同的测试用例所得到的输出应该是一致的。准确的测试用例可以保障软件测试的有效性和稳定性。
可复用性：
良好的测试用例具有重复使用的功能，这样就可以大大地节约测试的时间，提高测试的效率。
易组织性：
在一个软件测试流程中测试用例可能有成千上万个，但是好的测试计划可以有效地组织
这些测试用例，分门别类地提供给测试人员参考和使用。
特别对于测试人员中的新手，好的测试用例可以帮助他们更好地完成复杂的测试任务，提高测试工作的效率。
可评估性：
从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标
准。
可管理性：
测试用例可以作为检验测试人员进度、工作量以及跟踪 /管理测试人员工作效率的因素。
第五章 软件测试用例设计
5.1测试用例概述
3．测试用例的编制要素
编写测试用例文档应有文档模板，须符合内部的规范要求。这方面可以参考一些基本的测试用例编制标准，例如 ANSI/IEEE829-1983标准中列出的关于软件测试用例的相关编制规范和模板。
测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。 软件测试用例的基本要素包括测试用例编号、测试标题、测试模块、
用例级别、测试环境、测试输入、执行操作、预期结果。
第五章 软件测试用例设计
5.1测试用例概述
在书写测试用例时，相关的编制要素如下：
用例编号：每个测试用例都有唯一的标识号，用以区别其他测试用例。测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则：
PROJECT1-ST-001,命名规则是项目名称＋测试阶段类型（系统测试阶段）
＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题,对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如,测试用户登录时输入错误密码时，软件的响应情况,。
测试模块：指明并简单描述本测试用例是用来测试哪些项目、子项目或软件特性的。
用例级别,定义测试用例的优先级别，可以粗略地分为,高,和
,低,两个级别，也可以分为“高”、“中”、“低”三个级别。一般来说，软件需求的优先级和测试用例的优先级一致。即如果软件需求的优先级为,高,,那么针对该需求的测试用例的优先级也为,高,；
反之亦然。
第五章 软件测试用例设计
5.1测试用例概述
测试环境：描述执行测试用例所需要的具体测试环境，包括硬件环境和软件环境。通常，在整个测试模块中需要对应说明整个测试的特殊环境要求，在单个测试用例的测试环境需要表述该测试用例所单独需要的特殊环境要求。
测试输入：用来执行测试用例的输入要求。这些输入可能是数据、文件或具体操作（例如单击鼠标，在键盘做按键处理等）。有时候相关的数据库或文件也要作具体说明。通常，根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
执行操作：执行本测试用例所需的每一步操作。对于复杂的测试用例，
测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果：描述被测项目或被测特性所希望或要求达到的输出或指标。
一般来说，预期结果主要根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；
反之则测试通过。
第五章 软件测试用例设计
5.1测试用例概述第五章 软件测试用例设计软件测试用例的设计主要从上述 8个方面考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。通用的测试用例模板如下：
表 5-1 测试用例软 件 测 试 用 例元 素 含 义 给出定义的测试角色用例编号 被标识过的测试需求测试标题 测试用例的描述测试模块 指明测试的具体对象用例级别 指明测试用例的优先级别测试需求分析测试环境 进入测试实施步骤所需的资源及其状态。
测试输入 运行本测试所需的代码和数据，包括测试模拟程序和测试模拟数据 测试设计（描述性定义）
执行操作 建立测试运行环境、运行被测对象、获取测试结果的步骤序列预期结果 用于比较测试结果的基准 测试实现（计算机表示）
评价标准 根据测试结果与预期结果的偏差，判断被测对象质量状态的依据
5.1测试用例概述
4．测试用例的设计原则
测试用例除了应该符合基本的测试用例编写规范，还要遵守以下几条基本设计原则：
（ 1）保证测试用例的明确性。
测试人员要尽量避免测试用例存在含糊的因素，否则会影响测试工作的进行，
影响测试结果的准确性。清晰的测试用例会使测试人员在测试过程中不会出现模棱两可的测试结果。在测试过程中，测试用例的测试结果是唯一的，即通过、没通过或未进行测试。如果测试没有通过，一般会生成相应的测试错误报告；如果测试没有进行，也会生成相应的原因说明报告，如测试用例本身具有错误性、测试用例的不适用性等等。
例如，测试用例这样描述：
用户正确操作，系统正常运行；
用户进行非法操作，系统不能正常运行。
在这里，测试用例没有具体说明什么是正确的操作，什么是非法的操作。另外，从测试用例描述中也无法知道什么是系统的正常或不正常的运行状态。
这就必然导致测试人员对测试用例的不确定理解，从而引发测试中的错误问题。
第五章 软件测试用例设计
5.1测试用例概述
（ 2）保证测试用例的代表性。
尽量将具有相似功能的测试用例抽象合并。这样，
每一个测试用例都具有代表性，可以测试一类或一系列的系统功能。
（ 3）保证测试用例的简洁性。
冗长和复杂的测试用例是不应该出现的，因为这样的用例可读性差、不利于测试人员理解和操作。
简洁的测试用例可以让测试过程目的明确，让测试结果具有唯一性。
第五章 软件测试用例设计
5.1测试用例概述
5．测试用例的设计过程
（ 1）分析系统程序的工作流程该步骤的目的在于确定并说明用户与系统交互时的操作和步骤。这些测试过程说明将进一步用于确定与描述测试系统程序所需的测试用例。
这些初期的测试过程说明应是较概括的说明，即：对操作的说明应尽可能笼统，而不应具体引用实际构件或对象。制定测试用例时应该参考如下主要文档：
在某一点可遍历测试对象（系统、子系统或构件）的用例。
设计模型。
任何技术或补充需求。
测试对象应用程序映射表（由自动测试脚本生成工具生成）。
第五章 软件测试用例设计
5.1测试用例概述
（ 2）确定并制定测试用例该步骤的目的是为每项测试需求编写适当的测试用例。编写测试用例文档应有文档模板，须符合内部的规范要求。
软件测试用例主要根据前面介绍过的测试用例编写要素来设计，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例，
并且生成规范的测试用例表。
如果已测试过以前的版本，则测试用例已经存在。应复审这些测试用例，供回归测试及其设计使用。回归测试用例应包括在当前迭代中，并应与处理新行为的新测试用例结合使用。
第五章 软件测试用例设计
5.1测试用例概述
（ 3）确定测试用例数据根据测试用例表的内容，复审测试用例，并确定支持这些测试用例的实际值。本步骤将确定用于以下三种目的的数据：
用作输入的数据值
用作预期结果的数据值
用作支持测试用例所需的数据
（ 4）测试用例的修改更新测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：
第一、在测试过程中发现设计测试用例时考虑不周，需要完善；
第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；
第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。
第五章 软件测试用例设计
5.2黑盒测试用例设计
NextDate 函数包含三个变量,month（月份）,day（日期） 和 year
（年），函数的输出为输入日期后一天的日期。 例如，输入为 2007
年 9月 9日，则函数的输出为 2007年 9月 10日 。要求输入变量
month,day 和 year 均为整数值，并且满足下列条件：
（ 1） 1≤month≤12
（ 2） 1≤day≤31
（ 3） 1912≤year≤2050
此函数的主要特点是输入变量之间的逻辑关系比较复杂。复杂性的来源有两个：一个是输入域的复杂性，另一个是指闰年的规则。例如变量
year和变量 month取不同的值，对应的变量 day会有不同的取值范围，
day值的范围可能是 1～ 30或 1～ 31，也可能是 1～ 28或 1～ 29。
下面根据黑盒测试中几种常见的测试方法为 NextDate函数设计测试用例。
第五章 软件测试用例设计
5.2黑盒测试用例设计
1．等价类划分法设计测试用例
（ 1）简单等价类划分测试 NextDate函数有效等价类简单等价类划分测试 NextDate函数可以划分以下三种有效等价类：
M1＝ {month,1≤month≤12}
D1＝ {day,1≤day≤31}
Y1＝ {year,1912≤year≤2050}
无效等价类若条件 （ 1）～（ 3）中任何一个条件无效，那么 NextDate 函数都会产生一个输出，指明相应的变量超出取值范围，例如 month 的值不在 1～ 12 范围当中。显然还存在着大量的 year,month,day 的无效组合,NextDate 函数将这些组合统一输出为：“无效输入日期”。其无效等价类为：
M2＝ {month,month<1}
M3＝ {month,month>12}
D2＝ {day,day<1}
D3＝ {day,day>31}
Y2＝ {year,year<1912}
Y3＝ {year,year>2050} 第五章 软件测试用例设计
5.2黑盒测试用例设计第五章 软件测试用例设计一般等价类测试用例如表 5-2所示。
表 5-2 NextDate函数的一般等价类测试用例测试用例输入 期望输出
month day year
Test
Case
1
9 9 2007 2007年 9月 9日健壮等价类测试中包含弱健壮等价类测试和强健壮等价类测试。
弱健壮等价类测试弱健壮等价类测试中的有效测试用例使用每个有效等价类中的一个值。弱健壮等价类测试中的无效测试用例则只包含一个无效值，其他都是有效值，
即含有单缺陷假设。如表 5-3所示。
5.2黑盒测试用例设计第五章 软件测试用例设计表 5-3 NextDate函数的弱健壮等价类测试用例测试用例 输入 期望输出month day year
Test Case
1 9 9 2007 2007年 9月 10日
Test Case
2 0 9 2007 month不在 1～ 12中
Test Case
3 13 9 2007 month不在 1～ 12中
Test Case
4 9 0 2007 day不在 1～ 31中
Test Case
5 9 32 2007 day不在 1～ 31中
Test Case
6 9 9 1911 year不在 1912～ 2050中
Test Case
7 9 9 2051 year不在 1912～ 2050中
5.2黑盒测试用例设计第五章 软件测试用例设计
强健壮等价类测试强健壮等价类测试考虑了更多的无效值情况。强健壮等价类测试中的无效测试用例可以包含多个无效值，
即含有多个缺陷假设。因为 NextDate函数有三个变量，所以对应的强健壮等价类测试用例可以包含一个无效值
，两个无效值或三个无效值。 如表 5-4所示。
表 5-4 NextDate函数的强健壮等价类测试用例测试用例 输入 期望输出month day year
Test Case 1 -1 9 2007 month不在 1～ 12中
Test Case 2 9 -1 2007 day不在 1～ 31中
Test Case 3 9 9 1900 year不在 1912～ 2050中
Test Case 4 -1 -1 2007 变量 month,day无效变量 year有效
Test Case 5 -1 9 1900 变量 month,year无效变量 day有效
Test Case 6 9 -1 1900 变量 day,year无效变量 month有效
Test Case 7 -1 -1 1900 变量 month,day,year无效
5.2黑盒测试用例设计
（ 2）改进等价类划分测试 NextDate函数
在简单等价类划分测试 NextDate函数中，没有考虑 2月份的天数问题，
也没有考虑闰年的问题，月份只包含了 30天和 31天两种情况。在改进等价类划分测试 NextDate函数中，要考虑 2月份天数的问题。
关于每个月份的天数问题，可以详细划分为以下等价类：
M1＝ {month,month有 30天 }
M2＝ {month,month有 31天 }
M3＝ {month,month是 2月 }
D1＝ {day,1≤day≤27}
D2＝ {day,day＝ 28}
D3＝ {day,day＝ 29}
D4＝ {day,day＝ 30}
D5＝ {day,day＝ 31}
Y1＝ {year,year是闰年 }
Y2＝ {year,year不是闰年 }
第五章 软件测试用例设计
5.2黑盒测试用例设计第五章 软件测试用例设计改进等价类划分测试 NextDate函数如表 5-5所示。
表 5-5 改进等价类划分法 测试用例测试用例 输入 期望输出month day year
Test Case 1 30 6 2007 2007年 7月 1日
Test Case 2 31 8 2007 2007年 9月 1日
Test Case 3 2 27 2007 2007年 2月 28日
Test Case 4 2 28 2007 2007年 3月 1日
Test Case 5 2 29 2000 2000年 3月 1日（ 2000是闰年）
Test Case 6 31 9 2007 不可能的输入日期
Test Case 7 2 29 2007 不可能的输入日期
Test Case 8 2 30 2007 不可能的输入日期
Test Case 9 15 9 2007 变量 month无效
Test Case 10 9 35 2007 变量 day无效
Test Case 11 9 9 2100 变量 year无效
5.2黑盒测试用例设计
2．边界值分析法设计测试用例在 NextDate函数中，规定了变量 month,day,year的相应取值范围。在上面等价类法设计测试用例中已经提过，具体如下：
M1＝ {month,1≤month≤12}
D1＝ {day,1≤day≤31}
Y1＝ {year,1912≤year≤2050}
第五章 软件测试用例设计
5.2黑盒测试用例设计表 5-6为 NextDate函数边界值法测试用例。
测试用例输入期望输出
month day year
Test Case 1 -1 15 2000 month不在 1～ 12中
Test Case 2 0 15 2000 month不在 1～ 12中
Test Case 3 1 15 2000 2000年 1月 16日
Test Case 4 2 15 2000 2000年 2月 16日
Test Case 5 11 15 2000 2000年 11月 16日
Test Case 6 12 15 2000 2000年 12月 16日
Test Case 7 13 15 2000 month不在 1～ 12中
Test Case 8 6 -1 2000 day不在 1～ 31中
Test Case 9 6 0 2000 day不在 1～ 31中
Test Case 10 6 1 2000 2000年 6月 2日
Test Case 11 6 2 2000 2000年 6月 3日
Test Case 12 6 30 2000 2000年 7月 1日
Test Case 13 6 31 2000 不可能的输入日期
Test Case 14 6 32 2000 day不在 1～ 31中
Test Case 15 6 15 1911 year不在 1912～ 2050中
Test Case 16 6 15 1912 1912年 6月 16日
Test Case 17 6 15 1913 1913年 6月 16日
Test Case 18 6 15 2049 2049年 6月 16日
Test Case 19 6 15 2050 2050年 6月 16日
Test Case 20 6 15 2051 year不在 1912～ 2050中
5.2黑盒测试用例设计
3．决策表法设计测试用例
NextDate函数中包含了定义域各个变量之间的依赖问题。等价类划分法和边界值分析法只能“独立地”选取各个输入值，不能体现出多个变量的依赖关系。决策表法则是根据变量间的逻辑依赖关系设计测试输入数据，排除不可能的数据组合，很好地解决了定义域的依赖问题。
NextDate函数求解给定某个日期的下一个日期的可能操作
（动作桩）如下：
变量 day加 1操作；
变量 day复位操作；
变量 month加 1操作；
变量 month复位操作；
变量 year加 1操作。
第五章 软件测试用例设计
5.2黑盒测试用例设计根据上述动作桩发现 NextDate函数的求解关键是日和月的问题，通常可以在下面等价类（条件桩）的基础上建立决策表：
M1＝ {month,month有 30天 }
M2＝ {month,month有 31天,12月除外 }
M3＝ {month,month是 12月 }
M4＝ {month,month是 2月 }
D1＝ {day,1≤day≤27}
D2＝ {day,day＝ 28}
D3＝ {day,day＝ 29}
D4＝ {day,day＝ 30}
D5＝ {day,day＝ 31}
Y1＝ {year,year是闰年 }
Y2＝ {year,year不是闰年 }
输入变量间存在大量逻辑关系的 NextDate函数决策表如表 5-7所示。
决策表共有 22条规则：
第 1~5条规则解决有 30天的月份；
第 6~10条规则解决有 31天的月份（除 12月份以外）；
第 11~15条规则解决 12月份；
第 16~22条规则解决 2月份和闰年的问题。
不可能规则也在决策表中列出，比如第 5条规则中在有 30天的月份中也考虑了 31日。
第五章 软件测试用例设计
5.2黑盒测试用例设计 表 5-7 NextDate函数的决策表规则选项
1 2 3 4 5 6 7 8 9 10 11
条件：
C1,month在 M1 M1 M1 M1 M1 M2 M2 M2 M2 M2 M3
C2,day在 D1 D2 D3 D4 D5 D1 D2 D3 D4 D5 D1
C3,year在 － － － － － － － － － － －
动作：
A1,不可能 √
A2,day加 1 √ √ √ √ √ √ √ √
A3,day复位 √ √
A4,month加 1 √ √
A5,month复位
5.2黑盒测试用例设计
A6,year加 1
规则选项 12 13 14 15 16 17 18 19 20 21 22
条件：
C1,month在 M3 M3 M3 M3 M4 M4 M4 M4 M4 M4 M4
C2,day在 D2 D3 D4 D5 D1 D2 D2 D3 D3 D4 D5
C3,year在 － － － － － Y1 Y2 Y1 Y2 － －
动作：
A1,不可能 √ √ √
A2,day加 1 √ √ √ √ √
A3,day复位 √ √ √
A4,month加 1 √ √
A5,month复位 √
A6,year加 1 √
5.2黑盒测试用例设计表 5-8 简化的 NextDate函数决策表选项规则
1,
2,
3
4 5
6,
7,
8,
9
10
11,
12,
13,
14
15 16 17 18 19 20 21,22
条件：
C1,month在 M1 M1 M1 M2 M2 M3 M3 M4 M4 M4 M4 M4 M4
C2,day在
D1,
D2,
D3
D4 D5
D1,
D2,
D3,
D4
D5
D1,
D2,
D3,
D4
D5 D1 D2 D2 D3 D3 D4,D5
C3,year在 － － － － － － － － Y1 Y2 Y1 Y2 －
动作：
A1,不可能 √ √ √
A2,day加 1 √ √ √ √ √
A3,day复位 √ √ √ √ √
A4,month加 1 √ √ √ √
A5,month复位 √
A6,year加 1 √第五章 软件测试用例设计
5.2黑盒测试用例设计第五章 软件测试用例设计根据简化的决策表 5-7，可设计如表 5-9所示的测试用例。
表 5-9 NextDate函数的测试用例组测试用例 month day year 预期输出
Test Case 1~3 6 15 2007 2007年 6月 16日
Test Case 4 6 30 2007 2007年 7月 1日
Test Case 5 6 31 2007 不可能的输入日期
Test Case 6~9 1 15 2007 2007年 1月 16日
Test Case 10 1 31 2007 2007年 2月 1日
Test Case 11~14 12 15 2007 2007年 12月 16日
Test Case 15 12 31 2007 2008年 1月 1日
Test Case 16 2 15 2007 2007年 2月 16日
Test Case 17 2 28 2000 2000年 2月 29日
Test Case 18 2 28 2007 2007年 3月 1日
Test Case 19 2 29 2000 2000年 3月 1日
Test Case 20 2 29 2007 不可能的输入日期
Test Case 21,22 2 30 2007 不可能的输入日期
5.3白盒测试用例设计实例 1 运用逻辑覆盖的方法测试程序程序 5-1：
1 If (x>1&& y＝ 1) then
2 z=z*2
3 If (x=3|| z>1) then
4 y++
运用逻辑覆盖的方法设计测试用例组，如表 5-10所示。
第五章 软件测试用例设计
5.3白盒测试用例设计第五章 软件测试用例设计逻辑覆盖方法 测试用例组 执行路径语句覆盖 x=3,y=1,z=2 1,2,3,4
判断覆盖 x=3,y=1,z=2x=1,y=1,z=1 1,2,3,41,3
条件覆盖 x=3,y=0,z=1x=1,y=1,z=2 1,3,41,3,4
判断 /条件覆盖 x=3,y=1,z=2x=1,y=0,z=1 1,2,3,41,3
条件组合覆盖
x=3,y=1,z=2
x=3,y=0,z=1
x=1,y=1,z=2
x=1,y=0,z=1
1,2,3,4
1,3,4
1,3,4
1,3
路径覆盖
x=3,y=1,z=2
x=3,y=0,z=1
x=2,y=1,z=1
x=1,y=1,z=1
1,2,3,4
1,3,4
1,2,3
1,3
表 5-10 测试用例组 10
5.3白盒测试用例设计实例 2 运用路径分析的方法测试程序程序 5-2：
1 main ()
2 {
3 int flag,t1,t2,a=0,b=0;
4 scanf (“%d,%d,%d \n”,&flag,&t1,&t2);
5 while (flag>0)
6 {
7 a=a+1;
8 if (t1=1)
9 then
10 {
11 b=b+1;
12 flag=0;
13 }
14 else
15 {
16 if (t2=1)
17 then b=b-1;
18 else a=a-2;
19 flag--;
20 }
21 }
22 printf(“a=%d,b=d% \n”,a,b);
23 } 第五章 软件测试用例设计第五章 软件测试用例设计程序 5-2的流程图如图 5-3所示：
图 5-3 程序 5-2的流程图
5.3白盒测试用例设计
5.3白盒测试用例设计第五章 软件测试用例设计程序的控制流图如图 5-4所示，其中 R1,R2,R3和 R4代表控制流图的 4个区域。 R4代表的是控制流图外的区域，也算作控制流图的一个区域。
图 5-4 程序 5-2的控制流图
5.3白盒测试用例设计下面运用路径分析的方法设计测试用例组：
（ 1） 根据程序环形复杂度的计算公式，求出程序路径集合中的独立路径数目。
V(G)=4，其中 4是控制流图 G中区域的数目。
因此，控制流图 G的环形复杂度是 4。
（ 2） 根据上面环形复杂度的计算结果，源程序的基本路径集合中有 4条独立路径：
path1,5->22
path2,5->7,8->11,12->21->5->22
path3,5->7,8->16->17->19->21->5->22
path4,5->7,8->16->18->19->21->5->22
（ 3）设计测试用例组 11如表 5-11所示。根据上述 4条独立路径设计出了这组测试用例，其中的 4组数据能够遍历各个独立路径，也就满足了路径分析测试的要求。需要注意的是，对于源程序中的循环体，测试用例组 11中的输入数据使其执行零次或一次。
第五章 软件测试用例设计
5.3白盒测试用例设计第五章 软件测试用例设计表 5-11 测试用例组 11
测试用例输入 期望输出执行路径
flag t1 t2 a b
Test Case 1 0 1 1 0 0 路径 1
Test Case 2 1 1 0 1 1 路径 2
Test Case 3 1 0 1 1 -1 路径 3
Test Case 4 1 0 0 -1 0 路径 4
习题
1,简述测试用例的定义。
2,概括测试用例的设计过程。
3,下面是某股票公司的佣金政策，根据决策表方法设计具体测试用例。
4,如果一次销售额少于 1000元，那么基础佣金将是销售额的 7%；如果销售额等于或多于 1000元，但少于 10000元，那么基础佣金将是销售额的 5%，外加 50元；如果销售额等于或多于 10000元，那么基础佣金将是销售额的 4%，外加 150元。另外销售单价和销售的份数对佣金也有影响。如果单价低于 15元 /份，则外加基础佣金的 5%，此外若不是整百的份数，再外加 4%的基础佣金；若单价在 15元 /份以上，但低于 25元 /份，则加 2%的基础佣金，若不是整百的份数，再外加 4%的基础佣金；若单价在 25元 /份以上，并且不是整百的份数，
则外加 4%的基础佣金 。
第五章 软件测试用例设计习题
5,利用逻辑覆盖的方法测试下列源代码。
void TEST(int x,int A,int B)
{
if((A>2)&&(B=0))
X=X/A;
if((A=3)||(X>1))
X=X+1;
}
第五章 软件测试用例设计
