GoodTest.doc

　　摘要 　　设计好的测试用例是一门复杂的艺术。其复杂性有三个原因： 　　测试用例能帮我们发现信息。不同类型的测试对不同类型的信息有效。可以从多方面证明测试用例是“好的”。但没有一个测试用例在任何方面都很优秀。 　　人们往往会根据某个测试类型来创建测试用例，比如域测试或基于风险的测试。好的域测试与好的基于风险的测试是不同的。 　　什么是测试用例？ 　　让我们从基础开始，什么是测试用例？ 　　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的见解。）。要取得测试结果，我们需要充分地寻找测试提供的信息。 信息目标 　　执行测试时，我们能学到或得到什么？这里有几个例子： 　　发现缺陷。 　　这是测试普遍的目的。运行测试的目的是触发故障并暴露缺陷。 　　通常，我们是在产品所有感兴趣的部分寻找缺陷。 　　缺陷数量最大化。 　　这与“发现缺陷”的区别就是缺陷总数比其覆盖面更重要。 　　即使这是及时发现更多缺陷的有用方法，我们也只是狭隘的关注少数几个高风险的方面。 　　阻止不合格产品的发布。 　　测试人员发现产品有严重缺陷时阻止其出库，直到这些问题得到解决。在每次的发布决议会上，测试人员的目的是发现新的瑕疵、缺陷。 　　协助管理者做出库的决定。 　　管理者普遍都关心这方面的风险。 　　他们想知道缺陷覆盖面（可能不是过于简单的代码覆盖面统计，而是说明产品发现了多少缺陷，有多少还没有解决），和已发现问题的重要性。书面上出现的重大而不会引起客户不满的问题，可能不会影响产品的出库决定。 　　技术支持成本最小化。 　　与技术支持或服务组一起工作，测试组要识别出需要支持的问题。这些通常是与产品相关的外围支撑，是不需要测试的，例如，测试产品需要与特定的打印机一起工作或者从第三方数据库成功地导入数据，可以高频率的访问和数据崩溃。 　　遵照规格