什么是测试用例？

-

判例案件

-

中科永琏先进技术培训中心

测试用例是为特定目标而编写的一组测试输入、执行条件和预期结果，用以测试程序路径或验证其是否满足特定要求。

目前测试用例还没有一个经典的定义。一般来说，它是指对一个具体软件产品测试任务的描述，体现了测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。，并形成一个文档。

不同类型的软件有不同的测试用例。与系统、工具、控制、游戏软件不同，管理软件的用户需求更加不一致，变化更多更快。作者主要从事企业管理软件的测试工作。因此，我们的方法是从测试用例中分离测试数据和测试脚本。测试用例往往是为软件产品的功能、业务规则和业务处理而设计的测试方案。对软件的每个具体功能或操作路径的测试构成一个测试用例。

随着中国软件产业的发展，软件测试也在发展。从最初的软件程序员兼职测试，到软件公司成立独立的专职测试部门。测试工作也从简单测试发展到正式测试，包括:准备测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等等。测试方式从单纯的人工测试发展到人工和自动测试并重，有向第三方专业测试公司发展的趋势。

要让最终用户对软件满意，最有力的措施就是明确最终用户的期望，从而验证这些期望并确认其有效性。测试用例反映了需要验证的需求。然而，验证这些需求可能会以不同的方式由不同的测试人员来实现。例如，执行软件以验证其功能和性能可以由使用自动测试技术的测试器来实现；计算机系统的关机步骤可以通过人工测试和观察来完成；然而，市场份额和销售数据(以及产品需求)只能通过评估产品和竞争销售数据来实现。

由于可能无法(或没有必要)验证所有的需求，因此能否选择最合适或最关键的需求进行测试，关系到项目的成败。选择要验证的需求将是权衡成本、风险和验证需求的必要性的结果。

确定测试用例很重要，原因如下。

测试用例是设计和制定测试过程的基础。

测试的“深度”与测试用例的数量成正比。由于每个测试用例反映了产品中不同的场景、条件或事件流，随着测试用例数量的增加，您将对产品质量和测试过程更有信心。

判断测试是否完整的主要评估方法之一是基于需求的覆盖，这是基于确定、实现和/或执行的测试用例的数量。类似这样的陈述:“95%的关键测试用例已经被执行和验证”远比“我们已经完成了95%的测试”更有意义。

测试工作量与测试用例的数量成正比。根据全面和详细的测试用例，可以更准确地估计测试周期中每个连续阶段的时间进度。

测试设计和开发的类型以及所需的资源主要由测试用例控制。

测试用例通常根据其关联关系的测试类型或测试需求进行分类，并会随着类型和需求的变化而相应变化。最好的解决方案是为每个测试需求编译至少两个测试用例:

一个测试用例用来证明需求已经满足，通常称为正测试用例；

另一个测试用例反映了不可接受的、异常的或意外的条件或数据，用于证明需求只能在要求的条件下得到满足。这个测试用例称为否定测试用例。

首先，测试用例是软件测试的核心。

软件测试的重要性毋庸置疑。然而，如何以最少的人力物力投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良质量，是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要一个优秀的测试方案和方法。

影响软件测试的因素有很多，比如软件本身的复杂程度，开发人员(包括分析、设计、编程和测试的人员)的素质，测试方法和技术的应用等等。因为有些因素是客观存在的，无法避免的。有些因素是波动的，不稳定的，比如开发团队是流动的，有经验的人走了，不断有新人加入；具体一个人的工作也会受到情绪等等的影响。如何保证软件测试质量的稳定性？有了测试用例，无论谁来测试，都可以通过引用测试用例来保证测试的质量。人为因素的影响可以降到最低。即使最初的测试用例没有想好，也会随着测试的进展和软件版本的更新而改进。

因此，测试用例的设计和编写是软件测试活动中最重要的。测试用例是测试工作的指南，是软件测试必须遵循的准则。这也是软件测试质量稳定的根本保证。

第二，准备测试用例

本文主要介绍编写测试用例的一些具体方法。

1，测试用例文档

写测试用例文档要有文档模板，必须符合内部规范要求。测试用例文档将受到测试用例管理软件的约束。

软件产品或软件开发项目的测试用例一般以产品的软件模块或子系统为单位形成测试用例文档，但不是绝对的。

测试用例文档由引言和测试用例组成。引言部分编写了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列出了每个测试用例。每个具体的测试用例将包括以下详细信息:用例编号、用例名称、测试级别、进入标准、验证步骤、预期结果(包括判断标准)、退出标准、注释等。以上内容涵盖了测试用例的基本要素:测试指标、测试环境、测试输入、测试操作、预期结果和评估标准。

2.测试用例的设置

我们早期的测试用例是按功能设置的。后来，引入了路径分析方法，根据路径设置用例。目前已经演变成按照功能和路径的混合模式来设置用例。

按功能测试是最简单的，每个功能都是用用例规格说明来测试的。

对于操作复杂的程序模块，其功能的实现是交互的、紧密相关的、环环相扣的，可以演化成大量的变化。没有严谨的逻辑分析，疏漏在所难免。路径分析是一个很好的方法，它最大的优点是可以避免漏测。

但是路径分析方法也有局限性。在一个非常简单的字典维护模块中有十多条路径。一个复杂的模块有几十到几百条路径是不足为奇的。作者认为这是一个适合于路径分析的尺度。如果一个子系统有十个或更多的模块，这些模块是相互关联的。如果再用路径分析法，路径数呈几何级数增长，达到5位数以上，就不能用了。那么子系统模块之间的测试路径或者测试用例仍然需要用传统的方法来解决。这就是根据功能和路径的混合模式来设置用例的由来。

3.设计测试案例

测试用例可以分为基本事件、备选事件和异常事件。在设计基本事件的用例时，要参考用例规约(或设计规约)，通过路径分析，根据相关的功能和操作设计测试用例。对于孤立的功能，直接根据功能设计测试用例。基本事件的测试用例应包含所有需要的功能，覆盖率为100%。

设计替代事件和异常事件的用例要复杂和困难得多。比如字典的编码是唯一的，不能重复。测试需要验证:在字典添加程序中已经存在对字典代码的约束。如果有代码重复，必须报告错误，并且错误文本是正确的。往往在设计和编码阶段形成的文档，对备选事件和异常事件的分析和描述不够详细。测试本身要求验证所有非基本事件，尽可能发现软件缺陷。

软件测试中常用的基本方法可以用来设计测试用例，如等价类划分法、边界值分析法、错误推断法、因果图法、逻辑覆盖法等。根据软件的不同属性，采用不同的方法。如何灵活运用各种基本方法设计出完整的测试用例，并最终暴露出隐藏的缺陷，有赖于测试设计人员的丰富经验和精心设计。

第三，测试用例在软件测试中的作用

1，指导测试的实施

测试用例主要适用于集成测试、系统测试和回归测试。测试时以测试用例为测试标准，测试人员必须严格按照测试用例及测试步骤逐一实施测试。并在测试用例管理软件中记录测试情况，从而自动生成测试结果文档。

根据测试用例的测试层次，集成测试要测试那些用例，系统测试和回归测试要测试那些用例，这些在设计测试用例的时候已经明确，测试人员在实施测试的时候不能随意更改。

2、规划测试数据的准备

在我们的实践中，测试数据从测试用例中分离出来。根据测试用例准备一套或几套原始测试数据和标准测试结果。特别是对于测试报告等数据集的正确性，按照测试用例规划准备测试数据是非常必要的。

除了正常数据，还必须根据测试用例设计大量的边缘数据和错误数据。

3、编写测试脚本《设计规范》

为了提高测试的效率，软件测试大力发展了自动化测试。自动化测试的中心任务是编写测试脚本。如果软件工程中的软件编程一定要有设计规范，那么测试脚本的设计规范就是测试用例。

4.评估测试结果的测量基准

完成测试实现后，需要对测试结果进行评估，并准备测试报告。需要一些量化的结果来判断软件测试是否完成，衡量测试质量。举例:什么是测试覆盖率，通过率，重要测试的通过率等等。以前的统计基准是一个软件模块或者功能点，太粗糙了。使用测试用例作为度量基准更加准确有效。

5、缺陷分析的标准

通过收集缺陷并将测试用例与缺陷数据库进行比较，对其进行分析以确认缺陷是否被遗漏或重现。遗漏的测试反映了测试用例的不完善，相应的测试用例应该立即得到补充，最终逐步提高软件质量。已经有相应的测试用例，反映出测试或者变更处理的实现存在问题。

第四，相关问题

1，测试用例评审

测试用例是软件测试的准则，但它一旦被编写出来并不成为准则。在设计和编写测试用例的过程中，应该组织同行评审。编制完成后应组织专家评审，通过后方可使用。评审委员会可能由项目负责人、测试、编程、分析和设计人员组成，也可能邀请客户代表参加。

2.测试用例的修改和更新

测试用例在被记录后需要改进。主要来自三个原因:一是在测试过程中发现测试用例的设计考虑不周，需要改进；二是软件交付使用后反馈的软件缺陷，缺陷是测试用例中的漏洞造成的；第三，软件本身的新功能和软件版本的更新，测试用例也必须进行修改和更新。

一般来说，小的修改和改进可以在原测试用例文档中进行修改，但是文档应该有变更记录。当软件版本更新时，测试用例通常也应该更新。

3.测试用例管理软件

使用测试用例还需要测试用例管理软件。它主要有三个功能:一是可以自动将测试用例文档的关键内容如编号、名称等导入管理数据库，形成与测试用例文档完全对应的记录；二是可以用来在测试实施时及时输入测试情况；第三，自动生成测试结果文档，包括每个测试度量值、测试覆盖表和通过或未通过测试的测试用例列表。

有了管理软件，测试人员可以很容易地编写日常测试日志或生成软件测试报告。

动词 （verb的缩写）测试用例的设计

(A)白盒技术

白盒测试是一种结构化测试，所以测试的对象基本上是源程序，测试用例是基于程序的内部逻辑来设计的。

1，逻辑覆盖

程序内部的逻辑覆盖程度，当程序中存在循环时，不可能覆盖每一条路径。有必要设计一个测试用例，以高覆盖率覆盖最具代表性的路径。根据图7-1所示的程序，分别讨论了几种常见的叠加技术。

(1)语句覆盖。

为了提高发现错误的可能性，程序中的每一条语句都应该在测试过程中执行。语句覆盖是指设计足够多的测试用例，使得被测试程序中的每条语句至少可以执行一次。

如图7-1所示，是一个被测程序的流程图:

(2)确定覆盖范围。

决策覆盖是指设计足够多的测试用例，使被测程序中的每个决策表达式至少能得到一次“真”值和一次“假”值，使程序的每个分支至少能通过一次。因此，决策覆盖也称为分支覆盖。

(3)有条件覆盖。

条件覆盖是指设计足够多的测试用例，使得判断表达式中每个条件的所有可能值至少出现一次。

(4)判断/条件测试。

覆盖标准是指设计足够多的测试用例，使得决策表达式的每个条件的所有可能值至少出现一次，每个决策表达式的所有可能结果也至少出现一次。

(5)条件组合覆盖。

条件组合覆盖是一种强覆盖标准，是指设计足够多的测试用例，使每个决策表达式中条件的各种可能值的组合至少出现一次。

(6)路径覆盖。

路径覆盖是指设计足够多的测试用例来覆盖被测程序中所有可能的路径。

在实际的逻辑覆盖测试中，一般是基于条件组合覆盖来设计测试用例，然后补充一些测试用例，达到路径覆盖测试标准。

2.循环覆盖

3.基本路径测试

(B)黑盒技术

1.等价类划分

(1)划分等价类。

①如果输入条件指定了值的范围或值的数量。则可以确定一个合理的等价类(输入值或数字在该范围内)和两个不合理的等价类(输入值或数字小于该范围的最小值或大于该范围的最大值)。

(2)如果指定了输入数据的一组值，程序对不同的输入值区别对待，那么每个允许的输入值都是合理的等价类，也有不合理的等价类(任何不允许的输入值)。

(3)如果规定了输入数据必须遵循的规则，就可以确定一个合理的等价类(符合规则)和几个不合理的等价类(从各个角度违反规则)。

④如果划分的等价类中的元素在程序中被区别对待，那么等价类应该被进一步划分成更小的等价类。

(2)确定测试用例。

①对每个等价类进行编号。

②设计一个测试用例，覆盖尽可能多的合理等价类。重复这个步骤，直到所有合理的等价类都被测试用例覆盖。

③设计一个测试用例，只覆盖一个不合理的等价类。

2.边界值分析

设计测试用例时，边界值分析一般与等价类划分相结合。但它并不从等价类中选择一个例子作为代表，而是以测试边界为重点对象，选取恰好等于、刚好大于或刚好小于边界值的测试数据。

(1)如果输入条件指定了取值范围，可以选择刚好等于边界值的数据作为合理测试用例，也可以选择刚好超出边界值的数据作为不合理测试用例。如果输入值的范围是[1，100]，则0，1，100，101的值可以作为测试数据。

(2)如果输入条件指示输入数据的数量，则测试用例根据最大数量、最小数量、小于最小数量的1和大于最大数量的1来设计。例如，一个输入文件可以包含1-255条记录，那么分别设计包含1条记录、255条记录和0条记录的输入文件的测试用例。

(3)对于每种输出条件，分别按上述原理(1)或(2)确定输出值的边界。比如一个学生成绩管理系统，规定只能查询95-98级的大学生成绩，可以设计测试用例，这样就需要设计查询范围内某一届或四届的学生成绩(不合理输出等价类)。

因为输出值的边界与输入值的边界并不对应，所以不一定能检查出输出值的边界，也不一定能产生超出输出值的结果，但必要时需要重新尝试。

(4)如果程序规范中给出的输入或输出字段是有序集(如顺序文件、线性表、链表等。)，应该选择集合的第一个和最后一个元素作为测试用例。

3.错误的推测

在测试程序时，人们可能会根据经验或直觉推断出程序中可能存在的各种错误，从而编写有针对性的测试用例来检查这些错误，这就是错误推断法。

4.因果图

等价类划分和边值法分析方法只是孤立地考虑了每个输入数据的检验函数，没有考虑多个输入数据组合所带来的误差。

5.综合战略

每种方法都可以设计一组有用的例子，容易发现一类错误，但可能不容易发现另一类错误。所以在实际测试中，各种测试方法结合起来，形成一个综合的策略。通常先用黑盒法设计基本测试用例，然后用白盒法补充一些必要的测试用例。

第六，测试用例设计的误区

(来源:关河考试网)

能够发现目前还没有发现的缺陷的用例是好的用例；

首先我必须声明，这句话其实很有道理，但是我发现很多人曲解了这句话的本意，一心想要设计和发现“难以发现的缺陷”，陷入了盲目的片面，忘记了测试的目的，这是非常可怕的。我倾向于把测试用例认作一个集合，它的评估只能在测试用例的集合上进行。考试本身就是一种“V &；AMpv”，测试需要保证以下两点:

程序做了它应该做的。

程序没有做不该做的事。

因此，作为测试实现的基础，测试用例必须能够完全覆盖测试需求，而不应该针对单个测试用例进行判断。

测试用例要详细记录所有的操作信息，让一个没有接触过系统的人也能测试；

我不知道国内有没有公司真的能做到这一点，或者说我不知道国内有没有公司能把每一个测试用例都写得这么详细。在我的测试经验中，我对测试用例描述的细节和复杂性有很多疑问。写的太简单了，除了你自己没人能执行。写的太详细了，测试用例维护花费的时间(别忘了，测试用例是动态的，一旦测试环境、需求、设计和现实发生变化，测试用例也需要随之变化)真的很惊人，在目前国内大部分软件公司测试资源匮乏的情况下大概很难做到。但我恰好遇到一些这样的老板或者项目负责人，甚至是测试工程师自己，不管实际资源如何，一定要写一个“没接触过系统的人也能测试”的用例。

在讨论这个问题之前，我们可以考虑一下测试的目的。测试的目的是尽可能地发现程序中的缺陷。测试活动本身也可以看作是一个项目，它需要在给定的资源条件下尽可能地实现目标。根据我个人的经验，国内大部分软件公司在测试方面都没有配备足够的资源，所以在测试规划阶段一定要明确测试目标，一切都要围绕测试目标来进行。

除了资源限制之外，测试用例的详细程度也需要根据需要来确定。如果测试用例的执行者，测试用例的设计者，以及参与测试活动的人员对系统有很深的了解，就没有必要对测试用例做太详细的描述。文档的作用是交流，只要能达到交流的目的，就OK。在我担任测试经理的项目中，在测试规划阶段，一般会给测试设计30%-40%左右的时间，测试设计工程师可以根据项目的需要确定测试用例的细节，参与测试用例评审的相关人员会进行检查。

测试用例设计是一劳永逸的事情；

我想在这里没有人会认可这句话，但在实际情况中，我们往往能找到这种想法的影子。我曾经参与过一个项目，软件需求和设计已经改了很多次，但是测试用例根本没有修改。直接结果是新的测试工程师在执行测试用例时无所适从，间接结果是测试用例变成一堆废纸。在多次被无效的缺陷报告困扰后，开发人员对测试人员不屑一顾。

这个例子可能比较极端，但是在实际开发过程中，测试用例与需求和设计不同步的情况并不少见。测试用例文档是“活的”文档，测试工程师应该牢记在心。

测试用例不应该包含实际数据；

一个测试用例是“一组输入、执行条件和预期结果”，它无疑应该包括清晰的输入数据和预期输出。一个没有测试数据的测试用例最多只是指导性的，不具有可执行性。当然，测试用例中包含输入数据会带来维护、与测试环境同步等问题。在这方面，《有效的软件测试》一书提供了详细的测试案例和测试数据维护方法，供大家参考。

测试用例中不需要明显的验证手段；

我见过很多测试工程师写的测试用例，其中“预期输出”只被描述为程序可见的行为。事实上，“预期结果”的意义不仅仅是程序可见的行为。例如，对于订购系统，如果您输入订购数据并单击确定，系统会提示“订购成功”。这是一个完整的用例吗？系统输出的“订单成功”应该是我们唯一的验证手段吗？显然不是。订单成功与否取决于相应的数据记录是否更新。因此，在这样的用例中，还应该包括一个验证测试结果的显式手段:在数据库中执行一个查询语句，查看查询结果是否与预期一致。

七、从用例中生成测试用例。

用于功能测试的测试用例来自于测试目标的用例。应该为每个用例场景编译测试用例。用例场景应该通过描述用例的路径来确定，它应该从用例的开始到结束遍历所有的基本流程和可选流程。

例如，下图中用例的每个不同路径反映了基本流程和可选流程，两者都用箭头表示。基本流程由一条黑色的直线表示，这是用例中最简单的路径。每个备选流程从基本流程开始，然后在一定条件下执行备选流程。备选流可以重新加入基本流(备选流1和3)，或者可以源自另一个备选流(备选流2)，或者终止用例而不重新加入某个流(备选流2和4)。

用例的事件流示例

遵循上图中每个用例的可能路径，可以确定不同的用例场景。从基本流程开始，然后将基本流程与备选流程相结合，可以确定以下用例场景:

场景1基本流

场景2基本流备选流1

场景3基本流备选流1备选流2

场景4基本流备选流3

场景5基本流备选流3备选流1

场景6基本流备选流3备选流1备选流2

场景7基本流备选流4

场景8基本流备选流3备选流4

注意:为方便起见，场景5、6和8仅描述了替代流程3所示的循环执行一次的情况。

为每个场景生成测试用例是通过确定特定的条件来完成的，这将导致特定用例场景的执行。

例如，假设上图中描述的用例将备选流程3定义如下:

“如果在上面的步骤2‘输入提款金额’中输入的美元金额超过当前帐户余额，则会发生此事件流。系统将显示一条警告信息，然后重新加入基本流程，并再次执行上述步骤2“输入取款金额”。这时银行客户可以输入新的取款金额。”

基于此，您可以开始确定需要用来执行备选流程3的测试用例:

测试用例ID场景条件预期结果

TC x场景4第2步-提取金额>账户余额在第2步重新加入基本流。

TC y方案4第2步-提款金额

TC z场景4，步骤2-取款金额=账户余额不执行备选流程3，执行基本流程。

注意:因为没有提供其他信息，所以上面显示的测试用例非常简单。测试用例很少这么简单。

下面是一个从用例中生成测试用例的更现实的例子。

示例:

一台ATM机的主角和用例。

下表包含了上图中提款案例的基本流程和部分备用流程:

这个用例的开始是ATM准备好了。

准备取款——客户将银行卡插入ATM机的读卡器。

验证银行卡——ATM机从银行卡磁条上读取账户代码，检查是否属于可接受的银行卡。

输入PIN-ATM要求客户输入PIN码(4位数字)。

验证帐户代码和PIN-验证帐户代码和PIN，以确定帐户是否有效以及输入的PIN对于帐户是否正确。对于此事件流，帐户有效，并且此帐户的PIN正确。

自动柜员机选项-自动柜员机显示本机器上可用的各种选项。在这种事件流中，银行客户通常会选择“取款”。

输入金额-从自动柜员机提取的金额。对于此事件流，客户需要选择预设金额(10美元、20美元、50美元或100美元)。

授权-ATM通过将卡ID、PIN、金额和账户信息作为交易发送到银行系统来启动验证过程。对于这个事件流，银行系统是在线的，并且对授权请求给出回复，批准完成取款过程，并且相应地更新账户余额。

发行货币-提供现金。

还银行卡——银行卡还了。

收据-打印收据并提供给客户。ATM也会相应地更新内部记录。

在用例结束时，ATM再次准备就绪。

备选流程1-银行卡作废基本流程第二步-验证银行卡，如果卡作废，则退卡并通知相关消息。

备选流程二——ATM无现金——ATM选项在基本流程第五步，如果ATM无现金，“取款”选项将不可用。

备选流程ATM中的现金短缺属于基本流程步骤6-输入金额。如果ATM中的金额少于取款请求的金额，将显示一条适当的消息，并且基本流程将在步骤6-输入金额处重新加入。

备用流程4-基本流程步骤4中的PIN错误-验证帐户和PIN，客户有三次机会输入PIN。

如果PIN输入错误，ATM将显示适当的信息；如果还有输入机会，这个事件流将在步骤3-输入PIN重新加入基本流。

如果最后一次尝试输入的PIN码仍然错误，该卡将被ATM保留，ATM将返回就绪状态，此用例将被终止。

备选流程5-基本流程中不存在帐户步骤4-验证帐户和PIN。如果银行系统返回的代码表明找不到该账户或禁止从该账户中取款，则ATM显示适当的消息，并在步骤9-返回银行卡重新加入基本流程。

可选流程6-基本流程步骤7-授权中的账面金额不足，银行系统返回一个代码，表明账户余额小于基本流程步骤6-输入金额中输入的金额，然后ATM显示一条适当的消息，并在步骤6-输入金额重新加入基本流程。

备选流程7-达到每日最大取款金额在基本流程步骤7-授权中，银行系统返回的代码表明客户已经或将超过24小时内允许提取的最大金额，然后ATM显示适当的信息，并在步骤6-输入金额中重新加入基本流程。

备用流程x-记录错误如果记录无法在基本流程步骤10-收据中更新，ATM将进入“安全模式”，在该模式下，所有功能都将暂停。同时，向银行系统发送适当的警报消息，指示ATM已被暂停。

客户可以随时决定终止交易(退出)。交易终止，银行卡就会退出。

可选的flow z-“tilt-up”ATM包含大量传感器来监控各种功能，例如电源检测器、不同门和入口的压力计以及运动检测器。在任何时候，如果有人