用例分析技术
用例说明组成部分
用例说明组成部分用例（Use Case）是指对系统功能的需求和行为进行描述的一种方法。
它是一种用于描述和分析系统的技术工具，是需求工程中的重要组成部分。
用例使用文本或图形化的方式来描述系统的功能和行为，从用户的角度来定义系统的功能和行为。
用例由以下几个部分组成：1. 用例名称：每个用例都有一个独特的名称，它应该能够清楚地描述用例的功能。
2. 参与者（Actors）：参与者是与系统进行交互的外部实体，可以是用户、系统或其他外部系统。
参与者可以主动触发系统的功能，也可以被动地接收系统的响应。
3. 主要场景（Main Scenario）：主要场景描述了参与者与系统之间的基本交互流程，以及系统对参与者的响应。
主要场景应该是一个简洁而完整的描述，可以通过步骤或事件的序列来表示。
4. 替代场景（Alternate Scenario）：替代场景描述了在某些条件下，主要场景可能发生变化的情况。
替代场景可以是异常情况、错误处理或可选步骤等。
5. 前置条件（Preconditions）：前置条件描述了在执行用例之前，系统必须满足的条件。
它可以包括一些系统状态、数据准备或其他的先决条件。
6. 后置条件（Postconditions）：后置条件描述了在执行用例之后，系统应该满足的状态或结果。
它可以包括一些状态变化、数据更新或其他的结果。
用例可以帮助系统开发团队和用户之间更好地沟通和理解系统的需求和行为，它可以作为需求规格说明书的一部分，也可以作为系统设计和测试的依据。
用例的编写需要准确地理解用户需求，同时要考虑系统的各种情况和可能的变化。
编写好的用例应该是精确、一致性强、易于理解和修改的。
总之，用例是描述系统功能和行为的重要工具，它能够帮助开发团队和用户更好地沟通和理解需求。
编写好的用例应该准确地描述系统的功能和行为，同时考虑到各种情况和可能的变化。
黑盒测试用例设计技术包括哪些方面内容
黑盒测试用例设计技术包括哪些方面内容黑盒测试是软件测试中的一种重要方法，通过研究软件系统的功能和接口，设计合理的测试用例来验证软件是否符合需求。
在黑盒测试中，测试人员不需要了解软件的内部实现细节，而是关注软件的输入和输出之间的关系。
在设计黑盒测试用例时，需要考虑以下几个方面内容：1.需求分析在进行黑盒测试用例设计时，首先需要深入理解软件的需求规格说明书。
测试人员需要准确理解软件的功能、性能要求和限制条件，以确保设计的测试用例覆盖了所有的功能需求。
2.边界值分析边界值分析是黑盒测试中常用的一种技术。
通过测试软件在输入值的边界情况下的表现，可以有效发现潜在的错误。
在设计测试用例时，需要考虑参数的边界值、极端情况以及非法输入等情况。
3.等价类划分等价类划分是一种测试用例设计技术，将测试数据划分为等价类，每个等价类的数据具有相同的影响，只需使用一个测试用例来代表整个等价类。
通过等价类划分可以减少测试用例的数量，并提高测试效率。
4.因果图因果图是用来描述软件功能与输入之间的逻辑关系的图形工具。
通过绘制因果图，可以帮助测试人员理清软件功能之间的关系，从而设计出覆盖全面的测试用例。
因果图通常用于复杂系统的测试用例设计。
5.决策表决策表是一种描述软件系统中条件和结果之间关系的工具。
通过对决策表的分析，可以设计出全面的测试用例来覆盖不同的条件组合。
决策表通常用于有复杂条件判断的软件系统测试中。
总结在进行黑盒测试用例设计时，需要综合考虑需求分析、边界值分析、等价类划分、因果图、决策表等多种技术。
设计合理的测试用例可以有效提高测试的覆盖率和效率，帮助发现潜在的软件缺陷。
通过不同的技术手段结合使用，可以设计出全面而有效的黑盒测试用例，从而保证软件的质量和稳定性。
测试用例的设计技术有哪些内容
测试用例的设计技术有哪些内容测试用例的设计技术是软件测试中非常重要的一环，它直接影响到测试的覆盖率和测试效果。
在测试用例的设计过程中，我们需要考虑多种因素和技术，以确保测试用例的全面性和有效性。
下面将介绍一些常见的测试用例设计技术。
1. 等价类划分法等价类划分法是一种常用的测试用例设计技术，它将输入域划分为多个等价类，并从每个等价类中选取一个典型值作为测试用例。
这样可以有效地减少测试用例的数量，同时覆盖到不同的等价类。
2. 边界值分析法边界值分析法是一种基于输入域的测试用例设计技术，它主要关注输入域的边界值。
通过选取输入域的边界值作为测试用例，可以更好地发现输入域的异常情况。
3. 判定表方法判定表方法是一种基于决策表的测试用例设计技术，它将软件的决策规则表示为一个判定表，并根据判定表来生成测试用例。
这种方法可以有效地覆盖到不同的决策路径，提高测试的效果。
4. 状态转换法状态转换法是一种基于状态机的测试用例设计技术，它将软件系统的状态和状态之间的转换关系表示为一个状态转换图，并从图中选取测试用例。
这种方法可以覆盖到不同的状态和状态转换路径。
5. 错误推测法错误推测法是一种基于错误假设的测试用例设计技术，它假设软件系统中可能存在的错误，并据此设计测试用例。
这种方法可以帮助测试人员主动发现软件系统中的潜在问题。
6. 场景法场景法是一种基于用户场景的测试用例设计技术，它以用户的使用场景为基础，设计测试用例。
这种方法可以更好地模拟用户的实际使用情况，提高测试的真实性和有效性。
7. 成对测试法成对测试法是一种基于组合测试的测试用例设计技术，它将可能的输入值组合成不同的测试用例，并进行测试。
这种方法可以有效地发现输入值之间的交互问题。
8. 正交试验法正交试验法是一种基于正交表的测试用例设计技术，它根据测试目标和测试需求，选取合适的正交表，并从表中选取测试用例。
这种方法可以有效地减少测试用例的数量，同时覆盖到不同的测试需求。
软件测试用例设计的有效性分析
软件测试用例设计的有效性分析软件测试是保证软件质量的必要步骤之一，而测试用例设计是软件测试中最关键的部分之一。
一个有效的测试用例设计可以提高软件测试的效率和准确性，确保软件在不同场景下的正确性和可靠性。
本文将对软件测试用例设计的有效性进行分析，并探讨如何提高测试用例设计的质量。
1. 测试用例设计的定义测试用例设计是根据软件需求和设计规格，针对各种功能和场景，设计出一系列具体的测试用例。
测试用例应该具备完整性、可行性、准确性等特点，旨在全面检验软件的各个功能和性能。
2. 有效性分析的重要性一个好的测试用例设计应该是有效的，即能够发现大部分软件中的缺陷和问题。
有效的测试用例设计可以帮助测试团队更全面、更准确地评估软件的质量，并提供有价值的反馈给开发团队。
3. 提高测试用例设计有效性的方法3.1 全面理解软件需求和设计规格测试人员应该对软件的需求和设计规格进行全面理解，确保测试用例能够覆盖到所有的功能和场景。
同时，还应该根据软件的具体特点，设计出不同类型的测试用例，包括正常情况下的输入、边界情况下的输入、异常情况下的输入等。
3.2 使用适当的测试技术测试人员应该合理选择测试技术，根据软件的特点和需求，设计出合适的测试用例。
常用的测试技术包括等价类划分、边界值分析、因果图等。
这些技术可以帮助测试人员更有针对性地设计测试用例，提高测试效果。
3.3 设计可重复执行的测试用例一个好的测试用例应该是可重复执行的，即能够反复执行并获得相同的结果。
为了确保测试用例的可重复性，测试人员应该考虑到测试环境的稳定性和一致性，以及测试数据的准确性和可控性。
3.4 设计易于维护的测试用例测试用例的维护也是测试用例设计的一个关键考虑因素。
测试人员应该设计易于维护的测试用例，即能够随着软件的迭代和升级，方便地进行修改和扩展。
4. 测试用例设计有效性评估指标为了评估测试用例设计的有效性，可以考虑以下指标：4.1 覆盖率指标：包括代码覆盖率、功能覆盖率、场景覆盖率等。
软件测试用例技术发展分析及对策
软件测试用例技术发展分析及对策1. 引言随着信息技术的飞速发展，软件在人们生活和事务中所扮演的角色越来越重要。
然而，软件中的缺陷与错误是不可避免的，因此软件测试成为了软件开发过程中不可或缺的一部分。
测试用例是软件测试的关键组成部分之一，它们通常用于描述期望软件执行的行为并验证其实际行为是否符合预期。
软件测试用例技术作为软件开发和测试的重要方法，不断发展并逐步完善，但难免存在一些问题和挑战。
本文将对软件测试用例技术的发展历程进行分析，并提出相应的对策以应对当前的挑战。
2. 软件测试用例技术发展历程测试用例是验证软件是否正确执行的关键工具。
随着软件复杂性的增加，测试用例技术也在不断进化。
测试用例技术的发展历程主要可分为以下几个阶段。
2.1. 手工编写测试用例早期的软件测试用例是手工编写的。
该方法的优点是可以针对软件的特定需求编写测试用例，并能够详细描述期望的软件执行结果。
然而，手工编写测试用例需要大量的时间和劳动力，并容易受到测试人员的主观因素影响，测试效率和效果有待提高。
2.2. 生成测试用例为了解决手工编写测试用例的缺点，自动化测试工具被研发出来。
自动化测试工具可以快速生成测试用例，并帮助测试人员快速执行测试。
该方法大大提高了测试效率和准确度，但需要投入大量的资金和资源来实现自动化测试。
2.3. 模型驱动测试用例通过对软件进行分析和建模，测试人员可以更准确地预测软件的行为，并生成自动化测试用例。
模型驱动测试方法可以减少测试用例的数量，提高自动化测试效率和准确度，但对测试人员的技能和经验要求较高，测试人员需要对软件的架构和模型进行充分的理解和掌握。
2.4. 数据驱动测试用例数据驱动测试用例是根据不同输入数据生成不同的测试用例。
这种方法基于可重用的测试数据生成测试用例，可以减少测试用例数量，并且测试结果更加准确。
2.5. 基于语义的测试用例基于语义的测试用例利用自然语言语义解析技术，从自然语言文本中提取测试用例。
实验1利用黑盒测试技术设计测试用例分析
14级本科《软件测试技术》实验指导书实验1 利用黑盒测试技术设计测试用例【实验目的】1、熟悉并掌握黑盒测试的方法：等价类划分法、边界值分析法、错误推测法、场景法。
2、了解待测的功能，灵活应用黑盒测试方法中的等价类划分法、边界值分析法、错误推测法以及场景法，设计测试用例，掌握正面测试和负面测试。
【实验内容】【1】应用等价类划分法进行测试。
用户注册功能，要求用户密码必须满足两个条件：长度为6到8位。
必须是字母和数字的组合。
（1）请分析等价类，填写表1-1。
表1-1 等价类表输入条件有效等价类编号无效等价类编号用户密码大于6小于8 1 小于6位 22 大于8位 3字母和数字的组合 4 全为数字 5全为字母 6 （2）根据表1-1的等价类设计测试数据，填写表1-2。
表1-2 根据等价类划分法设计的测试数据序号输入数据覆盖等价类预期结果1 abd3211 1,4 有效2 12345 2,5 无效3 Abcdf 2,6 无效4 Shg96 2,4 无效5 Sjdgjsdjhskjfh646 3,4 无效【2】应用等价类划分法和边界值分析法进行测试。
在教务系统中进行课程成绩录入，要求0≤成绩≤100，且成绩为整数。
（1）请分析等价类，填写表1-3。
表1-3 等价类表输入条件有效等价类编号无效等价类编号输入成绩大于等于0小于等于1 小于0 2100大于100 3为整数 4 不为整数 5 （2）根据表1-3的等价类设计测试数据，填写表1-4。
表1-4 根据等价类划分法设计的测试数据序号输入数据覆盖等价类预期结果1 60 1,4 有效2 100 1,4 有效3 59.9 1,5 有效4 101 3,4 无效5 -1 2,4 无效（3）根据边界值分析法设计测试数据，填写表1-5。
表1-5 根据边界值分析法设计的测试数据序号输入数据预期结果1 100 有效2 0 有效3 110 无效4 -5 无效【3】应用场景法进行测试。
系统用例分析
系统用例分析软件开发是一个复杂且多样化的过程，通常需要许多团队成员共同合作。
软件工程师们使用许多不同的方法和工具来帮助他们设计、构建和测试软件系统。
其中一个关键的步骤是系统用例分析，这是一个用于确定软件系统功能需求的过程。
什么是系统用例分析？系统用例分析是软件开发过程中的重要组成部分，其主要目的是帮助开发团队理解系统中的各种行为和功能。
它通过创建系统用例来定义和描述系统的功能需求，以及系统与用户之间的交互。
系统用例是对系统功能的一种描述，它以用户的角度来描述系统的各种操作和行为。
系统用例分析是通过许多不同的方法和工具来完成的，其中包括用户需求收集、场景建模、用例建模等。
通过这些方法和工具，开发团队可以更好地理解用户的需求，为他们提供满意的软件系统。
系统用例分析的重要性系统用例分析在软件开发过程中起着关键的作用。
它帮助开发团队理解用户的需求和期望，并将其转化为具体的系统功能。
下面是系统用例分析的一些重要性：确定系统功能需求系统用例分析帮助开发团队明确系统的功能需求。
通过系统用例，团队可以了解到软件系统需要实现的各种功能、操作和行为。
这有助于开发团队设计和实现出适合用户要求的软件系统。
理解系统与用户之间的交互系统用例分析还可以帮助开发团队更好地理解系统与用户之间的交互。
通过用例分析，团队可以了解到用户如何与系统进行交互以及系统对用户输入的响应。
这有助于团队设计出用户友好且易于操作的系统界面。
识别系统的边界和限制系统用例分析还有助于开发团队识别系统的边界和限制。
通过用例分析，团队可以确定系统所能支持的参数范围、输入和输出限制等。
这有助于团队设计出鲁棒性好、安全性高的软件系统。
清晰定义开发团队的工作范围系统用例分析可以帮助开发团队清晰地定义他们的工作范围。
通过用例分析，团队可以明确各个功能模块的职责和功能，避免工作重叠和方向混乱。
这有助于团队更高效地组织和管理软件开发过程。
系统用例分析的步骤系统用例分析是一个复杂而多步骤的过程。
浅谈测试用例分析和设计
浅谈测试用例分析和设计测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据。
下面我们来浅谈下测试用例的分析和设计过程。
一、测试用例分析阶段测试用例设计的基础文档是需求文档，如果测试人员能拿到一份完整的准确的需求文档，那么对测试人员来说，工作量可以减轻大半，工作效果会大幅提高。
但是我们在需求分析阶段，即便是在需求评审之后，我们拿到的需求文档，仍然是存在一些疑义的或者是分析不透，表达不清的一些需求文档。
这样的时候，测试人员是否有自己的分析方法，显得尤为重要。
测试人员对付需求文档，从操作策略上来说，可以从以下两点出发：（一）、对于需求规格全面、完整的需求文档来说，我们可以采取“切割策略”，把需求按一定的粒度进行分解，来编写测试用例。
（二）、对于简单不全面、需求规格含糊的需求文档，我们可以采取的策略：“联想策略”。
这点还是主要来自工作经验及对该行业的理解，把一些含糊的内容补充起来。
在参与需求文档阅读的过程中，我们还可以采用一些小方法，把需求吃透。
例如：1、在参与需求阅读的过程中，我们可以把需求中的一些边界或者异常的情况列出来，这些往往是以后bug的多发地带。
2、对于需求文档中的一些隐式缺陷，我们需要补充清楚质量属性，例如一些安全性、性能、UI等的一些质量属性内容，我们需要补充清楚。
3、对需求文档的阅读，我们还可以采用一些工具：思维导图工具及UI界面设计工具，把图给画出来，有助于我们理解需求，找到测试点。
例如思维导图工具，通过名词+动词的方法，可以把测试数据和操作动作列出来，有利于理清测试的要点。
通过以上的一些策略和方法，我们大致上可以把需求测试分析做的比较到位了。
测试人员对需求文档分析后，接下去还需要对设计文档进行分析，大部分的测试人员，不是太注重开发组的这份设计文档，觉得与己无关，其实，理解设计文档，有利于降低我们的测试规模，降低劳动负荷。
一般来说缺陷会与内部结构映射，如果你了解了代码的结构，一般来说，我们都可以找到缺陷出现的真正原因了。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
11
动作
• 是一个计算程序或算法程序，在参与者或 系统得到一个事件时被调用。
• 动作是原子的，或是执行全部动作或是根 本不执行。
• 动作中不能由操作者打断。 • 一个动作的完成意味着将某种信号传递给
调用动作的参与者。
12
动作序列
• 应该清楚地说明用例的事件流，让外行 也能很容易地理解它。
• 用例事件流最终要描述所有可能的过程 。
• 事件流应该说明系统做什么，而不是说 明为了执行所需的行为而对系统进行的 设计。
26
事件流
• 用例的事件流从系统的黑盒视角描述了系 统的行为，而在设计中的用例实现则是白 盒视角。
• 三种事件流可以将一个用例中的各种状况 包括在内
• 用例提供了一种大部分项目相关人员都能理解的 形式来表述问题。
• 用例确实是需求，但用例不是所有的需求。 • 用例只是行为需求，外部接口、数据格式、业务
规则、计算公式等是用例行为需求的聚集。
6
用例是软件开发过程的基础
• 用例通过定义由系统执行的行为提供了要 开发的软件可视化的线索。
• 用例驱动的软件开发过程中，为系统定义 的用例是软件开发过程的基础。
查询余额
修改密码
余额不足
退卡
24
情景或场景
• 不可能在每个不同的用例中表示每一条可 能的事件流。
• 我们希望将一个用例的所有事件流结合成 组，分组定义一个用例类，用例类的对象 就是一个实例，这个实例是一个特定的事 件流或一个特定的路径。
• 用例类的实例也称为情景或场景。
25
用例事件流
• 用例事件流包含用例建模工作所得到的 最重要的信息。
ATM机
环境： 学校 操作者:学生
ATM机 环境：北京王府井 操作者:购物者
17
ATM机用例图
• 银行客户可以通过使 用自动取款机提款、 查询帐户余额、修改 帐户密码。
• 这些功能可以通过一 组用例表示出来。
• 用例名称通常可以表 达提供给参予者的价 值。
18
用例
19
用例的概念
• 用例可以用来捕获系统的 需求，尤其是交互系统的 需求。
S2: 客户输入六位密码并以确认键完成密码输入。 系统验证密码，如果密码正确执行S3。
S3: 系统提示操作功能菜单供用户选择其中一种操作 (<取款>或<查询余额>或<退出>)
S3.1:客户选择<退出>功能键时，转向执行S6。
37
取款用例描述(3)
S4: 客户选择<取款>操作后，系统提示客 户输入<取款数额>(条件:50元的整倍数)
32
前置条件和后置条件
利用前置条件和后置条件 的概念来阐明事件流如何 开始和结束是一种非常有 用的方法。 前置条件是开始用例前所 必需的系统及其环境的状 态。后置条件是用例结束 后系统可能具备的状态。
前置条件
后置条件
33
用例描述模板属性
• 用例编号 • 创建人 • 创建日期 • 版本号 • 主要参与者 • 次要参与者 • 简要描述 • 触发事件 • 前置条件
29
事件流的结构
• 异常事件流是很少发生的特征行为。 • 异常事件流虽然很少发生，而且也很难预测，但
是一旦发生则会成为一种系统的缺陷,甚至对系统 造成很大的危害。
30
事件流的典型结构。直线箭头代表基本事件流，而曲线则代表与正常行 为相关的备选事件流。有些备选路径返回到基本事件流，而其他备选路
径则结束此用例。
• 主事件流 (基本路径) • 备选事件流(可选路径) • 异常事件流(缺陷路径)
27
事件流
• 可以将用例的事件流捕获为该用例动作序列的单 独文本描述。
• 事件流规定了在执行确定的用例时系统要完成的 工作。还规定了执行用例时系统如何与参与者进 行交互。
• 一个事件流描述包括一个动作序列的集合，该动 作序列适于修改、评审、设计、实现和测试。
。
4
用例是描述交互行为的一种方法
• 人类社会的对象之间交互需要计算机的帮 助。
• 计算机是社会对象之间交互的一种工具， 利用它去尽量模拟真实的社会。
• 用例是描述人类社会对象之间交互行为的 一种方法。
5
用例是捕获需求的一种方法
• 用例通常作为一种捕获需求和对已知功能需求进 行建模的方法而被使用。
其它状态。 • (在新的状态)等待由参与者发出的另一个外部消
息。 • 再次由新消息所激发，依次类推，可能经过许多
状态(状态图)直到用例实例结束。
14
系统执行
• 系统是我们的研究对象；参与者与之交互 ，用例定义了这些交互作用。
• 我们关心系统要做些什么才能完成动作序 列，用例帮助我们限定系统的边界(范围)
用例分析技术
1
用例分析技术
• 用例概念 • 用例 • 用例图
2
用例概念
3
用例的交互概念
• 人类的社会是社会对象之间交互的社会。 • 社会对象之间的交互使社会充满活力。 • 交互产生运动、摩擦和阻力，所以还需要
能量。 • 最终消耗能量的运动产生新的有价值的结
果(产品)。 • 现代社会对象之间的交互主要是信息交互
• 并适合作为用户手册中的一节或一小节来描述。
28
事件流的结构
• 事件流的两个主要部分是基本事件流和备选事件 流。
• 基本事件流应包括在执行用例时“通常”会发生 的事件。
• 备选事件流包括与正常行为相关的可选或较少发 生的特征行为，同时也包括正常行为的各种变形 。
• 可以将备选事件流看作是基本的“绕行道”，有 些备选事件流将返回到基本事件流，而有些事件 流将结束此用例的执行。
21
事件流
• 事件流描述了参与者与系统之间的动作序 列，它用自然语言写成，或者用含有精确 术语的前后一致的散文写成。
• 这些术语通常来自于问题域中的术语表。 • 用例事件流最终要描述所有可能的过程。
22
用例实例的事件流
• 一系列动作实际上是贯穿整个系统的某个特定事件流，即一个实例。 • 可能会有许多事件流，而许多事件流可能非常相似。 • 为了使用例模型便于理解，应该将相似的事件流组合到一个用例中。 • 确定和说明某个用例实际上就是确定和说明一组相关的事件流。
• 可选事件流: S1.1:系统验证灵通卡或牡丹卡的ID号，ID号不正确，系
统提示<请您去办卡行换卡>后，转向S6。 S2.1:客户输入四位或六位密码并以结束键完成密码输
入。系统验证密码，密码不正确，系统将再次提示 客户<输入密码>。 S2.2:客户再二次输入密码,如果密码正确执行S3。 S2.3:客户再三次输入密码不正确，系统进行吞卡操作后 将ATM机转入待机状态。。
15
有价值的可见结果 • 动作序列一定要产生对系统的参与者
有价值的结果 • 可见结果表达了交互的作用 • 重视价值可确保用例的适度性 • 可确保用户理解用例的粒度水平。
16
特定的操作者
• 重视特定的操作者可帮助我们 分隔提供给系统某一组特定用 户的价值,确保系统满足它们 的需要。
• 任何软件产品都面向软件产品 的操作者和一些特定的操作者 以及这些操作者的不同的使用 环境，重视不同的操作者以 及它们不同的使用环境可确 保软件产品的价值。
39
取款用例描述(4)
• S5.1:客户帐户余额不足时，系统提示<您的帐户 余额不足>后转向S6。
• 例外:无 • 非功能性需求:客户与系统交互的平均等待时间不
得大于15秒。 • 假设:无 • 备注:无 • 补充规格说明书:无 • 修改历史:无
40
END
41
23
用例实例的路径
• 一个用例具有许多可能的实例 。
• 一个用例实例几乎可以遵循无 限多的路径，但这些路径仍然 可以计数。
• 路径代表了用例事件流说明中 的用例实例可以选择的各种方 案。路径的选择取决于事件。
• 事件类型包括：
• 来自主角的输入。例如，主角 可以从几个选项中决定下一步
应该做什么。
扦卡 取款
31
有关事件流的内容
• 说明用例如何开始和结束 • 说明在主角和用例之间交换的是什么数据 • 不要详细描述用户界面 • 说明事件流，而不只是功能。为了做到这一点，每个动作
都应从“当主角... 时”开始 • 只说明属于该用例的事件，而不是发生在其他用例中或系
统外部的事件 • 避免不明确的术语，如“例如”、“等等”和“信息” • 详细说明事件流，即回答所有包含“什么”的问题。 • 测试设计人员将使用此文本来确定测试用例。
9
用例的定义 • 系统的参与者与系统交互后,由系统所
执行的动作序列,对特定的操作者产生 可以观察到的有价值的结果值。 • 用的定义对于我们捕获需求、用例描 述、用例粒度分析有直接的帮助。
10
参与者(角色)
• 是系统之外与系统能产生交互作用的 某个人或某件事。
• 软件是由人来使用的，操作者使用用 例来完成他的任务，许多任务的集合 代表了操作者的职责。
• 事件流 • 后置条件 • 可选事件流 • 例外 • 非功能性需求 • 假设 • 备注 • 补充规格说明书 • 修改历史
34
ATM机示例
• 客户使用工商银行的ATM机取款或查询余额 。
35
取款用例描述(1)
• 用例编号: 001
• 创建人: 高静
• 创建日期: 2003.4.8
• 版本号:
Байду номын сангаас
01
• 主要参与者: 持有工商银行灵通卡或牡丹卡的客户
• 次要参与者: 无