NEXTDATE的决策表示例(软件测试技术实验报告).doc

NextDate函数测试用例 选择NextDate函数，是因为它可以说明输入定义域中的依赖性问题，这使得这个例子成为基于决策表测试的一个完美例子，因为决策表可以突出这种依赖关系。从前面对等价类测试的分析我们知道，等价类分析假设所有的变量都是独立的。如果变量确实是独立的，则使用类的笛卡尔积是有意义的。如果变量之间在输入定义域中存在逻辑依赖关系，则这些依赖关系在笛卡尔积中就会丢失(说抑制可能更确切)。决策表格式通过使用“不可能动作”概念表示条件的不可能组合，使我们能够强调这种依赖关系。下面将对NextDate函数的决策表描述做三次尝试。 第一次尝试 标识合适的条件和动作，假设首先从分析等价类集合开始。 M1 = {月份：每月有30天}； M2 = {月份：每月有31天}；M3 = {月份：此月是2月} D1 = {日期：1≤日期≤28}；D2 = {日期：日期=29}；D3 = {日期=30}；D4 = {日期=31} Y1 = {年：年是闰年}；Y2 = {年：年不是闰年} 如果我们希望突出不可能的组合，则可以建立具有以下条件和动作的有限项决策表。(请注意，年变量对应的等价类收缩为下表的一个条件。) 这个决策表会有256条规则，其中很多是不可能的。如果要显示为什么这些规则是不可能的，可将动作修改为： a1：月份中的天数太多；a2：不能出现在非闰年中；a3：计算NextDate。 第二次尝试 如果我们将注意力集中到NextDate函数的闰年问题上，则可以修改已有的等价类集合。为了说明另一种决策表表示方法，这一次采用扩展项决策表开发，并更仔细地研究动作桩。在构建扩展项决策表时，必须保证等价类构成输入定义域的真划分。如果规则项之间存在“重叠”，则会存在冗余情况，使得多个规则都能够满足。这里，Y2是一组1812～2012之间的年份，并除以4，2000除外。 M1 = {月份：每月有30天}； M2 = {月份：每月有31天}；M3 = {月份：此月是2月} D1 = {日期：1≤日期≤28}；D2 = {日期：日期=29}；D3 = {日期=30}；D4 = {日期=31} Y1 = {年：年=2000}；Y2 = {年：年是闰年}；Y3 = {年：年是平年} 从某种意义上说，我们采用的是“灰盒”技术，因为更仔细地研究了NextDate函数。为了产生给定日期的NextDate，能够使用的操作只有五种：日期和月份的增1和复位，年的增1。(我们不允许通过复位年来回退时间。) 这些条件可以产生有对应等价类笛卡尔积的36个规则的决策表(自己可以分析一下)。结合不关心项，可得到下表所示的17条规则的决策表。仍然存在逻辑不可能的规则，但是这个表有助于我们标识测试用例的扩展输出。如果填满这个决策表的动作项，就会发现12月有一些麻烦的问题(规则8)。我们下面解决这些问题。 第三次尝试 通过引入等价类的第三个集合，可以澄清年末问题。这一次可以特别关注日和月，并重新使用第一次尝试的较简单的闰年或非闰年条件，因此2000年没有特别处理。(还可以做第四次尝试，采用第二次尝试的年等价类。) M1 = {月份：每月有30天}； M2 = {月份：每月有31天，12月除外}；M3 = {月份：此月是12月}；M4 = {月份：此月是2月} D1 = {日期：1≤日期≤27}；D2 = {日期：日期=28}；D3 = {日期=29}；D4 = {日期=30}；D5 = {日期=31} Y1 = {年：年是闰年}；Y2 = {年：年不是闰年} 这个等价类的笛卡尔积包含40个元素。所产生的组合规则包含不关心项，如下表所示，可与第二次的36条规则比较。大的测试用例集合是否一定比小的测试用例集合好？这里我们有一个22条规则的决策表，得到的NextDate函数的描述比包含36条规则的决策表更清晰。前5条规则处理有30天的月份，请注意，这里不考虑闰年。接下来两组规则(规则6～10，规则11～15)处理有31天的月份，前5条规则处理12月之外的月份，后5条规则处理12月。不可能规则也在决策表中列出，尽管存在一些高效测试人员可能会有疑问的冗余。10条规则中的8条只是对日期增1。针对这个子功能是否真的需要8条单独的测试用例，可能不需要，但是请注意我们可以通过决策表得到的启发。最后7条规则关注的是2月和闰年。 上表所示的决策表是NextDate函数源代码的基础。这个例子从另一个方面说明测试如何能够很好地改进程序设计。所有决策表分析都应该在NextDate函数的详细设计期间完成。 我们可以使用决策表代数进一步化简这22个测试用例。如果决策表中两个规则的动作集合相同，则一定至少有一个条件能够把两条规则用不关心条目合并。这正体现出决策表等价于用于标识等价类的“相同处理”方针。在某种意义上，我