工作流测试用例

工作流测试用例（精选9篇）

工作流测试用例 篇1

如何做好测试计划和测试用例工作

如何做好测试计划和测试用例工作 用例设计 测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法? 个人认为做好测试计划的编写工作应该从以下几个方面考虑问题： 1、要充分考虑测试计划的实用性，即，测试计划与实际之间的接近程度和可操作性。 编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制，可能受到的各种影响。说的再明确一点就是要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。 2、要坚持“5W1H”的原则，明确测试内容与过程。 明确测试的范围和内容(WHAT); 明确测试的目的(WHY); 明确测试的开始和结束日期(WHEN); 明确给出测试文档和软件册存放位置(WHERE); 软件测试 明确测试人员的任务分配(WHO); 明确指出测试的方法和测试工具(HOW)。 3、采用评审和更新机制，确保测试计划满足实际需求。 因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地进行变更。 之所以采取相应的评审制度，就是要对测试计划的完整性、正确性、可行性进行评估，以保证测试的质量。 4、测试策略要作为测试的重点进行描述。 测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素，而测试策略则是说明世纪的测试过程中，应该怎样具体实施。因此，测试策略一定要描述详尽并且重点突出。 打个不太恰当的比喻，你可以认为测试计划就是测试工作的预期输出，而测试执行是测试工作的实际输出，在预期输出!=实际输出的情况下，您会认为这样的测试合格么? 至于测试用例工作，我认为我们首先要明确测试用例在整个测试工作中的地位及其作用。个人认为，测试用例在整个测试工作中的地位和作用主要体现在以下几个方面： 1、测试用例是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式; 2、测试用例是团队内部交流以及交叉测试的依据; 3、在回归测试中，测试用例的存在可以大大的降低测试的工作量，从而提高测试的工作效率; 4、测试用例便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核; 5、在测试工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性; 6、测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。 当我们认识到测试用例在政工测试工作中的地位及其作用之后，相信大家都已经认识到了测试用例对测试工作的重要性和必要性，那么，我们就来讨论一下如何有效的保证测试用例的质量。 1、做好测试人员的.项目培训(主要指对需求分析、软件设计、测试计划的认知程度)工作。要想发挥团队中每一个成员的所有能力，最好的办法就是让他们每一个人都清楚这个项目中的所有细节，以及自己要在这个项目中所承担的责任。 2、尽可能的利用以往其他项目的测试用例;并将该项目中类似模块进行归类，按类编写测试用例，再根据每个模块的特点进行修改，要充分利用测试用例的可重用性。 3、在时间资源紧张的情况下，可以按照测试的关键路径编写测试用例，针对关键路径的测试用例一定要详尽，其他边缘模块的测试用例可以考虑仅通过性测试(既仅证真测试)。 4、采用针对测试用例的模块化编写。个人建议将测试用例和测试数据分开，测试用例中的操作步骤应主要体现于业务流程的检验，而测试数据主要体现于针对系统的数据处理结果的检验。考虑到软件项目的需求变更问题，建议将这两项分开，通过测试用例编号进行关联，以应对需求变化造成的测试用例的修改，从而减少测试用例的修改量，缩短项目周期，提高工作效率。 以上是针对“做好测试计划和测试用例的工作的关键是什么”的问题的个人见解，如有不同意见，请大家及时指出和补充。 焦点测试：www.testfocus.com.cn/

工作流测试用例 篇2

关键词：系统用例,测试用例,复用,软件质量

1、引言

长期以来，软件质量问题一直困扰着大多数国内的软件企业。大多数企业，重开发、轻测试，认为软件测试是可有可无的事情。软件测试要么流于形式，由开发人员自己对自己的代码进行检查，要么根本没有，拿用户做实验，软件直接交给用户来测，待用户发现问题后再做补救。软件的质量根本无法保证。近年来，随着客户对软件质量的要求越来越高，软件行业也逐渐意识到，软件测试才是确保软件质量的最有效的手段。因此，近年来形成了比较完善的软件测试理论体系。但是，如何编写高效的测试用例。即，如何利用尽可能少的用例做到尽可能大的覆盖率，仍是每一个测试人员需要面对的问题。[1]

2、软件测试的一般方法

软件测试按照阶段划分一般分为：单元测试、集成测试、系统测试、验收测试。[1]单元测试针对每个模块进行的测试，通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。单元测试的目的是看已完成的编码是否符合详细设计说明书上的要求。集成测试在单元测试的基础上，将所有模块按照设计要求组装成为系统，必须精心计划，应提交集成测试计划、集成测试规格说明和集成测试分析报告。集成测试着眼于各模块之间的接口是否正确。由于软件集成的过程是一个持续的过程，会形成多个临时版本。因此，在集成测试的过程中，需要不断地对系统进行冒烟测试，即对程序的主要功能进行测试。确认测试验证软件的功能和性能及其它特性是否与系统的概要设计说明书一致。系统测试和验收测试的目的在于检验系统的提供的功能是否与用户的要求一致，系统测试是在实际运行环境或相对真实的模拟环境下进行一系列的测试。

软件测试按照测试技术划分，一般分为：白盒测试和黑盒测试。白盒测试检查程序的代码设计。该方法将语句与判断作为研究对象，检查所有的结构和路径是否都是正确的。白盒测试以覆盖率作为衡量标准，覆盖率越高，其测试越充分。白盒测试一般分为语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖以及路径覆盖等[1]。然而100%的代码测试几乎是不可能的，白盒测试的成本非常高，除非在航空或军用领域，一般的应用系统只需针对最重要的核心代码进行白盒测试。

黑盒测试是从用户的角度对系统进行测试查找系统存在的缺陷。黑盒测试与需求紧密相关，系统业务需求分析的正确程度直接影响黑盒测试的质量。在进行嵌入式软件黑盒测试时，要把用户需求作为重要依据。黑盒测试针对的是系统的外在功能，因此对软件系统的分支覆盖率比白盒测试要低，在系统修改后，一般要进行回归测试。[5]

3、系统用例和测试用例的关系

作为分析建模活动的一部分，系统用例用来捕获信息的生产者、使用者和系统本身之间发生的交互。即，从某个特定参与者的角度用简单易懂的语言说明一个特定的使用场景。[2]下面通过一个实例来说明用例的组成与结构。

用例1：登录

[执行者]：员工

[基本路径]：

1）、员工插入安全锁触发系统登录过程。

2）、系统打开安全锁

3）、系统从安全锁中获取证书信息。

4）、系统验证证书的合法性。

5）、系统获取证书中的用户名。

6）、系统将用户的考勤信息存储至数据库。

7）、系统将用户的在线状态记录至数据库。

8）、系统从数据库中获得在线用户列表、通知列表、带接收文件列表、日程安排、收文回执列表等。

[扩展路径]：

2a、无法打开安全锁

2a1、提示用户安全锁错误。

2a2、用例结束

2b、PIN码不正确

2b1、输入未超过3次，要求用户重新输入PIN码

2b2、返回步骤2

2b1a、用户输入PIN码达到3次

2b1a1、用例结束

3a、无法获得安全锁中的证书

3a1、提示用户锁内证书无法获得

3a2、用例结束

4a、证书验证不合法

4a1、提示用户锁内证书不合法

4a2、用例结束

6a、无法存储至数据库

6a1、将登录信息存储至本地

6a2、重复尝试存储登录信息。

7a、无法存储至数据库

8 a 1、重复尝试存储在线信息。

这是一个利用硬件设备通过数字证书进行系统登录的用例。基本路径描述了自顶向下的易于理解的典型场景。在其中用户目标得以实现，风险承担者的利益也得到了保障。[4]扩展路径则表述了系统出现问题情况下的场景。扩展路径可以在执行后重新加入到基本路径中，也可以不再重新加入基本路径而终止用例。

我们在得到了系统用例之后，则可以通过该用例来设计测试用例。在设计过程中，不仅要考虑基本路径所产生的成功场景，也必须要考虑当扩展路径执行时的失败场景。

通过表1六个用例执行了系统用例中步骤1-4中的场景。用例1为正面测试用例，它沿着系统用例的基本路径执行，未发生任何偏差。用例2-6为负面测试用例，它们在系统出现偏差时沿着扩展路径执行。负面测试是相对于基本路径而言的，对于扩展路径来说用例2-6是正面测试。

通过系统用例生成测试用例非常方便，二者之间的转换是非常自然的过程。与其他方法不同，这个方法对系统用例的依赖程度高。因此，测试用例的成功与否，取决与系统需求分析的正确程度。只有真正捕获了用户的需求，并且编写出正确的系统用例，才能得到高效的测试用例。

4、用例复用

测试用例复用是指重复使用“为了复用目的而设计的测试用例”的过程。[3]相应地，可复用测试用例是指为了复用目的而设计的测试用例。与软件复用的概念相对应，软件的复用是为了支持软件在应用维的演化，使用“为复用而开发的软件 (构件) ”来更快、更好地开发新的应用系统。好的测试用例用来确保软件的质量，而有效复用现有的测试用例更能提升软件测试的效率。[2]测试用例的复用技术目前已成为一个新的研究热点，由于本人的水平有限，在这里只能根据自己的经验提出一点自己的体会。

传统上，我们都是针对特定的系统设计软件系统设计测试用例，过于局限于某一种产品，依赖性非常强，不利于测试用例的复用。

需求分析的结果取决于用户需求，系统分析结果是针对问题域的某些问题的抽象程度较高的结果，很少受到设计技术及实现条件的影响，因此复用的机会更多。一般可以从现有系统的分析结果中提取可复用构件。[2]因而通过系统用例生成测试用例的方法则可以凭借软件工程中的软件构件技术实现需求、系统和软件的需求规约的复用；继而确保由这些复用构件生成的测试用例达到复用的目的。

5、结束语

通过系统用例我们可以很方便的得到测试用例，进行系统测试。测试用例能够达到的效果取决于系统需求分析的准确程度。因此，要求我们在系统开发的过程中要高度重视系统的需求分析，准确把握用户的需求。测试用例可以与系统用例同步开发，将测试介入到软件开发过程的时间大大提前，从而确保软件开发的每一阶段，都能通过测试保证开发的质量。

需要注意的是, 本介绍的方法属于黑盒测试的范畴。覆盖率能够达到30-40%。因此, 对于系统的核心模块, 如有必要还必须借助白盒测试的方法进行全面的测试。

参考文献

[1]柳纯录.软件评测师教程.清华大学出版社.2005

[2]邵维忠.面向对象的系统分析.清华大学出版社.2005

[3]Roger Pressman.软件工程-实践者的研究方法.机械工业出版社.2007

[4]Alistair Cockburn.Writings Effective Use Case.机械工业出版社.2002

工作流测试用例 篇3

关键词 软件测试 需求建模 测试用例 生成方法

中图分类号：TP31 文献标识码：A

0前言

长时间以来，在软件设计的过程中，其需求与测试之间都具有很微妙的内在联系，两者之间的的内在联系被认为是一种先后出现的顺序关系。在之前的软件开发过程中，当其软件需求分析阶段进行开展时，测试被认定为还没有开始。但随着软件开发的不断发展以及其开发规模的不断扩大，这一观点也得到了相应的改变。Dorothy Graham中就曾指出，如果测试在软件的需求分析阶段进行介入的话，就可以帮助软件需求分析的更为详细。

1一种软件测试需求建模——模型驱动测试

随着软件系统形势越来复杂，如何对软件系统进行有效的测试成为了软件开发过程中的重点关注问题，而模型驱动测试作为一种新颖的具有良好发展前景的自动化测试方式，已经逐渐被广泛应用到软件系统需求的测试中。

模型驱动测试指的是通过测试模型对测试的架构及行为进行表示，并通过图形化的方式对测试模型进行展示。这里需要提到的是，将测试模型用图形化的方式进行展示，是因为该种方式更有利于测试人员对其进行理解与修改。测试模型的图形化将传统的基于特定语言环境下并且难以理解的测试脚本维护转化成了更加直观的测试用例模型维护，这种做法在极大程度上减少了软件测试人员的工作量，并且提高了软件测试时的工作效率。模型驱动测试可以实现将模型自动转化成测试脚本的职能转化，从而确保模型与测试脚本的同步性。与此同时，当软件的应用程序发生改变时，测试人员便不需要和过去一样，对测试项目进行重新设计，而只需要将测试模型进行修改，修改后的测试模型便会自动生成测试脚本。

在对软件需求测试的过程中采用模型驱动测试的方式，可以有效减少对软件进行测试设计过程中的初级阶段工作量，并有效提高测试的覆盖率。目前，在我国的软件开发工程中，测试占据了其五分之三的时间、能源和资金。而模型驱动测试中的新型方法以及相关工具的应用，可以有效提高软件开发者和测试人员的工作效率，在保证软件质量的同时，减少产品的开发时间。

2 基于测试需求的测试用例生成方法

测试需求模型可以对软件的测试需求进行直观且准确的概括，其作为整个测试活动的基础，可以对之后的软件测试进行有效的指导。测试用例可以通过软件需求测试模型和被测软件系统模型来生成，而测试用例可以与软件需求测试模型中的相应测试目标相对应，继而通过测试目标对测试目标设计提供依据的被测软件系统需求进行追溯。整个软件需求测试模型工作流程实现了软件系统需求对测试用例的自上向下追踪以及测试用例对软件系统需求的自下向上回溯。

2.1标记迁移系统

测试用例是通过软件需求测试模型与被测软件系统模型中的测试目标描述模型来得以实现和生成。其过程首先需要将被测软件系统在经过软件需求分析阶段并与用户进行多次讨论继而借助相关建模工具做出的状态图模型转换成标记迁移系统模型。而标记迁移系统模型是一种被广泛使用的通过计算机进行辅助设计和验证的形式模型，其通过节点的方式来表示软件系统的状态和配置，通过边来表示软件测试过程中的行为发生状态和系统配置之间的转移。

2.2测试用例生成

测试用例需要通过将被测软件系统模型系统的状态图模型转化成标记迁移系统模型（即形式模型）。根据软件需求测试系统状态图的显示，并采用标记迁移系统模型的生成算法，便可以得到与之相对应标记迁移系统模型。而在标记迁移系统模型的生成算法中，首先，需要通过Construct From（Specification Node）方法以被测软件系统模型状态图的初始状态为起点对其状态图进行分析，并将其状态图的结构信息在标记迁移系统模型中进行保存；其次，将标记迁移系统模型中同时拥有的输入输出信息的转移进行分裂，并在其中插入新生成的中间状态节点。而在将测试用例转化为标记迁移系统模型的过程中，软件需求测试模型中的测试目标模型也同样需要进行相应的标记迁移系统模型转化。

3结论

软件系统设计和实现的基础就是软件系统的需求，软件设计师对软件架构的设计、程序员对软件进行代码的编写都是根据软件的需求来进行并且完成，并且其需求还会影响到测试人员的测试方向。在软件的开发生命周期中，对软件的需求进行分析是最重要的步骤。而模型驱动的软件需求分析方法是将软件的需求模型作为软件需求标准的补充说明，继而对非形式化的软件需求信息从一个或多个角度进行正确度验证。该做法是为了发现软件需求标准中的差异性和缺陷性。

参考文献

[1] 杨波，吴际，刘超.一种软件测试需求建模及测试用例生成方法[J].计算机学报，2014，01（03）：522-538.

[2] 张丽颖，徐珞，蒋祖华.基于本体和规则推理的GUI软件测试用例生成[J].计算机应用研究，2010，01（19）：120-123.

[3] 殷永峰，刘斌，姜同敏.基于场景技术的嵌入式软件测试用例生成方法[J].计算机工程与设计，2012，11（16）：4111-4114.

测试用例书写标准 篇4

在编写测试用例过程中，需要参考和规范一些基本的测试用例编写标准，在ANSI/IEEE829-1983标准中列出了和测试设计相关的测试用例编写规范和模板。标准模板中主要元素如下。

 标识符（identification）：每个测试用例应该有一个唯一的标识符，它将成为所有和测试用例相关的文档/表格引用和参考的基本元素，这些文档/表格包括设计规格说明书、测试日志表、测试报告等。

 测试项（test item）：测试用例应该准确地描述所需要测试地项及其特征，测试项应该比测试设计说明书中所列出地特性描述更加具体，例如做windows计算器应用程序地窗口设计，测试对象是整个地应用程序用户界面，这样测试项就应该是应用程序地界面地特性要求，例如缩放测试、界面布局、菜单等。

 测试环境要求（test environment）：用来表征执行该测试用例需要地测试环境，一般来说，在整个的测试模块里面应该包含整个的测试环境的特殊要求，而单个测试用例的测试环境需要表征该测试用例所单独需要的特殊环境需求。

 输入标准（input criteria）：用来执行测试用例的输入需求。这些输入可能包括数据、文件，或者操作（例如鼠标的左键单击，鼠标的按键处理等），必要的时候，相关的数据库、文件也必须被罗列。

 输出标准（output criteria）：标识按照指定的环境和输入标准得到的期望输出结果。如果可能的话，尽量提供适当的系统规格说明书来证明期望的结果。

 测试用例之间的关联：用来标识该测试用例与其它的测试（或其它测试用例）之间的依赖关系，例如，用例A需要基于B的测试结果正确的基础上才能进行，此时需要在A的测试用例中表明对B的依赖性，从而保证测试用例的严谨性。

综上所述，如果使用一个数据库的表来表征测试用例的话，它应该有以下的格式：

例一：对Windows记事本程序进行测试，选取其中的一个测试项――文件菜单栏的测试 测试对象：记事本程序文件菜单栏（测试用例标识1000，下同），所包含的子测试用例描述如下：

|---------文件/新建（1001）

|---------文件/打开（1002）

|---------文件/保存（1003）

|---------文件/另存（1004）

|---------文件/页面设置（1005）

|---------文件/打印（1006）

|---------文件/退出（1007）

|---------菜单布局（1008）

|---------快捷键（1009）

选取其中的一个子测试用例――文件/退出（1007）作为例子，测试用例如下表所示：

通过这个例子了解了测试用例的组成方法。要组织成一个完整的良好测试用例，还需要更多的技巧，并要考虑一些常见的因素。

测试用例设计考虑因素

测试是不可能实现穷举测试的，因此试图用所有的测试用例来覆盖所有测试可能遇到的情形是不可能的，所以，在测试用例的编写、组织过程中，尽量考虑有代表性的典型的测试用例，来实现以点带面的穷举测试。这要求在测试用例设计中考虑一些基本因素：  测试用例必须具有代表性、典型性。

 测试用例设计时，要浓缩系统设计。

例二：常见的web登录页面，通过这个例子来阐述从功能规格说明书到具体测试用例编写的过程

A）用户登录的功能设计规格说明书（摘选）

―――――――――――――――――――――――――――――――――――――――

1． 用户登录

1．1满足基本页面布局（图示，略）

1．2当用户没有输入用户名和密码时，不立即弹出错误对话框，而是在页面上使用红色字体来提示，见2描述

1．3用户密码使用掩码号（*）来标识。

1．4*代表必选字段，将出现在输入文本框的后面。

2． 登录出现错误

当出现错误时，在页面的顶部会出现相应的错误提示。错误提示的内容见3。错误提示是高亮的红色字体实现。

3． 错误信息描述

3．1

3．2密码为空

3，3用户名/

（注：本例子中的页面图示，消息编号如WMSG001的描述均为给出。）

―――――――――――――――――――――――――――――――――――――――

B）通用安全性设计规格说明书（摘选）

―――――――――――――――――――――――――――――――――――――――

1． 安全性描述

1．1输入安全性：在用户登录或者信用卡验证过程中，如果三次输入不正确，页面将需要重新打开才能生效。

1．2密码：在所有的用户密码中，都必须使用掩码符号（*），数据在数据库中存储使用统一的加密和解密算法。

1．3Cookie：在信用卡信息验证，用户名输入时，Cookie都是被禁止的，当用户第一次输入后，浏览器将不再提供是否保存信息的提示，自动完成功能将被禁用。

1．4SSL校验：所有的站点访问时，都必须经过SSL校验。

2． 错误描述（略）

―――――――――――――――――――――――――――――――――――――――

C）测试用例

结合相关的规格说明书，理解和掌握测试用例设计的关键点，测试用例设计如下表所示。

 测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分

析怎样使得这样的错误或者异常能够发生。

用户登录功能测试用例

完善的测试用例

软件测试用例的设计心得 篇5

在编写一个软件或者模块的测试用例时候，一定要明白这个功能的原始需求，也就是软件的使用者（客户）的需求。理解原始需求后，编写的测试用例才更有目的性。

2、熟悉软件的功能需求（测试点）

这个功能需求是指软件的细化需求点，这个一般在需求文档里面都会体现。这里要做的是把 “粗略”的需求，细化成一个个小需求点。熟悉功能需求后，要知道软件是怎么使用的，这也才能覆盖到各种操作。

总之，测试用例一定要全部覆盖所有的需求点，这是最基本的一点。

3、熟悉软件的实现原理（测试点）

在理解原始需求和软件的功能需求后，根据需求编写的测试用例，基本上都能覆盖得比较全面了。

在此基础上，熟悉软件的实现原理，理解软件的内部处理。

（1）熟悉原理的过程是进一步深入熟悉软件的过程。如果单单是从需求点上面覆盖案例，测试用例只能覆盖“表面”的一层。一些内部的处理流程也许没有覆盖到，而这些没有覆盖到的代码很可能就是一个风险点。

（2）熟悉模块原理后，还有一点就是易于分析软件模块的关联性。一个大型的软件，都是一些小模块的组合而成。软件越是大型，耦合就越大，“互相影响”就会越多，若设计用例单单从模块本身考虑的话，很可能就会对其他模块造成风险。

4、用户场景和网上问题（测试点）

从用户的使用场景考虑，这在一些网络设备比较重要，比如软件后期在一些真实的使用环境中使用。

还要就是从一些网上问题总结出来的，那些地方容易出错，在设计案例的时候需要考虑进去。

5、测试用例的框架

一个测试用例的框架体现了一个测试人员在设计测试用例的整体思路。框架也是从大到小划分下来，可以是：

UI界面，功能，容错，兼容，性能等几大类，每个大类在根据软件的逻辑等进行划分成小类，最后细分到测试点。

6、测试步骤（测试技巧方法）

前面4点都是从测试点的角度考虑，测试用例在完成测试点外，接下来就是测试步骤和测试结果啦。

测试用例可以写的很详细，也可以写的比较简单。这要看公司的要求，有些公司要求测试步骤很细很细，包括测试结果和测试步骤一一对应。

要求测试步骤写的很详细的公司，一般是怕执行人员的执行力不到位，导致没有理解案例的目的，导致漏测。一般出现在新员工对软件系统的不熟悉。如果测试步骤写的很详细的话，会很耗时间，而且过于详细的会限制执行人员的思维。个人认为测试用例的重点在于测试点上。

7、测试用例的一些思路

在设计测试用例中，通常较多使用的是边界值，等价类，通过和不通过测试。下面从单个模块或者单个功能点考虑：（结合一些网上文章的观点）

（1）UI界面：易用性，提示信息，整体布局，按钮图标，色彩，中英文标点错别字。

（2）数据的多样性：有效数据，合法的无效数据（边界值），非法的异常数据，产生错误输出的合法数据组合等各种数据的组合。

（3）操作多样性：添加删除编辑查询，多用户的操作。

（4）容量测试

（5）用户权限：使用权限，各种操作的权限。

（6）升级安装卸载：平滑升级

（7）日志相关（包括调试日志）

（8）软件功能的逻辑划分：功能上划分未能覆盖的代码逻辑，可以添加白盒灰盒用例。

（9）可靠性，容错性

（10）兼容性：浏览器，系统，支撑软件。

（11）安全性

（12）性能（这里的性能是指，单个模块或者子系统的性能）

总之测试用例首先要能覆盖所有功能需求点，然后搞懂软件处理逻辑，可以找开发一起看测试用例，把没有覆盖到的代码流程相应的用例补充，至此，用例基本不会出现基本功能的问题。

工作流测试用例 篇6

测试用例复用是指测试工程师在执行一项新的测试工作时，通过直接调用或修改现有的、合适的测试用例，并将其应用在测试执行中的过程。如果搜索后得到的测试用例与需求完全一致，则直接复用现有测试用例，但是一般情况下，直接复用测试用例的情况很少;如果搜索到的测试用例与需求近似，则对其进行修改，得到新的测试用例之后再复用。在一定程度上，测试用例复用可以节省重新设计测试用例的时间，减少测试工程师的工作量，提高软件测试的效率。

然而，并非所有的测试用例都适合复用，有些测试用例定制化程度较高，只适合某些特定的测试场景，这样的测试用例可复用程度不高。由此可知，测试用例要能进行复用，须具备一定的可复用特性。

1.2 可复用测试用例特性

经过对大量可复用测试用例的收集以及分析，本文认为可复用测试用例需满足以下5个特性：标准化、通用性、有效性、独立性、小粒度1]。

1) 标准化。测试用例通常用自然语言进行描述，但由于自然语言的非结构化特性，无统一结构的测试用例不利于测试用例复用。因此，测试用例的设计必须使用统一的格式或结构，以消除由于自然语言的表述的差异带来的问题。标准化不仅强调测试用例的可复用能力，更偏向于测试用例管理。采用明确无歧义的语言描述测试用例并用统一结构进行存储，如表1测试用例描述案例所示2]。其中，加粗字体表示测试用例的字段，中括号 ]里的内容表示测试用例的具体内容或相关属性。

2) 有效性：测试用例的目标是发现软件中的问题或者验证功能是否正确，因此测试用例必须是针对它的测试目的而设计，并且经审核后必须是正确、完整、适用于被测对象并且是可执行的。

3) 通用性：测试用例不局限于具体的应用，不过分依赖于被测软件的需求、设计、环境、其他功能以及其他业务流程，可复用测试用例可多次适用于不同版本的软件测试或广泛应用于某同类软件或类似功能模块的测试。

4) 独立性：测试用例不过分受制于测试环境、相关业务流程以及前置测试用例。理论上，测试用例与其他因素的耦合度越小，则独立性也就越高，其测试用例的可复用程度相对较高。

5) 小粒度：通常指一个被测模块的末梢功能，测试用例的粒度设计追求功能的不可分割性。粒度越小并且相对独立的功能，针对其功能设计的用例，可复用性也就越高。

以登录功能举例，该功能相对于整个应用系统来说粒度最小，并且与其他功能相对独立，同时，针对登录功能设计的测试用例具有较强的通用性，所以通常情况下，登录功能的测试用例具有较高的可复用性。

1.3 测试用例复用场景

然而，并非所有的软件测试过程都适合进行测试用例复用。测试用例复用是为了避免测试用例的重复设计，提供现有的测试用例给测试工程师直接使用。因此，只有在需要重复执行的测试用例时，测试用例的复用才能真正发挥作用。通常情况下，测试用例复用主要由三类测试场景3]：

1) 软件升级：包括版本升级、缺陷修复等升级行为。例如：一家公司的业务管理系统的升级，或某个功能的改进。通常不会引起非常大的业务流程变动或界面改动，因此前一个版本的测试用例可被大量复用。

2) 产品测试：此类场景多存在于软件研发公司，多从事于某个领域的软件研发工作，通常此类公司有着自己的测试用例库。比如：从事ERP(企业资源计划)软件开发的公司。虽然不同行业的业务流程都不完全一致，但也有存类似的可复用业务流程，例如员工管理模块等。

3) 第三方测评4]：第三方测评机构适用于此类测试用例复用场景。由于第三方测试机构会对大量的软件进行测评，其中不乏相同领域的软件产品。如果对每个测试软件重新设计测试用例，必然增加工作成本。因此，对于第三方测评机构测试用例复用是十分有必要的。测试用例复用在不同领域和场景中有着广泛应用，对于大量测试用例的复用需要建立在大量测试用例基础上，需要将以往设计的测试用例加以存储和管理，因此设计一套测试用例管理系统是测试用例复用成为可能的先决必要条件。

2 测试用例复用库模型设计与实现

测试用例复用就是对已经执行的测试用例进行重复使用或修改使用。要实现测试用例复用，则需要对以往设计的测试用例进行有效的存储以及分类管理以供后续使用。对测试用例的管理就需要创建一个测试用例复用库来存储测试用例，在测试用例复用库中使用统一的规范数据格式对测试用例进行管理。当测试工程师要设计测试用例时，可先在测试用例库中进行搜索，查找合适的测试用例进行复用。但是，随着时间的增长以及测试项目的增加，测试用例库也随之扩充，测试用例数目与日俱增，这就增加了搜索的工作量。为了提高搜索的效率，根据测试用例适用的行业领域，对测试用例进行划分存储，并打上行业领域的标记。其原因在于，相同行业领域的软件其测试用例的通用性更高，可复用性也更高。

为了提高在测试用例库中的搜索效率和准确度，将分词技术应用于测试用例搜索功能中，对用户的搜索输入进行分词、筛选，得出有效的搜索关键字，根据关键字在测试用例复用库中进行搜索，减少了非关键字的干扰，提高了查询速度，并且搜索结果更准确。

通常情况下，测试用例复用分为直接使用以及修改使用，但无论何种情况，都需要对新测试用例进行审核，确定其有效性和唯一性方能进入测试用例复用库，测试用例复用模型如图1所示。

3 测试用例复用搜索设计与实现

3.1 分词词库

测试工程师进行测试用例复用时，需要对查询输入进行处理，常用方法是使用分词技术提取其中的关键字进行查询。分词技术中，英文单词之间以空格作为自然分界符，而中文是以字为基本的书写单位，词与词之间没有明显的区分标记，因此，对中文信息处理相对比较复杂。语义分析是中文信息处理的基础与关键，常见的.分词算法有两种：

算法1：建立词库，对待分析字符串逐词匹配，分离关键字;

算法2：建立词库，对目标串构造全文索引，然后将结果集与词库进行笛卡尔积匹配，获取匹配结果。

以上算法如果用于较大规模词库时，存在如下效率问题：

1) 当词库较大时，逐词匹配耗时较长;

2) 采用全文索引方式消耗多余内容，同时不适用于测试用例复用查询功能，因为用户输入的查询信息较短，而全文索引多适用于长文本字符串搜索功能。

在测试用例复用查询功能中，用户查询输入相对简单，但需要进行精确分词，因此针对此类特点，本文对文献5]中提出的索引方法加以改进，采用二级索引对中文词条进行分词(这里只讨论中文分词，英文分词可使用Lucene工具进行分词)，以确保能快速并精确地进行分词。由于长度为2的中文词条占整个汉字词条约70%5]以上，同时假设汉字词长度2、3、4的词条个数比例为7：2：1，因此，大约90%的情况下，执行两次检索便能定位一个汉字词条，以保证较高的分词效率。同时为减少磁盘I/O，在系统启动时，将词库载入至内存，使所有计算可在内存中进行，进一步提高分词效率。根据《中国大百科全书》目前收录约6 000万个词条为例，整个中文词库大约适用300MB～400MB内存，因此，常见的主机可满足其硬件需求。

3.2 搜索算法

随着软件测试项目的日益增加，测试用例复用库不断扩充，这势必会影响到搜索的效率。本文中，当接收到用户的查询输入，程序首先将其与分词词库进行匹配，对查询输入进行分词，然后根据被测软件的行业领域，查询对应领域的测试用例数据，并且根据排序算法对查询结果进行排序。由于该分词算法仅用于测试用例查询，因此对于中文分词算法中歧义词的处理可以忽略不计，其伪代码如下所示：

由于词库在初建之时，未必能覆盖所有中文词条，并且随着各个行业的高速发展，每天都可能会有新词条出现，因此必然存在无法匹配的词条。当出现新词时，分词算法将自动定位到下一个可匹配词条，然后继续进行拆分，而新词则被单独作为一个分词加载至分词结果中。同时存储该用户输入，待管理员进行审核，人工加入到词库中。采用人工添加新词而非程序自动添加新词的原因在于，程序还不够智能，也无意义做到足够智能，同时对于新词的理解或判断的正确率远低于人判断的正确率。

3.3 结果排序

针对测试工程师进行测试用例的复用查询，其查询结果可能是几条，也可能是几十条，甚至是几万条数据，然而并非所有查询到的测试用例都是查询者所需要的，当查询结果数量庞大时，逐条查看筛选所消耗的时间可能早已超过了重新设计一个测试用例所需的时间，必然导致时间成本上的浪费，这与测试用例复用的初衷相违背。由此可见，根据查询到的测试用例与用户所需测试用例的相关性，为用户推荐一个“好”的测试用例是十分必要的。

可复用测试用例的查询结果的排序可以为用户提供选择测试用例的依据，针对查询主要针对教育期刊网

关键词 的搜索，因此对查询结果中的测试用例按照一个三元组方式排序，其中K表示搜索的教育期刊网

关键词 集合，ki是该教育期刊网

关键词 集合中的某个教育期刊网

关键词 ，则排序三元组表示如下：

C(ki)表示当前查询结果中是否有与ki匹配的教育期刊网

关键词 ，如有，则C(ki)记为1，如没有，则C(ki)记为0。

C(ki)是K中每个教育期刊网

关键词 在本次查询中是否匹配的计数之和，始终大于0，因为查询结果中显示的是至少有一个查询关键字匹配的搜索结果。S(ki)表示当前查询结果中教育期刊网

关键词 ki出现的频次。S(ki)是K中每个教育期刊网

关键词 在本次查询中出现频次之和。Creuse则表示查询结果中该条测试用例被复用的次数。

通过上述三元组对测试用例的查询结果进行排序。首先按照C(ki)列进行降序排序，若该列数值相同，则按S(ki)列进行降序排序，若此列数值相同，则按Creuse列进行降序排列。由此可以发现，查询关键字匹配越完全，其满足查询需求的程度就越高，同时，复用次数越多的测试用例，越具有通用性。

4 总结

软件测试用例设计 篇7

使用人工和自动化手段来测试或运行某个系统的过程,其目的在于检验它是否真的满足规定的需求或者是明确预期结果与实际结果之间的差异。

2 测试用例的定义

测试用例是为特定的目的而设计的一组测试输入、执行条件和逾期结果。测试用例是执行的最小实体。

3 测试用例的特征

(1)最有可能发生的错误;

(2)不是重复的、多余的;

(3)一组相似测试用例最有效的;

(4)不要太复杂;

(5)可复用。

4 测试用例设计的原则

(1)全面性原则。覆盖所需要测试的功能点,要想达到覆盖面比较全,首先要对测试产品全面了解,并且明确测试范围,即明确不需要测试的内容和需要测试的内容。

(2)单个测试用例覆盖最小化的原则。假如要测试一个功能Y,它有三个子功能Y1、Y2和Y3,可以用下面两种方法来设计测试用例。

方法1:用一个测试用例覆盖三个子功能-Test_Y1_Y2_Y3。

方法2:用三个单独的用例分别来覆盖三个子功能-Test_Y1,Test_Y2,Test_Y3。

方法1适用规模较小的工程,但有规模和质量要求的项目,方法2则是更合适的选择,因为它具下面几个优点:测试用例的覆盖边界定义更明确;测试结果对产品问题的明确指向性更强;测试用例间的耦合度最低,彼此之间的干扰也就越低。

以上3个优点带来的直接好处是测试用例的调试、分析和维护成本是最低的。每个测试用例应尽可能简单,只验证所需要验证的内容,否则只会增加测试执行阶段的风险,还会带来彼此之间的干扰。此外,覆盖功能点简单明确的测试用例,便于组合生成新的测试,如在Visual Studio中引入了Ordered Test的概念。

(3)测试用例替代产品文档的功能原则。在开发软件产品的初级阶段通常是用Word文档的形式来记录产品的需求描述、功能描述和功能的具体细节等信息,来描述未来要实现产品的功能,便于团队进行交流,并且在团队内部达成对产品功能和细节的共识。假设在这时达成的共识并描述的功能是B,随着产品开发进程的深入,团队成员对产品的功能有更新的认识,产品功能也会变得更具体细化,在一个迭代或者Sprint结束时最终实现的功能很可能是B+。如此反复,在不断接纳用户的反馈,多个迭代过后,原本被描述为B的功能很可能最终变为了C。这时再去看曾经的Word文档和One Note页面,它们仍然记录的是B。之所以会这样,是因为很少有人会去以及能够去不断更新那些文档,以准确反映出产品功能当前准确的状态。

产品代码和测试用例能够准确描述产品的功能细节。产品代码实现了产品功能,且准确描述了产品的功能,但是,由于各种编程技术,如面向对象、抽象技术、设计模式、资源文件等,使得产品代码本身很难读懂,所以,往往是在知道产品功能的前提下去读代码,而不是反过来看代码来了解功能。目前来看测试用例能如实反映产品功能,测试执行也如实反映了产品功能,否则测试用例就会执行失败。所以,对测试用例的理解应再上升到另一个高度,测试用例能够体现产品描述文档的功能。所以,要求编写的测试用例足够详细、测试用例的组织要有条理,这些单靠Word、Excel或者One Note这样通用的工具是无法实现的,需要使用专业的测试用例管理工具来辅助,例如,Mercury Interactive公司生产的企业级测试管理工具Test Director。

对于自动化测试用例而言,代码在编写上应有别于产品代码编写风格,可读性和描述性应是重点考虑内容。在测试代码中,可以引入面向对象、设计模式等优秀的设计思想,但是一定要适度使用,通常面向过程的编码方式更利于组织、阅读和描述。

5 测试用例的设计方法

5.1 等价类划分法

等价类划分法是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的常用的黑盒测试用例设计方法。

在进行测试用例设计时,要同时考虑有效等价类和无效等价类,这样能使软件接受合理的数据,验证合理的功能,也要经受住不合理的意外考验,增强程序的容错能力,确保软件的测试具有更高的可靠性。

有效等价类:是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类:与有效等价类的定义相反,无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能有多个。

5.2 边界值分析方法

边界值分析方法是对等价类划分方法的补充,也是黑盒测试方法之一,是对等价类分析方法的一种补充。

在测试工作中得出的经验证明,大量错误发生在输入或输出的边界值上,所以,设计各种边界值的测试用例,可以发现更多BUG。

使用边界值分析方法设计测试用例,首先应确定边界情况,通常输入或者输出等价类的边界,着重测试的边界情况,应选取正好等于或者略大于或者略小于便界的值作为测试数据,而不是选择等价类中的典型值或者任意值作为输入数据。

基于边界值分析方法选择测试用例的原则如下:

(1)如果输入条件规定了值的范围,则应取刚达到这个范围边界的值,或者刚刚超过这个范围边界的值作为测试输入数据;

(2)如果输入条件规定了值的个数,则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据;

(3)根据规格说明的每个输出条件,使用前面的原则;

(4)根据规格说明的每个输出条件,应用前面的原则;

(5)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例;

(6)如果程序中使用了一个内部数据结构,则应选择这个内部数据结构的边界上的值作为测试用例;

(7)分析规格说明找出其他可能的边界条件。

5.3 案例

以计算三角形面积的程序为例,运用基本的测试用例设计方法灵活设计测试用例。

某程序需要实现如下功能:输入3个整数D、E、F,输出D、E、F为三边的三角形面积(1<=D、E、F<100),结果保留2位小数。

分析:可以运用等价类和边界值的方法,编写测试用例,具体分析见图1:

根据上面的分析,设计出计算三角形面积测试用例,见表1:

6 结语

影响软件测试的因素很多,如软件的复杂度、团队成员的素质、测试方法、测试技术等。因为某些客观因素存在,有些因素是波动的、不稳定的,会影响测试者的情绪,这种情况下测试用例在软件测试中发挥重要的指导作用。只有理解测试用例的设计原则、设计方法,和具体业务相结合,设计出合理的、高覆盖率、高容错率的测试用例,测试用例才能更好地规范测试执行人员对软件产品进行测试,使软件产品质量得到保障,人们才能使用到高质量的软件产品。

摘要：随着科技的发展,电脑、手机等电子产品的普及,软件的应用越来越普遍,软件测试的重要性得到越来越多的关注。软件产品的测试质量如何保障,重点还是在软件的测试用例设计上,软件测试用例设计的合理性、覆盖率和容错能力,决定了软件产品本身的质量。基于此,介绍了软件测试的基本概念、软件测试用例设计的原则和软件测试用例设计几个基本方法。

关键词：软件测试,测试用例设计,等价类划分法

参考文献

[1]郑人杰.计算机软件测试技术[M].北京:清华大学出版社,1992.

UML用例图总结 篇8

用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。

用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)

包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

2、扩展(extend)扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。对于一个扩展用例，可以在基用例上有几个扩展点。

例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

4、泛化(generalization)泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。

*****************************************************************

(1)系统整体用例图

(商品用例图)

（购买信息用例）

(用户资料用例)

按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!

转：UML中扩展和泛化的区别

泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：

●泛化侧重表示子用例间的互斥性；

●包含侧重表示被包含用例对Actor提供服务的间接性；

●扩展侧重表示扩展用例的触发不定性；详述如下：

既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：

⒈无条件发生：肯定发生的；

⒉有条件发生：未必发生，发生与否取决于系统状态；

因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。

ATM(自动取款机)的用例图 篇9

参与者“银行储户”和ATM机。简化后的ATM机仅有取款、存款及其余功能。其余功能不做详细说明。

银行储户在ATM机上完成取款、存款及其他业务。类图

图2所示的银行系统类图和图5是类似的，只是将工作人员换成了ATM。整个银行系统包括了帐户库、银行储户库及ATM系统。

许多单个的帐户组成了帐户库。帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。

setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。

getType获取帐户类型，返回类型为char，无参数。

setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。

getAccountNumbe获取帐户号，返回类型为int，无参数。

caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。

getBalance获取帐户余额，返回类型为double，无参数。

许多银行储户组成了储户库。ATM系统包含了许多ATM机。银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。同样对于一个真正的银行系统，这个类图过于简单。比如帐户类型我们可以先定义一个abstract class，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract class，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。

图2 银行系统类图 顺序图

图3描述了顾客在ATM机上取款时信息的流动情况。以时间为顺序。因为仅是示例，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。

通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个“X”，这是因为这个流程中还未遇到有对象生命结束。当有对象生命结束时需在对应的生命线终端画“X”，表明这个对象在这时被销毁。

首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来…..因为这个顺序图较长，且很清晰，即便是初学者也很容易读懂，在此就不对本图做过多的解释。

图3 ATM取款顺序图状态图

图4描述了顾客在ATM机上进行操作会经历的几种状态，及各种状态之间转换的条件。因为是简化了的例子，所以除了等待顾客插入磁卡的起始状态和结束服务的终止状态，顾客会处于输入密码、选择服务类型、存款及取款四种状态。

图4 ATM状态图

插入磁卡后进入输密码状态，当密码输入正确时进入选择服务类型状态，当输入密码不正确时，停留在原状态，但如果三次不正确，服务结束。进入选择服务类型后根据选择的不同，顾客可进入存款和取款状态。存、取款结束后，顾客既可以选择结束服务到最终状态，也可以选择继续服务回到选择服务类型状态。

通过状态图我们可以无歧义的了解各个活动角色是如何在不同状况下转换的，转换的条件是什么，是否会出现死锁现象，是否有条件没考虑周全，是否有状态无法达到。状态图可以帮助我们发现问题，并及时改正。活动图

图5参考了Randy Miller的《A Hands-On Introduction for Developers》一文，3图中的客户管理和事物管理对应于5图中的Bank，图3中的读卡机、显示、输入设备及点钞机对应于5图中的ATM Machina，银行储户就是Customer。初看活动图和顺序图表达的意义很接近。但我们可以注意到顺序图着重时间的顺序，而活动图侧重于各部分之间的相互制约，对于一些并行的活动能够有效的表示出来。例如5图中fork和join处，我们可以很清楚的看到一些并行活动的存在。

这个活动图以顾客插入卡为开始，以顾客取卡结束。我们可以看到活动图的重点虽然不在时间顺序，但我们同样可以得到时间的信息。

图5 ATM银行系统活动图 协作图

在第四章中我们知道协作图和顺序图是可以无信息损失的相互转换，只是它们的侧重点是不一样的。顺序图着重于对象间消息传递的时间顺序，协作图着重于表达对象之间的静态连接关系。图6将3图转换为协作图。

1．插入ATM卡

2．接受ATM卡

3．查询密码

4．显示输入密码请求

5．输入密码

6．密码传递

7．请求确认密码合法性

8．确认密码合法性

9．询问服务类别

10．显示输入服务服务类别请求

11．输入取款请求

12．取款请求 13．询问取款数额

14．显示输入数额请求

15．输入取款数额

16．传递取款数额

17．询问取款数额确认

18．显示确认数额请求

19．输入确认

20．传递确认信息

21．数额合法性确认请求

22．确认数额和法性

23．出钞请求

24．计算帐户余额

25．出钞

26．取钞

27．传递余额并询问是否还需要其他服务

28．显示帐户余额并提示选择下面的服务

图6 ATM系统协作图