怎么对测试用例分类? (怎么对测试用户评价)

本文目录导航：

• 怎么对测试用例分类?
• 性能测试用例是依照什么方法启动的
• 什么是测试用例

怎么对测试用例分类?

测试用例可以依据不同的属性和目的启动分类。

通常，咱们可以将测试用例分为以下几类：配置测试用例、性能测试用例、安保测试用例和兼容性测试用例。

首先，配置测试用例关键针对软件产品的各项配置启动验证，确保每个配置都能依照预期上班。

例如，在一个登录配置的测试中，配置测试用例将笼罩正确的用户名和明码登录、失误的用户名或明码登录、空用户名或明码登录等多种状况，以片面测验登录配置的正确性和强健性。

其次，性能测试用例关键用于评价软件产品在特定条件下的性能目的，如照应期间、吞吐量、并发用户数等。

例如，针对一个在线购物网站的性能测试，或许会设计测试用例来模拟少量用户同时访问网站、启动搜查、参与商品到购物车、提交订单等操作，以检测系统在高负载下的性能表现。

再者，安保测试用例旨在测验软件产品的安保性和防护才干，以防止潜在的安保要挟和破绽。

例如，关于一个网络支付系统，安保测试用例或许会包括检测SQL注入、跨站脚本攻打（XSS）、跨站恳求伪造（CSRF）等经常出现的安保破绽，以确保系统能够抵御这些攻打。

最后，兼容性测试用例关键用于验证软件产品在不同环境敌对台上的兼容性和互操作性。

例如，针对一个移动运行，兼容性测试用例或许会笼罩多种操作系统版本、屏幕分辨率、网络条件等，以确保运行在各种场景下都能失常运转。

经过对测试用例的分类，咱们可以更有针对性地设计和口头测试，从而提高测试效率和质量。

同时，不同类型的测试用例相互补充，有助于片面评价软件产品的质量和牢靠性。

性能测试用例是依照什么方法启动的

性能测试用例的设计，还是得看你的测试对象，以及测试目的，一句你的实践业务来启动详细设计；普通而言，咱们所谓的性能测试，大局部指的是对后端主机的性能方面测试，当然测试环节中，或许会经过client，或许web端来辅佐启动；随着性能测试的展开，与性能排查的越来越精准，最终或许针对web、以及client端的每个细节都会启动笼罩到；至于测试用例的设计，倡导对症下药，依据并重点去设计，每条用例，尽量之测试一个点，观测一个点的性能状况；当然，有些业务的性能是有目的和目的的，你从基本的配置数量开局，逐渐参与，施加压力，最终到原定目的指；有些业务的性能目的是没定义的，这时刻，或许就是一种探求性的，一点一点的模拟实践用户增长，知道最终知道系统的瓶颈所在，而后逐渐启动提升；

什么是测试用例

上方那个匿名的，你的给的那是什么网址啊！－－－－－－－－－－－－－测试用例－－－－－－－－－－－－－－－－－－中科永联初级技术培训中心测试用例（Test Case）是为某个不凡目的而编制的一组测试输入、口头条件以及预期结果，以便测试某个程序门路或核实能否满足某个特定需求。

测试用例（TESt CASe）目前没有经典的定义。

比拟通常的说法是：指对一项特定的软件产品启动测试义务的形容，表现测试方案、方法、技术和战略。

内容包括测试目的、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并构成文档。

不同类别的软件，测试用例是不同的。

不同于诸如系统、工具、控制、游戏软件，治理软件的用户需求愈加不一致，变化更大、更快。

笔者关键从事企业治理软件的测试。

因此咱们的做法是把测试数据和测试脚本从测试用例中划分进去。

测试用例更趋于是针对软件产品的配置、业务规则和业务处置所设计的测试方案。

对软件的每个特定配置或运转操作门路的测试构成了一个个测试用例。

随着中国软件业的日益壮大和逐渐走向成熟，软件测试也在始终开展。

从最后的由软件编程人员兼职测试到软件公司组建独立专职测试部门。

测试上班也从繁难测试演化为包括：编制测试方案、编写测试用例、预备测试数据、编写测试脚本、实施测试、测试评价等多项内容的正轨测试。

测试形式则由单纯手工测试开展为手工、智能兼之，并有向第三方专业测试公司开展的趋向。

要使最终用户对软件感到满意,最有力的举措就是对最终用户的希冀加以明白论述，以便对这些希冀启动核实并确认其有效性。

测试用例反映了要核实的需求。

但是，核实这些需求或许经过不同的形式并由不同的测试员来实施。

例如，口头软件以便验证它的配置和性能，这项操作或许由某个测试员驳回智能测试技术来成功；计算机系统的关机步骤可经过手工测试和观察来成功；不过，市场占有率和开售数据（以及产品需求），只能经过评测产品和竞争开售数据来成功。

既然或许无法（或不用担任）核实一切的需求，那么能否能为测试筛选最适宜或最关键的需求则相关到名目的成败。

选中要核实的需求将是对老本、危险和对该需求启动核实的必要性这三者权衡思考的结果。

确定测试用例之所以很关键，要素有以下几方面。

测试用例构成了设计和制订测试环节的基础。

测试的“深度”与测试用例的数量成比例。

由于每个测试用例反映不同的场景、条件或经由产品的事情流，因此，随着测试用例数量的参与，您对产质量量和测试流程也就越有信念。

判别测试能否齐全的一个关键评测方法是基于需求的笼罩，而这又是以确定、实施和/或口头的测试用例的数量为依据的。

相似上方这样的说明：“95 % 的关键测试用例已得以口头和验证”，远比“咱们已成功 95 % 的测试”更无心义。

测试上班量与测试用例的数量成比例。

依据片面且细化的测试用例，可以更准确地预计测试周期各延续阶段的期间布置。

测试设计和开发的类型以及所需的资源关键都受控于测试用例。

测试用例通常依据它们所关联相关的测试类型或测试需求来分类，而且将随类型和需求启动相应地扭转。

最佳方案是为每个测试需求至少编制两个测试用例： ·一个测试用例用于证实该需求曾经满足，通常称作侧面测试用例； ·另一个测试用例反映某个无法接受、失常或异常的条件或数据，用于论证只要在所需条件下才干够满足该需求，这个测试用例称作负面测试用例。

一、测试用例是软件测试的外围 软件测试的关键性是无须置疑的。

但如何以起码的人力、资源投入，在最短的期间内成功测试，发现软件系统的毛病，保证软件的优异质量，则是软件公司探求和谋求的目的。

每个软件产品或软件开发名目都要求有一套优秀的测试方案和测试方法。

影响软件测试的要素很多，例如软件自身的复杂水平、开发人员（包括剖析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。

由于有些要素是主观存在的，无法防止。

有些要素则是动摇的、不稳固的，例如开发队伍是流动的，有阅历的走了，新人始终补充出去；一个详细的人上班也受心情等影响，等等。

如何保证软件测试质量的稳固？有了测试用例，无论是谁来测试，参照测试用例实施，都能保证测试的质量。

可以把人为要素的影响缩小到最小。

即使最后的测试用例思考不周全，随着测试的启动和软件版本更新，也将日趋完善。

因此测试用例的设计和编制是软件测试优惠中最关键的。

测试用例是测试上班的指点，是软件测试的必定遵守的准绳。

更是软件测试质量稳固的基本保证。

二、编制测试用例 着重引见一些编制测试用例的详细做法。

1、测试用例文档 编写测试用例文档应有文档模板，须合乎外部的规范要求。

测试用例文档将受制于测试用例治理软件的解放。

软件产品或软件开发名目的测试用例普通以该产品的软件模块或子系统为单位，构成一个测试用例文档，但并不是相对的。

测试用例文档由简介和测试用例两局部组成。

简介局部编制了测试目的、测试范畴、定义术语、参考文档、概述等。

测试用例局部逐个列示各测试用例。

每个详细测试用例都将包括下列详细信息：用例编号、用例称号、测试等级、入口准绳、验证步骤、希冀结果（含判别规范）、进口准绳、注释等。

以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价规范。

2、测试用例的设置 咱们早期的测试用例是按配置设置用例。

起初引进了门路剖析法，按门路设置用例。

目前演化为按配置、门路混合形式设置用例。

按配置测试是最简捷的，按用例规约遍历测试每一配置。

关于复杂操作的程序模块，其各配置的实施是相互影响、严密相关、环环相扣的，可以演化出数量单一的变化。

没有严密的逻辑剖析，发生遗漏是在劫难逃。

门路剖析是一个很好的方法，其最大的好处是在于可以防止漏测试。

但门路剖析法也有局限性。

在一个十分繁难字典保养模块就存在十余条门路。

一个复杂的模块会有几十到上百条门路是无余为奇的。

笔者认为这是门路剖析比拟适宜的经常使用规模。

若一个子系统有十余个或更多的模块，这些模块相互无关联。

再驳回门路剖析法，其门路数量成几何级增长，达5位数或更多，就无法经常使用了。

那么子系统模块间的测试门路或测试用例还是要靠传统方法来处置。

这是按配置、门路混合形式设置用例的由来。

3、设计测试用例 测试用例可以分为基身手情、备选事情和异常事情。

设计基身手情的用例，应该参照用例规约（或设计规格说明书），依据关联的配置、操作按门路剖析法设计测试用例。

而对孤立的配置则直接按配置设计测试用例。

基身手情的测试用例应蕴含一切要求成功的需求配置，笼罩率达100%。

设计备选事情和异常事情的用例，则要复杂和艰巨得多。

例如，字典的代码是惟一的，不准许重复。

测试要求验证：字典新增程序中已存在无关字典代码的解放，若出现代码重复必定报错，并且报错文字正确。

往往在设计编码阶段构成的文档对备选事情和异常事情剖析形容不够详尽。

而测试自身则要求验证所有非基身手情，并同时尽量发现其中的软件毛病。

可以驳回软件测试罕用的基本方法：等价类划分法、边界值剖析法、失误推测法、因果图法、逻辑笼罩法等设计测试用例。

视软件的不异性质驳回不同的方法。

如何灵敏运用各种基本方法来设计完整的测试用例，并最终成功泄露暗藏的毛病，全凭测试设计人员的丰盛阅历和精心设计。

三、测试用例在软件测试中的作用 1、指点测试的实施 测试用例关键实用于集成测试、系统测试和回归测试。

在实施测试时测试用例作为测试的规范，测试人员必定要依照测试用例严厉按用例名目和测试步骤逐个实施测试。

并对测试状况记载在测试用例治理软件中，以便智能生成测试结果文档。

依据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明白规则，实施测试时测试人员不能轻易作变化。

2、布局测试数据的预备 在咱们的通常中测试数据是与测试用例分别的。

依照测试用例配套预备一组或若干组测试原始数据，以及规范测试结果。

尤其象测试报表之类数据集的正确性，依照测试用例布局预备测试数据是十分必定的。

除失常数据之外，还必定依据测试用例设计少量边缘数据和失误数据。

3、编写测试脚本的设计规格说明书 为提高测试效率，软件测试已鼎力开展智能测试。

智能测试的中心义务是编写测试脚本。

假设说软件工程中软件编程必定有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

4、评价测试结果的度量基准 成功测试实施后要求对测试结果启动评价，并且编制测试报告。

判别软件测试能否成功、权衡测试质量要求一些量化的结果。

例：测试笼罩率是多少、测试合格率是多少、关键测试合格率是多少，等等。

以前统计基准是软件模块或配置点，显得过于毛糙。

驳回测试用例作度量基准愈加准确、有效。

5、剖析毛病的规范 经过搜集毛病，对比测试用例和毛病数据库，剖析确证是漏测还是毛病复现。

漏测反映了测试用例的不完善，应立刻补充相应测试用例，最终到达逐渐完善软件质量。

而已有相应测试用例，则反映实施测试或变卦处置存在疑问。

四、相关疑问 1、测试用例的评审 测试用例是软件测试的准绳，但它并不是一经编制成功就成为准绳。

测试用例在设计编制环节中要组织同级互查。

成功编制后应组织专家评审，需取得经过才可以经常使用。

评审委员会可由名目担任人、测试、编程、剖析设计等无关人员组成，也可约请客户代表参与。

2、测试用例的修正更新 测试用例在构成文档后也还要求始终完善。

关键来自三方面的缘故：第一、在测试环节中发现设计测试用例时思考不周，要求完善；第二、在软件交付经常使用后反应的软件毛病，而毛病又是因测试用例存在破绽形成；第三、软件自身的新增配置以及软件版本的更新，测试用例也必定配套修正更新。

普通小的修正完善可在原测试用例文档上修正，但文档要有更改记载。

软件的版本更新更新，测试用例普通也应随之编制更新更新版本。

3、测试用例的治理软件 运用测试用例还需装备测试用例治理软件。

它的关键配置有三个：第一、能将测试用例文档的关键内容，如编号、称号等等智能导入治理数据库，构成与测试用例文档齐全对应的记载；第二、可供测试实施时及时输入测试状况；第三、最终成功智能生成测试结果文档，蕴含各测试度量值，测试笼罩表和测试经过或不经过的测试用例清单列表。

有了治理软件，测试人员无论是编写每日的测试上班日志、还是出软件测试报告，都会变得轻而易举。

五、测试用例的设计（一）白盒技术白盒测试是结构测试，所以被测对象基本上是源程序，以程序的外部逻辑为基础设计测试用例。

1、逻辑笼罩程序外部的逻辑笼罩水平，当程序中有循环时，笼罩每条门路是无法能的，要设计使笼罩水平较高的或笼罩最有代表性的门路的测试用例。

上方依据图7-1所示的程序，区分探讨几种罕用的笼罩技术。

(1)语句笼罩。

为了个提高发现失误的或许性，在测试时应该口头到程序中的每一个语句。

语句笼罩是指设计足够的测试用例，使被测试程序中每个语句至少口头一次性。

如图7-1是一个被测试程序流程图： (2)判定笼罩。

判定笼罩指设计足够的测试用例，使得被测程序中每个判定表白式至少取得一次性“真”值和“假”值，从而使程序的每一个分支至少都经过一次性，因此判定笼罩也称分支笼罩。

(3)条件笼罩。

条件笼罩是指设计足够的测试用例，使得判定表白式中每个条件的各种或许的值至少出现一次性。

(4)判定/条件测试。

该笼罩规范指设计足够的测试用例，使得判定表白式的每个条件的一切或许取值至少出现一次性，并使每个判定表白式一切或许的结果也至少出现一次性。

(5)条件组合笼罩。

条件组合笼罩是比拟强的笼罩规范，它是指设计足够的测试用例，使得每个判定表白式中条件的各种或许的值的组合都至少出现一次性。

(6)门路笼罩。

门路笼罩是指设计足够的测试用例，笼罩被测程序中一切或许的门路。

在实践的逻辑笼罩测试中，普通以条件组合笼罩为主设计测试用例，而后再补充局部用例，以到达门路笼罩测试规范。

2.循环笼罩3.基本门路测试（二）黑盒技术1.等价类划分(1)划分等价类。

①假设某个输入条件规则了取值范畴或值的个数。

则可确定一个正当的等价类(输入值或数在此范畴内)和两个不正当等价类(输入值或个数小于这个范畴的最小值或大于这个范畴的最大值)。

②假设规则了输入数据的一组值，而且程序对不同的输入值做不同的处置，则每个准许输入值是一个正当等价类，此处还有一个不正当等价类(任何一个不准许的输入值)。

③假设规则了输入数据必定遵照的规则，可确定一个正当等价类(合乎规则)和若干个不正当等价类(从各种不同角度违犯规则)。

④假设已划分的等价类中各元素在程序中的处置形式不同，则应将此等价类进一步划分为更小的等价类。

(2)确定测试用例。

①为每一个等价类编号。

②设计一个测试用例，使其尽或许多地笼罩尚未被笼罩过的正当等价类。

重复这步，直到一切正当等价类被测试用例笼罩。

③设计一个测试用例，使其只笼罩一个不正当等价类。

2.边界值剖析经常使用边界值剖析方法设计测试用例时普通与等价类划分结合起来。

但它不是从一个等价类中任选一个例子作为代表，而是将测试边界状况作为重点目的，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。

(1)假设输入条件规则了值的范畴，可以选用正好等于边界值的数据作为正当的测试用例，同时还要选用刚好越过边界值的数据作为不正当的测试用例。

如输入值的范畴是[1，100]，可取0，1，100，101等值作为测试数据。

(2)假设输入条件指出了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等状况区分设计测试用例。

如，一个输入文件可包括1--255个记载，则区分设计有1个记载、255个记载，以及0个记载的输入文件的测试用例。

(3)对每个输入条件区分依照以上准绳(1)或(2)确定输入值的边界状况。

如，一个在校生效果治理系统规则，只能查问95--98级大在校生的各科效果，可以设计测试用例，使得查问范畴内的某一届或四届在校生的在校生效果，还需设计查问94级、99级在校生效果的测试用例(不正当输入等价类)。

由于输入值的边界不与输入值的边界相对应，所以要审核输入值的边界不必定或许，要发生超出输入值之外的结果也不必定能做到，但必要时还需试一试。

(4)假设程序的规格说明给出的输入或输入域是个有序汇合(如顺序言件、线形表、链表等)，则应选取汇合的第一个元素和最后一个元素作为测试用例。

3.失误推测在测试程序时，人们或许依据阅历或直觉推测程序中或许存在的各种失误，从而有针对性地编写审核这些失误的测试用例，这就是失误推测法。

4.因果图等价类划分和边界值方法剖析方法都只是孤立地思考各个输入数据的测试配置，而没有思考多个输入数据的组合惹起的失误。

5.综合战略每种方法都能设计出一组有用例子，用这组例子容易发现某种类型的失误，但或许不易发现另一类型的失误。

因此在实践测试中，联结经常使用各种测试方法，构成综合战略，通常先用黑盒法设计基本的测试用例，再用白盒法补充一些必要的测试用例。

六、测试用例设计的误区（来源：关河测试网）·能发现到目前为止没有发现的毛病的用例是好的用例；首先要声明，其实这句话是十分有情理的，但我发现很多人都误会了这句话的原意，一心要设计登程现“难于发现的毛病”而堕入自觉的片面中去，遗记了测试的目的所在，这是十分可怕的。

我偏差于将测试用例当作一个汇合来意识，对它的评价也只能对测试用例的汇合来启动，测试自身是一种“V&AMp;V”的优惠，测试 要求保证以下两点：程序做了它应该做的事情 程序没有做它不该做的事情 因此，作为测试实施依据的测试用例，必定要能完整笼罩测试需求，而不应该针对单个的测试用例去评判好坏。

·测试用例应该详细记载一切的操作信息，使一个没有接触过系统的人员也能启动测试；不知道国际有没有公司真正做到这点，或许说，不知道有国际没有公司能够将每个测试用例都写得如此详细。

在我的测试阅历中，对测试用例形容的详细和复杂水平 也曾有过很多的徘徊。

写得太繁难吧，除了自己没人能够口头，写得太详细吧，消耗在测试用例保养（别忘了，测试用例是灵活的，一旦测试环境、需求、设计、实 现出现了变化，测试用例都要求相应出现变化）上的期间真实是太惊人，在目前国际大局部软件公司的测试资源都无余的状况下，恐怕很难成功。

但我偏偏就能遇到 一些这样的老总或许是名目担任人，甚至是测试工程师自身，全然不顾实践的资源状况，必定要写出“没有接触过系统的人员也能启动测试”的用例。

在探讨这个疑问之前，咱们可以先思考一下测试的目的。

测试的目的是尽或许发现程序中存在的毛病，测试优惠自身也可以被看作是一个ProjECt，也要求在 给定的资源条件下尽或许达成目的，依据我团体的阅历，大局部的国际软件公司在测试方面装备的资源都是无余够的，因此咱们必定在测试方案阶段明白测试的目 标，一切围绕测试的目的启动。

除了资源上的解放外，测试用例的详细水平也要求依据要求确定。

假设测试用例的口头者、测试用例设计者、测试优惠相关人对系统了解都很深入，那测试用例就没有必要太详细了，文档的作用原本就在于沟通，只需能到达沟通的目的就OK。

在我担任测试经理的名目中，在测试方案阶段，普通给予测试设计30% - 40%左右的期间，测试设计工程师能够依据名目的要求自行确定用例的详细水平，在测试用例的评审阶段由介入评审的相关人对其把关。

·测试用例设计是与日俱增的事情；这句话摆在这里，我想没有一团体会认可，但在实践状况中，却经常能发现这种想法的影子。

我曾经介入过一个名目，软件需求和设计曾经变卦了屡次，但测试用例 却没有任何修正。

造成的直接结果是新参与的测试工程师在口头测试用例时手足无措，直接的结果是测试用例成了废纸一堆，开发人员在屡次被有效的毛病报告打扰 后，对测试人员等闲视之。

这个例子或许有些极其，但测试用例与需求和设计不同步的状况在实践开发环节中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

·测试用例不应该蕴含实践的数据；测试用例是“一组输入、口头条件、预期结果”、毫无不懂地应该包括明晰的输入数据和预期输入，没有测试数据的用例最多只具备指点性的意义，不具备可口头 性。

当然，测试用例中蕴含输入数据会带来保养、与测试环境同步之类的疑问，关于这一点，《Effective Software TeST》一书中提供了详细的测试用例、测试数据的保养方法，可以参考。

·测试用例中不要求显著的验证手腕；我见过很多测试工程师编写的测试用例中，“预期输入”仅形容为程序的可见行为，其实，“预期结果”的含意并不仅是程序的可见行为。

例如，对一个订货系统， 输入订货数据，点击“确定”按钮后，系统揭示“订货成功”，这样是不是一个完整的用例呢？是不是系统输入的“订货成功”就应该作为咱们惟一的验证手腕呢？ 显然不是。

订货能否成功还要求检查相应的数据记载能否更新，因此，在这样的一个用例中，还应该蕴含对测试结果的显式的验证手腕：在数据库中口头查问语句启动查问，看查问结果能否与预期的分歧。

七、从用例中生成测试用例 用于配置性测试的测试用例来源于测试目的的用例。

应该为每个用例场景编制测试用例。

用例场景要经过形容流经用例的门路来确定，这个流经环节要从用例开局到完结遍历其中一切基本流和备选流。

例如，下图中经过用例的每条不同门路都反映了基本流和备选流，都用箭头来示意。

基本流用直黑线来示意，是经过用例的最繁难的门路。

每个备选流自基本流开局，之后，备选流会在某个特定条件下口头。

备选流或许会从新参与基本流中（备选流 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 - 提款金额 < 帐户余额 不口头备选流 3，口头基本流 TC z 场景 4 步骤 2 - 提款金额 = 帐户余额 不口头备选流 3，口头基本流 注：由于没有提供其余信息，以上显示的测试用例都十分繁难。

测试用例很少如此繁难。

上方是一个由用例生成测试用例的更合乎实践状况的示例。

示例：一台 ATM 机器的主角和用例。

下表蕴含了上图中提款用例的基本流和某些备用流： 本用例的开局是 ATM 处于预备就绪形态。

预备提款 - 客户将银行卡拔出 ATM 机的读卡机。

验证银行卡 - ATM 机从银行卡的磁条中读取帐户代码，并审核它能否属于可以接纳的银行卡。

输入 PIN - ATM 要求客户输入 PIN 码（4 位）验证帐户代码和 PIN - 验证帐户代码和 PIN 以确定该帐户能否有效以及所输入的 PIN 对该帐户来说能否正确。

关于此事情流，帐户是有效的而且 PIN 对此帐户来说正确无误。

ATM 选项 - ATM 显示在本机上可用的各种选项。

在此事情流中，银行客户通常选用“提款”。

输入金额 - 要从 ATM 中提取的金额。

关于此事情流，客户需选用预设的金额（10 美元、20 美元、50 美元或 100 美元）。

授权 - ATM 经过将卡 ID、PIN、金额以及帐户信息作为一笔买卖发送给银行系统来启动验证环节。

关于此事情流，银行系统处于联机形态，而且对授权恳求给予回答，同意成功提款环节，并且据此更新帐户余额。

出钞 - 提供现金。

前往银行卡 - 银行卡被返还。

收据 - 打印收据并提供应客户。

ATM 还相应地更新外部记载。

用例完结时 ATM 又回到预备就绪形态。

备选流 1 - 银行卡有效 在基本流步骤 2 中 - 验证银行卡，假设卡是有效的，则卡被退回，同时会通知相关信息。

备选流 2 - ATM 内没有现金 在基本流步骤 5 中 - ATM 选项，假设 ATM 内没有现金，则“提款”选项将无法经常使用。

备选流 3 - ATM 内现金无余 在基本流步骤 6 中- 输入金额，假设 ATM 机内金额少于恳求提取的金额，则将显示一则适当的信息，并且在步骤 6 - 输入金额处从新参与基本流。

备选流 4 - PIN 有误 在基本流步骤 4 中- 验证帐户和 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 曾经暂复上班。

备选流 y - 分开 客户可随时选择中断买卖（分开）。

买卖中断，银行卡随之分开。

备选流 z - “翘起” ATM 蕴含少量的传感器，用以监控各种配置，如电源检测器、不同的门和出入口处的测压器以及举措检测器等。

在任一时辰，假设某