规格说明测试的可行性：
考虑下面的例子。假定某个数据处理产品的规格说明指出，必须包含5类佣金和7类折扣。仅测试佣金和折扣的每个可能的组合就需要35个测试用例，说佣金和折扣是在两个完全独立的模块中，因而可以独立测试是没有用的，因为在黑盒测试中将产品当作黑盒对待，它的内部结构因此是完全无关的。因此，彻底的规格说明测试在实际中是不可能的，因为它的组合方式会爆炸式的增长。
代码测试的可行性：
代码测试最常见的形式要求对模块通过的每条路径最少执行一次。试验产品中全部路径是不可靠的，因为存在这样的产品，某些数据试验一个给定路径将检测到错误，而不同的数据试验同一个路径将不会检出错误。然而，面向路径的测试是有效的，因为它没有固有地将可能揭示错误的测试数据的选择排除在外。
因为组合爆炸，彻底的规格说明测试或彻底的代码测试都是不可行的。为此，在使用将尽可能多揭示错误的技术的同时，也承认没有方法保证已经检测出全部错误，一个继续下去的合理的办法是首先使用黑盒测试用例，然后使用玻璃盒测试开发额外的测试用例。
黑盒单元测试技术：
彻底的黑盒测试通常要求成百上千亿的测试用例，因此测试的技巧是设计一个较小，可管理的测试用例集，是检测出一个错误的机会最大，同时通过让相同的错误由多个测试用例检出从而使浪费一个测试用例的机会最小。一个这样的黑盒技术是结合了边界值分析的等价测试。
1. 等价测试和边界值测试
假定一个数据库产品的规格说明指出，该产品必须能够处理任何从1到16383个记录，如果该产品能够处理34个记录和14870个记录，那么它在比如说 8252个记录时工作良好的可能性很大。因此，该产品能够处理的记录数的规定范围可以定义三个等价类：比1个记录小，从1到16383个记录和多于 16383个记录。
一个成功的测试用例能检测出先前未检测到的错误，为了使发现这一的错误的机会最大，一个高效的技术是边界值分析。
综上，因此，测试这个数据库产品的时候，应选择7个测试用例：
1> 0个记录：等价类1的成员，临近边界值。
2> 1个记录：边界值。
3> 2个记录：临近边界值。
4> 723个记录：等价类2的成员。
5> 16382个记录：临近边界值。
6> 16383个记录：边界值。
7> 16384个记录：等价类3的成员，临近边界值。
等价测试的过程概括如下：
对于输入和输出规格说明
对于每个范围（L，U）：
选择5个测试用例：小于L，等于L，比L大但比U小，等于U以及大于U。
对于每个集合S：
选择2个测试用例：一个S的元素和一个非S的元素。
对于每个精确值P：
选择2个测试用例：P和其他任何值。
2. 功能测试
一个可选的黑盒测试形式是根据模块的功能选择测试数据。在功能测试中，要区别每个功能项或在模块中实现的功能。
玻璃盒单元测试技术：
在玻璃盒测试技术中，基于代码的检查，而不是规格说明的检查来选择测试用例。有一些不同形式的玻璃盒测试，包括语句，分支以及路径覆盖。
1. 结构测试：语句，分支和路径覆盖
最简单形式的玻璃盒测试是语句覆盖，即运行一系列测试用例，在运行期间每个语句最少执行一次。这个方法的缺点是不能保证对分支的所有输出都充分地测试。
语句覆盖的一个改进是分支覆盖，即运行一系列，确保所有的分支最少测试一次。
像语句或分支覆盖的技术成为结构测试。
功能最强大的结构测试的形式是路径覆盖，即测试所有的路径。
2. 复杂性度量
质量保证观点提供另一个玻璃盒单元测试的方法。假定一个管理者被告知代码模块m1比代码模块m2更复杂，且不管术语复杂是如何准确定义的，管理者直觉上相信m1可能比m2有更多的错误。沿着这条思路，计算机科学家已经开发出一些软件复杂性度量，以帮助确定哪个代码模块更可能有错误。如果发现一个代码模块的复杂度不合理的高，管理者可能直接要求对它重新设计和重新实现，与试图调试一个有错的代码模块相比，可能从头开始的代价更小，速度更快。
