这项研究部分基于NSF制定的EIA-0113539 ITR/SY+PE：“提高软件测试者的教育。” 材料中表达的任何观点、发现和结论或者评论都属于作者，不代表国家科学基金会（NSF）的观点。
摘要设计好的测试用例是一门复杂的艺术。其复杂性有三个原因：
测试用例能帮我们发现信息。不同类型的测试对不同类型的信息有效。
可以从多方面证明测试用例是“好的”。但没有一个测试用例在任何方面都很优秀。
人们往往会根据某个测试类型来创建测试用例，比如域测试或基于风险的测试。好的域测试与好的基于风险的测试是不同的。
什么是测试用例？
让我们从基础开始，什么是测试用例？
IEEE标准610（1990）对测试用例的定义如下：
1） 为特定目的开发的一套测试输入、执行条件以及期望结果的集合，例如运用特殊的程序路径或检查应用是否满足某个特定的需求。
2） （IEEE Std 829-1983）指定输入、预期结果和一组测试项的执行条件的文档。 根据Ron Patton（2001,p,65）的定义：
测试用例是进行软件测试时，尝试使用的特殊输入和遵照的流程。
Boris Beizer（1995,p.3）把测试定义为：
一个或多个子测试的执行顺序就像是一个序列，因为一个子测试的结果和/或最终状态是下一个子测试的输入和/或初始状态。“测试”这一词通常涵盖子测试、专用测试和组测试。
Bob Binder（1999,p.47）定义的测试用例：
测试用例阐明了IUT测试前的状态及其环境、测试输入或条件、以及期望的结果。期望的结果指明了IUT会从测试输入中产生什么结果。这些细则包括了IUT产生的信息、异常、返回值、IUT的结果状态及其环境。测试用例也会为其他构成IUT及其环境的对象指定初始和结果条件。
实践中，很多事物都可以当作测试用例，即使他们完全不符合准备好的测试文档。
Brian Marick用一个相关的术语来描述没有完全文档化的测试用例，其测试观点是：
“测试观点是对被测事物的一个简要描述。例如，测试平方根功能，其中一个测试构思可以是“测一个小于0的数”。这个测试想法是检验代码是否有错误处理机制。”
我认为，测试用例是对程序提出的质疑，运行测试的目的就是获取信息，比如程序是否会通过测试。
在明确测试观点是什么以及怎样把这种思想应用在产品的某些特殊方面（比如，外观）时，需要还是不需要注明流程细节。依照习惯，如果文件记录是测试用例不可或缺的一部分，那么就请用测试观点代替遵循的所有测试用例。
测试用例定义的一个重要应用就是：测试用例必须具有一定的能力暴露信息。
按照这种定义，测试用例的变化范围会随着程序趋于稳定。测试初期，在程序的任何方面都会出现问题的时候，试着用最大的有效值填写数据型的输入字段是一个明智有效的测试方式。数周之后，程序经过数次构建通过测试之后，不再需要测试用例对这个字段进行独立测试，因为它已经具有了处理异常的能力。此时，更多相关的测试用例会同时组合10个不同变量组成边界线，或者会根据较长的测试序列或情景设置边界。
同样，按照这种定义，对测试用例数量报告的度量是没有意义的。几周前一组20个单变量的测试是有用的，而现在它们已经没用或者合为一体时，应该怎么做？假设你创建了一个包含20个测试的组合测试，这个测试的度量报告是20还是21个测试？仅执行一次的测试是怎样的？因为程序设计变化而使测试没有意义时，没有运行设计和实现的测试是怎样的？
测试用例定义的另一个应用是设计的测试不是用来暴露缺陷的，目的是信息。通常，缺陷中含有信息，但不是绝对的（这要归功于Marick,1997的见解。）。要取得测试结果，我们需要充分地寻找测试提供的信息。
信息目标执行测试时，我们能学到或得到什么？这里有几个例子：
发现缺陷。
这是测试普遍的目的。运行测试的目的是触发故障并暴露缺陷。
通常，我们是在产品所有感兴趣的部分寻找缺陷。
缺陷数量最大化。
这与“发现缺陷”的区别就是缺陷总数比其覆盖面更重要。
即使这是及时发现更多缺陷的有用方法，我们也只是狭隘的关注少数几个高风险的方面。
阻止不合格产品的发布。
测试人员发现产品有严重缺陷时阻止其出库，直到这些问题得到解决。在每次的发布决议会上，测试人员的目的是发现新的瑕疵、缺陷。
协助管理者做出库的决定。
管理者普遍都关心这方面的风险。
他们想知道缺陷覆盖面（可能不是过于简单的代码覆盖面统计，而是说明产品发现了多少缺陷，有多少还没有解决），和已发现问题的重要性。书面上出现的重大而不会引起客户不满的问题，可能不会影响产品的出库决定。
技术支持成本最小化。
与技术支持或服务组一起工作，测试组要识别出需要支持的问题。这些通常是与产品相关的外围支撑，是不需要测试的，例如，测试产品需要与特定的打印机一起工作或者从第三方数据库成功地导入数据，可以高频率的访问和数据崩溃。
遵照规格说明书进行评审。
规格说明书中提出的要求都是经过审核的。规格说明书中没有列出的程序特性不（当作目标的一部分）进行审核。
遵照规范。
如果规范指明了覆盖范围内的某个类型（例如，至少对产品的每个声明做一个测试），那么测试组要创建合适的测试。如果规范为规格说明书或其他文档指明了一个类型，那么测试组可能需要检查这个类型。一般地说，测试组关注规则中覆盖以及没有覆盖的任何事物。
最小化安全诉讼风险。
任何会导致事故或伤害的失误都应该在第一时间被关注。导致时间或数据丢失或数据损坏，但不会对实际事物带来伤害或损坏风险的失误可以不考虑。
发现使用产品的安全情景（即使发现存在缺陷，也能工作的方法）。
有时，寻找的是可以持续不断进行一项作业的方法---其他人依照一组指令会可靠地发送期望产生的有益信息。在这种情况下，测试员不是寻找缺陷。他是在进行试验，按照经验推敲和证实进行作业的方法。
质量评估。
这是一个棘手的目标，因为质量是多维度的。
质量的性质依赖于产品的性质。例如，一个没有娱乐性的摇动物体的电脑游戏是一个令人厌恶的游戏。
进行质量评估--测量并报告质量水平--你可能需要对这个产品的大多数重要质量标准有一个明确的定义，并且需要有相关的定义测试结果的理论知识。例如，可靠性不只是关于产品缺陷数的。它是（或经常被定义成）关于可靠性相关的故障数，这些故障期望在一段时间内或一段时间的应用中发生。（可靠性相关？比如，测量可靠性时，企业可能不关心错误信息中的拼写失误。）为了进行预测，你需要一个精确的、依经验形成的合理原型，使测试结果具有可靠性。测试包括获取模型需要的数据，包括产品绝对稳定和不稳定的方面做深入的工作。设想一个可靠的模型是基于统计（可能以严重性类型来区分）每N行代码或每K小时测试发现的BUG数的。查找BUG是重要的，消除重复也是重要的，发现并解决问题使缺陷报告更易于理解、更可能纠正是（在评估的范围内）超出范围的。
检验产品的正确性。
测试是不可能做到这一点的。你可以证明产品不正确，或者你可以证明你在特定时间内用特定的测试策略没有找到任何错误。但是，你不可能进行详尽的、无一遗漏的测试，并且产品可能在你没进行测试的条件下宣告失败。（如果你有一个实在的、可靠的模型）你能做的最好的就是评估出现错误的概率。（参照下面关于可靠性的讨论）。
质量保证。
尽管质量保证是共同的目标，但是不能通过测试来保证质量，不能通过获取度量值来保证质量，不能通过设置标准来保证质量。
质量保证包括构建一个高质量的产品，以及为此贯穿在整个开发过程中有熟练技能、有时间、有激情、有方向、有创造自由的人。
这超出了一个测试团队的工作范围，但在项目经理和相关实施者的范围内。
在进行技术研究的过程中测试团队可获得一定的帮助，但这些研究并不不能保证质量。
给定一个测试对象，好的测试过程能够提供与这个对象直接相关的信息。
