Narayana Maruvada是一名计算机科学与工程专业的研究生，目前担任系统分析员—ValueLabs质量保证。  Narayana拥有超过7年开发和测试基于Web的应用程序的工作经验。  他的主要工作和专长的领域是测试建立在用于不同域的开源技术上的应用程序及产品。  他是对评估该系统的功能和非功能属性，研究和实施新的测试工具、技术与方法有着浓厚的兴趣。他为了改进测试过程，努力扩展佳做法和质量标准。

　　显然，无论缺陷预防工作贯彻落实地多好，软件组件总有缺陷。这很明显，因为开发商无法阻止/消除软件开发周期的所有缺陷。因此，软件必须进行彻底的测试，然后才交付给终用户。测试人员的责任是：设计既可以（?）找软件缺陷，又能（ii ）评估该软件的性能，可用性和可靠性等方面的测试。
　　现在，为了实现这些目标，测试人员必须（往往是从一个非常大的执行域中）选择和/或制定测试用例的有限数量。不幸的是，完整的测试通常不是在这个范围，预算和时间的约束内实现和/或执行的。重要的是，当测试开始失控且不按计划地运行时，由于预期无法实际，测试人员往往承受了来自管理层和利益相关者的巨大压力。
　　因此，测试人员必须有效地计划测试并制定正确的测试用例，选择并执行合适的用例，监控过程，以确保有效利用工作资源和时间。所以，要列出这些无疑是一项艰巨的任务；要有效地实施，测试人员需要受过适当的教育和培训并拥有赢得管理层支持的能力。
　　一般情况下，测试人员会用两种不同的测试方法，其中，使用常规方法，测试人员主要是尝试用所有可能的输入去测试一个模块或组件，用所有可能的软件结构去实践。尽管这种做法仍在使用，测试人员却在慢慢灌输推理软件的一切的价值，终使他们能够检测出所有可能存在的缺陷。但见多识广且有学问的测试员们都明白，这在现实或经济上是不可行，不可实现的目标。
　　现在，另一种方法可能是让测试员们随机选择测试输入，希望这些测试能将大的缺陷找出来。不过，测试专家认为，随机生成的测试输入在评估系统的质量属性方面表现纪录欠佳。所以，从测试的角度来看，这是一个无休止的争论和悬而未决的问题。尽管如此，我们还是认为，测试员的终目标是了解测试的功能、输入/输出域和使用环境，等等。
　　同样，对于某些特定类型的测试，测试人员也需要详细地了解代码是如何构造的。此外，测试人员也需要利用关于常在软件开发或维护过程中生成的特定缺陷的知识。有了这些信息，测试者必须明智地选择测试输入的子集，以及被认为有可能找测试过程中条件和限制内的缺陷的测试输入组合。然而，这个过程需要时间和精力。所以，测试人员知道且赞同：只有开发出基于执行的测试的有效测试用例，才能大化和/或优化对时间和资源的利用。
　　“有效测试用例”我们是指：“一个很可能找出缺陷的测试用例” 。因此，制定有效测试用例的能力对于一个组织迈向一个更高质量的测试过程来说是非常重要的；反过来，　　一个组织迈向一个更高质量的测试过程对制定有效测试用例的能力也有许多积极影响。
例如，如果测试用例是有效的，那么：
　　检测缺陷的概率更大。
　　更有效地利用组织资源。
　　测试再用的可能性更高。
　　更符合测试、项目进度、预算，更重要地，提供更高质量的软件产品的可能性。

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

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