模板
教程
环境
性能
功能
管理
白盒方法在用例设计中的正确应用
问题：
int IsLeap(int year)
{
if (year % 4 == 0)
{
if (year % 100 == 0)
{
if (year % 400 ==0)
leap = 1;
else
leap = 0;
}
else
leap = 1;
}
else
leap = 0;
return leap;
}
回答：
纯粹从白盒角度来设计用例，是方向性的错误，这是缺少实践的书本和专家的误导。这叫跟着代码走，费力不讨好。
程序中的错误，根据产生原因可分为两类：代码错误和代码缺失。代码缺失是程序员未考虑到某些输入，未编写对应代码形成的。白盒覆盖基于现有代码，无法发现这种错误。那么，白盒覆盖是否能发现前一种错误?未必!用例必须根据程序功能设定正确的预期输出，否则再高的白盒覆盖也没有意义。也就是说，程序的设计功能是用例设计工作中绕不过去的，是一切的基础。既然如此，为什么要纯粹从白盒角度来设计用例?我认为，类似基路径法之类的纯白盒方法都是应该抛弃的，效率低下不说，既不能发现代码缺失错误，也容易造成忽略程序设计功能这个测试的根本依据。
白盒方法的价值在于衡量对既有代码的测试完整性，也可以根据白盒覆盖找出遗漏的用例，这些价值也是建立在用例是基于功能来设计、设定了必要的预期输出的基础上的。
所以，正确的方法应该是：首先根据功能来设计用例，并将数据集中起来，从“有哪些正常输入?有哪些边界输入?有哪些非法输入”三个角度检查完整性，这样可以有效发现代码缺失错误。然后，再统计白盒覆盖，根据未覆盖的逻辑单位，找出遗漏用例，实现高覆盖，新加的用例也要根据设计功能设定必要的预期输出。这样做，即避免了掉入“跟着代码走”的陷阱，白盒方法也不用起头做起，效率高得多。
下面我就楼主提供的代码演示一下：
首先根据设计功能：计算某一年是否为润年，设计了几个用例：
这里输入只有一个参数，表格中容易检查，对于多个输入的代码来说，应该把数据进一步集中检查，除了检查每个参数或其他输入的取值，必要时还要检查这些值的组合：
接下来，再查看白盒覆盖率，代码中，红色带背景的语句未覆盖，[F]表示条件的取假值未覆盖，[T]表示取真值未覆盖，[M]表示MC/DC未覆盖;逻辑结构图中，红色的分支未覆盖，未覆盖路径用红色画出。
然后，选中未覆盖的语句，使用用例设计器，找出对应的遗漏用例，根据提示，year%4==0，这是不能破坏的，year%100!=0，这是我们要满足的，那么，把year的值改为1996(当然也可以是满足条件的其他值)就OK了：
执行测试后，所有覆盖都已完成，包括：语句覆盖、分支覆盖、路径覆盖、条件覆盖、判定条件覆盖(C/DC)、修正判定条件覆盖(MC/DC)。
这比纯粹从白盒角度来设计用例效率高多了吧?最重要的是，避免了“跟着代码走”陷阱。以上用的是Visual Unit 2.6，用别的工具，或者不用工具，道理也是一样的。
