用例文档(最终版)
用例文档及活动图
活动图
定义活动图
活动图的符号
一个活动图必然有一个开始状态
至少有一个结束状态
转移用来表示活动或状态间的控 制流
有分支时要在分支路径中注明分 支条件
分岔用来开始并行处理 联结用于把并行处理转换为
单个处理
活动图
定义活动图
ATM机“登录”用例的活动图
事件流
事件流描述参与者在完成用例的过程中发生的一系列的交 互行为。
“增加预约”示例
➢ 示例一：“掌上校园” ➢ 示例二：“网络教学平台”
重构用例
如果你对以下问题都回答“是”的话，那么这个用 例就是集中的。否则，这个用例需要拆分为几个小 的
这个用例是否能够带来一个独立的好处？ 你是否可以利用２０个字来描述这个好处，且不用“和”，“与” 参与者是否能够仅通过在一次会话就完成这个用例 你能否想象在一个连贯的测试计划中，这个用例将是一个测试用例
前置条件 参与者启动这个用例之前必须完成的所有用例。
后置条件 包括这个用例对系统所做的所有改变。
部署约束 描述访问这个用例的所有约束
事件流
事件流描述参与者在完成用例的过程中发生的一系列的交 互行为。
一个事件流仅描述用例中的一条路径，不包括其他的分支。
在用例中有三种事件流：
正常事件流：通过描述一切都按部就班时的情况来捕捉用 例的目标。
绩 3. 在记录学生成绩之前，系统需要验证这些成绩是否有效。首先，根据学生信息文件来确认
管
该学生是否选修这门课程，若没有，那么这些成绩是无效的;如果他的确选修了这门课程，再
理
根据课程信息文件和课程单元信息文件来验证平时成绩是否与这门课程所包含的单元相对应， 如果是，那么这些成绩是有效的，否则无效。
如何编写用例文档
如何进行用例建模呢，这里主要分解为三步：1.识别参与者(ACTOR)参与者作为同系统交互的所有事物，它可以是人也可以是其它系统或硬件等。
它不是系统的组成部分，是独立于系统而客观存在的。
其实在确定参与者时可以采用提问的方式来找出来，如谁是系统的主要用户？谁从系统获得信息等等。
而作为BLOG这种软件，这里为了便于分析，将参与者确定为用户(或会员和作者等，一但确定之后，下面的用例描述就要这样使用它们)，同时为了不与域模型中的用户和用户列表有任何模糊上的关联。
这里将域模型中的用户和用户列表更名为用户信息，用户信息列表。
而另一个ACT OR就是系统管理员了，而先前域模型中的系统管理员则相应更名为系统管理员信息。
2.确定用例。
确定用例时IC ONIX方法认为“首先要确定尽可能多的用例，然后不断地编写和改进描述这些用例的文本，在这一过程中，您将发现新的用例和通用情况”。
而确定用例的一个最重要的原则就是它必须同用户手册中的材料密切相关，每个用户和用户指南的各部分之间的关系必须是显而易见的。
从手册出发的原因就是要求开发人员“必须从用户角度来分析和设计系统”。
因为手册内容一般都非常庞大(相关模版在网上获取)，动不动就几十甚至几百页。
而从中归纳出文档所需要的内容必定也是非常繁琐的，但这一步又非常必要。
因为篇幅所限，又因为担心大家偏离本文的思想，所以这里也只有跳过了，大家完全可以在网上找到相关的信息来填充这一空白。
另外识别用例也可以采用提问方式，如每个参与者的任务？系统需要何种输入输出？等（详见“系统分析师设计指南之统一建模语言”）。
在有些书中会使用合并需求（主要是功能性需求，非功能性需求可附加到用例描述中）来获得用例，而进行合并操作的原则也就是生成“可见结果”的过程(这一步因为所做的事情过于繁杂，本文就不再涉略了)，并完成用例命名和绘制用例图。
第1章需求问题
25
业务需求就是系统目标
现状：功能分解盛行的今天，常常会犯“盲人摸象” 的错误，这使得需求太过脆弱，难以经受考验。 目标！目标！还是目标！--系统开发应目标驱动！ 目标是团队唯一的行动纲领。 目标的定义不能够流于形式，应该具有以下特征： 业务导向、可度量、合理、可行。要 注意目标太夸大会浪费资源，目标 太缩小会影响士气。（教堂与小屋） 目标通常就是业务需求！
验、确定、可跟踪的，正确的，可行的和必 要的。
6
需求问题的症状 1
症状：在软件项目中，变更频繁，而且集中出现在 项目的中后阶段。 分析要点： > 变更是对原需求的背离，还是补遗(需求不完整)? > 背离发生在什么方面(流程间/流程内/数据使用…)？ > 这些变更是需求阶段是否可能预见的? > 是否存在无效的变更响应(管理有问题)? 改进方向： > 变更的可预测性需求阶段标识(需求捕获/分析) > 变更渠道单一化、统一化(需求管理)
I E E E软件工程标准词汇表（ 1 9 9 7年）中定义需求为： （1）用户解决问题或达到目标所需的条件或权能（ C a p a b i l i t y）。 （2）系统或系统部件要满足合同、标准、规范或其它正式规 定文档所需具有的条件或权能。 （3）一种反映上面（1）或（2）所描述的条件或权能的文档 说明。 21
22
需求的层次
软件需求包括三个不同的层次 业务需求（ business requirement） 用户需求(user requirement) 功能需求(functional requirement) 软件需求规格说明（ software requirements specification，S R S）中说明 的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说 明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要 的作用。 非功能需求。它描述了系统展现给用户的行为和执行的操作等。 它包括产品必须遵从的标准、规范和合约； 外部界面的具体细节； 性能要求； 设计或实现的约束条件及质量属性。
图书管理系统UML用例文档
读者借到了图书
假设与约束
持非本人借阅证不能借书
非功能需求
无
补充规格说明书
无
优先级
中
业务需求列表
创建人
版本
描述
创建日期
表
用例标识
无
用例名称
还书
创建人
无
创建日期
无
版本
无
用例类型
业务用例
用例描述
读者将图书带到前台进行还书
参与者
读者
图书管理员
触发事件
读者还书
前置条件
读者看完了这本书或者不想看这本书了
假设与约束
B-1系统允许用户重试三次登录操作，超过三次后系统自动结束，不允许用户重试
非功能需求
安全性：密码应该采用加密的方式存储，有关密码的加密算法待定
补充规格说明书
无
优先级
高
业务需求列表
创建人
版本
描述
创建日期
表
用例标识
无
用例名称
超期罚款
创建人
无
创建日期
无
版本
无
用例类型
业务用例
用例描述
读者借书超过一定期限未归还图书需要罚款。
事件流
基本流程
1.用例起始于读者申请注销账户，系统管理员需要删除读者信息
2.系统管理员正确登录该系统
3.系统管理员输入读者信息（D-1）（A-1）
4.系统确认删除该读者信息（A-2）
扩展流程
A-1确认该读者没有未归还图书
A-2保存失败
1.系统显示保存失败
2.系统管理员可以选择再次提交，也可以结束该用例
非功能需求
允许绑定支付宝等支付平台，方便读者超期付款
测试用例模板和例子
测试⽤例模板和例⼦该范例已经包含⼀个测试⽤例的模板。
项⽬/软件技术出⼝合同⽹络申领系统（企业端）程序版本 1.0.25功能模块名Login 编制⼈ xxx⽤例编号-TC-TEP_Login_1 编制时间 2002.10.12相关的⽤例⽆功能特性⽤户⾝份验证测试⽬的验证是否输⼊合法的信息，允许合法登陆，阻⽌⾮法登陆预置条件⽆特殊规程说明如数据库访问权限参考信息需求说明中关于“登陆”的说明测试数据⽤户名=yiyh 密码=1操作步骤操作描述数据期望结果实际结果实际结果测试状态（P/F）1 输⼊⽤户名称，按“登陆”按钮。
⽤户名=yiyh，密码为空显⽰警告信息“请输⼊⽤户名和密码！”2 输⼊密码，按“登陆”按钮。
⽤户名为空，密码=1显⽰警告信息“请输⼊⽤户名和密码！”3输⼊⽤户名和密码，按“登陆”按钮。
⽤户名=yiyh，密码=2显⽰警告信息“请输⼊⽤户名和密码！”4输⼊⽤户名和密码，按“登陆”按钮。
⽤户名=xxx，密码=1显⽰警告信息“请输⼊⽤户名和密码！”5输⼊⽤户名和密码，按“登陆”按钮。
⽤户名=xxx，密码=2显⽰警告信息“请输⼊⽤户名和密码！”6输⼊⽤户名和密码，按“登陆”按钮。
⽤户名=空，密码=空显⽰警告信息“请输⼊⽤户名和密码！”7输⼊⽤户名和密码，按“登陆”按钮。
⽤户名=yiyh，密码=1进⼊系统页⾯。
8输⼊⽤户名和密码，按“登陆”按钮。
⽤户名=Admin，密码=admin进⼊系统维护页⾯。
9输⼊⽤户名和密码，按“登陆”按钮。
⽤户名=yiyh'',密码=1显⽰警告信息“请输⼊⽤户名和密码！”10输⼊⽤户名和密码，按“登陆”按钮。
⽤户名=yiyh，密码=1''显⽰警告信息“请输⼊⽤户名和密按“登陆”按钮。
码=1''户名和密码！”11输⼊⽤户名和密码，按“重置”按钮。
⽤户名=yiyh，密码=1清空输⼊信息测试⼈员开发⼈员项⽬负责⼈3、测试⽤例设计的误区1、能发现到⽬前为⽌没有发现的缺陷的⽤例是好的⽤例：⾸先要申明，其实这句话是⼗分有道理的，但我发现很多⼈都曲解了这句话的原意，⼀⼼要设计出发现“难于发现的缺陷”⽽陷⼊盲⽬的⽚⾯中去，忘记了测试的⽬的所在，这是⼗分可怕的。
25 软件集成测试用例-GJB438C模板
编号：版本：状态：密级：分发号：XX软件集成测试用例编制/日期：审核/日期：标审/日期：会签/日期：批准/日期：XX科技有限公司20XX年X月文档修订记录目录1范围 (1)1.1标识 (1)1.2系统概述 (1)1.3文档概述 (1)2引用文档 (1)3测试准备 (2)3.1硬件准备 (2)3.2软件准备 (2)3.3其他测试前准备 (2)4测试说明 (3)4.1测试用例编号规则 (3)4.2测试用例列表 (3)4.3测试用例 (3)5需求的可追踪性 (8)6注释 (8)1范围1.1标识【注释：本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号和发布号。
】1.2系统概述【注释：本条应概述本文档所适用的系统和软件的用途。
描述系统与软件的一般特性（如规模、安全性、可靠性、实时性、技术风险等特性）；概述系统开发、运行和维护的历史；标识项目的需方、用户、开发方和保障机构等；标识当前和计划的运行现场；列出其他有关文档。
】1.3文档概述【注释：本条应概述本文档的用途和内容，并描述与它的使用有关的安全保密方面的要求。
】2引用文档【注释：本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应给出不能通过正常渠道得到的文档的来源。
】3测试准备3.1硬件准备【注释：本条应描述测试工作所需的硬件准备规程。
有关这些规程，可以引用已发布的操作手册。
（若适用）应提供以下内容：a）用名称和（若适用）编号标识要使用的特定硬件；b）所有连接硬件所有的开关装置和电缆；c）说明硬件、互联控制和数据路径的一个或多个图示；d）使硬件处于就绪状态的逐步的操作说明。
】3.2软件准备【注释：本条描述准备被测项、相关软件以及数据的必要规程。
有关这些规程，可以引用已经发布的软件手册。
（若适用）应提供下述信息：a）测试中要使用的特定软件；b）被测项的存储介质（如光盘、磁盘）；c）所有相关软件（如模拟器、测试驱动程序、数据库）的存储介质；d）加载软件的说明，包括所需的顺序；e）多个测试用例共用的软件初始化说明。
(品质)(管理知识)企业薪酬管理测试用例 品质
（管理知识）企业薪酬管理测试用例文档信息修订历史记录文档审核与批准目录1范围41.1标识41.2系统概述41.3文档概述42引用文件43术语和缩略语54测试准备54.1硬件准备54.2软件准备54.3数据准备54.4测试工具准备65测试用例61范围1.1标识a.文档标识号：uuid_doc_1b.标题：薪酬管理c.委托单位：软件学院1.2系统概述产品应用领域：企业产品特点：a.企业薪酬管理系统用来支持企业薪酬管理，包括组织结构定义、员工信息管理、薪酬模板管理、薪酬发放管理、薪酬报表主要功能模块：a.组织结构定义d.员工信息管理e.薪酬模版管理f.薪酬发放管理g.薪酬报表1.3文档概述本文档是对企业薪酬管理系统进行测试的说明，根据该被测软件的需求分析、概要设计说明、用户手册等输入条件拟制系统测试的说明。
即对测试报告中提出的测试条目安排测试进度、准备测试的软件和硬件环境，并在此基础上设计详细的测试用例，包括测试输入设计、测试操作设计、期望测试结果等。
2引用文件表2-1引用文件表3术语和缩略语4测试准备1.4硬件准备服务器：机型：联想启天M4300CPU：Intel（R）Pentium（R）内存：1GB硬盘：80GB压力机：机型：IBM8175CPU：P42.8GHz内存：512MB硬盘：40GB交换机：型号：CiscoCatalyst2950 1.5软件准备服务器：操作系统：WindowsXPSP2浏览器：IE6SP2应用服务器：Tomcat6.0Java：JDK1.6.0_07应用软件：LiferayPortal5.1.1数据库：Mysql5.1.28Office2003压力机：操作系统：WindowsXPSP2浏览器：IE6SP2性能测试软件：Loadrunner8.0Office20031.6数据准备测试数据：5300条稿件记录用户数据：50个在线用户1.7测试工具准备LoadRunnerVirtualUserGenerator使用LoadRunner的VirtualUserGenerator（简称VuGen），创建系统负载。
[整理版]H02-医院预约挂号系统用例图和用例文档
![[整理版]H02-医院预约挂号系统用例图和用例文档](https://img.taocdn.com/s3/m/a8cf8bb9102de2bd97058855.png)
[整理版]H02-医院预约挂号系统用例图和用例文档医院预约挂号系统用例图图1. 医院预约挂号系统用例图表1. 医院预约挂号系统参与者说明参与者名称描述同义词未注册用户普通游客，没有访问该系统的账号和密码游客、匿名用户注册用户通过管理员审核后的合法用户会员系统管理员对本系统进行日常维护和后台管理人员分诊台护士使用该系统的医院各科室分诊台的护士挂号处使用该系统的医院挂号处的工作人员挂号处工作人员支付系统为该系统提供支付接口的外部系统支付宝时间习惯用法，启动需要系统自动执行的用例表2. 医院预约挂号系统用例说明用例名称描述同义词实名注册完成在系统的注册业务注册查询医院信息查询医院、相关科室、各科室的医生等各类信息登录登录系统预约挂号注册用户可通过该用例完成预约挂号业务打印预约单打印出已经预约挂号的预约单打印挂号单打印出已经预约挂号并支付费用的挂号单支付挂号费针对已经预约的挂号支付费用取消预约取消已经完成的预约业务，并完成相应的费用处理审核注册信息审核用户提交的注册信息是否合法维护出诊信息设定医生的出诊情况，也可通过定义相应的业务规则由系统自动生成出诊信息生成出诊信息系统根据管理员设定的规则自动生成出诊信息处理预期未取处理那些预期未取消的也未看病的预约记录消预约核查预约单核查用户的预约单是否合法核查预约单和核查用户的预约单和挂号单是否合法挂号单表3 “预约挂号”用例文档用例名预约挂号简要描述注册用户可通过该用例完成预约挂号业务参与者注册用户涉众注册用户、医院扩展点打印预约单、打印挂号费、支付挂号费前置条件用户成功登录到本系统后置条件用户的预约信息被记录到系统中基本事件流1. 该用例起始于注册用户需要通过该系统进行预约挂号(A-1);2. 用户设定查询条件(D-1)，查询到需要预约的医院、科室以及出诊信息;3. 系统显示可预约的出诊信息(A-2，D-2);4. 用户选择一个可用的出诊信息，进行预约;5. 系统显示有关本次预约的详细信息(D-3);6. 用户提交本次预约记录;7. 系统保存本次预约记录，并提示用户预约成功(A-3)。
案例旅游业务申请系统用例图和用例文档.doc
案例旅游业务申请系统用例图和用例文档文件编号UML-T02 版本号 1.1 创建日期2009-11-11 作者thbin 更新日期2010-10-29 北京航空航天大学软件学院“面向对象分析与设计”案例文档旅游业务申请系统用例文档旅游申请系统用例图表1给出了旅游申请系统中“办理申请手续”用例的文档。
由于该用例中并没有明确的非功能需求，因此在文档中也没有体现。
表1 “办理申请手续”用例文档用例名办理申请手续简要描述前台服务员通过该用例为申请人办理申请旅游团的手续参与者前台服务员涉众申请人、前台服务员相关用例暂无前置条件前台服务员登录到系统后置条件申请信息被正确保存，相关旅游团可申请人数减少基本事件流 1. 该用例起始于旅客需要办理申请手续； 2. 前台服务员录入要申请的旅游团旅行路线代码和出发日期； 3. 系统查询要申请的旅游团信息（A-1）； 4. 系统显示查询到的旅游团和相关路线信息（D-1）（A-2、A-3）；5. 前台服务员录入本次申请信息（D-2）； 6. 系统显示旅行费用的总额和申请订金金额；7. 前台服务员提交该申请信息；8. 系统保存该申请信息（A-4），用例结束。
备选事件流A-* 前台服务员在提交该申请前，随时都可能中止该申请 1. 系统显示中止确认的消息； 2. 前台服务员可以结束该用例，也可以选择继续录入下一个申请。
A-1 无法查询到所需的旅游团信息1. 系统显示录入的旅游线路代码或者出发日期有误信息； 2. 前台服务员再次录入旅游路线代码和出发日期，也可以结束用例。
A-2 旅行已超过申请截止日期1. 系统提示已超过申请截止日期，不能申请； 2. 前台服务员重新输入旅游线路代码和新的出发日期，也可以结束用例。
A-3 可以申请的人数为0人1. 系统提示旅游团人数已满；2. 前台服务员重新输入新的旅游线路代码和出发日期，也可以结束用例。
A-4 保存信息失败1. 系统显示保存失败，并提示用户需要再次提交； 2. 前台服务员可以重新提交该申请，也可以结束用例。
如何写测试用例【范本模板】
如何编写测试用例测试工作也从简单测试演变为包括:编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。
测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。
一、测试用例是软件测试的核心软件测试的重要性是毋庸置疑的.但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷,保证软件的优良品质，则是软件公司探索和追求的目标。
每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。
影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员)的素质、测试方法和技术的运用等等。
因为有些因素是客观存在的,无法避免.有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。
如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。
可以把人为因素的影响减少到最小.即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。
因此测试用例的设计和编制是软件测试活动中最重要的.测试用例是测试工作的指导,是软件测试的必须遵守的准则。
更是软件测试质量稳定的根本保障。
二、什么叫测试用例测试用例(Test Case)目前没有经典的定义.比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略.内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。
不同类别的软件，测试用例是不同的。
不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一,变化更大、更快。
笔者主要从事企业管理软件的测试。
因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。
测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案.对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
用例分析文档(新)
电力指标分析系统1.1. 扭亏增盈分析 (4)1.1.1用例图 (4)1.1.2 指标偏差分析 (4)1.1.3 指标完成情况分析 (5)1.1.4 历史指标分析 (6)1.1.5 调度会议信息 (7)1.1.5.1 添加扭亏增盈会议信息 (7)1.1.5.2 修改扭亏增盈会议信息 (8)1.1.5.3 删除会议信息 (9)1.1.5.4 查看会议信息 (9)1.1.5.5 查看会议详细信息 (10)2.1 系统管理 (11)用例图： (11)2.1.1 指标管理 (12)2.1.1.1 查看指标信息 (12)2.1.1.2添加指标信息 (13)2.1.1.3删除指标信息 (13)2.1.1.4修改指标信息 (14)2.1.2 部门管理 (15)2.1.2.1 查看部门信息 (15)2.1.2.2 添加部门信息 (16)2.1.2.3 删除部门信息 (16)2.1.2.4修改部门信息 (17)2.1.3 用户管理 (18)2.1.3.1 查看用户信息 (18)2.1.3.2 添加用户信息 (19)2.1.3.3 删除用户信息 (19)2.1.3.4 修改用户信息 (20)2.1.4 机构管理 (21)2.1.4.1 查看机构信息 (21)2.1.4.2 添加机构信息 (22)2.1.4.3 删除机构信息 (22)2.1.4.4 修改机构信息 (23)2.1.5 调度管理 (24)2.1.5.1 修改调度人员 (24)2.1.5.2 查看调度人员 (25)3.1 指标数据报表 (26)3.1.1用例图 (26)3.1.2 综合分析报表 (26)3.1.3 指标明细报表 (27)3.1.4 历史分析报表 (27)3.1.5 导出Excel报表文档 (28)3.1.6 打印报表 (29)4.1 数据采集 (30)4.1.1 用例图 (30)4.1.2 每月目标值采集 (30)4.1.2.1 添加每月目标值 (30)4.1.2.2 删除每月目标值 (31)4.1.3 每月完成值采集 (32)4.1.3.1 添加每月完成值 (32)4.1.3.2 删除每月完成值 (33)4.1.4 数据半自动采集 (33)4.1.5 年度值采集 (34)5.1 数据管理 (35)5.1.1 用例图 (35)5.1.2 每月目标值维护 (36)5.1.2.1 查询每月目标值 (36)5.1.2.2 修改每月目标值 (37)5.1.3 每月完成值维护 (38)5.1.3.1 查询每月完成值 (38)5.1.3.2 修改每月完成值 (39)5.1.4 年度先进值维护 (40)5.1.4.1 查询年度先进值 (40)5.1.4.2 添加年度先进值 (41)5.1.4.3 修改年度先进值 (41)5.1.5.4 删除年度先进值 (42)5.1.5 Excel模板维护 (43)5.1.6.1 查询模板 (43)5.1.6.2 添加模板 (44)5.1.6.3 修改模板 (44)5.1.6.4 删除模板 (45)5.1.6.5 导出模板 (46)5.1.6 年度值维护 (46)5.1.6.1 查看年度值信息 (46)5.1.6.2 修改年度值信息 (47)5.1.6.3 删除年度值信息 (48)系统用户1.1. 扭亏增盈分析1.1.1用例图系统用户1.1.2指标偏差分析用例名称指标偏差分析用例编号DJ_DLZBS_1_1用例审核人研发一部用例编写人唐超前置条件 1.用户成功登录系统2.用户具有指标偏差分析权限基本路径 1.系统用户选择扭亏增盈分析下的指标偏差分析。
如何编写用例文档
如何进行用例建模呢，这里主要分解为三步：1.识别参与者(ACTOR)参与者作为同系统交互的所有事物，它可以是人也可以是其它系统或硬件等。
它不是系统的组成部分，是独立于系统而客观存在的。
其实在确定参与者时可以采用提问的方式来找出来，如谁是系统的主要用户？谁从系统获得信息等等。
而作为BLOG这种软件，这里为了便于分析，将参与者确定为用户(或会员和作者等，一但确定之后，下面的用例描述就要这样使用它们)，同时为了不与域模型中的用户和用户列表有任何模糊上的关联。
这里将域模型中的用户和用户列表更名为用户信息，用户信息列表。
而另一个ACTOR就是系统管理员了，而先前域模型中的系统管理员则相应更名为系统管理员信息。
2.确定用例。
确定用例时ICONIX方法认为“首先要确定尽可能多的用例，然后不断地编写和改进描述这些用例的文本，在这一过程中，您将发现新的用例和通用情况”。
而确定用例的一个最重要的原则就是它必须同用户手册中的材料密切相关，每个用户和用户指南的各部分之间的关系必须是显而易见的。
从手册出发的原因就是要求开发人员“必须从用户角度来分析和设计系统”。
因为手册内容一般都非常庞大(相关模版在网上获取)，动不动就几十甚至几百页。
而从中归纳出文档所需要的内容必定也是非常繁琐的，但这一步又非常必要。
因为篇幅所限，又因为担心大家偏离本文的思想，所以这里也只有跳过了，大家完全可以在网上找到相关的信息来填充这一空白。
另外识别用例也可以采用提问方式，如每个参与者的任务？系统需要何种输入输出？等（详见“系统分析师设计指南之统一建模语言”）。
在有些书中会使用合并需求（主要是功能性需求，非功能性需求可附加到用例描述中）来获得用例，而进行合并操作的原则也就是生成“可见结果”的过程(这一步因为所做的事情过于繁杂，本文就不再涉略了)，并完成用例命名和绘制用例图。
从我个人来看，这两者(ICONIX方法和其它方法) 是相辅相成，并无冲突。
限于篇幅直接将初步确定并整理出来的用例列出来[采用动词(短语)-名词(短语)形式]：注册用户(UC01),登陆系统(UC02),发表文章(UC03),编辑文章(UC04),删除文章(UC05),浏览评论(UC07),删除评论(UC08),浏览留言(UC09),删除留言(UC10),添加链接(UC11),编辑链接(UC12),删除链接(UC13),上传文件(UC14),删除文件(UC15),管理文件类型(UC16),编辑签名(UC17),编辑个人信息(UC18),编辑BLOG基本信息(UC19),(管理员)审核用户(UC20), 创建俱乐部[或群](UC21)等。
登录用例文档
“登录”用例文档
基本时间流
（1）用例起始于用户需要登录到该系统
（2）系统显示欢迎界面，并要求用户输入用户名和密码
（3）用户输入用户名和密码
（4）系统验证用户名和密码，允许用户登录系统（A-1）
（5）系统根据用户类型启动不同的主操作界面
备选事件流
A-1用户名错误或密码错误
（1）系统显示用户名错误或密码错误的提示信息，并进入第（2）步
（2）用户可以重新输入用户名和密码（B-1），也可以选择结束该用例
补充约束-业务规则
B-1系统允许用户重试三次登录操作，超过三次后系统自动结束，不允许用户重试补充约束-非功能需求
安全性：密码应该采用加密的方式存储，有关密码的算法待定
待解决问题
关于用户名和密码的管理和维护功能还需要进一步明确
相关图
（可画出登录过程的活动图，此处省略）。
软件测试用例文档模板(带实例)
数据
憧憬截止
本质截止
尝试状态（P/F）
1
采用用户称呼，按“提接”按钮.
用户名=administrators，暗号为空
隐现告诫疑息“帐号或者暗号没有克没有及为空！”
（切合）
P
2
采用用户称呼,输进过失暗号，按“提接”按钮.
用户名为administrators，暗号=123
隐现告诫疑息“帐号或者暗号没有过失！”
尝试脚段
查看维护窗体界里取安排的切合性.
预置条件
不妨登录加进到系统
特殊规程证明
（无）
参照疑息
系统提要安排证明战仔细安排证明
尝试数据
支配步调
支配形貌
数据
憧憬截止
本质截止
尝试状态（P/F）
1
…
…
…
…
…
234ຫໍສະໝຸດ 5678
9
10
11
12
尝试人员
彭贝贝、李绍霞、唐姣凤
启垦人员
杨丽娟
控造人
李虎(脚写)
功能个性
系统的初初窗体，并举止用户的合法性考证.
尝试脚段
考证是可输进合法的疑息，遏止非法登陆，以包管系统的仄安个性
预置条件
数据库中保存了一些用户疑息
特殊规程证明
（区别大小写）
参照疑息
需要证明中闭于“登录”的证明
尝试数据
用户名=administrators暗号=1001（数据库表中有相映的疑息）
支配步调
体例人
李虎、彭贝贝、唐姣凤
用例编号
Project_MA_Interface_3
体例时间
2005–2–21
相闭用例
Project_MA_Interface_1、Project_MA_Interface_2、Project_MA_Priority_1、Project_MA_DBACCESS_1
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
超市运营管理系统系统用例文档
超市运营管理系统开发小组：
姓名学号
罗振强20
刘发胜48
徐壁38
黄伟浩39
2010月10日27
目录
1 超市运营系统顶层用例图 (4)
1.1系统角色用例图 (4)
1.2 超市运营系统顶层用例图 (4)
2 用例说明 (5)
UC1 ：身份验证 (6)
UC2 ：录入商品信息 (7)
UC3 ：打印购物清单 (7)
UC4 ：上架管理 (9)
UC5：读取商品存入表 (10)
UC6 ：接收订单 (11)
UC7 ：商品入库管理 (12)
UC8 ：读取商品存入表 (13)
UC9 ：统计财务 (14)
UC10 ：统计报表 (15)
1 超市运营系统顶层用例图
1.1系统角色用例图
超市服务的对象是顾客，外部有供应商，超市系统内部员工可以按人员的职能来分类。
下图是超市进销存管理系统角色分析的用例图。
其中，角色“员工”和“管理员”是抽象角色。
经理
供应商顾客
图1 1.2 超市运营系统顶层用例图
会计员
顾客
经理
图2
2 用例说明
超市运营系统登陆系统用例图
UC1 ：身份验证
范围：登陆系统
级别：用户目标
用例描述：超市员工要进入系统的时候，首先要通过身份验证，验证成功后才能进入系统。
登陆成功后系统根据员工的职能权限判断验证员工的身份并进入相应的系统界面。
参与者：员工
前置条件：输入员工正确
后置条件：登陆相应的系统成功
涉众及其关注点：
员工：希望能够准确地输入员工号，成功登陆相应的系统。
基本路径：
1. 输入员工号
2. 系统验证员工信息
1.验证失败，返回1
2.进入相应的系统界面
扩展点：销售系统，采购系统，财务系统
补充说明：要确保输入员工号准确，才能成功登陆相应的系统
对应的用例图
图3
超市运营系统销售系统用例图
销售管理子系统：
UC2 ：录入商品信息
范围：销售系统
级别：子功能（销售管理）
用例描述：售货员按顾客提交的购买商品，录入商品的条形码，系统根据条形码查询商品，并计算数量，返回信息。
并修改销售情况表和仓库表。
参与者：销售员
前置条件：修改销售情况表成功
后置条件：修改仓库表
涉众及其关注点：
销售员：希望能够准确地录入商品信息，成功修改销售情况表和仓库表。
基本路径：
3.录入商品条形码
4.录入失败反回1
5.修改销售情况表
6.修改失败反回3
7.修改仓库表
8.修改失败反回5
扩展点：修改销售情况表
补充说明：要确保销售情况表和仓库表的信息准确，才能做好销售情况的统计
UC3 ：打印购物清单
范围：销售系统
级别：子功能（销售管理）
用例描述：售货员完成顾客购买商品的输入，形成购买商品清单，如顾客同意付款，进入打印购物清单用例。
该用例接收顾客付款，计算余额，打印清单。
参与者：销售员
前置条件：顾客购买商品
后置条件：打印清单
涉众及其关注点：
销售员：希望能够准确地录入商品信息，成功打印清单。
基本路径：
1.客户购买商品
2.销售员打印清单
3.顾客拒绝付款
4.取消购买
扩展点：计价
补充说明：销售员告诉顾客该付的商品费用。
对应的用例图
顾客
图4
表2
上架管理子系统：
UC4 ：上架管理
范围：销售系统
级别：子功能（销售管理）
用例描述：理货员用从仓库里取出的商品上架，并根据上架情况修改商品取出表、商品上架表、仓库表。
参与者：理货员
前置条件：修改商品取出表成功
后置条件：修改商品上架表成功
涉众及其关注点：
理货员：按照需求从仓库去出商品上架到货架，及时更新商品取出表，商品上架表，仓库表。
基本路径：
1. 修改商品取出表
2.修改失败返回1
3. 修改商品上架表
4.修改失败返回3
扩展点：“修改商品取出表”，“修改商品上加表”，“修改仓库表”
补充说明：理货员应对“修改商品取出表”，“修改商品上加表”，“修改仓库表”进行实时更新。
用例图
图5
表3
超市运营系统采购系统用例图
订货管理子系统：
UC5：读取商品存入表
范围：采购系统
级别：子功能（订货管理）
用例描述：仓库管理员读取仓库表所再根据表中情况制作订货表，再将其信息修改入订货表，然后将查询的统计结果制成订单，再发送订单给供应商。
参与者：仓库管理员
前置条件：读取商品存入表成功，修改进货情况表
后置条件：发送订单
涉众及其关注点：
仓库管理员：希望能够准确地读取商品存入表，成功修改进货情况表。
基本路径：
1读取商品存入表
2读取失败反回1
3修改进货情况表
4修改失败反回3
5发送订单
6发送失败返回5
扩展点：修改订货表
补充说明：要确保商品订货表的信息准确，才能做好订货情况的统计UC6 ：接收订单
范围：采购系统
级别：子功能（订货管理）
用例描述：接收统计结果制成的订单。
参与者：仓库管理员
前置条件：向供应商发送订货单
后置条件：供应商接收订单
涉众及其关注点：
仓库管理员：希望能够准确发送订单给供应商。
基本路径：
9.供应商接收订单
10.读取失败反回1
扩展点：接收订单
补充说明：要确保订单的信息准确，才能保证进货的商品对数。
用例图
图6
用例描述
表4
存入商品管理子系统：
UC7 ：商品入库管理
范围：采购系统
级别：子功能（存入商品）
用例描述：理货员将供应来的商品存入仓库，并修改商品存入表和仓库表。
参与者：仓库管理员
前置条件：读取商品表成功
后置条件：修改仓库表
涉众及其关注点：
仓库管理员：希望能够准确地读取商品表，成功修改仓库况表。
基本路径：
1修改商品存入表
2修改失败反回1
3修改仓库表
4修改失败反回3
扩展点：修改进货情况表
补充说明：要确保商品存入表的信息准确，才能做好进货情况的统计
用例图
图7
表5
统计进货情况子系统：
UC8 ：读取商品存入表
范围：采购系统
级别：子功能（统计进货）
用例描述：仓库管理员根据通过读取商品来修改进货情况表。
参与者：仓库管理员
前置条件：读取商品存入表成功
后置条件：修改进货情况表
涉众及其关注点：
仓库管理员：希望能够准确地读取商品存入表，成功修改进货情况表。
基本路径：
1读取商品存入表
2读取失败反回1
11.修改进货情况表
12.修改失败反回3
扩展点：修改进货情况表
补充说明：要确保商品存入表的信息准确，才能做好进货情况的统计用例图
仓库管理员
图8
表6
超市运营系统财务系统用例图
UC9 ：统计财务
范围：财务系统
级别：用户目标
用例描述：会计员通过读取销售情况表与进货情况表统计出一个月的收入与支出情况，再将情况生成报表，发给经理。
参与者：会计员，经理
前置条件：生成报表成功
后置条件：发送报表成功
涉众及其关注点：
会计员：通过读取销售情况表与进货情况表统计出一个月的收入与支出情况，再将情况生成报表，发给经理
经理：审查会计员发送的财务报表。
基本路径：
1. 读取销售情况表
2.读取失败返回1
3. 读取进货情况表
4.读取失败返回3
5. 发送统计报表
6.发送失败返回5
扩展点：“读取销售情况表”，“读取进货情况表”，“统计报表”
补充说明：会计员应对“读取销售情况表”，“读取进货情况表”，“统计报表“做出第一时间的统计。
UC10 ：统计报表
范围：财务系统
级别：用户目标
用例描述：接收会计员统计报表包含的统计报表。
参与者：会计员，经理
前置条件：发送报表成功
后置条件：接收报表成功
涉众及其关注点：
经理：审查会计员发送的财务报表。
基本路径：
1. 接收统计报表
2.接收失败返回1
扩展点：统计财务
补充说明：经理审查统计的财务报表是否有错，并对当前超市运营情况做出及时的规划和调整。
用例图
经理
图9。