用例描述的写法

用例说明模板

范围
角色
级别
概要
主执行者
登陆成功的用户鼠标点击角色删除
前置条件
角色管理
后置条件
无
触发事件
用户鼠标点击角色删除
描述
步骤
活动
1
用户鼠标点击选择菜单上的角色删除选项
2
3
扩展
步骤
分支动作
1
2
用例#
角色修改
使用语境
用户在角色管理界面下鼠标点击选择角色修改
范围
角色
级别
概要
主执行者
登陆成功的用户鼠标点击角色修改
前置条件
2
3
扩展
步骤
分支动作
1
2
用例#
用户增加
使用语境
用户在用户管理界面鼠标点击用户增加
范围
用户,角色
级别
用户目标
主执行者
用户在用户管理界面鼠标点击用户增加
前置条件
用户管理
后置条件
无
触发事件
用户鼠标点击用户增加
描述
步骤
活动
1
用户鼠标点击用户管理界面上的用户增加选项
2
3
扩展
步骤
分支动作
1
2
用例#
用户删除
使用语境
用户在用户管理界面鼠标点击用户删除
范围
用户,角色
级别
用户目标
主执行者
用户在用户管理界面鼠标点击用户删除
前置条件
用户管理
后置条件
无
触发事件
用户鼠标点击用户删除
描述
步骤
活动
1
用户鼠标点击用户管理界面上的用户删除选项
2
3
扩展

图书管理系统用例描述文档

删除图书新增图书用例名称：登录用例描述：本系统需要参与者输入帐号和密码进行系统登陆，该用例页面是系统起始页面。

用户帐号和密码是系统默认已经分配的。

参与者：图书馆工作人员。

前置条件：无基本路径：1.输入帐号，密码2.点击“进入系统”3.验证用户权限，进入主界面备选流程：1.点击“重新填写”，实现重填帐号密码功能。

2.输入帐号或密码不正确，重新登陆。

3.进入基本路径1用例名称：注销用例描述：图书管理员离开系统参与者：图书馆工作人员。

前置条件：已经进入系统基本路径：1.点击“注销”2.提示“确认退出”3.点击确认，退出系统备选流程：1.点击取消不退出系统用例名称：借阅管理用例描述：此用例用来供用户完成借阅管理工作，包括两个扩展用例——“新办借阅证”和“补办借阅证”。

参与者：图书馆工作人员。

前置条件：图书馆工作人员已经登录用例名称：新办借阅证用例描述：图书馆工作人员输入学生信息进行借阅证办理。

参与者：图书馆工作人员。

前置条件：图书馆工作人员点击“新办借阅证”基本路径：1.输入学生信息（学号，姓名，专业，班级，性别）2.点击“提交”3.显示添加的借阅证信息（借阅证编号，学号，姓名，专业，班级，性别）备选流程：1.点击“重新填写”，实现重填学生信息功能。

2.进入基本路径1用例名称：补办借阅证用例描述：图书馆工作人员输入学生信息进行借阅证补办。

参与者：图书馆工作人员。

前置条件：图书馆工作人员点击“补办借阅证”基本路径：1.输入学号2.点击“查询”3.显示该学生遗失的借阅证信息（借阅证编号，学号，姓名，专业，班级，性别）4.点击“补办”5.显示该学生新借阅证信息（借阅证编号，学号，姓名，专业，班级，性别）6.进入备选流程B备选流程：A：1点击“重新填写”，实现重填学号。

2进入基本路径1B：如果学生有借阅图书未归还，显示当前该学生借阅情况（书名,ISBN，借阅时间，应归还时间）用例名称：图书借阅用例描述：图书馆工作人员输入借阅证编号和图书编号来完成图书借阅。

用例描述文档模板

1. 必须要有的项目：标题+部门+时间+操作人
2. 必须要有的项目：时间＋地点＋专家＋主题
3. 邮件格式：
您好！[讲座时间]将举办[专家]主讲的[主题]讲座，
特殊需求（Special Requirement）
描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（指出所使用的操作系统、开发工具等）。
用例执行完毕后系Βιβλιοθήκη 可能处于的一组状态。涉众利益(Stakeholder)
说明涉众及涉众关心和担心的事情。如下：
1.开发人员-担心收到太多垃圾邮件
2.组织工作人员-希望操作方便，尽量减少手工劳动
用例场景 (Use-Case Scenario)
包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。
事件流 (Flow of Event)
基本流程（Base Flow）
1. 组织工作人员输入讲座信息，请求发布
2. 系统验证讲座信息充分
3. 系统保存讲座信息，生成讲座网页、讲座邮件
4. 系统发布网页到公司网站
5. 系统请求邮件列表系统发送邮件
6. 系统记录发布情况
7. 系统显示讲座消息已经发布
扩展流程（Extend Flow）
用例编号(Number)：UC_1_1用例名称(Name)：XXXXX
简要说明 (Brief Description)
简要介绍该用例的作用和目的。
执行者(Actors)
说明主要执行者和辅助执行者。
前置条件(Pre-Condition)
执行用例之前系统必须所处的状态。
后置条件(Post-Condition)
如：*1-7应在10秒之内

图书管理系统—用例描述

3.读者输入读者证号，系统根据借阅规则检查读者借书有效性
A1：读者无效
4. 管理员输入待借阅的图书条码号，检查图书有效性
A2：图书无效
5．系统登记一条新的借书信息
6．系统检查读者预定信息
A3:有预定
7．用例结束
其他事件流：
A1:读者无效
(1).系统显示读者无效的提示信息
(2).返回主事件流第3步
A2:
特殊需求：使用条码扫描仪和图书条码，预约一本书时间不超过30秒
(1). 系统显示图书无效提示信息
(2). 返回主事件流第4步
A3:有预定
(1). 系统提示预定信息，并取消预定
(2). 返回主事件流第7步
后置条件：系统成功写入一条借书信息，读者当前的借书数量加1
扩展点：
特殊需求：支持使用IC卡阅读器，输入读者证号，使用条码扫描仪和图书条码，借一本书时间不超过30秒
4.剔除新书信息
5.系统登记剔除一条旧书信息
6.用例结束
其他事件流：
A1:旧书条码无效
(1).提示新书条码无效
(2).返回主事件流第3步
后置条件：系统成功写入一条剔除旧书信息，当前的图书数量减1
特殊需求：支持使用条码扫描仪输入图书条码，剔除一本书时间不超过30秒
用例名称：统计月借阅情况
描述：馆长使用图书查询用例完成统计月借阅情况的活动
用例名称：剔除旧书
描述：图书管理员使用办理预定业务用例完成图书管理员剔除旧书活动
标识符:uc7
优先级：B(中)
角色:图书管理员
前置条件：图书馆员已成功登录系统并具有剔除旧书的权限
主事件流:
1.管理员选择“剔除旧书”选项，用例开始
2.打开剔除旧书窗体

用例描述模板内容

用例描述模板内容
以下是 9 条用例描述模板内容：
1. 嘿，你知道不，当你要描述一件事情的时候，就像讲故事一样！比如说，“我今天出去买菜，哇，那菜市场人多得像蚂蚁开会！”看到没，就这样简单直接，把事情说明白了。

2. 哎呀呀，咱就说如果你要写一个使用某个工具的用例，可以这样呀，“我拿起那把剪刀，就跟拿起了我的秘密武器似的，喀嚓喀嚓就把纸剪开啦！”这多生动形象啊。

3. 哇塞，要描述一个人的行为时，可以这么说呀，“他吃饭的样子，简直就像一头饿了好几天的狼！”这不是很容易让人懂嘛。

4. 嘿，当你写一个流程的时候，像这样，“我先打开冰箱门，然后像在找宝藏似的找我想吃的东西。

”是不是很清楚呢？
5. 哟呵，比如说要描述一个场景，“那个房间暗得跟晚上没开灯一样！”这样一说，大家一下子就有画面感了呀。

6. 你想想看啊，要是描述一个人的心情，“我当时开心得就像中了彩票一样！”简洁明了还有感觉。

7. 哇哦，像描述一个动作，“她跳舞的姿势，就像蝴蝶在花丛中飞舞！”是不是很妙呀。

8. 哎呀，当你要描述一个现象的时候，“那雨下得跟倒水似的！”这样多形象呀。

9. 好啦，总之呢，用例描述就是要让别人一听就懂，就像我举的这些例子一样，简单又有趣，大家肯定都喜欢呀！。

用例说明模板（经典模板）

用例说明模板1(经典模板)编者说明：随着UML的日益普及，用例（Use case）分析技术也在需求实践中广泛被采用。

但是也有许多团队在使用该技术时，只画出了用例图，而缺少了用例说明，其实这是一个严重的误区。

而本模板就将指导你编写该说明。

1.用例名称1.1 简要说明[简要说明用例的作用和目的。

该小节的篇幅不要太长。

]2.上下文图[在此小节中，有一个只包括本用例和所有与该用例相关的Actor和其它用例组成的，一个用例图的局部。

]3. 事件流3.1 基本流[当Actor采取行动时，用例也就随即开始。

用例总是由Actor启动的，用例应说明Actor 的行为及系统的响应，可按照Actor与系统进行对话的形式来逐步引入用例。

] [要注意的是，用例描述应该说明系统内发生的事情，而不是事件发生的方式与原因。

如果进行了信息交换，则需指出来回传递的具体信息。

例如，只表述主角输入了客户信息就不够明确。

最好明确地说主角输入了客户姓名和地址。

当然你也可以通过项目词汇表来定义这些信息，使得用例中的内容被简化，从而不致于让用例描述陷入过多的细节内容。

] [如果存在一些相对比较简单的备选流，只需少数几句话就可以说明清楚，那么也可以直接在这一部分中描述。

但是如果比较复杂，还是应该单独放在备选流小节中描述。

] [一幅图胜过千言万语，因此建议在这一小节中，除了叙述性文字之外，你还可以引用UML中的活动图、顺序图、协作图、状态图等手段，对其进行补充说明。

]3.2 备选流3.2.1 第一备选流[正如前面所述，对于较复杂的备选流应单独地说明。

]3.2.1.1 备选支流[如果能使表达更明确，备选流又可再分为多个支流。

]3.2.2 第二备选流[在一个用例中很可能会有多个备选流。

为了使表达更清晰，应将各个备选流分开说明。

使用备选流可以提高用例的可读性，并防止将用例分解为过多的层次。

应切记，用例只是文本说明，其主要目的是以清晰、简洁、易于理解的方式记录系统的行为。

学生管理系统的用例描述

牡一中2018级高一学年下学期4月考试历史试题单项选择（在下列各题的四个选项中，只有一项是最符合题意的。

共22小题，每小题2分，满分44分）1．《白虎通》记载：“至于神农，人民众多，禽兽不足，于是神农因天之时，分地之利，制耒耜，教民农耕。

”上述材料反映的史实是（）A.种植经济的出现B.采集经济的出现C.渔猎经济的出现D.畜牧经济的出现2.《诗经》云：“千耦其耘。

”李悝说：“今一夫挟五口，治田百亩，岁收亩一石半，为粟百五十石。

”上述现象变化主要得益于（）A.土地私有制确立B.铁犁牛耕的运用C.赋税制的改革D.井田制度的瓦解3.我国古代农业生产动力经历了由人力到畜力、再到利用自然力的过程。

下列农业生产工具最能体现与农业生产动力发展过程相一致的是（）①牛耕②翻车③筒车④水排A.①②B.②④C.①③D.③④4.《汉书·食货志》认为，“治田勤谨则亩益三斗。

”东汉王充提出了“勉致人工，以助地力”。

南宋陈旁认为，对待不同土壤要对症下药，可使土地更加精熟肥美。

这反映了古代农业（）A.需要大量劳力B.适时增加肥力C.善于积累经验D.提倡精耕细作5.《新全球史》载：“其目的在于确保土地的平均分配，以避免出现类似于汉朝的土地兼并。

这项制度根据土地的贫瘠和受地者的需要将土地分配给个人及其家庭。

”对“这项制度”的评价不正确的是（）A．缓解了政府的财政问题 B．有利于社会的稳定C．促进了自然经济的发展 D．解决了土地兼并问题6.著名史学家王家范先生曾经精辟地指出：“小农经济一锄、一镰（或者再加上一犁，不是家家都有畜力，那就用人力拉犁）一个主要劳力加上一些辅助劳力，一旦和土地结合，就可以到处组织起简单再生产。

”对这段话最正确的理解是（）A.小农经济非常脆弱B.小农经济具有稳定性C.小农经济只需要一些简单的劳动工具D.小农经济有顽强的生命力7.元代著名文学家张养浩在《山坡羊》中写道：“一头犁牛半块田，收也凭天，荒也凭天。

这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。

这个网站我用UML完整的分析一下，以下我提取了用例图和用例描述的部分。

这个家教网站分为前台客户系统和后台管理系统。

前台客户系统的用例图如下：
后台管理系统用例图如下：
对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。

如下：
用例名称：网站公告发布
用例标识号：101
参与者：负责人
（注：专业文档是经验性极强的领域，无法思考和涵盖全面，素材和资料部分来自网络，供参考。

可复制、编制，期待你的好评与关注）。

用例描述(部分)

用例描述(部分)用例名称：登录主参与者：顾客、客服、系统管理员层次：海平面（用户目标）利益相关者：顾客、客服、系统管理员前置条件：已经注册成为八公宠物乐园的用户最低保证：回滚任何未完成的事务，系统记录进展日志直到失败成功保证：用户能够登录自己的账号触发器：用户进入“登录”页面主要成功情节：1.用户进入八公宠物乐园网站的“登录”页面。

2.用户输入自己的账号、密码以及验证码。

3.系统验证用户权限，登录成功，进入主页面。

扩展：1.a “登录”页面不能加载或找不到1.a.1 用户在浏览器中得到一个“找不到网页”的错误页面。

1.a.2 用户单击刷新按钮，“登录”页面成功加载。

1.a.3 用户单击刷新按钮，“登录”页面不能成功加载，用户离开网站。

1.b 已显示成功登录过的用户账号并且勾选了“记住密码”1.b.1 输入验证码完成登录，并进入八公宠物乐园首页。

1.b.2输入验证码后登录失败，进入“登录”页面，显示之前的账号密码，重新输入。

1.c已显示成功登录过的用户账号但没有勾选“记住密码”1.c.1 用户输入密码和验证码完成登录，并进入八公宠物乐园首页。

1.c.2 用户重新输入账号密码、验证码。

2.a 用户忘记密码2.a.1 用户单击“找回密码”，通过身份验证能够修改密码。

3.a 用户账号密码不正确3.a.1系统回滚到用户“登录”页面。

3.a.2 用户重新输入正确的账号、密码，成功登录。

3.b 不存在该账号3.b.1 账号输入错误，用户重新输入正确的账号，成功登录。

3.b.2 用户调用“注册”用例，注册一个新的账号。

3.c 输入的验证码不正确3.c.1系统回滚到用户“登录”页面3.c.2 用户输入正确的验证码，成功登录。

用例名称：注册主参与者：顾客、客服层次：海平面（用户目标）利益相关者：顾客、客服前置条件：用户必须在线并且可访问网络最低保证：回滚任何未完成的事务，系统记录进展日志直到失败成功保证：用户能够注册自己的账号触发器：用户进入“注册”页面主要成功情节：1.用户进入八公宠物乐园网站的“注册”页面。

06用例描述

收银员通过执行寻找产品帮助以获取正确的商品 ID 寻找产品帮助是另一个用例，这样可以简化用例的描述
2d 3b
收银员向其他员工询问商品 ID，然后手工输入
当购买多个同一商品时 1 收银员可以直接输入数量
3-6a
顾客要求收银员从输入的商品中去掉一项 1 2 收银员输入商品 ID 并将其删除系统删除相应的购买记录 2a 商品价格超过了收银员的权限 1 2 3 系统提示错误收银员请求经理进行控制操作经理执行控制操作后，收银员重新删除
实际上，用例应该满足所有关注者的要求，因此这是非常重要的部分前置条件收银员必须经过确认和认证后置条件记录并保存销售信息，更新账务和库存信息，生成票据，记录支付授权数据。主成功场景（基本流程） 1 2 3 4 顾客携带所购商品到收银台通过 POS 付款这是一个启动事件收银员开始一次新的销售交易收银员输入商品条码系统显示商品名称、单价收银员重复 3-4 步，直到输入结束 1
15 16
用户确定收到此确认码用例结束
替代流程 A1 无此航班 1 2 3 A2 系统提示没有相应的航班用户确认返回主事件流的第 2 步
用户用 frequent−flyer membership 购买免费机票 1 2 3 系统提示输入卡号用户输入卡号系统确认卡号有效 A3：卡号无效 4 系统确认有足够的里程数可以兑换免费机票 A4：没有足够的里程数兑换免费机票 A5：没有免费机票 5 6 票价设为 0 返回主事件流第 8 步
7b
信用卡支付为了简化，也可以不在此处详细描述信用卡支付的处理过程，而用处理信用卡支付来代替 1 2 3 4 顾客输入信用卡账户信息系统显示其支付信息以备验证收银员确认系统向外部支付授权服务系统发送支付授权请求 4a 系统检测到与外部系统协作时故障 1 2 5 系统向收银员提示错误收银员请求顾客更换支付方式

用例描述的三种形式

用例描述的三种形式以《用例描述的三种形式》为标题，用例描述（Use Case Description）是软件工程中常用的一种工具，是详细描述一定的联系性的用例（use cases）的文档。

它可以帮助开发人员更好地理解需求，并且在实现的过程中正确的重点放在最重要的功能上而不是浪费时间在整体范围外的需求。

一般来说，用例描述可以分为三种形式：简单描述、标准描述和详细描述。

1.单描述：简单描述又叫高层描述，它是最轻量级的用例描述，通常只需几行文字就可以描述清楚用例的核心功能。

它不需要复杂的文字和技术性的说明，它是最一般化的，只需要一个概括性的句子就可以把整个用例的主要内容全部概括出来。

2.标准描述：标准描述又称为中等层次描述，它比简单描述深入得多，它将系统的具体要求和目标细化，更多的关注用户行为，并且还包括了用例可能的异常处理，和输出的结果。

而且它包含了更多的技术性和详细的描述，因此可以满足更多的需求，对于程序的开发也更有参考价值。

3.细描述：详细描述又称为低层次描述，它就像一首歌的每个旋律，它更加详细到每一个可能的操作，并且做到不遗漏。

它甚至包括了每个步骤之间的可能事物，可以提供开发人员详细的指导，而不用一遍又一遍地浪费时间在发现问题上。

用例描述的三种形式都有它们各自的优点和特点，同时也有一定的局限性，有些需求只适合特定的形式来进行描述，比如说，一些复杂的需求就应该使用标准或详细的描述，而简单的需求则可以使用简单的描述。

但不管用什么形式来描述，最重要的还是要明白用户的需求，因为无论是采用哪种描述形式，所有的用例描述都是要服务于其目的：搞清楚用户的需求。

此外，不论是哪种用例描述，在写作的过程中也有很多的注意事项，首先，要有一个精确的定义，确保用例的范围和功能清楚；其次，要非常细致，写出每一个细节，以确保不遗漏任何可能的情况；最后，也要具备良好的可读性，这样才可以更容易地理解和被理解，以达到它的本质目的。

测试用例描述

测试用例描述是指对一个特定的测试用例进行详细描述，包括测试目的、测试环境、测试步骤、测试结果等方面的信息。

以下是一个示例：
测试用例描述：
1. 测试目的：本测试用例旨在测试电机喇叭口组件的性能是否符合要求。

2. 测试环境：
* 设备：电机喇叭口组件、电机、电源、控制器等。

* 工具：流量计、压力计、噪音计等。

* 条件：温度为25±5℃，湿度为60±10%。

3. 测试步骤：
* 准备电机喇叭口组件，确保其安装牢固，无泄漏。

* 将流量计、压力计、噪音计等工具连接到电机喇叭口组件上。

* 按照电机的使用要求，启动电机并控制其转速和流量。

* 记录电机喇叭口组件的流量、压力和噪音等数据。

* 分别在不同流量和转速下进行多次测试，以评估电机喇叭口组件的性能。

4. 测试结果：
* 在不同流量和转速下，电机喇叭口组件的流量应符合电机的要求。

* 在正常工作范围内，电机喇叭口组件的压力应保持稳定，无异常波动。

* 电机喇叭口组件的噪音应符合电机的要求，无异常噪音现象。

5. 测试结论：根据测试结果，电机喇叭口组件的性能符合电机的要求，可以正常使用。

在上述测试用例描述中，包括了对电机喇叭口组件的性能进行测试的目的和意义，以及具体的测试环境、测试步骤和测试结果的描述。

这个例子是一个简单的示例，具体的测试用例描述会根据不同的测试需求和具体情况有所不同。

用例描述(1)

1 用例名称：登录描述：车主、管理员和老板用来进入系统。

前置条件：无部署约束：必须可以让车主、管理员、老板从公司客户端、行程中的任何一台计算机登录，并可以通过客户端防火墙进入系统。

正常事件流：（1）车主、管理员或老板输入用户名和密码。

（2）系统验证姓名和密码、（3）系统判断是否第一次登录，如果是则提示更改密码。

可选事件流：验证错误●系统提示再次输入姓名和密码。

●如果连续验证错误3次，系统提示相应信息，用例结束。

非功能性需求：无。

后置条件：无。

未解决的问题：无。

2 用例名称：修改密码。

描述：车主用来修改自己的登录密码。

前置条件：车主成功登录到系统中或有验证信息。

部署约束：车主可以从客户端访问该用例，如果是客户端访问，则要考虑到客户端的防火墙。

正常事件流：（1）车主输入用户和密码。

（2）选择修改密码，验证密保。

（3）输入新密码并确定。

可选事件流：密保错误●系统提示再次输入密保信息●如果连续错误3次，系统提示相应信息，用例结束。

非功能需求：无。

后置条件：如果用例执行成功，则车主修改后的密码信息，被保存到系统中。

未解决问题：无。

3 用例名称：余额查询。

描述：车主用来查询账户余额。

前置条件：成功登录到系统。

部署约束:车主可以从客户端访问该用例，如果是客户端访问，则要考虑到客户端的防火墙。

正常事件流：（1）成功登录到系统。

（2）选择余额查询或充值。

（3）显示余额信息或充值信息。

可选事件流：打印回单●选择打印回单。

●回单打印成功，返回到主页面。

非功能性需求：无。

后置条件：无。

未解决的问题：无。

4 用例名称：停车记录。

描述：记录用户停车的信息。

前置条件：用户车辆在此停放。

部署约束：用户或管理员成功登录后可以访问该用例。

正常事件流：（1）用户或管理员选择停车记录。

（2）显示车辆在停车场所有停放记录。

可选事件流：●选择具体的时间进行搜索、查询。

非功能性需求：无。

后置条件：如果用例执行成功，则显示详细信息。

未解决的问题：无。

用例描述

用例编号：001用例名：系统管理员登录系统用例描述：系统管理员登录系统后，通过身份验证，能够对学生的基本信息进行管理，包括录入学生基本信息、修改学生基本信息、查询学生基本信息、删除学生基本信息，并且可以找回自己的密码。

基本路径：1、系统提示用户输入用户名和密码。

2、用户输入用户名和密码。

3、点击学生基本信息，查看学生基本信息。

4、点击修改学生基本信息，修改某位同学的基本信息。

5、点击删除学生基本信息，删除某位或多位学生信息。

6、点击添加学生信息，添加学生基本信息。

扩展点2a输入的用户名错误2a1提示用户账号不存在或者错误2a1用户离开或重新输入账号2b输入密码错误2b1提示用户密码输入错误或者是否找回密码2b2用户离开或者重新登录、找回密码。

变异点无补充说明用例编号：002用例名：教师登录系统用例描述：教师在日常管理中可以登录系统，如果忘记密码，可以找回，可以通过系统查询、修改删除学生的考试成绩。

当考试结束后，教师有权将学生成绩录入系统。

基本路径；1、系统提示用户输入用户名和密码。

2、用户输入用户名和密码。

3、点击录入学生成绩，可以录入学生成绩。

4、点击修改学生成绩，修改该学生的成绩。

5、点击查询学生成绩，查看学生的成绩。

6、点击删除学生成绩，删除学生成绩。

扩展点2a输入的用户名错误2a1提示用户账号不存在或者错误2a1用户离开或重新输入账号2b输入密码错误2b1提示用户密码输入错误或者是否找回密码2b2用户离开或者重新登录、找回密码。

变异点无补充说明用例编号：003用例名：学生登录系统用例描述：学生登录后可以进入本系统用例图，查询自己的个人基本信息。

如果忘记密码可以通过系统找回。

基本路径：1、系统提示用户输入用户名和密码。

2、用户输入用户名和密码。

3、输入个人信息，查看个人基本信息。

扩展点2a输入的用户名错误2a1提示用户账号不存在或者错误2a1用户离开或重新输入账号2b输入密码错误2b1提示用户密码输入错误或者是否找回密码2b2用户离开或者重新登录、找回密码。

用例描述模板

用例描述模板篇一：用例描述文档模板篇二：用例描述模板实验一编写用例（以下给出用例描述模板），并画出用例图（编写时可参照下面的实例）用例描述模板是一种被广泛使用的用于发现和记录需求(特别是功能需求)的机制。

写出用例是一种最好的理解和描述需求的技巧。

注意：这个模板列出可以定义用例的典型标题，但应当强调的是，实用上更重要的是专注于写出完整的可理解的事件路径，而不是按指定的模板填写每个部分。

名称用例的名称应当用简短的动词短语表达，说明用户使用用例完成的任务。

概述或简要描述单列一节概述该用例完成什么通常是有益的。

参与者列出此用例涉及的参与者和负责发起此用例执行的主要参与者。

触发器触发器是开始此用例的事件。

触发者并不必须向该系统输入事件，例如，在预约系统示例中，“预约”用例的触发者可能是“一个潜在的客户打给餐馆(来自: 小龙文档网:用例描述模板)的一个预约电话”。

而在另一种情况下，触发者可能是此用例中第一个系统事件。

前置条件前置条件概述在用例可以开始前，什么必须为真。

通常前置条件说明在指定的一个用例运行前，另一个什么用例必须运行。

典型的前置条件可以是“用户已成功登陆”。

后置条件后置条件概述当用例完成时什么是真。

在许多情况下，这将依赖于在一个特定用例实例中发生的确切的一系列交互。

区分“最低保证”和“成功保证”可能是实用的，前者描述在所有情况下发生什么和不发生什么，后者描述如果正常的事件路径成功地完成将会发生什么。

事件路径或脚本基本的或正常的事件路径，通常应当作为不中止的交互序列出现。

对事件路径中的交互通常加以编号，以便于以后的参考。

可选和例外事件路径可选和例外事件路径可以完整地写出。

然而通常只须在基本事件路径中的分叉点简单地指明可选事件流，对行为可能改变的位置予以编号，并指明导致分叉的事件。

扩展点这一节应当列出在事件路径中可能发生扩展的位置，并给出确定扩展是否发生的条件或事件。

扩展本身应当作为单独的用例写出；否则，可以指明可选的事件路径。

用例描述模板

用例模板(表单形式)e Case Description Information（用例描述信息）<以下内容定义了适用一个特定用例的信息。

每一条信息对于理解隐藏在用例后的目的都非常有用。

>名称:<一个简短的描述性动词短语给一个用例命名。

>1.2.Goal目标:<从用户的角度，用几句话描述这个用例的终极目标。

>e Case Team Leader/Members用例负责人及其成员:<这是定义一个负责完成这个用例的人，及其团队成员。

>1.4.Pre-condition前置条件:<在开始执行这个用例的路径之前，系统必须达到的状态。

当进行路径层的分析时，这些应该会被深化>1.5.Post-condition后置条件:<当用例的路径完成后，系统必须达成的状态。

当进行路径的分析时，这些可能会被深化。

>1.6.Constraints/Issues/Risks约束/问题/风险:<当进行用例细节的设计时，这里的任何一条都会增加开发团队的负担。

当进行路径的分析时，这些可能也会被深化。

把每个问题指派给具体的个人也许会带来好处。

>1.7.Trigger Event(s)驱动用例的事件:<外部事件或内部时钟事件可以触发一个穿过用例的路径。

这些事件也可以在每个路径分析时定义。

>1.8.Primary Actor主要活动者:<这个关键活动者参与进这个用例中。

典型地，这个个体是触发用例路径的事件来源。

>1.9.Secondary Actor(s)次要活动者:<其他活动者，在用例中充当一定的角色。

>e Case Pathway Names用例路径名称:<这些代表路径的名称列表，它们只是作为下面部分路径细节描述的一个总览列表。

>2.1.Primary Path(Happy Path)主要路径（愉快路径）:<这是这个用例最经常发生的路径。

用例及用例描述

用例图用例描述用例：留言ID：1简单描述：用户在本网站留言板上进行留言（咨询）主参与者：user副参与者：数据库前置条件：本网站被打开且用户有留言需要主流：i)用户打开本网站ii)进入留言板页面iii)在留言板对话框内发布信息iv)点击确定，完成留言后置条件：用户留言成功附加流：数据库添加失败时提醒错误原因并询问是否重新留言用例：搜索ID：2简单描述：在本网站进行所需信息的搜索主参与者：user副参与者：数据库前置条件：本网站被打开且用户有搜索信息的需要主流：i)用户打开本网站ii)在网站搜索引擎中键入搜索条件或直接按类别搜索iii)点击确定，完成搜索iv)得到预期信息，用户可以对所得信息进行浏览后置条件：搜索完成并且用户得到预期信息附加流：搜索数据库无结果，提示原因并询问是否重新搜索用例：回复ID：3简单描述：客服对用户的留言板提问或留言进行回复主参与者：客服副参与者：数据库前置条件：有用户在留言板上提问或留言主流：i)客服登录网站后台ii)进入留言板回复页面iii)点击回复，在出现的对话框内键入回复内容iv)点击确定，完成回复后置条件：客服回复信息成功附加流：数据库添加失败时提醒错误原因并询问是否重新回复ID：4简单描述：普通管理员将最新资讯信息添加到网站数据库中主参与者：普通管理员副参与者：数据库前置条件：网站有最新的咨询信息需要添加主流：i)普通管理员登录网站后台页面ii)将最新资讯信息录入到数据库中iii)点击确定完成录入后保存所作修改iv)修改成功后关闭后台页面后置条件：最新资讯信息成功添加到数据库中附加流：添加信息出错时数据库提示出错信息用例：删除网站信息ID：5简单描述：普通管理员将废旧资讯信息从网站数据库中删除主参与者：普通管理员副参与者：数据库前置条件：网站有废旧的咨询信息需要删除主流：i)普通管理员登录网站后台页面ii)查询废旧的资讯信息iii)将废旧资讯信息从数据库中删除iv)点击确定完成删除后保存所作修改v)删除成功后关闭后台页面后置条件：废旧资讯信息成功从数据库中删除附加流：删除信息出错时数据库提示出错信息ID：6简单描述：普通管理员对网站数据库中数据进行修改主参与者：普通管理员副参与者：数据库前置条件：网站有待修改的数据信息需要修改主流：i)普通管理员登录网站后台页面ii)查询待修改的资讯信息iii)对待修改资讯信息进行修改iv)点击确定完成修改后保存所作修改v)修改成功后关闭后台页面后置条件：待修改资讯信息在数据库中修改成功附加流：修改信息出错时数据库提示出错信息用例：查询网站信息ID：7简单描述：对数据库中的网站信息通过不同条件进行搜索查询主参与者：普通管理员副参与者：数据库前置条件：已确定要查询信息的关键字主流：i)普通管理员登录网站后台页面ii)根据搜索关键字对信息进行搜索iii)搜索成功，显示查询到的语句后置条件：信息查询成功，得到所查信息详情附加流：搜索失败，未能得到要查询信息并提示出错信息用例：删除留言ID：8简单描述：对数据库中的留言进行删除管理主参与者：普通管理员副参与者：数据库前置条件：存在不合法留言信息，普通管理员需要对其进行删除操作主流：i)普通管理员登录网站后台页面ii)在数据库中查询到不合法的留言信息iii)对不合法留言信息进行删除操作iv)点击确定完成操作后进行保存v)保存后关闭后台页面后置条件：不合法留言信息得以成功删除附加流：删除留言信息失败并提示出错信息用例：查询留言ID：9简单描述：对数据库中的留言信息进行查询检索主参与者：普通管理员副参与者：数据库前置条件：确定要检索留言信息的关键字主流：i)普通管理员登录网站后台页面ii)根据不同的检索条件对留言信息进行查询iii)成功检索到所要查询留言信息并显示信息详情后置条件：所要查询留言信息得以成功检索附加流：未能查询到所要查询的留言信息并提示出错信息用例：登录ID：10简单描述：网站的超级管理员、普通管理员和客服登录进本网站后台主参与者：超级管理员、普通管理员，客服副参与者：无前置条件：各种管理员需要进入后台进行各种信息维护主流：i)进入网站后台管理页面ii)键入预先分配好的帐号和密码iii)点击登录，进入后台iv)登录成功后置条件：各种管理员登录后台成功附加流：登录出错时提示出错信息用例：创建管理员用户ID：11简单描述：超级管理员创建一个新的管理员用户（普通管理员、客服）主参与者：超级管理员副参与者：数据库前置条件：网站需要新建一个管理员用户主流：i)超级管理员登录网站后台页面ii)创建一个新的管理员用户（帐号，密码）iii)点击确定完成新管理员用户的创建，数据库进行保存iv)创建成功后关闭后台页面后置条件：网站得到一个新的普通管理员用户或客服用户附加流：创建失败时数据库提示出错信息用例：删除管理员用户ID：12简单描述：超级管理员删除一个管理员用户（普通管理员、客服）主参与者：超级管理员副参与者：数据库前置条件：网站需要删除一个管理员用户主流：i)超级管理员登录网站后台页面ii)删除一个管理员用户（帐号，密码）iii)点击确定完成管理员用户的删除，数据库进行保存iv)删除成功后关闭后台页面后置条件：删除一个普通管理员用户或客服用户成功附加流：删除失败时数据库提示出错信息用例：设置管理员权限ID：13简单描述：超级管理员对网站中的管理员设置权限主参与者：超级管理员副参与者：数据库，普通管理员，客服前置条件：需要对网站内的普通管理员和客服进行区分，对他们分别设置不同的权限主流：i)超级管理员登录网站后台页面ii)对普通管理员设置权限，令其能对网站信息进行增、删、改、查以及对游客留言信息（不合法）进行查询和删除对客服设置权限，令其只能对游客的留言或提问信息进行回复iii)点击确定完成权限设置，数据库进行保存iv)设置成功后关闭后台页面后置条件：普通管理员或客服的权限设置成功附加流：权限设置失败时数据库提示出错信息用例：查看管理员用户信息ID：14简单描述：超级管理员对普通管理员用户或客服用户的信息进行查看主参与者：超级管理员副参与者：数据库前置条件：需要查看管理员用户信息主流：i)超级管理员登录网站后台页面ii)对指定普通管理员用户或客服用户的信息进行查询iii)显示指定管理员用户信息后置条件：管理员信息查询成功，得到所查信息详情附加流：查询信息失败时数据库提示出错信息。

用例描述

LAST NAME：Hatzayar TIILE：Walker_Bay
SUGG．PRICE：161，250 PURCHASE PRICE：205，000
——————————————————————————————————
CLASSIFICATION：*Other PURCHASE DATE：07/13/2003
TRENDS
Artist：David Hatzayar
——————————————————————————————————
CLASSIFICATION：Masterwork TIILE：Table_Mountain
SALE DATE：05/11/2003
TARGETPRICE：264，450 SALEPRICE：270，000
分类
购买日期
画家姓氏
油画名称
建议的最大购买价格
实际购买价格
任何以超过由算法确定的最大购买价格的价格购买的油画必须标记出来。
该报告必须依据分类和分类中的购买日期排序存储。
在报告末尾应该显示报告中所有油画的实际购买价格与算法建议的最大购买价格之间的平均比率。
Report Date：08/14/2004
Osbert Oglesby – Collector of Fint Art
2.1对于名品：
信息系统首先把该油画看作是同一位画家的精品来计算最大购买价格。然后，如果油画是在21世纪绘制的，则用该数字乘以0.25；否则，用该数字乘以
（21－c）/（22－c），其中c代表作品是在哪个世纪绘制的（12＜c＜21）。
2.1对于其他油画：
信息系统通过公式Ｆ×A来计算最大购买价格，其中Ｆ是针对那位画家的一个常数(流行度系数)，A是以平方厘米为单位的油画布的面积。如果那位画家没有流行度系数，Osbert将不会购买该油画。

测试方案的系统测试用例描述

测试方案的系统测试用例描述1.引言1.1 概述概述部分的内容可以如下所示：在软件开发过程中，系统测试是非常重要的一环。

通过系统测试，我们能够验证软件系统是否满足预期的功能需求和性能指标，并且能够发现潜在的问题和缺陷。

为了有效地进行系统测试，一个明确的测试方案是必不可少的。

测试方案是针对软件系统的整体测试过程进行规划和组织的指导性文档，它包含了测试的目标、范围、策略、资源和时间安排等内容。

其中，系统测试用例描述是测试方案中的一个重要组成部分。

系统测试用例描述用于描述系统测试的具体场景、输入和预期输出，通过执行这些用例，可以检验系统的各项功能是否符合设计要求。

系统测试用例描述需要具备一定的准确性、完整性和可读性。

一个好的用例描述应当能够清楚地说明用例的测试目标、测试条件、操作步骤以及预期结果。

通过详细而准确的用例描述，可以帮助测试人员进行测试过程的有效执行，提高测试效率，同时也有助于团队成员之间的沟通和理解。

在编写系统测试用例描述时，需要从不同的维度考虑进行测试，如功能测试、性能测试、安全测试等。

对于复杂的系统，可能涉及到多个层次、多个模块和多个功能点的测试，因此需要对用例进行分类、组织和管理，以确保测试的全面性和有效性。

综上所述，系统测试用例描述在测试方案中具有重要的地位和作用。

通过精心编写和执行测试用例，可以帮助我们发现系统中的问题和风险，从而提高软件质量和用户体验。

因此，在进行系统测试时，我们应当充分重视系统测试用例描述的编写和管理工作。

1.2 文章结构本文将按照以下结构进行论述：1. 引言部分将概述本文的主题以及文章的目的，引导读者了解本文的背景和意义。

2. 正文部分将重点介绍系统测试的概念和测试方案的重要性。

首先，将解释系统测试的概念，包括其定义和目的，并探讨其在软件开发生命周期中的作用。

随后，将详细探讨测试方案的重要性，包括其对软件质量保证的影响以及在项目开发过程中的必要性。

3. 结论部分将总结系统测试用例描述的重要性，并提出对测试方案的建议。

SRS用例描述

2、人数已达上限的具体科目能否增加一个等待队列，当有人取消报名时等待队列靠前的学生就可以获得选报机会。
用例描述1-6：“修改密码”用例描述
用例
修改密码
启动者
学生or管理员
支持者
主要流程
1、已通过验证的用户点击自己界面上的“修改密码”按钮，进入到修改密码的界面。
2、用户输入自己的旧密码。
3、用户输入新设的密码。
5、考试系统检查学生已报科目在时间上是否与选报其他科目有冲突，未检测到。
6、考试系统同意学生选报该科目，将该科目添加到学生的个人信息表中，同时使该科目的已选人数+1。
7、重复步骤1~6，直到学生结束选报。
替代流程
科目已选满：提醒学生，并取消选报操作，回到主界面。
学生无选报资格：提醒学生，并取消选报操作，回到主界面。
用户名验证失败：在连接数据库验证信息时，如果在所选身份中找不到用户输入的用户名，给予提示：“用户名不存在”，并让用户重新输入。
密码验证失败：在连接数据库验证信息时，如果在所选身份中找到所输用户名，但是输入的密码和正确密码不一致，给予提示：“密码错误”，并让用户重新输入。
学院规则
CR1：用户身份一共二种，分别为：学生、管理员。
2、学生可以在主界面上看到自己的学号、姓名、性别以及考试科目信息。
3、学生单击主界面上的“查看报考科目”按钮，可以在弹出窗口中看到自己已报科目情况。
替代流程
无
学院规则
CR4：一名学生获成绩达到或超过规定的及格分时才能通过考试，如果有超过的部分也没有额外的奖励。
用例描述1-3：学生“查看科目信息”用例描述
3、当学生点击另一行具体科目后，科目详细信息栏又将改变成点击科目的详细信息。