测试的主要评测方法包括覆盖和质量。

　　测试覆盖是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。

　　质量是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上

　　一、覆盖评测

　　覆盖指标提供了“测试的完全程度如何？”这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。

　　系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的，指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。

　　如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了 75% 的性能测试需求。

　　如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。

　　两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到

　　a）基于需求的测试覆盖

　　基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。

　　测试覆盖通过以下公式计算：

　　测试覆盖 = T(p,i,x,s) / RfT

　　其中：

　　T 是用测试过程或测试用例表示的测试 (Test) 数（已计划的、已实施的或成功的）。

　　RfT 是测试需求 (Requirement for Test) 的总数。

　　在制定测试计划活动中，将计算测试覆盖以决定已计划的测试覆盖，其计算方法如下：

　　测试覆盖（已计划的） = Tp / RfT

　　其中：

　　Tp 是用测试过程或测试用例表示的已计划测试 (Test) 数。

　　RfT 是测试需求 (Requirement for Test) 的总数。

　　在实施测试活动中，由于测试过程正在实施中（按照测试脚本），在计算测试覆盖时使用以下公式：

　　测试覆盖（已执行的） = Ti / RfT

　　其中：

　　Tx 是用测试过程或测试用例表示的已执行的测试 (Test) 数。

　　RfT 是测试需求 (Requirement for Test) 的总数。

　　在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。

　　这些覆盖评测通过以下公式计算：

　　测试覆盖（已执行的） = Tx / RfT

　　其中：

　　Tx 是用测试过程或测试用例表示的已执行的测试 (Test) 数。

　　RfT 是测试需求 (Requirement for Test) 的总数。

　　成功的测试覆盖（已执行的） = Ts / RfT

　　其中：

　　Ts 是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试 (Test) 数。

　　RfT 是测试需求 (Requirement for Test) 的总数。

　　如将以上比率转换为百分数，则以下基于需求的测试覆盖的陈述成立：

　　x% 的测试用例（上述公式中的 T(p,i,x,s)）已经覆盖，成功率为 y%

　　这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础

　　b）基于代码的测试覆盖

　　基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。

　　基于代码的测试覆盖通过以下公式计算：

　　测试覆盖 = Ie / TIic

　　其中：

　　Ie 是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。

　　TIic (Total number of Items in the code) 是代码中的项目总数。

　　如将该比率转换为百分数，则以下基于代码的测试覆盖的陈述成立：

　　x% 的测试用例（上述公式中的 I）已经覆盖，成功率为 y%

　　这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础

　　二、质量评测

　　测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。

　　缺陷评估可能建立在各种方法上，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。

　　严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，这是一个活跃的研究领域。由于该类型的评估缺乏工具支持，所以应该慎重平衡成本与其增加价值。

　　缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。

　　对于缺陷分析，常用的主要缺陷参数有四个：

　　状态：缺陷的当前状态（打开的、正在修复或关闭的等）。

　　优先级：必须处理和解决缺陷的相对重要性。

　　严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。

　　起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。

　　可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。

　　例如，预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值，在缺陷发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数，以允许检测“较差的模块”、“热点”或需要再三修复的软件部分，从而指示一些更基本的设计缺陷。

　　这种分析中包含的缺陷必须是已确认的缺陷。不是所有已报告的缺陷都报告实际的缺陷，这是因为某些缺陷可能是扩展请求，超出了项目的规模，或描述的是已报告的缺陷。然而，需要查看并分析一下，为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷，这样做是有价值的

　　三、缺陷报告

　　Rational Unified Process 以三类形式的报告提供缺陷评估：

　　缺陷分布（密度）报告允许将缺陷计数作为一个或多个缺陷参数的函数来显示。

　　缺陷龄期报告是一种特殊类型的缺陷分布报告。 缺陷龄期报告显示缺陷处于特定状态下的时间长短，如“提出的”。在龄期类别中，缺陷还可以按其他属性分类，如“拥有者”。

　　缺陷趋势报告按状态（新的、已打开的或关闭的）将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的。

　　测试结果和进度报告显示对测试的应用程序进行若干次迭代和测试生命周期后的测试过程执行结果。

　　许多此类报告对于评估软件质量具有很高的价值。一般测试标准中包括有关特定类别（如严重性级别）中打开的缺陷数的陈述。通过缺陷分布评估可以轻松地核对该标准。对测试需求进行过滤或分类，该评估可以侧重于不同的需求集。

　　要有效生成此类报告，一般需要工具支持

　　a）缺陷密度报告

　　缺陷状态与优先级

　　应该给定所有缺陷的优先级，通常可行的做法是设定四种优先级中的一种：

　　立即解决

　　高优先级

　　正常排队

　　低优先级

　　一个成功测试的标准可以表示为缺陷在上述优先级上所应体现的分布方式。例如，对于一个成功的测试标准来说，可能不存在优先级为 1 的打开的缺陷，而且优先级为 2 的打开的缺陷要少于 5 个

　　缺陷状态与严重性

　　缺陷严重性报告显示每种严重性级别的缺陷个数，例如致命错误、未执行主要功能、次要错误等严重性级别。

　　缺陷状态与在实施模型中的位置

　　缺陷起源报告显示缺陷在实施模型元素上的分布情况

　　b)缺陷龄期报告

　　缺陷龄期分析提供了有关测试有效性和缺陷排除活动的良好反馈。例如，如果大部分龄期较长的、未解决的缺陷处于有待确认的状态，则可能表明没有充足的资源应用于再次测试工作

　　c)缺陷趋势报告

　　趋势报告确定缺陷率并提供了一个出色的测试状态视图。在测试生命周期中，缺陷趋势遵循着一种比较好预测的模式。在生命周期的初期，缺陷率增长很快。在达到顶峰后，就随时间以较慢的速率下降

　　四、性能评测

　　评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在评估测试活动中进行评估，但是也可以在执行测试活动中使用性能评测评估测试进度和状态。

　　主要的性能评测包括：

　　动态监测 - 在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。

　　响应时间/吞吐量 - 测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。

　　百分位报告 - 数据已收集值的百分位评测/计算。

　　比较报告 - 代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。

　　追踪报告 -主角（测试脚本）和测试对象之间的消息/会话详细信息

　　a）动态监测

　　动态监测通常以柱状图或曲线图的形式提供实时显示/报告。该报告用于在测试执行过程中，通过显示当前的情况、状态以及测试脚本正在执行的进度来监测或评估性能测试执行情况

　　b）响应时间/吞吐量报告

　　响应时间/吞吐量报告评测并计算与时间和/或吞吐量（处理的事务数）相关的性能行为。这些报告通常用曲线图显示，响应时间（或事务数）在“y”轴上，而事件数在“x”轴上

　　除了显示实际的性能行为外，它在计算并显示统计信息方面也很实用，如显示数据值的平均偏差和标准偏差

　　c）百分位报告

　　百分位报告通过显示已收集数据类型的全体百分位值，提供了另一种性能统计计算方法

　　d）比较报告

　　比较不同性能测试的结果，以评估测试执行过程之间所作的变更对性能行为的影响，这种做法是非常必要的。比较报告应该用于显示两个数据集（分别代表不同的测试执行）之间的差异或多个测试执行之间的趋势

　　这是一个故事，即五个软件质量分析师如何学会好的测试用例达到一个可测量的区别。他们经验丰富，自成管理小组，对于测试用例看起来应该像什么，每一个人都有不同的想法。一个用例罗列成从几十个杂乱、冗长的指导，到一个根本没有指导的一个矩阵。测试者是对软件几乎没有信心的商业用户。他们渴望测试，但经过一个星期后，花费的更多的时间是在试图找出做什么，而不是在实际测试中，他们非常无奈。他们的经理最后告诉分析师，他们已投入了他们议定的大量的时间，再没有更多的时间给他们了。在该点上不到一半测试才被执行。就这些，许多结果还只是个问号。一个测试者甚至在测试中写下愤怒的言辞。分析师表现出的测试者只是抱怨者，而不是很聪明的。

　　在这痛苦的周期中，分析师遇到新的测试经理。她看着测试用例，并开始了一个培训和辅导方案。她展示了好的测试用例的模样，给了他们一份核查表，并让小组在下一个软件模块中用它来写用例。该用例将在两个月后安排测试。她一个接一个接触了他们每个人并在如何改善方面给了他们具体的帮助。每一个编写者开始产出达到标准的用例。第一个星期的编写进展很慢，但在两个月期间的最后，他们都达到生产率的目标。在下一个测试周期，用例就较短，每一个都有明确的目的和准确的通过或失败的标准。尽管如此，分析者仍担心测试将又一次是棘手的。

　　测试者开始预期另一个负面的经历，但很快改变了他们的态度。他们发现，他们可以很容易地完成每一个用例，无需拨打电话或来到编写者的小隔间。他们的信心增长，而且有些人说，他们已害怕这个软件的改动，但现在他们可以看到它明显好于他们所使用的。这个话传到了销售人员，使他已经迫切地希望了解该软件。他们的经理来了，问是否他们也可以测试。测试经理在该周期并不需要更多的测试者，但和他们签约了下一个周期。技术编写者问是否他们也可以拥有用例的复件。

　　测试经理保持着一些指标的提高。当她最初到来时，分析师一天花费2到3个小时和测试者排查不好的用例。他们安排的测试时间是每个测试用20分钟，而事实上他们平均用时约45分钟。除了与测试者花费的时间外，在当前的周期中，一些分析师还花费一个小时或两个天时尝试修改用例，而不是进行他们安排的工作 – 为下一个模块写用例。

　　在培训和标准确定后，下一个测试周期的指标看上去更好。没有分析师再一天花费超过一小时来帮助测试者。即使有更多的测试，因为简短的测试用例的标准，测试者可以在20分钟内完成测试，而测试往往提前一天完成。在项目结束时，分析师和测试者已确信会加快发表一个月。

附录A

 测试用例核查表

 质量属性

 ● 精确的 - 只测试描述中所说的将测试的内容。

 ● 经济的 - 只有对于它的目标所需要的步骤

 ● 可重用的、自立的 - 不管是谁测试它都是相同的结果。

 ● 适合的 – 不仅对当前而且对今后的测试者

 ● 可追溯的 – 对应到一个需求

 ● 可自我清理的 - 返回测试环境到未使用状态

 结构和可测试性

 ● 有一个名称和编号

 ● 有一个明确的目标，其中包括什么需求将被测试

 ● 有一个测试方法的描述

 ● 指定设置信息 - 环境、数据、前提测试、安全访问

 ● 进行的活动和预期结果

 ● 陈述需要被保存的任何证据，如报告或抓屏

 ● 留下干净的测试环境

 ● 使用生动的用例语言

 ● 不超过15个步骤

 ● 矩阵不需要超过20分钟的时间来测试

 ● 自动脚本用目标、输入、预期结果来注释

 ● 如果可能的话，设置提供前提测试的替代品

 ● 与其他测试处于正确的商业场景顺序中

 配置管理

 ● 使用命名和编号协定

 ● 以指定的格式、文件类型保存

 ● 对应版本和受测软件相匹配

 ● 包括用例需要的测试对象，如资料库

 ● 存储为可读取形式

 ● 以受控访问的形式存储

 ● 存储在网络备份操作处

 ● 现场外存档

附录B

附录C

　矩阵模

　　对一种类型的测试用例的偏好超过另一个，多起因于机构的文化和观念，而不是什么最适合于软件和测试计划。“我们一直这样做”已和一些难改的谬论相结合：

　　谬论之一。分步测试用例要花太长的时间来编写。我们负担不起。

　　事实：他们可能会或不会需要较长的时间来编写，粒度小使他们健壮和易于维护。他们是唯一充分测试一些功能的方法。

　　谬论之二。矩阵始终是最好的选择。选用它吧。

　　事实：一个长期存在的问题是如何把一个矩阵和适当的组织安排信息放在一起。这一组织安排信息往往被忽略，或更糟糕的是，如果输入的不同的组织安排或分类不能强加成一个带有类似组的矩阵，他们根本就不能被测试。

　　谬论之三。高技术是最好的。如果您可以自动化测试用例，就去做它。

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

　　谬论之四。我们没有时间编写手工测试用例。让我们自动化测试用例吧。

　　事实：自动化测试用例的创建需要比其他两种类型更长的时间。

　　如果一个有支配权力的人不懂装懂的说出这些谬论，一个不成熟的组织（一个更多地依靠杰出人士而不是过程的组织）是最容易认为这些谬论是正确的。他们的质量之路将是一个漫长的道路。他们会继续误解测试用例，直到他们经受打乱的时间表或经费损失为止，显然他们经受的这些起因于不良的测试。

　　为工作使用最佳的测试用例类型的另一个约束是在文字和数字表达之间的接近状况。如果你擅长于一个或另一个，你可能更喜欢你可以直观地去做的测试用例类型。分步用例倾向于更多的文字，而矩阵倾向于更多的数字。良好的培训应建立起对于使用所有类型的用例的了解和信心，对于每一处它都是最有成效的。然而，个人偏好是一个不可忽视的因素。如果你是一个经理，你需要通过教育和范例克服困难。

　　往往最有成效的途径是使用所有三种类型的用例。前两个用于单元、集成和系统测试；而自动化脚本用于回归测试。

提升测试用例

　　提高测试用例的可测试性

　　准确的说，可测试性的定义是指易于测试。易于测量执行测试需要多久，在测试过程中测试者是否需要获得说明。准确意味着，如果测试者遵循指导，那么通过或失败的结果将会是正确的。

　　用语言提高可测试性

　　测试步骤应该编写在生动的用例中。告诉测试者做什么。例如：

　　● 做这个。做那个。

　　● 浏览购物车页面。

　　● 对比车中物品和屏幕捕获的物品。

　　● 点击<OK>。

　　应始终明确的是，是测试者做一些事，还是系统做它。如果一个测试者读到， “按钮被按下，”这意味着他或她应该按下按钮呢，还是它意味着已经按下后验证系统显示它？搞乱测试者最好的一种办法是混淆活动和结果。比如，活动总是在左侧，结果在右侧。测试者做什么总是一个活动。系统显示什么或者做什么始终是一个结果。

　　如果我们知道一个对象的内外，养成一个简单的习惯，就是以不同的方式提及相同的事情。测试语言要一丝不苟地命名显屏、字段、服务器、Web网页、或其他测试对象。在一个开发团队，我们习惯于在某些对象甚至是原型以前，一般就提到它，如“电子邮件答复屏幕，”而它的标签实际将指：“订单确认。”或者我们可能用数字指一个显屏，无论测试者在哪儿看它，数字都不会出现。测试必须有精确的参考来指导测试者。

　　如果您为了测试者注意以后将核实的输入，建立了结构化的字段，测试可能加速。例如，如果你正在测试一个审核日志，你事先不能知道测试者将完成一个审核活动的确切分钟。如果你告诉他们注意它，它可能被胡乱地写在测试中，纸片上，或加进一个临时文件。他们可能不会找麻烦来标明什么是什么，并可能不得不到处搜寻来找到它。最好是在测试中留下一个标记的空格，在这里，他们可以写下输入，示例：

　　删除条目日期：________时间： _______

　　条目编号：________

　　测试者登录ID ：________

通过控制长度来提高可测试性

　　一个测试用例应该多长？一个好的分步用例长度是10-15步，除非测试者不节省他们的工作。保持测试这么简短有几个好处：

　　● 简短的用例用更少的时间来测试每一个步骤

　　● 测试者不太可能受迷惑，犯错误，或需要帮助。

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

　　● 结果更容易追踪

　　不要试图在10-15个步骤的标准上作弊，把很多活动填满一个步骤。

　　一个步骤应该是一个明确的输入或测试任务。您总可以在相同的步骤中添加一个简单的完成标志，如单击<OK>或按<Enter>。同样，一个步骤可以包括一套逻辑相关的输入。您不必对每个步骤都有结果，如果系统不响应某一步的话就不需用。

　　保持单个测试简短的目标并不是不符合用最少数量的测试来测试应用系统的传统的目标。传统目标标准的目的是要精巧，当合理的测试业务场景或用例（use case）和需求一样多时，会工作到10-15步。该标准的目的还在于避免重复，即在一些测试中测试相同的需求。你可能不想通过使每一个测试都很长，来创建最低数量的测试，因为对于测试或维护来说，这将是一个恶梦。看老的“最低数量的测试，”的更好的方法是，衡量是否是一个“最低数量的步骤。”那么通过将50个步骤放入一个中以创造较少的测试是感觉不到好处的。

　　对于一个矩阵，一个好的长度是可以测试约20分钟。

　　自动化脚本的长度不是一个测试执行问题，因为测试通常是几秒钟。相反，问题是内容、维护和缺陷跟踪的管理。每个脚本一个业务场景或用例是足够的。它可以根据需要循环多次来加载数据或执行变量组合。

累积用例的优点和缺点

　　累积用例是那些依赖于以前的用例来运行的用例 — 在你测试＃6以前，你得先运行测试 1-5。您的目标是让测试尽可能的独立。这给了安排测试最大的灵活性，并减少了维护时间。可惜的是，它落后的一面是，该标准可能会不符合其他标准，如保持每个测试用例简短和不重复覆盖。你如何达到这一点呢？

　　● 问问自己，是否你真正需要从另一个测试输入数据？如果是这样，测试必须是具有累积性的。

　　● 只要有可能，提供一个以前的测试的替代品。这意味着它们可以使用在以前的测试中建立的数据，同时它们也可以使用其他数据。例如：“你需要两个处于90天拖欠状况的帐户，如为逾期帐户的测试用例所创建的账户。”

　　● 提及其他测试时要象共有的一样尽可能在精确性上保持一致。不要只用编号提及一些测试。测试重编号后。如果您使用一个编号，还包括标题或说明。这可避免维护时的恶梦。

　　改善可用性或可测试性的另一个问题是测试用例的顺序，它们应该根据业务使用排序。什么是最终用户通常首先做得，不是他们首先不得不做的，象在累积用例中一样？如果测试者是一个商业用户，他们将有一个他们希望完成软件任务的心理模式。通过复制其模式来适应他们，增加了他们的测试生产率。

　　用模板提高生产率

　　测试用例模板是一个带有标签字段的表单。附加的附录B是一个分步测试用例的模板。这是开始提高测试用例的一个重要的方式。它加快开始编写过程，并提供一个好用例的各个内容。这里是使用模板的一些其他的好处：

　　● 防止空白页的恐慌

　　● 对混乱现象给于帮助

　　● 用标准创建

　　● 打印好看的测试

　　● 协助测试者找到信息

　　● 可以包括与测试过程相关的其他字段

　　为了改进测试用例什么是值得做的？什么风险会促使你投资于更好地测试用例？在他们覆盖软件需求时，还不是足够的好吗？对这些问题的答案是，粗劣的测试用例的确会将你暴露于相当大的风险之下。他们在理论上可能覆盖了需要，但很难用来执行测试，并会获得含糊不清的结果。好的测试会获得更可靠的结果，而且会在以下三个范畴降低成本：

　　1.生产率 - 更短的时间撰写和维护用例

　　2.可测试性 - 更短的时间来执行他们

　　3.计划的可靠性 – 估算时有更好的可靠性

　　本文介绍如何避免因为粗劣的测试案例必然带来的损失。将让我们看到罩盖下各种不同的测试用例，并展示在控制风险的质量中，在何处以及如何建立测试用例。对如何提高生产率、可用性、计划的可靠性和资产管理，将给出切实可行的建议。一旦你了解测试用例是什么和为什么的问题，您可以使用一个标准的核查表，像附录A一样的一个附件，来确定风险领域并改善您当前的和未来的测试用例。

　　在准备测试软件的过程中，最繁杂的工作是编写测试用例。建立健壮的测试用例的动机是由可能性来激励的，测试用例将被重用于维护版本。超过所有软件开发工作的半数的工作是维护项目。你怎么才能编写良好的测试用例，它将提供经济的测试，首次测试后，在回归测试时将再次使用？让我们通过掀起测试用例的罩盖，看看里面是什么，来开始我们的答案吧。

　　● 看测试用例内部

　　● 测试用例的内容（element）

　　● 针对我们的目标，一个测试用例是一套基于系统需求的，带有预期结果的活动。用例包括这些内容：

　　● 测试的目标或将被测试的需求的描述

　　● 它将被如何测试的方法

　　● 测试的设置：接受测试的应用程序的版本、硬件、软件、操作系统、数据文件、安全访问、时间、逻辑的或物理的起止日期、先决条件（如其他测试），以及对于被测需求（一个或多个）的任何其他有关的设置信息

　　● 活动和预期的结果，或输入和输出

　　● 任何校样或附件（可选）

　　这些同样的内容必需被用在每一级测试——单元、集成、系统、或验收测试的测试用例中。对于功能、性能和可用性测试，它们同样有效。“预期结果”的标准并不适用于一个探索性质的诊断测试或其他测试。实际上诊断测试在其用例中需要其他内容。然而，如果测试是测量性能，那性能应属于一个范围，这个范围就是一个预期结果。

　　测试用例的另一种描述是，说明、目标和组织安排是用例或规格说明。完成它的步骤被称为脚本。而另一种观点认为目标或说明是一个场景（scenario）或功能用例（use case）。这些观点都符合本文提议的质量评估和改进。

测试用例的质量

　　有一种误解，以为编写质量是主观的，就像看一幅画，哪里美丽只在观看者的眼睛里。

　　事实上，编写质量是客观的和可测量的。就像附录A一样，建立一个测试用例的构成内容（目标、方法、组织安排、输入和输出等）的客观核查表，这是很简单的。然后走查每个用例。内容是有或者没有？除了其构成，用例也必须符合这些质量标准：

　　精确的。它们只测试它们描述中所说的它们将测试的内容。

　　经济的。它们只有对于它们的目标所需要的步骤或信息。它们不给出软件导航。

　　可重用的，自立的。一个测试用例是一个对照试验。每一次不管是谁测试它，它都应当得到相同的结果。如果只有作者可以测试它并获得结果，或如果不同的测试者测试，得到不同的结果，那该测试用例就需要在组织或活动上做更多的工作。

　　适合的。一个测试用例必须适合测试者和环境。如果它在理论上是合理的，但需要所有的测试者都没有的技能，那它将会被束之高阁。即使你知道谁在测试第一次，你也需要考虑维护和回归时的情况。

　　可追溯的。你必须知道此用例测试的是什么需求。它可能满足所有的其他标准，但如果其结果是，通过或失败都无关紧要，那为什么还要费心做它呢？

　　可自我清理的。运行后自动收起。它返回测试环境到预测试状态。例如，它不会留下测试系统设置在错误的日期。自动脚本可调用其他脚本来做到这一点。不要把这一标准与破坏性混淆。测试应该是破坏性的，包括试图通过可控制和可重复的方式打破一个模拟生产环境。

　　这些标准也是客观的和可测量的。它们也可以被添加到您的核查表。

　　如果谁知道需求和受测应用程序，那他应该填写该核查表作为一个同行审查的一部分。

　　遵循多少标准只有测试后才能知道，但它们都是可测量的。对于新的测试编写者，这是一种特别有用练习，看看他们在哪块始终没有达到某一要素，或不符合某一标准。

测试用例的格式

　　一个测试用例看起来像什么呢？它们似乎分为三个主要群组：分步、矩阵和自动化脚本。当然自动化脚本将作为一个在线文件来运行，毫无疑问，其他两个必须是基于纸张的。他们也可以是在线的。让我们来看看每一个的格式：

　　分步。图1显示了这个基本的格式模样。这个格式的一个完整的视图，在一个带有其他测试内容的模板中，作为附录B来显示。

图1 - 分步测试用例详细信息

　　矩阵或表格。图2显示了这个格式的基本模样。这个格式的一个完整的视图，在一个带有其他测试内容的模板中，作为附录C来显示。

图2 - 矩阵测试用例详细信息

　　自动化脚本。图3显示了这种格式的模样。

图3 - 自动化脚本测试用例详细信息

   使用测试类型

　　每种类型用例的最佳用途

　　● 分步用例多用于：

　　● 分步

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

　　● 从一屏到另一屏展开的业务场景

　　● 许多处理规则

　　● GUI 界面

　　● 在矩阵中难以表示的输入与输出

　　分步用例不一定需要如图1所示的有一个按键水平的详述。活动步骤可以在一个更高的水平，如：打开“my account”页面，寻找一个日期范围内的事务，注意该范围:______   ，打印报告，转送报告，等等。
矩阵。矩阵用例多用于：

　　● 填写表格有许多变化，同一字段，不同的值、输入文件

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

　　● 基于显屏的字符

　　● 用矩阵表示出来最好的输入与输出

　　几乎任何测试都可以表示成一个矩阵，但要裁定的问题是，对于测试，是否矩阵是最好的方式。最重要的是，矩阵要辅之以测试的一个描述、组织安排，以及如何记录结果。如何测试矩阵，对于编写者可能是显而易见的，但没有更多的指导时，测试者可能会做错。

　　矩阵的一个变化是输入列表。它可以被插入一个分步测试或作为一个带有关于测试的解释性内容的矩阵。

　　自动化脚本。使用自动化测试软件的决定，更多的与进行测试的规划和组织相关，而与将要测试什么关系不大。工具改变时，一些技术问题必然会遇到，但大多数应用程序都可以找到适合的技术。项目管理必须明白，编写自动化用例比手工测试需要花费较长的时间，因为手工测试必然首先是写成静态的。当界面稳定时，测试可以被录制。真正的自动化测试的回放是在软件生命周期的维护阶段。此时，脚本可以被反复执行，甚至无人值守，极大节省了测试时间。

　　管理部门必须配备人员，用工具语言，如C++或Visual Basic 等来编程。简单的脚本可以用大多数测试分析工具录制，但功能更强大的脚本，往往使用自定义函数和对象，必须由程序员编写。一个组可以一起安排，几个人做普通的录制/回放脚本，一个人编程。

　　和其他类型的测试用例相比，该用例适用于录制和回放，或数据驱动脚本。除了录制/回放脚本，自动化工具也用于性能和负载测试。他们可能会使用手工分步用例或矩阵，详细说明自动化工具将如何被用来创建虚拟用户，给出事务脚本，监控性能，和其他活动。