如何撰写更好的测试用例【待继续修改】

原文位置：

by Dianne L. Runnels, CQA, CST

Interim Technology Consulting

对测试用例的投资：

改进测试用例有什么价值呢？当你集中精力于更好的用例时，你会遇到什么样的风险呢？之前的用例已经覆盖了软件需求，那还不够好吗？这些问题的答案是，粗糙的测试用例会将你置于相当大的风险中。他们能从理论上覆盖需求，但是很难执行测试，预期的结果也是模棱两可。好的测试用例包含更可靠的测试预期并且能从三方面降低测试成本。

生产力：更少的时间来编写和维护用例

可测性：更少的时间啦执行这些用例

调度的可靠性：更可靠的测试预期

本文介绍了如何避免由于粗糙的用例设计所带来的风险。我们将更底层地从不同类型的测试用例分析，并展示在何处及如何建立质量来控制风险。它会就如何提高生产率，可用性，调度的可靠性和资产管理提供切实可行的建议。一旦你了解了用例的“什么”和“为什么”，你可以使用一份标准的检查点清单来确定风险领域以改善当前和未来的测试用例。

为测试软件所做的最多的工作就是编写测试用例。激励大家编写强健的测试用例的是维护版本成本减少的可能性。半数以上的软件项目都是需要长期维护的项目。那么你怎样擦能写出既经济，有能在回归测试中再次使用的高质量的测试用例呢？让我们开始寻找答案，撩起测试用例的面纱，看看里面究竟有什么。

展望测试用例内部：

测试案例的要素：

对我们而言，一个测试用例建立在系统需求之上的一系列动作和预期结果的集合。测试用例包括下面这些内容：

u

测试目的或者对于所测试内容需求的描述

u

测试方法

u

测试计划：应用程序版本，硬件环境，软件环境，操作系统，数据文件，

安全访问，测试时间，逻辑或物理的日期，测试先决条件

(

比如其他测试

)

，以及其他任何与被测软件系统需求相关的测试信息。

u

步骤和预期结果，或者输入输出

u

任何检验或附件（可选）

这些相同的元素，需要在每种级别测试的测试用例中体现：集成，系统，或

验收测试，对于功能，性能和可用性测试同样适用。“预期结果“标准不适用于诊断或其他探索性测试。诊断测试需要在他的用例中添加其他因素。不过，如果我们测试的结果应该属于一个范围，那么这也是“预期的结果”。测试用例的一个替代描述是说明，目的和设置情况或详细说明书。完成这些的步骤被称为脚本。然而另观点是将目的或者描述称为测试场景或者测试用例。所有这些观点在本文中对于质量评估和改进建议都是一致的。

测试用例的质量：

有一种误解，用例的编写质量是就跟欣赏一幅画一样，是主观的，就如情人眼里出西施。其实，用例的编写质量是客观的和可衡量的。如附录

A

中所示，我们能建立一个清晰的检查点列表，包含测试用例的结构性因素

测试目的，测试方法，测试计划，输入和输出。然后遍历每条用例，元素是有或没有？此外对它们的结构，测试用例也必须符合下面这些质量标准。

u

精确的，他们只测试在他们的说明中需要进行测试的。

u

经济的，他们只有为了测试目的所必须的测试步骤说明，而不是为软件写一个手册

u

可重复，自立式的，测试用例是一个对照实验。不管是谁在什么时间执行测试，都应该得到完全相同的测试结果。如果只有测试编写者能够执行测试并获得结果，或如果不同的测试人员得到不同的测试结果，那么我们需要在测试步骤及动作设计上做更多的工作。

u

适当的，测试用例要对测试人员和的环境都应该是合适的。如果所设计的测试用例只是理论上的，实际执行需要的技能没有一个测试人员拥有，那么这只是一个空架子而已。当你知道谁是将第一次执行测试，你需要为他的测试执行铺好路：用例维护和回归。

u

可追踪性，你需要知道你用例所测试的软件需求是什么？它可能符合所有其他标准，但如果其结果，及格或不及格，不打紧，何必呢？

u

自我清理，执行完后将环境清理干净，测试环境返回测试前的状态。例如，不在错误的日期离开所测试的测试系统。自动化脚本，可通知其它脚本来做到这一点。不要将这个标准和破坏性混淆。测试应具有破坏性，包括通过一些可控制的，可重复的方法模拟一个生产环境。

这些标准也是客观的，可衡量的。他们也可以添加到您的清单。那些理解产品需求及测试的应用程序的人可以填写这份清单作为同行审查的一部分。这同一些标准直到被测试之后才能知道一样，但他们都是可衡量的。这对于一个新的用例设计者而言是一个有帮助的练习，让他们直到在考虑用例设计时会漏掉哪些影响因素，或者哪些不符合标准。

格式化测试用例：

测试用例看起来像什么？他们似乎分为三大类：分步测试，矩阵和自动化脚本。虽然自动化脚本以联机文档的方式运行，这不是假设其他两个必须是基于纸张。他们也可能会联机。让我们来看看各种格式：

分步测试

，图

1

显示了这种格式的基本样式。这一格式的完整视图，将在附录

B

中作为模板显示其他的测试元素。

Figure 1 - Detail of step-by-step test case

矩阵或表

：图

2

显示了这种格式的基本模样。这一格式的完整视图，将在附录

C

中作为模板显示其他的测试元素。

Figure 2 - Detail of matrix test case

自动脚本

，图

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;

Figure 3 - Detail of automated script test case

使用测试类型

每种类型的最佳使用情况

分步测试

：分步测试用例最有成效的用途是：

l

一次性测试用例，每一个不同的

l

业务模式各种各样

l

很多处理规则

l

图形用户界面

l

输入和输出难以用矩阵表示

分步测试的用例不一定需要有一个按键的细节程度，如图

1

所示。那个操作步骤，可以在更高的层次，例如：打开“我的帐户”页面，搜索交易日期范围，注意范围：

，打印报告，提出报告，等等。

矩阵

，矩阵用例最有成效的用途是：

l

在一张表中填写各种不同的值，同一领域，不同的值，输入文件

l

相同的输入，不同的平台，浏览器，配置

l

屏幕字符

l

输入和输出最好以矩阵表示

几乎所有的测试，可以表示成为一个矩阵，但问题是决定矩阵是否是最好的测试方法。矩阵由描述，计划以及如何记录结果组成，这是最重要的。如何测试矩阵这对于用例设计者而言这可能是显而易见的，但对于其他测试人员，如果没有更多的指导，情况就不一样了。

矩阵的变化其实就是各种输入。一个分步测试或矩阵可以作为测试的解释性要素插入进来。

自动化脚本

，决定使用自动化测试软件更大程度取决于做测试的项目和组织，而不是被测试的是什么产品。还有一些技术上的问题必须满足，各种工具都各不相同，但大多数应用程序都可以找到一个合适技术。项目管理人员必须明白需要编写自动化测试用例比手动测试时间长，因为必须手动测试用例仍然需要先写。当接口是稳定的，则测试也是可被记录的。自动化测试真正的回报是在软件生命周期的维护阶段。然后那时候，脚本可以重复执行，即使是在无人值守的时候，测试时间大量节省。

管理部门必须提供一些使用工具语言如

C + +

或

Visual Basic

来编程的人。简单的脚本可以由大多数的测试分析人员去录制，但更强大的脚本往往需要使用自定义函数和对象，必须由程序员编写的。一个小组可以由几个人做普通的记录

/

回放脚本，一个人编程一起工作。

对比其他几种比较适合于录制和播放，或数据驱动的脚本，使用自动化工具的性能和负载测试就不仅仅是这些了。他们可能使用常规的分步用例或矩阵来详细介绍自动化工具如何使用，以创建虚拟用户，运行事务脚本，监控性能，以及其他活动。

选择测试类型

人们选择哪种测试用例的类型，更多的是由所在组织的文化以及直觉来决定的，即“什么才是适合软件以及测试方案的”。“我们一直是这样做”往往被加入一些神秘色彩，难以消灭：

神话

1

，分步测试用例需要很长时间才能完成，我们消耗不起。

现实：他们可能会或可能不会花费更长的时间写作，粒度使他们牢固，易于维护。它们是用来充分测试某些功能的唯一方法。

神话

2

，矩阵始终是最好的选择，使用它

现实：一个永恒的问题是将恰当的设置信息放到一个矩阵中。这常常导致信息被忽略，或更糟糕的是，如果不同的设置或输入类不能成为一类进入矩阵，他们不会被测试到的。

神话

3

，高科技是最好的，如果你能将测试用例自动化，那么就这样做。

现实：决定使用自动测试应基于许多因素。

神话

4

，我们没有时间写手动测试用例，让我们自动化。

现实：自动测试用例相比于其他两种类型需要更长的时间来编写

不成熟的组织（个性超过流程的）当领导人这样告诉他们时，是最容易假设这些神话是真的。他们质量的道路将是非常漫长的。他们可以继续对于测试用例的误解，直到他们认识到计划没有完成或预算损失，显然是由于不良的测试所引起的。

另一种阻碍大家利用最合适的测试用例用于工作的原因是是口头之间的紧张关系和数字

表达。如果你擅长于多种测试类型，那么您可能更喜欢某种测试类型，而不是直观。分步测试更倾向于口头，矩阵则更倾向于数字。良好的培训应建立对于每种测试用例的理解和信任，每一个种测试都有它最有生产力的应用场景。但是个人喜好是一个不容忽视的因素。如果你是经理，你需要通过教育和实例来弄懂。通常，最有成效的途径是使用所有三种类型用例方法，前两个主要用于单元，集成和系统测试，回归测试使用自动化的脚本。

改进测试用例

提高测试用例的可测试性

可测性的定义是很容易测试。实际上，容易可通过需要多长时间执行测试来衡量，以及测试人员在测试过程中是否对自己所进行的事情有明确的认识。也就是说，如果测试人员依照用例执行，测试结果无论是否通过，都是正确的。

通过语言改善可测试性

测试步骤应该用积极的用例，告诉测试人员做什么，例如：

·这样做，那样做

·导航到购物车页面

·比较购物篮中的商品与屏幕截图

·单击

<

确定

按钮

它应该清楚的说明是测试人员在做还是由系统来做。如果一个测试人员看到“按下按钮”这是否意味着他或她应该按下按钮，还是验证系统的确将它显示为已经按下的状态呢？它最容易搞混测试人员的是将动作和结果混淆。

在图

1

中，动作总是在左边，结果在右侧。测试人员要做的是动作，系统要显示或处理的

=

是结果。

一个简单的习惯，如果我们知道一个主题内外，实际是以不同的方式描述同样的事情。在测试语言中，必须一丝不苟地记录屏幕上的命名，字段，服务器，

Web

页或其他测试对象。在一个开发团队，我们经常有对某些物体笼统称呼的习惯，即使在原型中，如“电子邮件答复屏幕”，它的标签实际上说“命令确认。或者我们可以把号码，与屏幕对应，当屏幕不显示任何地方时，测试人员可以看到它。测试人员必须有最初测试用例设计者的参考。

测试可以加速，如果对于需要核实的测试输入建立结构化的测试，例如，如果您测试的是审计日志，你不能预先知道确切什么时候一个测试人员将完成一个可审计的行动。如果你告诉他们要注意它，它可能是潦草的测试，搜索周围找到它。最好是在测试用例中留下空间，他们可以用来记录，例子：

Delete item date:________

Time: _______

Item ID:________

Tester login ID:________

通过控制长度改善可测性

一个测试用例应该多长？分步测试的一个比较好的长度是

10-15

步骤，除非测试人员不能保存他们的工作。保持这个测试长度有下面几个好处：

l

在每个小的测试步骤中，执行测试的时间很短

l

测试人员不太可能迷失方向，犯错误，或需要援助。

l

测试经理可以准确地估计需要多少时间来进行测试

l

结果更容易追踪

不要试图对

10-15

步中很多的行动步骤放到一步中。一个步骤应当是一个明确的输入或测试任务。您可以对一些相同的步骤，如点击一个简单的动作，点击

<

确定或按回车键进行标示。另外一个步骤可以包括逻辑有关的输入集合。如果系统并不是对每一个步骤都有相应，则不需要在每一步中写出预期结果。

保持个体的测试用例简短，并不是为了与传统的最小化测试量进行区别。传统的目标的标准是想在所要求的

10-15

步中测试更多的需求，使该业务情景或测试用例的使用更有意义。该标准还旨在避免重复，也就是在多条测试用例中测试同一个需求。你不想通过使每个用例很庞大来达到最小化用例数的目的。而这对以后测试执行或者维护来说都是一个噩梦。一个更好的方式来看待旧的“最低数量的测试，”估计将是一个“最低限度数的步骤。这样每个用例设计成

50

步来建立很少的用例并没有明显的优势。

矩阵的一个很好的长度是可以在大约

20

分钟测试完成。

一个自动脚本长度不是测试执行问题，因为自动化测试通常是时间问题。相反，这些问题主要受到内容，维护和缺陷跟踪的影响。一个业务场景或每个脚本的使用实例就足够了。它可以根据须要加载数据或改变输入组合来不断循环。

累积的测试用例的利弊：

累积的测试用例是那些依赖于以往的测试用例运行的

case

，例如当当你需要运行

case#6

时，你需要先运行之前的

case1-5

。你的目标是保持每个测试用例的独立。这样能给人在测试执行时以最大的调度灵活性，并减少了维护时间。不幸的是，往往在一个标准中是弊的地方在另外的标准中却相反，例如保持每个测试用例段，并且不重复的覆盖。您将如何做到这一点？

l

问问自己，你是是否真的需要从另一个测试用例中获取数据输入？如果是这样，检验标准必须是累积性的。

l

只要有可能，提供以前测试用例的替换。这意味着他们可以使用的在先前的测试中创建的数据，但他们也可以使用其他数据。例如：“你需要两个帐户在

90

天不良状况，就像为逾期帐户创建的测试用例。

l

保持作为其他测试用例的参考，尽可能准确一致。不要只根据用例数来看测试。测试须要重新编号，如果您使用编号，也包括了标题或说明。这个可避免维护上的噩梦。

关于整理测试用例以提高可用性和可测试性的，另外一个问题是他们要被用于商业。在累计的用例中，什么才是最终用户通常做的第一件事，如果测试人员是商业用户，他们对于软件的完成情况有一个心理预期，本地化所生产的软件，目的就是提高他们的测试生产力。

提高生产率的模板：

测试用例模板是一个标记了各种输入域的表格。有分步测试的用例模板，是附录

B

，这是一个提高测试用例的伟大开始。它支持跳跃式的过程并且支持每个元素的单独设计。以下是使用模板的一些其他好处：

l

防止空白页恐慌

l

帮助防止混乱

l

建立标准

l

有漂亮的测试文档形式

l

帮助测试人员查找信息

l

可以包括测试过程有关的其他领域

提高生产率与克隆

：

克隆测试用例方法意味着在一个测试用例中使用另一个测试用例中的样式。那些能够区别仅仅在变量不同并且能很容易进行替换的分步式的用例是进行克隆的绝佳候选。例如，您可能对维持一个供应商数据库测试。许多但不是所有的步骤，也将适用于托运人数据库。当你知道通过要求或原型是制定战略职能工作的方式，您可以可控这些测试用例。克隆它们并不意味着他们需要一起测试。您可以克隆步骤，也可以克隆测试用例。

文字处理和测试编写的软件支持克隆的功能，例如“另存为”，“复制”和“替换。”校对这些用例，以确保所有原始引用都用克隆来取代是很重要的。您还可以存储为文本和宏来节省时间，但不要试图让一个模式适合于所有的地方为代价。从例如其他人的测试用例或者用户手册或帮助教程来寻找使用克隆的机会。他们可能也在寻求与你互换测试用例。如果您正在管理一个用例设计团队，保持一测试设计者之间的交流，使他们能够积累和分享测试用例案件。

矩阵也可以克隆，特别是如果设置部分是相同的。所做的改变也就是变量的名称和值。同样，请一定要校对新版本。

通过测试管理提高软件生产力：

软件设计为从开始设计就开始考虑对于测试编写的支持是对测试用例编写的的最大生产力助推剂。它在文字处理，数据库或电子表格软件上有如下这些优势：

l

使编写和概述更容易

l

促进用例和步骤的克隆

l

轻松添加，移动，删除用例和步骤

l

自动编号和重编

l

使用易于遵循的测试模板

测试创作通常包括在现成的测试管理软件，也可以是自定义的。测试管理软件通常包含不仅仅是测试编写更多的功能。当你将购买因素纳入其中，价格越高所提供的功能也越多。如果你正在购买测试管理软件，它应拥有上面所有的可用性方面特点以及加上下面这些额外功能：

l

可以将用例导出成其他格式

l

多用户

l

跟踪测试用例编写进度，测试执行进展

l

跟踪测试结果，自动分配到数据库或缺陷跟踪

l

连接到需求和

/

或创建覆盖矩阵

l

通过测试用例建立测试集

l

允许灵活的安全

错误和挑战

七个最常见的测试用例的错误

每个用例设计者的作品，测试用例的缺陷往往集中在一个一定的编写错误中。如果您正在编写用例或管理用例设计者，不要等到用例等到用例设计完了才发现这些错误。每隔一两天都需要对用例进行审核，看是否这些失误是否会导致用例难以执行和难以维护。可能你会发现在下面七个最常见的测试用例错误中处理好，那儿对于整个用例设计都更有机会：

u

编写的用例太长

u

编写的用例不完整，不正确，或有不连贯的设置

u

步骤脱节

u

使用已经改变或不再存在的命名字段

u

目前还不清楚测试或系统如何操作

u

不清楚什么才是通过或失败

u

未能清理

编写良好的测试用例所要应付的的挑战：

即使你采用最好的技术和标准，你仍然需要克服相同的挑战，面对每个测试设计者的成果。让我们看看测试用例设计中通常遇到的挑战，看看它们如何可以管理对策，尽可能的提高质量。通常的挑战在实施的项目一级，与之对应的是测试管理的水平。如果他们都能从测试管理水平用例设计实施，测试设计人员则能很好处理。

挑战：需求变化

回应：

u

这里最好的防御是被告知。在编写测试用例致歉，在每二个合适的状态下，找出其中变化最大的需求风险。制定战略哪些测试用例在什么情况下不会受到影响的变化。先写出这些不受影响的用例。

u

内建变数或“待定”，你须要进一步确认并随后填写。

u

确保需求方知道了修改已经完成的测试用例代价。并量化每个用例须要付出什么代价。

u

让项目管理确定用例编写或修改的优先级。让他们看到你不能做到这一切，并请他们来决定哪儿会是最大风险。

u

释放并不很正确的测试用例修正。要求测试人员来标记哪些必须什么改变。以调度更多的时间来进行测试，将时间用于用例维护。

挑战：计划变更

回应：

u

如果测试的时间提前，让管理人员参与到对测试用例影响的评估中。正如在不断变化的需求的挑战，让他们可以选择他们想要的风险。

u

新增的工作人员，如果时间允许，只有一两个星期的训练，他们要生产，如果有人的话你需要有别人来指导和审查工作。

u

转移书面用例，以便让您写的应该首先执行的测试用例被优先执行到。尽量保持一个每个测试人员前面只有一个

case

。

u

你缩减你的测试用例，保证需求被测试到。这没有随机测试那么糟糕，但管理层应该知道我们的测试结果不能像完全测试那样可靠。规划更多的时间来执行这样的测试用例，并且测试完成后补充完成测试用例。

u

让测试设计者愿意执行测试设计测试用例，就像他们过去所愿意做的。规划更多的时间来进行测试以及测试完成后的用例补充

挑战：人员更替

回应：

1

。新的工作人员需要理解目标，进度，以及目前的测试项目的组织结构，如果可能，以书面形式写下来。如果只是口头，慢慢的就会丢失。

2

。新的工作人员应集中于了解该软件的商业用途，然后是要求和原型。他们写的用例很少，但往往是正确的。

3

。新的工作人员在标准的培训中应该多动手，多通过例子实践，以指导如何应用他们。他们的工作应优先予以密切检查。

4

。将新的工作人员放到那些有技术特点适合进行用例设计的地方。

测试用例资产

测试用例资产保护

保持测试用例的价值最重用的方法是维护测试用例以保证他们是可以执行的，他们应该在每个测试周期进行维护，因为就跟测试人员会在测试执行中发现软件缺陷一样，测试人员也会发现用例设计中的缺陷。当测试计划被创建的时候，分配时间应该考虑测试分析或当程序员在应用程序中修复错误时，测试人员修改测试用例。如果这些地方没有及时更正，那么在下一个软件周期中，测试人员和测试设计人员将会浪费时间去搞清楚是用例错误还是软件缺陷。

测试用例丢失或因不良版本或者储存失败会影响整个测试用例可重复使用的目标。测试用例的配置管理应项目组织，而不是测试管理处理。如果该组织没有这样的过程成熟度，测试经理或测试用例设计人员应该做这样的事情。无论是项目主管或测试经理都应通过下面这些配置管理保护好这些测试用例资产：

l

命名和编号公约

l

格式，文件类型

l

版本

l

测试用例所需要的对象，例如数据库

l

只读存储器

l

受控访问

l

异地备份

测试管理需要有一个对所有的测试用例索引。如果某些用例不支持配置管理，那么创建自己的。这个数据库应可搜索项目，软件，测试的名称，数字键，和要求。

如果支持全文搜索那会更好。

利用测试案例

作为发展的资产测试用例除了测试也有他自己的生命周期。他们用完整的图片代替了该软件如何工作的详细英语说明。即使重点是破坏性的，他们还必须证明，这一切业务情景的工作符合要求。通常情况下测试用例是为那些实际的企业用户所提供的，所以他们使用现实世界的语言和条款。对那些努力学习或出售软件的人来说，测试用例具有巨大的价值：

u

商业用户

u

技术作家

u

技术支持人员

u

培训师

u

销售和市场营销人员

u

网络管理员

所有这些人都对软件成功有自己的功劳，他们也是潜在的测试人员。

在这种组织结构下，测试人员和这些群体之间善意和开放的沟通将大大加快软键的生产和发布时间。

摘要

良好的教学技巧和写作测试用例的标准制定过程本身就是一个资产。它是

永远不变的，但必须动态地教，应用，审核，测量和改进。本文简要提到了什么是过程和测试用例的质量标准，如何将它们应用到各种测试情况下，如何使用它们以提高可测试性和生产力，如何解决测试用例质量的共同的挑战，以及如何保护测试用例的资产。

案例研究

这是一个五个软件质量分析师如何了解到良好的测试用例衡量差异的故事。他们是一支经验丰富，自我管理小组，每一个成员都对测试用例有不同的想法。一个测试从所有方向散漫开来。参加测试的人是对软件没有信心的企业用户。他们希望测试一下，但经过一周或者更多的时间，他们往往了解到的是测试了什么，而不是真正的测试，大多数情况下，他们认输了。最后他们的经理告诉分析人员他们花费了大量的时间去验证实现了的需求，但是没有时间去检查其他。这种情况下，不到一半的用例被执行。其中，很多结果还是问号标记。其中一个测试人员人甚至写了愤怒的言论。在分析家开来这些测试人员只是发发牢骚，不是很聪明。

在这悲惨的周期，分析来了一个新的测试经理。她看着测试用例，她开始了培训和辅导计划。她示范良好的测试用例是怎样的，给他们一份清单，并在小组内使用它来编写下一个软件模块的用例。这是两个月的测试规划。她与每人进行谈话，帮助他们如何提高。每一个测试设计人员一开始设计测试用例，符合标准。第一周编写进展缓慢，但在两三个月期限届满，他们都会达到生产率提高的目标。到了下一个测试周期，测试用例都较短，每一个都有明确的目的以及清楚的精确的是否通过。不过，分析家担心，测试将要会变得麻烦。

在测试开始了期待另一个负面经验，但很快就改变了态度。他们发现他们能轻易完成，而不必打电话或亲自过来问设计者每个用例。他们的信心增长，有人说他们一直害怕交接这个软件，但现在他们可以看到它是比他们更好的使用。在消息传出的销售人员，谁曾渴望了解软件。他们的经理来了，问他们是否也能测试。测试经理并不需要更多的测试周期，但签署了下一个。技术作家询问他们是否能有过这些用例的复印件。

测试经理不断改善的一些指标。当她第一次来到，分析家花费

2

至

3

小时的故障排除与测试者的不良情况。他们原计划的

20

分钟的测试，而事实上，他们平均约

45

分钟。除了所用的时间与测试，一些分析师花费一个小时或每天两试图解决在本周期的用例而不是他们安排工作

写在今后模块的用例。

经过培训和标准制定，下一个测试周期的指标看上去好多了。都不是分析家们花了一个多小时，每天帮助测试。尽管有更多的测试，由于在较短的测试用例的标准，测试人员可以在

20

分钟内完成他们和测试往往是多提前一天。通过该项目，分析师和测试结束时，项目被提前

1

个月发布。

Appendix A

Test Case Checklist

Quality Attributes

l

Accurate -

tests what the description says it will test.

l

Economical - has only the steps needed for its purpose

l

Repeatable, self standing - same results no matter who tests it.

l

Appropriate - for both immediate and future testers

l

Traceable - to a requirement

l

Self cleaning -

returns the test environment to clean state

Structure and testability

l

Has a name and number

l

Has a stated purpose that includes what requirement is being tested

l

Has a description of the method of testing

l

Specifies setup information - environment, data, prerequisite tests, security access

l

Has actions and expected results

l

States if any proofs, such as reports or screen grabs, need to be saved

l

Leaves the testing environment clean

l

Uses active case language

l

Does not exceed 15 steps

l

Matrix does not take longer than 20 minutes to test

l

Automated script is commented with purpose, inputs, expected results

l

Setup offers alternative to prerequisite tests, if possible

l

Is in correct business scenario order with other tests

Configuration management

l

Employs naming and numbering conventions

l

Saved in specified formats, file types

l

Is versioned to match software under test

l

Includes test objects needed by the case, such as databases

l

Stored as read

l

Stored with controlled access

l

Stored where network backup operates

l

Archived off-site