“有效测试用例”我们是指：“一个很可能找出缺陷的测试用例” 。因此，制定有效测试用例的能力对于一个组织迈向一个更高质量的测试过程来说是非常重要的；反过来，　　一个组织迈向一个更高质量的测试过程对制定有效测试用例的能力也有许多积极影响。
例如，如果测试用例是有效的，那么：
　　检测缺陷的概率更大。
　　更有效地利用组织资源。
　　测试再用的可能性更高。
　　更符合测试、项目进度、预算，更重要地，提供更高质量的软件产品的可能性。
测试用例设计方法 - 概念化
　　上面介绍了有效测试用例的种种好处，但缜密考虑测试人员用来设计这些有效测试用例的方法也同样重要。为了回答这个问题，有必要把软件作为一个精心设计的产品来查看和/或检查。现在，有了这个观念，有两个基本方法可以用来设计测试用例：
　　黑盒（有时也称为功能或规格）测试方法。
　　白盒（有时也称为clear或透明盒 ）测试方法。
　　使用黑盒测试方法，测试人员把SUT （测试中的软件）当作一个不知道其内部结构（即如何运作）的不透明盒子，测试人员只知道它的作用。使用这种方法的SUT的大小可以是一个简单的模块、成员函数、对象群、一个子系统、或一个完整的软件系统。此外， SUT的基础行为或功能的描述可以由正式规格，输入/处理/输出图（ IPO），或一套定义明确的先决、后置条件来提供；重要的是，另一个值得一提的信息来源是：需求规格说明文档，通常描述SUT的功能，输入及预期输出。现在，鉴于上述来源，测试员提供指定输入到SUT，进行测试运行，然后确定所产生的输出是否与说明文档中提供的一致。因为黑盒测试方法只考虑了软件的行为和功能，它通常被称为功能测试，或基于规范的测试。这种方法特别有用，极有助于找到要求和规格中的缺陷。
　　与此相反，白盒测试方法关注将被测试的软件的内部结构。因此，使用白盒测试方法来设计测试用例，测试人员应该先了解结构，且为了实现这一目标，必须可随时参考和理解代码或适当的类伪代码的要求。一旦对结构有了必要的了解，测试者可以选择合适的测试用例去实践特定的内部结构要素，并确定它们是否正常工作。例如，测试用例通常被设计来实践所有语句或发生在一个模块或成员函数中的真/假分支。但是，由于白盒测试的设计，执行和结果分析非常耗时，这种方法被限制和/或通常只适用于软件的小部分，如模块或成员函数。然而，白盒测试方法对于找出设计和基于代码的控件的逻辑缺陷和顺序缺陷，初始化缺陷和数据流缺陷等特别有用。
　　然而，从测试员的角度来看，要实现向用户提供低缺陷高质量的软件的目标，必须把这两种方法都用来设计测试用例。另外，这两种方法都支持测试员选择有限数量的将被用于测试的测试用例。这两种方法可以相互补充，因为每个都或许有助于找到某些特定类型的缺陷。重要的是，有了使用这两种方法设计出的一组测试用例，测试员找到SUT中各种不同类型缺陷的机会增加了。

　　测试员还有一套有效的可再用的用来进行回归测试（更改后的重新测试），以及软件测试的新版本。

　　上面是一份概要：使用任一设计方法制定测试用例的各种可用方法。
　　但是，在使用任一设计方法准备测试用例前有一些因素需要考虑清楚。它们分别是：
　　测试相关风险。
　　预期缺陷类型。
　　测试员的知识和经验。
　　测试水平和必须进行分组和管理的小组活动。
　　用于执行测试用例的工具。
　　应用程序，软件和问题域的类型。
　　客户要求，等等。

现在除了上述因素，以下几个要点和/或问题在选择正确的测试用例设计技术中发挥了至关重要的作用：
　　基于“经验”的测试用例设计
　　在基于经验的技术中，是人们的知识，技能和专业知识（关于域，技术等）构成了测试条件和测试用例的基础，且对制定测试条件和测试用例很重要。
　　在这儿，人们技术和业务两方面的经验都是必需的，必要的，因为这给测试分析和设计过程提供了不同的角度。
　　重要的是，有了他们使用类似系统工作的丰富（前）的经验，他们或许对什么会出错，什么有助于测试有了想法和/或深入的理解。
　　因此，基于经验的技术与基于规范既与基于结构的技术偕行，又可用于没有规格，或者规格不足或过时的时候。
　　这可能是用于设计测试低风险系统的测试用例的技术，但是这种方法可能在非常紧急的情况下特别有用，事实上，这是导致探索性测试的一个因素。