在测试用例部分已经说过，设计测试用例时要考虑边界输入和非法输入，这里统称为特殊输入，程序员在编写代码时也要考虑特殊输入，要为特殊输入编写处理代码。在实际工作中，程序员没有考虑到某些特殊输入是很常见的，这也是程序错误的一个重要来源。不幸的是，如果编写代码和建立测试用例时都没有考虑这些输入，那么白盒覆盖也不能自动发现，因为白盒覆盖是以代码为基础的，如果相应的代码根本不存在，白盒覆盖当然不会告诉用户“某某代码未覆盖”。
　　特殊输入通常与数据类型有关，例如，如果一个参数是指针，空指针是一个特殊输入，对于一个整数类型，大值、小值、0、1、-1都可以算是特殊输入；另一方面，当输入特殊数据时，如果程序未作合适的处理，运行结果常常是产生异常。根据这两个条件，如果预先为各个数据类型定义特殊值，然后由测试工具自动生成测试用例，使用这些特殊值或其组合作为输入数据进行测试，通常可以发现“未处理特殊输入”而产生的程序错误，这是边界测试。
　　VU具有强大的边界测试功能：完全自动生成测试用例；所有数据类型都可以定义边界值；可以自动过滤部分输入；可以断言输出是否符合某种“不变式”；可以在数据窗口中浏览输入输出数据以判断程序的工作是否正常。
　　如果在边界测试中发现了处理某些特殊输入的代码缺失，应补充这些代码，并完成白盒覆盖。
　　综上所述，VU并不把功能测试、白盒测试、边界测试作为并列的、重复的测试方法，而是把三者结合为一体，互相补充，形成一个完整的覆盖体系但又绝无重复工作，使用户可以用小的工作量达到大的测试完整性。用户在编写代码时，只需要为容易想到的、比较典型的等价类建立测试用例，能够满足编码的需要行了，可以说，这些测试用例是为编码服务的测试用例。编码完成后，通过白盒覆盖统计和测试用例设计器找出其他等价类并且很容易地建立起测试用例，后用边界测试自动捕捉“漏网之鱼”。
　　为了进一步说明测试完整性，举个例子：假如一个函数，大概有十个等价类，但这个数字并不是显式的，测试人员比较容易想到的，可能只有五个，自己画一下逻辑结构图，做一些代码分析，也许又可以找到二三个，是不是齐全了呢？很难衡量。使用VU，设计测试用例的过程大体是这样的：用户为容易想到的五个等价类建立测试用例，根据语句、条件、分支覆盖，在测试用例设计器的帮助下，找到另两个等价类，根据路径覆盖，又揪出了两个很隐秘的等价类，实现了语句、条件、分支、路径覆盖，后，边界测试又发现了一个意料之外的等价类。当然，这些数字只是一个示意，实现某某覆盖的目的，并不在于覆盖率，而在于尽可能找出所有等价类。
　　如果针对代码单元的测试完成了语句、条件、分支、路径覆盖，并且执行了边界测试，虽然仍然不能证明所有的等价类都测试到了，但可以肯定的说，已经达到了很高的测试完整性，局部代码中仍然含有错误的可能性很小，当然，设计上的错误除外，这不属于单元测试的范畴。