编写有效用例

1、编写有效用例编写有效用例主讲人：李锟软件需求的质量为何至关重要软件需求的质量为何至关重要常见的软件需求质量问题需求错误需求错误，未能反映出用户使用软件的真正意图。 开发人员按照错误的需求做设计或开发。 测试人员无法对软件进行正确的测试。 用户得到了完全无用的软件。需求过于简略需求过于简略，遗漏了大量重要的信息和细节。 开发人员按照自己的理解（常常是错误的）做设计或开发 测试人员根据从开发人员那里获得的信息开展测试，无法对软件进行充分的测试。 软件bug太多，或者非常难用，用户很不满意。大多数软件项目失败的原因，是因为需求质量方面的问题，而不是技术方面（设计、编程、测试、运维）的问题。需求质量低

2、下，无论传统的瀑布式开发过程，还是敏捷迭代式开发过程，都无济于事。软件需求的质量为何至关重要软件需求的质量为何至关重要软件的价值由其是否对用户有用、能否解决用户想要解决的问题来判断。需求质量低下，导致软件无法解决用户想要解决的问题，只得被用户抛弃。公司的业务无法顺利开展，甚至被迫倒闭。需求质量很高，即使在技术方面存在问题，开发出的软件对用户仍然是有价值的，可通过改造或重构来改善软件的质量。需求质量很低，开发出的软件对用户无价值，唯一的命运是被抛弃，重构等技术手段无用武之地。改善软件需求的质量，在源头解决问题，成本要比已经完成编程然后再解决低的多。问题发现的越早，解决的成本越低。4软件需求需要解

3、决的主要问题软件需求需要解决的主要问题使用软件的用户有哪些人，这些人可以划分成哪些角色角色？不同角色的用户，具有什么特征？不同角色的用户会使用软件的哪些功能，希望达到什么目目标标（使用软件的意图）？不同角色的用户，在使用软件时，会经历哪些场景？这些场景正常流程正常流程是什么，有哪些异常流程异常流程？为了满足不同角色用户的目标，软件需要实现哪些业务规业务规则则？对软件需求如何来验收，验收通过的标准验收通过的标准是什么？5什么是用例（什么是用例（Use Case）由Ivar Jacobson于1960年代后期在爱立信提出，1980年代后期他将用例引入面向对象编程领域。1994 - 1999年，由A

4、listair Cockburn加以完善。软件工程中做需求定义和分析的主要工具。开发团队开展设计、编程工作的基础。测试团队开展测试的基础。6用例的详细定义用例的详细定义用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。用例描述了在不同条件下，系统对某一项目相关人员的请求所作出的响应。提出请求的项目相关人员被称为主执行者主执行者。主执行者通过发起与系统的一次交互来实现某个目标目标。系统对任一执行者所作出的响应，要保证所有项目相关人员的利益不受侵犯。根据执行者作出的请求和请求涉及的条件，系统将执行不同的行为序列，每一行为序列称之为一个场景场景。一个用例是多个不同场景的集合。7用例的基本

5、形式用例的基本形式虽然可以用流程图、顺序图、Petri网或程序设计语言来表示用例，但是从根本上说，用例是文本形式文本形式的。通常情况下，它们是作为人与人之间，尤其是没有受过专门培训的没有受过专门培训的人员之间人员之间互相交流的一种手段。用例不等于UML中的用例图。用例图是由椭圆、箭头和一些“小人”图符组成，它并不是用来捕获用例的。椭圆和箭头显示了用例的打包和分解，而不是用例的内容。用例本身就是文字的，用例图只是为了帮助读者找到他们所要阅读的文字。用例的基本概念用例的基本概念执行者执行者：任何具有行为的人或物。有时，在一个用例中，它指一个个体。有时，它指担当某个给定角色的一类个体的通称。被讨论系

6、统被讨论系统：本身也是一个执行者一个特殊的执行者，简称系统或SuD。虽然SuD是一个执行者，但它不是任何用例的主执行者或者辅助执行者。主执行者主执行者：启动与被讨论系统的一次交互活动，从而达到某一目标的人或物。对系统来说，它有一个目标系统通过执行操作可以实现该目标。主执行者经常（但不一直）是触发用例的执行者。辅助执行者辅助执行者：为被讨论系统提供服务的外部执行者。它可以是一个高速打印机、一个网络服务或者是必须进行一些调查然后把调查结果反馈给我们的人。用例的基本概念用例的基本概念范围：范围：项目开发人员负责的设计工作的边界，以便与应由其他人负责的设计工作或已经完成的设计工作相区别。功能范围功能范

7、围：是指系统要提供的服务，它最终应被用例所捕获。在识别用例的同时也在决定项目的功能范围这两个任务是密不可分的。 执行者执行者-目标列表目标列表：列举了系统支持的所有用户目标，展示了系统功能方面的内容。 用例简述用例简述：对用例行为所做的一个包含2-6句话的描述，它仅提及了最重要的活动和失败情况。它提示读者用例中正在发生什么事情，对估计工作复杂度很有用。设计范围设计范围：开发人员负责设计和讨论的系统的集合，包括硬件系统和软件系统；它是集合的边界。用例的基本概念用例的基本概念前置条件前置条件：声明在用例执行之前必须满足的条件由于该条件由系统负责实施，并要求确保为真，因此在用例执行过程中，不必再对该

8、条件进行检查。保证保证：声明在用例执行之后必须满足的条件最小保证最小保证：系统向项目相关人员作出的最低承诺，尤其是在主执行者的目标不能被满足的情况下。当然，在目标被满足的情况下它们仍然成立，但是当主要目标被放弃时它们就成为人们真正关心的事情。成功保证成功保证：说明了用例成功结束后项目相关人员的哪些利益得到了满足，用例可以通过执行主场景获得成功，也可以通过执行可选路径获得成功。成功保证通常是作为最小保证的添加内容：最小保证被满足后，并且一些附加条件为真；附加条件中至少包括用例标题中声明的目标。用例的基本概念用例的基本概念触发事件触发事件：指明了启动用例的事件。有时，用例执行过程的第一步紧接着触发

9、事件发生，有时触发事件就是用例中的第一步操作。场景场景：一个操作和交互的序列。在特定条件下发生，在表达形式上不使用条件语句或分支结构。主成功场景主成功场景：一切顺利的情况。是一个完整地描述从触发到完成过程的场景，它包括实现目标的成功交付和开始后的所有记录。场景扩展场景扩展：场景执行过程中出现的不同情况。从另一个场景中的特殊条件开始的一个场景片段。在主成功场景下，因为特别条件而出现的行为分支。大多数场景扩展以重新与主成功场景汇合而结束。实质上是一个从主用例中被拆分的子用例。用例的层次用例的层次 概要级用例概要级用例 包含多个用户目标。 要花费一段时间（几周、几个月或几年）来完成。 用户目标用例用

10、户目标用例 主执行者努力使工作得以完成的目标。或是用户使用系统的目标。 满足对主执行者有价值的一个特殊的或直接的目标。 子功能用例子功能用例 那些在实现用户目标时可能会被用到的目标。 满足用户目标用例或另一个子功能的部分目标。整理用例需要用到的工具整理用例需要用到的工具 UML画图工具 用例图用例图：用来划分用例的目录。 协作图协作图：表达执行者之间的协作关系，突出协作的密度。 时序图时序图：表达执行者之间的协作关系，突出协作的时间顺序。 文本编辑工具 任何文本编辑工具：Notepad+、EditPlus、vim、Word、WPS 在线工具：Redmine、Confluence 优势：便于分享

11、、协作、估算工作量、计划、进度跟踪。整理用例的步骤整理用例的步骤 通过与用户沟通搜集需求。 确定用例的范围。 将用户划分成不同的执行者。 整理执行者-目标列表。 使用用例图来划分用例，每个用例有一个主执行者、多个辅助执行者，描述一个完整的场景。 根据从用例图得到的用例内容目录编写详细用例文字描述。 与相关人员（业务、开发、测试）沟通用例内容，确认用例内容满足了质量要求，并且相关人员在理解上达成了一致。用例主体的组成用例主体的组成 主执行者 范围 前置条件（可选） 触发事件（可选） 主成功场景 场景扩展用例主体的组成用例主体的组成 发生频率（可选） 最小保证（可选） 成功保证 业务规则（可选）

12、项目相关人员和利益（可选）用例的组织用例的组织 一个用例可以划分成多个子用例子用例。 一个执行步骤可以是一个简单的步骤或者另外一个用例（子用例）的名称。 一个子用例可以在多个用例中重用。 一个用例可以包括多个用例扩展用例扩展。 只有在必须的情况下才创建用例扩展，因为这些用例不容易被人们所理解，也不容易维护。编写用例的常见问题编写用例的常见问题 用例的划分方式错误。 粒度过小，一个用例应该至少包括一个完整的主成功场景。 粒度过大，包含多个独立的目标。 用例直接描述界面功能实现 用例应该描述真正的需求，即主执行者的目标，而不应该成为界面功能描述。 界面功能实现是UI团队和开发团队的事情。 未划分执

13、行者，未写明用例的主执行者。 每个用例要有一个主执行者。 仅描述主成功场景，未描述场景扩展。 未描述复杂的业务规则。用例什么时候才算完成用例什么时候才算完成已经命名了与系统相关的全部主执行者及其用户目标全部主执行者及其用户目标。捕获了系统的全部触发条件捕获了系统的全部触发条件，既包括用例触发条件，也包括扩展条件（启动）。编写了所有用户目标用例编写了所有用户目标用例以及必要的概要用例和子功能用例。每个用例描述足够清晰每个用例描述足够清晰，使得：投资方确认他们能够区分这个用例是或不是实际上要提交的用例。用户确认用例表达了他们的要求，或者能接受这些用例作为系统的行为。开发人员确认可以实现所有用例表示

14、的功能。投资方确认用例集覆盖了他们所有的需求覆盖了他们所有的需求。用例与用例与UML的关系的关系 用例图可以对用例起到辅助作用。 用例图中的信息和在执行者-目标列表中的信息是一样的，只是表现方式不同。用例图可以被用作一张目标表。 用例图是一个二维的助记工具，它可以突出用例的相互关系。应该将用例图仅仅用于这个目的，而不是去代替文字描述。 认识到椭圆图符不可能代替文本是很重要的。用例图（有意地）省掉了排序、数据和接收执行者，它可以被用作： 用例的内容目录 系统的语境图，显示出多个执行者正在寻求他们不同的和重叠的目标。系统可能还会涉及到辅助执行者。 一副“大图画”，可以显示高层用例和低层用例的关系。

15、协作图、时序图有助于更深入理解系统的用例。用例与用户故事的区别用例与用户故事的区别 用例更加全面严谨，更加形式化，有很多工具的支持。 用户故事的形式比较自由，非技术背景的人员更容易掌握。 用例的粒度通常比用户故事更大。 用例需要描述一个或多个场景（主成功场景+场景扩展），用户故事只需要描述一个功能点。 用户故事的工作量更容易度量，更容易安排计划。 用例不依赖面对面的沟通，用户故事依赖面对面的沟通。 用户故事可以开展自动化验收测试。 可以采用BDD方式（例如使用Cucumber），与验收测试用例相结合，编写可以自动化验收的用户故事。用例与界面原型的区别用例与界面原型的区别 界面原型已经到了实现层面，是对实现层面软件的一种模拟。 界面原型仅仅是满足用户目标的一种可能的实现方案，但未必是最佳方案。 不应该越过用例的文字描述直接绘制界面原型 容易陷入实现细节，只见树木不见森林。 容易忽视用户使用软件的真正目标。 容易