鉴于软件测试的定义，下一步将阐述是否有必要找出程序中的所有错误。尽管是最小的程序，我们都将给你否定的答案。一般来说这种做法是不可能实现的，因为我们不可能找出程序中的所有问题。假设测试人员要对某个程序开始测试，在这之前就必须编写测试用例，这些最基本的工作都能够体现出经济学与测试之间的联系。

　　为了表现测试与经济学的关联性，在开始前你必须判断应该采用哪种测试方式。我们将在接下来的内容中讨论最普遍采用的黑盒测试和白盒测试方法。

　　一、黑盒测试

　　黑盒测试、数据驱动和输入/输出驱动是较为常用的测试方法。使用这种测试方法测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当的接收输入数据而产生正确的输出信息。（比如测试程序外部结构，不考虑内部逻辑结构）

　　如果希望通过这种测试方式发现程序中的所有错误，那么在编写测试用例的时候必须考虑到所有的输入条件，准备非常详细的输入数据。原因是什么？以三角形程序为例，没有任何途径可以证明测试用例提供的测试数据可以完全检测出等边三角形的合法条件。该程序可能包含对3842，3842，3842这组数据的特殊检查，认为这种边长的三角形不是等边三角形。将程序看作黑盒子后，对此类特殊声明进行完全检测的唯一方法是列举出所有的输入条件。为了详尽的测试三角形程序，必须在测试用例中给出，该程序的开发语言所规定的最大整数范围内的三角形边长的所有输入条件。这种测试数据根本是个天文数字，但是它还不够详细，因为程序仍可能会将-3，4，5看作是个不等边三角形，而将2，A，2看作是等腰三角形。可以肯定的是，试图找出这类错误，不仅要考虑到所有的有效输入条件，也要考虑到所有可能发生的输出结果。因此，要详尽的测试三角形的程序必须使用无数的测试用例来完成，很显然，这是不可能做到的。

　　上述的程序似乎很难实现完整测试，那么对大型程序来说投入这种测试就更遥不可及了。我们先来考虑这样一个问题：对C＋＋编译器做个黑盒测试。你不但需要创建代表有效的C＋＋程序的测试案例（在此重申，这样的测试用例会有无数个），而且也需要创建代表C＋＋程序无效的测试用例（同样也会有无数个）以确保编译器检测它们是无效的。也就是说，对编译器进行测试以确保它不会做不应该做的工作，例如，成功编译语法不正确的程序。如果程序需要占用一定的，像操作系统或数据库进程之类的话，问题就会更加糟糕。拿数据库应用程序来说，航空公司的订票系统，在系统中执行一个交易（如查询数据库，预定某个航班的机票），这笔交易是否成功取决于之前所产生的交易。因此，不但要尝试所有的有效和无效的交易，还有尝试所有交易的组合。

　　以上的论述表明，详尽的输入数据以达到完全测试是不可能实现的。这包含两个意义：（1）不能通过测试来证明所测试的程序是准确无误的；（2）软件测试也要考虑经济的因素。也就是说，完全的测试是不可能的，目标应该是最大限度的提高测试收益率的测试，通过有限的测试用例，尽可能找出最多的问题。这样做表明，除一些必要的事项外，还需要通过设置某类假设条件，用来证明程序在完成这类操作时没有错误发生，虽然这种假设条件不能枚举出所有的可能（例如，在三角形的程序中输入边长为2，2，2的时候，程序会认定这是一个等边三角形，同理，在边长为3，3，3的时候程序也应该认定这是一个等边三角形）。这部分内容将会在软件测试法则中阐述。