无论缺陷预防
工作贯彻落实地多好，软件组件总有缺陷。这很明显，因为开发商无法阻止/消除
软件开发周期的所有缺陷。因此，软件必须进行彻底的
测试，然后才交付给最终用户。测试人员的责任是：设计既可以（ⅰ）找软件缺陷，又能（ii ）评估该软件的性能，可用性和可靠性等方面的测试。
现在，为了实现这些目标，测试人员必须（往往是从一个非常大的执行域中）选择和/或制定
测试用例的有限数量。不幸的是，完整的测试通常不是在这个范围，预算和时间的约束内实现和/或执行的。重要的是，当测试开始失控且不按计划地运行时，由于预期无法实际，测试人员往往承受了来自管理层和利益相关者的巨大压力。
因此，测试人员必须有效地计划测试并制定正确的测试用例，选择并执行合适的用例，监控过程，以确保有效利用工作资源和时间。所以，要列出这些无疑是一项艰巨的任务；要有效地实施，测试人员需要受过适当的教育和培训并拥有赢得管理层支持的能力。
一般情况下，测试人员会用两种不同的测试方法，其中，使用常规方法，测试人员主要是尝试用所有可能的输入去测试一个模块或组件，用所有可能的软件结构去实践。尽管这种做法仍在使用，测试人员却在慢慢灌输推理软件的一切的价值，最终使他们能够检测出所有可能存在的缺陷。但见多识广且有学问的测试员们都明白，这在现实或经济上是不可行，不可实现的目标。
现在，另一种方法可能就是让测试员们随机选择测试输入，希望这些测试能将大的缺陷找出来。不过，测试专家认为，随机生成的测试输入在评估系统的质量属性方面表现纪录欠佳。所以，从测试的角度来看，这是一个无休止的争论和悬而未决的问题。尽管如此，我们还是认为，测试员的最终目标是了解测试的功能、输入/输出域和使用环境，等等。
同样，对于某些特定类型的测试，测试人员也需要详细地了解代码是如何构造的。此外，测试人员也需要利用关于常在软件开发或维护过程中生成的特定缺陷的知识。有了这些信息，测试者就必须明智地选择测试输入的子集，以及被认为最有可能找测试过程中条件和限制内的缺陷的测试输入组合。然而，这个过程需要时间和精力。所以，测试人员知道且赞同：只有开发出基于执行的测试的有效测试用例，才能最大化和/或优化对时间和资源的利用。
“有效测试用例”我们是指：“一个很可能找出缺陷的测试用例” 。因此，制定有效测试用例的能力对于一个组织迈向一个更高质量的测试过程来说是非常重要的；反过来，一个组织迈向一个更高质量的测试过程对制定有效测试用例的能力也有许多积极影响。
例如，如果测试用例是有效的，那么：
检测缺陷的概率更大。
更有效地利用组织资源。
测试再用的可能性更高。
更符合测试、项目进度、预算，更重要地，提供更高质量的软件产品的可能性。
测试用例设计方法 - 概念化
上面介绍了有效测试用例的种种好处，但缜密考虑测试人员用来设计这些有效测试用例的方法也同样重要。为了回答这个问题，有必要把软件作为一个精心设计的产品来查看和/或检查。现在，有了这个观念，就有两个基本方法可以用来设计测试用例：
黑盒（有时也称为功能或规格）测试方法。
白盒（有时也称为clear或透明盒 ）测试方法。
使用
黑盒测试方法，测试人员把SUT （测试中的软件）当作一个不知道其内部结构（即如何运作）的不透明盒子，测试人员只知道它的作用。使用这种方法的SUT的大小可以是一个简单的模块、成员函数、对象群、一个子系统、或一个完整的软件系统。此外， SUT的基础行为或功能的描述可以由正式规格，输入/处理/输出图（ IPO），或一套定义明确的先决、后置条件来提供；重要的是，另一个值得一提的信息来源是：需求规格说明文档，通常描述SUT的功能，输入及预期输出。现在，鉴于上述来源，测试员提供指定输入到SUT，进行测试运行，然后确定所产生的输出是否与说明文档中提供的一致。因为黑盒测试方法只考虑了软件的行为和功能，它通常被称为
功能测试，或基于规范的测试。这种方法特别有用，极有助于找到要求和规格中的缺陷。
与此相反，
白盒测试方法关注将被测试的软件的内部结构。因此，使用白盒测试方法来设计测试用例，测试人员应该先了解结构，且为了实现这一目标，必须可随时参考和理解代码或适当的类伪代码的要求。一旦对结构有了必要的了解，测试者就可以选择合适的测试用例去实践特定的内部结构要素，并确定它们是否正常工作。例如，测试用例通常被设计来实践所有语句或发生在一个模块或成员函数中的真/假分支。但是，由于白盒测试的设计，执行和结果分析非常耗时，这种方法被限制和/或通常只适用于软件的小部分，如模块或成员函数。然而，白盒测试方法对于找出设计和基于代码的控件的逻辑缺陷和顺序缺陷，初始化缺陷和数据流缺陷等特别有用。
然而，从测试员的角度来看，要实现向用户提供低缺陷高质量的软件的目标，必须把这两种方法都用来设计测试用例。另外，这两种方法都支持测试员选择有限数量的将被用于测试的测试用例。这两种方法可以相互补充，因为每个都或许有助于找到某些特定类型的缺陷。重要的是，有了使用这两种方法设计出的一组测试用例，测试员找到SUT中各种不同类型缺陷的机会就增加了。
测试员还有一套有效的可再用的用来进行回归测试（更改后的重新测试），以及
软件测试的新版本。
上面是一份概要：使用任一设计方法制定测试用例的各种可用方法。
但是，在使用任一设计方法准备测试用例前有一些因素需要考虑清楚。它们分别是：
测试相关风险。
预期缺陷类型。
测试员的知识和经验。
测试水平和必须进行分组和管理的小组活动。
用于执行测试用例的工具。
应用程序，软件和问题域的类型。
客户要求，等等。
现在除了上述因素，以下几个要点和/或问题在选择正确的测试用例设计技术中发挥了至关重要的作用：
基于“经验”的测试用例设计
在基于经验的技术中，是人们的知识，技能和专业知识（关于域，技术等）构成了测试条件和测试用例的基础，且对制定测试条件和测试用例很重要。
在这儿，人们技术和业务两方面的经验都是绝对必需的，必要的，因为这给测试分析和设计过程提供了不同的角度。
重要的是，有了他们使用类似系统工作的丰富（前）的经验，他们或许对什么会出错，什么有助于测试有了想法和/或深入的理解。
因此，基于经验的技术与基于规范既与基于结构的技术偕行，又可用于没有规格，或者规格不足或过时的时候。
这可能是用于设计测试低风险系统的测试用例的唯一技术，但是这种方法可能在非常紧急的情况下特别有用，事实上，这是导致探索性测试的一个因素。
“随机”方式—考虑了吗？
通常，任何软件模块或系统都有输入域，从这个域里选择并使用测试输入数据建和/或执行测试用例。
现在，如果一个测试人员从必要输入域中随机选择输入，准备测试用例，并用它们来测试应用程序，这种方法被称为“随机测试”。
例如，如果一个模块的有效输入域是1到100之间所有的正整数，然后用这种方法测试人员会随机或胡乱地从该领域内选择值，如，选15 ， 27和33。
但是，使用这种方法，也有一些一直无解的问题：
值（上面的例子中三个值）足以表明，执行测试用或运行例测试时，模块符合其规格吗？
是否有其他输入值，比那些（在本例中）被选中的值，更能找缺陷？
抑或有效输入域外的任何值应该作为执行测试用例的测试输入？
这就是说，测试数据应包括大于100的浮点值，负值或整数值？
因此，上述问题可以立即通过更加结构化的黑盒测试设计方法解决，尽管使用随机测试输入可以节省一些时间和精力，其他测试输入选择方法要求。
但是，根据许多测试专家，随机选择测试输入会产生一个有效的用于执行测试用例的测试数据集的机会非常小，并且对于一个更结构化的方法，随机方法生成测试输入的相对有效性总成为自省和/或研究的课题。