实验一黑盒测试

一、实验目的及要求

实验目的：

1、能熟练应用功能性测试技术进行测试用例设计；

2、对测试用例进行优化设计；

实验原理：

   测试“日期推算”程序

该程序的功能是输入一个日期，输出该日期后两天的日期，例如输入20##年1月1日，则输出20##年1月3日。现在假设“日期推算”程序已经被开发出来了，请对该程序进行功能测试，要求用尽可能少的测试用例检测出尽可能多的软件缺陷。

二、实验环境

一台装有windows操作系统的计算机，vc++6.0

三、实验内容

为了方便，我们不考虑闰年的问题，默认为2月都是28天，假设限定输入数据均为整数，日期中年份的有效值范围为1000~9999。

四、实验步骤

1.选定测试方法

2.等价类划分

划分等价类的方法有：

按区间划分、按数值划分、按数值集合划分、按限制条件划分、按限制规则划分等。

确定了等价类后，可建立等价类表。

（1）无效等价类表

（2）有效等价类表

（3）测试用例表

3.执行测试用例

请根据“日期推算”程序功能要求，自行开发该程序。

4.测试执行结果，并统计，填入表中。

 

第二篇：NEXTDATE的决策表示例(软件测试技术实验报告)

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～20##之间的年份，并除以4，20##除外。

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)。我们下面解决这些问题。

第三次尝试

通过引入等价类的第三个集合，可以澄清年末问题。这一次可以特别关注日和月，并重新使用第一次尝试的较简单的闰年或非闰年条件，因此20##年没有特别处理。(还可以做第四次尝试，采用第二次尝试的年等价类。)

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个测试用例。如果决策表中两个规则的动作集合相同，则一定至少有一个条件能够把两条规则用不关心条目合并。这正体现出决策表等价于用于标识等价类的“相同处理”方针。在某种意义上，我们就是在标识规则的等价类。例如，规则1、2和3涉及有30天的月份日期类D1、D2和D3。类似地，有31天的月份的日期类D1、D2、D3和D4也可以合并，2月的D4和D5也可以合并。所得到的结果如下表所示：

相应的测试用例如下表所示：

总结

与其他测试技术一样，基于决策表的测试对于某些应用程序(例如NextDate函数)很有效，但是对另外一些应用程序就不值得费这么大的事。毫不奇怪，基于决策表所适用的情况都是要发生大量决策(例如三角形问题)，以及在输入变量之间存在重要的逻辑关系的情况(例如NextDate函数)。