投资于测试用例 为了改进测试用例什么是值得做的？什么风险会促使你投资于更好地测试用例？在他们覆盖软件需求时，还不是足够的好吗？对这些问题的答案是，粗劣的测试用例的确会将你暴露于相当大的风险之下。他们在理论上可能覆盖了需要，但很难用来执行测试，并会获得含糊不清的结果。好的测试会获得更可靠的结果，而且会在以下三个范畴降低成本：
1.生产率 - 更短的时间撰写和维护用例
2.可测试性 - 更短的时间来执行他们
3.计划的可靠性 – 估算时有更好的可靠性
本文介绍如何避免因为粗劣的测试案例必然带来的损失。将让我们看到罩盖下各种不同的测试用例，并展示在控制风险的质量中，在何处以及如何建立测试用例。对如何提高生产率、可用性、计划的可靠性和资产管理，将给出切实可行的建议。一旦你了解测试用例是什么和为什么的问题，您可以使用一个标准的核查表，像附录A一样的一个附件，来确定风险领域并改善您当前的和未来的测试用例。
在准备测试软件的过程中，最繁杂的工作是编写测试用例。建立健壮的测试用例的动机是由可能性来激励的，测试用例将被重用于维护版本。超过所有软件开发工作的半数的工作是维护项目。你怎么才能编写良好的测试用例，它将提供经济的测试，首次测试后，在回归测试时将再次使用？让我们通过掀起测试用例的罩盖，看看里面是什么，来开始我们的答案吧。
● 看测试用例内部
● 测试用例的内容（element）
● 针对我们的目标，一个测试用例是一套基于系统需求的，带有预期结果的活动。用例包括这些内容：
● 测试的目标或将被测试的需求的描述
● 它将被如何测试的方法
● 测试的设置：接受测试的应用程序的版本、硬件、软件、操作系统、数据文件、安全访问、时间、逻辑的或物理的起止日期、先决条件（如其他测试），以及对于被测需求（一个或多个）的任何其他有关的设置信息
● 活动和预期的结果，或输入和输出
● 任何校样或附件（可选）
这些同样的内容必需被用在每一级测试——单元、集成、系统、或验收测试的测试用例中。对于功能、性能和可用性测试，它们同样有效。“预期结果”的标准并不适用于一个探索性质的诊断测试或其他测试。实际上诊断测试在其用例中需要其他内容。然而，如果测试是测量性能，那性能应属于一个范围，这个范围就是一个预期结果。
测试用例的另一种描述是，说明、目标和组织安排是用例或规格说明。完成它的步骤被称为脚本。而另一种观点认为目标或说明是一个场景（scenario）或功能用例（use case）。这些观点都符合本文提议的质量评估和改进。
测试用例的质量
有一种误解，以为编写质量是主观的，就像看一幅画，哪里美丽只在观看者的眼睛里。
事实上，编写质量是客观的和可测量的。就像附录A一样，建立一个测试用例的构成内容（目标、方法、组织安排、输入和输出等）的客观核查表，这是很简单的。然后走查每个用例。内容是有或者没有？除了其构成，用例也必须符合这些质量标准：
精确的。它们只测试它们描述中所说的它们将测试的内容。
经济的。它们只有对于它们的目标所需要的步骤或信息。它们不给出软件导航。
可重用的，自立的。一个测试用例是一个对照试验。每一次不管是谁测试它，它都应当得到相同的结果。如果只有作者可以测试它并获得结果，或如果不同的测试者测试，得到不同的结果，那该测试用例就需要在组织或活动上做更多的工作。
适合的。一个测试用例必须适合测试者和环境。如果它在理论上是合理的，但需要所有的测试者都没有的技能，那它将会被束之高阁。即使你知道谁在测试第一次，你也需要考虑维护和回归时的情况。
可追溯的。你必须知道此用例测试的是什么需求。它可能满足所有的其他标准，但如果其结果是，通过或失败都无关紧要，那为什么还要费心做它呢？
可自我清理的。运行后自动收起。它返回测试环境到预测试状态。例如，它不会留下测试系统设置在错误的日期。自动脚本可调用其他脚本来做到这一点。不要把这一标准与破坏性混淆。测试应该是破坏性的，包括试图通过可控制和可重复的方式打破一个模拟生产环境。
这些标准也是客观的和可测量的。它们也可以被添加到您的核查表。
如果谁知道需求和受测应用程序，那他应该填写该核查表作为一个同行审查的一部分。
遵循多少标准只有测试后才能知道，但它们都是可测量的。对于新的测试编写者，这是一种特别有用练习，看看他们在哪块始终没有达到某一要素，或不符合某一标准。
测试用例的格式
一个测试用例看起来像什么呢？它们似乎分为三个主要群组：分步、矩阵和自动化脚本。当然自动化脚本将作为一个在线文件来运行，毫无疑问，其他两个必须是基于纸张的。他们也可以是在线的。让我们来看看每一个的格式：
分步。图1显示了这个基本的格式模样。这个格式的一个完整的视图，在一个带有其他测试内容的模板中，作为附录B来显示。
步骤 | 活动 | 预期结果 |
1 | 输入新的名称和地址。按<OK> 。 | 显示屏幕008新名称的详细信息。 |
2 | 用自然的数据填充所有空格。抓屏。按<OK> 。 | 显示屏幕005维护。 |
3 | 点击<Inquiry>按钮。 | 显示屏幕009查询的详细信息。 |
4 | 从抓屏上输入名字。按<OK> 。 | 显示屏幕010记录详细信息。 |
5 | 比较记录细节和抓屏。 | 所有详细信息完全匹配。 |
图1 - 分步测试用例详细信息
矩阵或表格。图2显示了这个格式的基本模样。这个格式的一个完整的视图，在一个带有其他测试内容的模板中，作为附录C来显示。
日期 | 1/96后受雇 | 401K | 生命险 | 付款数 |
10/25/99 | Y | 1 | 3 | $24.50 |
1/4/98 | Y | 3 | 1 | $34.00 |
3/6/96 | N | 2 | 5 | $48.00 |
8/15/96 | Y | 2 | 5 | $86.25 |
8/15/96 | N | 2 | 5 | $105.00 |
图2 - 矩阵测试用例详细信息
自动化脚本。图3显示了这种格式的模样。
# Open the Fax Form menu_select_item ("File;Fax Order..."); set_window("Fax Order"); # Retrieve the Fax Order information and compare it to data from the main window edit_get_text ("Arrival:", text); if(main_data["arr_time"] != text) { failure_msg = arrival_fr_mismatch; result = FAIL; |
图3 - 自动化脚本测试用例详细信息
使用测试类型
每种类型用例的最佳用途
● 分步用例多用于：
● 分步
● 一次性测试用例，每一个都不同
● 从一屏到另一屏展开的业务场景
● 许多处理规则
● GUI 界面
● 在矩阵中难以表示的输入与输出
分步用例不一定需要如图1所示的有一个按键水平的详述。活动步骤可以在一个更高的水平，如：打开“my account”页面，寻找一个日期范围内的事务，注意该范围:______ ，打印报告，转送报告，等等。
矩阵。矩阵用例多用于：
● 填写表格有许多变化，同一字段，不同的值、输入文件
● 相同的输入，不同的平台、浏览器、配置
● 基于显屏的字符
● 用矩阵表示出来最好的输入与输出
几乎任何测试都可以表示成一个矩阵，但要裁定的问题是，对于测试，是否矩阵是最好的方式。最重要的是，矩阵要辅之以测试的一个描述、组织安排，以及如何记录结果。如何测试矩阵，对于编写者可能是显而易见的，但没有更多的指导时，测试者可能会做错。
矩阵的一个变化是输入列表。它可以被插入一个分步测试或作为一个带有关于测试的解释性内容的矩阵。
自动化脚本。使用自动化测试软件的决定，更多的与进行测试的规划和组织相关，而与将要测试什么关系不大。工具改变时，一些技术问题必然会遇到，但大多数应用程序都可以找到适合的技术。项目管理必须明白，编写自动化用例比手工测试需要花费较长的时间，因为手工测试必然首先是写成静态的。当界面稳定时，测试可以被录制。真正的自动化测试的回放是在软件生命周期的维护阶段。此时，脚本可以被反复执行，甚至无人值守，极大节省了测试时间。
管理部门必须配备人员，用工具语言，如C++或Visual Basic 等来编程。简单的脚本可以用大多数测试分析工具录制，但功能更强大的脚本，往往使用自定义函数和对象，必须由程序员编写。一个组可以一起安排，几个人做普通的录制/回放脚本，一个人编程。
和其他类型的测试用例相比，该用例适用于录制和回放，或数据驱动脚本。除了录制/回放脚本，自动化工具也用于性能和负载测试。他们可能会使用手工分步用例或矩阵，详细说明自动化工具将如何被用来创建虚拟用户，给出事务脚本，监控性能，和其他活动。
