用例文档示例
字段列表 1. 几何特征包括内径、外径、螺距、形状等，不同类型的零件，表征所用的几何特征不同。 2. 零件的详细信息包括：零件编号，库存量，类别，几何特征，价格。
UC2：注册 用例描述
潜在会员注册成为会员。 参与者
潜在会员（首要） 前置条件
Actor 访问系统 后置条件
业务规则 1、添加到已有订单时，系统要检测并合并有相同商品的订单项。
UC5：管理订单 用例描述
会员对订单进行管理。 参与者
会员 前置条件
会员已经登录 后置条件
成功管理订单 基本路径 1. 会员请求查看订单 2. 系统显示会员的订单列表 3. 会员可以选择以下动作：
取消一张订单 4. 会员请求查看某张订单 5. 系统显示该订单明细 6. 会员可以选择以下动作：
UC1：检索零件 用例描述
Actor 根据零件的类别、编号以及几何特征信息（如形状、大小），检索出所需零件的详 细信息和价格。 参与者
潜在会员（首要），会员 前置条件
Actor 访问系统 后置条件
Actor 查询到所要的零件 基本路径 1. Actor 提交零件的类别、编号、几何特征查询条件 2. 系统按查询条件检索零件信息和价格信息 3. 系统显示搜索到零件的编号、类别、价格 4. Actor 选中某个零件 5. 系统显示该零件的详细信息 扩展点 2a. 系统没有检索到所需零件。
UC8：从联系地址簿中取地址 级别：子用例 用例描述
从会员的地址簿中取出地址 参与者
会员 前置条件
会员已经登录 后置条件
会员取出地址 基本路径
1. 会员请求打开地址簿 2. 系统显示该会员地址簿 3显示“账户未打开，不能结账”信息 4a. 库存不能满足
4a1. 系统显示不能满足库存的订单项 4a2. 会员修改订单项数量 2a. 会员提交信息不充分 2a1. 系统告知会员需要补充的信息 2a2.管理订单 7a. 会员修改订单 7a1.管理订单
业务规则 订单总价＝所有订单项价钱合计＋税金＋运费
6c1a. 会员从联系地址簿中取地址 6c2. 系统修改订单的送货地址 6d. 结账
业务规则 1. 在扩展点 6b 中，如果某订单项数量为 0，系统删除该订单项。
UC6：结账 用例描述
会员完成一次与商店的交易 参与者
会员 前置条件
会员已经完成选购 后置条件
把发货信息告知供应商发货 基本路径 1. 会员请求结账 2. 系统检查会员提交的信息是否充分 3. 系系统检查账户是否处于打开状态 4. 系统检查库存是否满足 5. 系统合计订单总价 6. 系统显示收费明细 7. 会员确认 8. 系统保存订单信息，通知供应商发货，减少相应库存数量。 扩展点 3a. 账户未打开
1. 会员信息包括：公司名、联系人、电话、传真、Email，以及若干个联系地址。 2. 一个会员可以有多个联系地址，其中一个为首选联系地址。联系地址包含以下信息： 州、城市、街道、邮编。 3. 会员订单的送货地址可以从会员联系地址中获取。
UC3：会员登录 用例描述
会员提供身份信息以通过系统验证。 参与者
系统记录会员信息，等待经理开放账户 基本路径 1. Actor 请求注册。 2. 系统显示注册界面。 3. Actor 提供会员信息。 4. 系统检查信息是否充分。 5. 系统保存会员信息。 6. 系统显示“注册成功，等待开放账户”信息。 扩展点 4a. Actor 提供的信息不充分。
4a1. 系统提示输入剩余信息 字段列表
从订单中删除某个订单项 会员修改某个订单项的购买数量 会员改变订单的送货地址 结账 扩展点 3a. 会员取消订单 3a1. 会员请求取消一张订单 3a2. 系统删除该订单 6a. 会员从订单中删除订单项 6a1. 会员请求从订单中删除某个订单项 6a2. 系统删除该订单项 6b. 会员修改订单项的购买数量 6b1. 会员修改某个订单项的购买数量，请求更改 6b2. 系统修改该订单项的购买数量 6c. 会员改变订单的送货地址 6c1. 会员修改订单的送货地址，请求更改
会员（首要） 前置条件
Actor 访问系统 后置条件
会员通过验证 基本路径 1. Actor 提交用户名，密码。 2. 系统验证用户名和密码。 3. 系统显示带有会员信息（姓名、账户余额）的检索零件界面。 扩展点 2a. Actor 提供的用户名不存在。
2a1. 系统显示“用户名不存在”信息，询问 Actor 是否注册 2a2. Actor 注册 2b. Actor 提供的密码错误。 2b1. 系统显示“密码错误”信息。
UC4：购物 用例描述
Actor购买某种零件 参与者
会员 前置条件
会员已经登录 后置条件
所选购零件进入订单 基本路径 1. 会员检索零件 2. 会员请求购买某种零件 3. 系统提示会员输入购买数量，显示会员订单列表 4. 会员输入购买数量，选择以下动作：
添加到新订单 添加到已有订单 5. 系统显示当前订单 扩展点 4a. 会员请求将所选购零件添加到新订单 4a1. 会员输入送货地址 4a2. 系统生成新订单，并加入新的订单项 4b. 会员请求将所选购零件添加到已有订单 4b1. 会员选中订单，请求添加订单项 4b2. 系统添加订单项
UC7：开放账户 用例描述
经理开放会员的账户 参与者
经理 前置条件
已得到银行确认信息，经理已经登录 后置条件
会员账户开放 基本路径 1. 经理检索会员 2. 经理选中会员，开放账户 3. 系统开放会员账户 扩展点
业务规则 如果是新会员，系统要生成用户名和密码，并把用户名和密码通知会员；如果是暂时被关闭 的老会员，系统发送账户开放通知。
测试用例文档
用例名称
验证是否符合图书馆管理的要求
用例编号
项目名称
图书馆管理系统测试用例子
编号/版本
参考信息
软件工程测试
测试目的
验证当用户点击登陆按钮，是否能够登陆系统，并提示用户输入用户名和密码
验证当用户点击注册按钮，能否注册成功，并提示输入用户名、姓名、密码、确认密码及邮箱
验证用户注册成功时的用户名和邮箱
环境要求
Win2000server操作系统、Oracle数据库、是图书借阅系统合法用户，选择登陆功能，并有用户名为hugo，密码为111111
用例引用
无
步骤
操作描述
输入
期待输出
1
2
选择要借阅的图书
借阅图书量超出六本
输入图书名称
输入六本书
库存图书数量不足！
对不起，您已超出最大借阅量
开发人员
张琼
测试人员
环境要求
Win2000server操作系统、Oracle数据库、是图书在线交易系统合法用户，选择登陆功能，并有用户名为David，密码为空
用例引用
无
步骤
操作描述
输入
期待输出
1
2
输入用户名，按确定
输入用户名，密码，确认密码，按注册
用户名为David
密码为123，确认密码123，
显示警告信息“请输入密码！
图书馆管理系统测试用例子
测试目的
验证当用户输入的正确用户名和正确密码，是否能够登陆系统，并提示用户登陆成功
验证当用户输入的正确用户名、密码、确认密码。邮箱，是否能够提示用户注册成功
环境要求
Win2000server操作系统、Oracle数据库、是图书在线交易系统合法用户，选择登陆功能，并有用户名为David，密码为111111
用例描述文档模板
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秒之内
用例文档范例
用例文档用例编号UC001用例名称订餐参与者客户过程描述用例起始于用户想要订餐，客户点击系统提供的订餐功能键，系统显示可供选择的餐品信息，客户填写相应餐品的份数，并填好送餐地址、联系电话、送餐时间、其他要求（粗斜体字未必填内容）后，提交订单。
系统根据业务规则BR_E001Celerity营业时间规则，判断该订单是否在营业时间内，以及业务规则BR_E003 Celerity订餐时间和送餐时间间隔规则，判断该订单的送餐时间是否有效。
系统保存有效订单、废弃无效订单，并对客户进行反馈。
基本流程参与者的动作系统动作1）用例起始于用户想要订餐，客户通过UIC000客户专业功能页面，点击系统提供的订餐功能键。
2）系统通过UIC001客户订餐页面，显示可供选择的餐品信息。
3）客户通过UIC001客户订餐页面，填写相应餐品的份数，并填好送餐地址、联系电话、送餐时间、其他要求（粗斜体字未必填内容）后，提交订单。
4）系统根据业务规则BR_E001Celerity营业时间规则，判断新订单是否在营业时间内，以及业务规则BR_E003 Celerity订餐时间和送餐时间间隔规则，判断新订单的送餐时间是否有效。
5）系统保存有效订单，并通过UIC801订餐成功返回页面，对客户进行反馈。
分支流程第4步验证订单为无效状态时5）系统废弃无效订单，并通过UIC901订单无效返回页面对客户进行反馈。
6）客户可以通过UIC901订单无效返回页面选择重填或放弃。
7）系统根据用户的选择返回UIC001客户订餐页面，或UIC000客户专业功能页面。
用例编号UC004用例名称修改订单参与者客户过程描述用例起始于想要修改订单，客户点击系统提供的修改订餐功能键，系统对满足业务规则BR_C001客户订单修改规则的订单进行修改。
基本流程参与者的动作系统动作1）用例起始于想要修改订单，客户通过UIC000客户专业功能页面，点击系统提供的修改订单功能键。
2）系统将客户提交的满足业务规则BR_C001客户订单修改规则的未处理订单,通过UIC012客户修改订单页面显示出来。
用例文档single
1.1.1系统模块
1.1.1.1 XT002_支行网点
一、用例描述
目标系统现有《支行网点》功能存在定位不准的问题，将根据原有代码进行更改，若原有代码不能达成目标时，全新开发。
该功能的目的是通过用户发送当前位置，根据现有支行网点的GPS数据，计算出最近的一家支行网点作主图文，附件的3家支行网点和分行作辅助图文，发送到粉丝微信端。
二、终端类型
手机
三、参与者
粉丝
四、前置条件
无
五、流程图
六、基本事件流
1.粉丝在微信端发送当前所在位置
2.系统根据现有支行网点的GPS数据，计算出最近的一家支行网点作主图文，附近的
3家支行网点和分行作辅助图文，发送到粉丝微信端
七、可选事件流
无
八、结束状态
微信端能够正确显示出附近的四家支行网点。
其中一个网点作为主图文，另外三个作为辅图文在微信端显示
九、补充说明
无
十、更新记录
1.创建人：胡云飞创建日期：2016-12-20
2.更新人：更新日期：
更新内容：。
软件测试用例模板一详细用例经典
软件测试用例模板一详细用例经典1.用例名称：用户登录用例描述：测试用户登录功能是否正常。
先决条件：用户已注册并拥有登录账号及密码。
步骤：1.打开应用程序。
2.点击“登录”按钮。
3.输入正确的用户名和密码。
4.点击“登录”按钮。
期望结果：1.应用程序成功打开。
2.能够正确跳转到登录页面。
3.用户名和密码能够成功输入。
4.可以成功登录到用户账号。
2.用例名称：用户注册用例描述：测试用户注册功能是否正常。
先决条件：用户未注册过账号。
步骤：1.打开应用程序。
2.点击“注册”按钮。
3.输入需要注册的用户名和密码。
4.点击“注册”按钮。
期望结果：1.应用程序成功打开。
2.能够正确跳转到注册页面。
3.用户名和密码能够成功输入。
4.注册后能够成功登录到用户账号。
3.用例名称：发送邮件用例描述：测试发送邮件功能是否正常。
先决条件：用户已登录。
步骤：1.打开邮件功能页面。
2.点击“新建邮件”按钮。
3.输入邮件主题、收件人和内容。
4.点击“发送”按钮。
期望结果：1.邮件页面正常打开。
2.能够成功打开新建邮件页面。
3.邮件主题、收件人和内容能够成功输入。
4.邮件发送成功并能够成功保存到发件箱。
4.用例名称：接收邮件用例描述：测试接收邮件功能是否正常。
先决条件：用户已登录，并有发送给用户的邮件。
步骤：1.打开邮件功能页面。
2.点击“收件箱”按钮。
3.选择并打开一封邮件。
4.阅读邮件内容。
期望结果：1.邮件页面正常打开。
2.能够成功进入收件箱。
3.能够成功选择并打开邮件。
4.邮件内容能够正常显示，并且可以正常阅读。
5.用例名称：退出登录用例描述：测试退出登录功能是否正常。
先决条件：用户已登录。
步骤：1.打开应用程序。
2.点击“退出登录”按钮。
期望结果：1.应用程序成功打开。
2.能够正常退出登录，并返回到登录页面。
以上是对于软件测试用例模板一的一个示例，用例名称根据实际情况进行命名，用例描述详细描述了用例的功能和先决条件，步骤中列出了实现该功能的具体步骤，期望结果描述了每个步骤的预期结果。
用例(UC)文档模板
类型|长度
排序
规则
界面元素——按钮
名称
规则
界面元素——<其他>：<通用描述>
名称
<……>
规则
业务规则
序号
规则
1
（UC通用规则写在这里，流程中某步的私有规则写在流程中）
流程描述
流程1（主流程）：<流程名称>
触发事件：<触发事件>
时序图or 活动图（尽量用图表达，下面的文字描述可选）
步骤
用户
系统
规则
用例id用例概述业务描述商业目标用户目的等业务内容需求描述产品需求需要实现哪些功能点行为者该用例的actor前置条件preconditions后置条件postconditions其他说明任何其他的说明信息等界面描述ui示意图
用例概述
业务描述
<商业目标，用户目的等业务内容>
需求描述
<产品需求，需要实现哪些功能点>
行为者
<该用例的Actor>
前置ቤተ መጻሕፍቲ ባይዱ件
<Pre-Conditions>
后置条件
<Post-Conditions>
其他说明
<任何其他的说明信息等>
界面描述
UI示意图：<页面名称>
<Demo截图1>
<截图说明1>（给出Demo文件的地址）
界面元素——表单：<表单名称>
名称
类型|长度
必填
默认值
规则
√
界面元素——列表：<列表名称>
1
2
分支流程1-1
1
测试用例的案例分析
测试⽤例的案例分析⼀、测试⽤例经典案例1：纸杯的测试⽤例规格：（1）能放多少⽔，是否符合需求。
（2）底盘直径是多少，是否符合标准。
（3）存放时间和存放的环境。
（4）不能装哪些液体。
性能：（1）底盘是否平稳。
（2）是否会漏⽔（时间、温度、液体<兼容性测试>）。
（3）是否容易变形，硬度是否⾜够（压⼒测试）。
（4）是否环保，是否会产⽣化学反应，产⽣有毒物质（安全测试）。
（5）从不同⾼度摔下来的损坏程度（压⼒测试）。
界⾯：（1）界⾯设置是否吸引客户。
（2）是否有相应的提⽰。
（3）图标布局是否合理。
（4）纸杯上的字体是否美观，是否有错别字。
（5）纸杯的图标、⽂字等印刷是否完整。
（6）图案是否容易脱落。
⼈性化：（1）⽔杯的⼿感如何，⼝感如何（易⽤性）。
（2）是否有利于叠在⼀起存放，使⽤时是否容易分开。
（3）外观是否适合拿起。
2：购物车的测试⽤例界⾯：（1）打开淘宝购物车页⾯后，页⾯的布局是否合理，是否完整。
（2）不同卖家的商品在不同的区域显⽰，区分是否明显。
（3）页⾯的功能按钮是否可以正常显⽰。
（4）商品的最下⽅是否可以显⽰失效宝贝。
（5）页⾯的最低端是否显⽰“你可能喜欢”。
（6）向下滑动页⾯，在购物车顶端是否展⽰购物车。
（7）购物车中如果存在有商品降价、库存不⾜、限购件数等，在商品详情下⾯，是否有对应字体展⽰。
功能：（1）购物车页⾯的所有连接是否正常。
（2）从商品信息页⾯添加的商品是否能显⽰在购物车中。
（3）如果没有登录，点击购物车中的商品直接进⾏结算，是否会提⽰⽤户输⼊⽤户名和密码，或者提⽰⽤户进⾏注册。
（4）如果没有选择任何商品时，点击结算，是否提⽰⽤户“请添加要结算的商品”。
（5）勾选商品后，已选商品的总价和优惠满减活动是否会显⽰。
（6）勾选商品，点击结算按钮后，是否可以进去确认订单信息页⾯。
（7）购物车页⾯中，是否可以对添加的商品信息进⾏修改，并⾃动保存成功。
（8）是否可以在购物车中重新修改商品规格。
用例文档示例
UC2：对成绩排名 用例描述
参与者 教师（首要） 前置条件 教师已经登录；成绩已经存在 后置条件
系统已经保存、或打印、或显示排名结果 基本路径 1. 教师提交学生范围、成绩范围、排名方式 2. 系统对成绩排名。 3. 系统显示排名结果 4. 教师可以选择以下动作： 打印 保存 扩展点 2a. 排名时间超时： 2a1. 系统提示正在处理，询问是否继续 2a2. 教师可以选择以下动作 取消 继续 2a2a. 教师选择“取消”： 2a2a1. 用例结束 2a2b. 教师选择“继续”： 2a2b1. 系统继续排名 4a. ×××： 4b. ×××： 补充说明 1. 学生范围。。。排名方式（升降序、） 2. 排名规则：主要科目… 3. 应显示信息为：年级、姓名… 2a. 超时时间为 2 分钟 待解决问题
用例文档示例
用例文档示例（零件销售系统）
参与者
潜在会员：没有注册的顾客，他们的权限受到限制，只能检索零件，不能购买。 会员：已经注册的顾客 经理：商店的管理人员 货管员：商店专职管理货物的人员 时间
UC1：分析成绩 用例描述 参与者
统计人员 前置条件
统计人员已经登录 后置条件
系统已经显示分析结果 基本路径
UC3：检索零件 用例描述
参与者根据零件的类别、编号以及几何特征信息，检索出所需零件的详细信息和价格。 参与者
潜在会员（首要），会员 前置条件
参与者访问系统 后置条件
参与者查询到所要的零件 基本路径
1. 参与者提交查询条件 2. 系统按查询条件检索零件 3. 系统显示搜索到零件的编号、类别、价格 4. 参与者选中某个零件 5. 系统显示该零件的详细信息 扩展点 2a. 系统没有检索到所需零件：
待解决问题
用例参考模板
4．系统添加新的图书书号。
可选操作流程
（可能有4个可选操作流程）
系统检查图书书目不存在，系统添加新的图书书目；
被泛化的用例
无
被包含的用例
无
被扩展的用例
无
修改历史记录
张三，定义基本操作流程，2004年3月20日
张三，定义可选操作流程，2004年3月20日
修改历史记录[可选]
关于用例的修改时间、修改原因和修改人的详细信息
问题[可选]
与此用例的开发相关的问题列表
决策[可选]
关键决策的列表，将这些决策记录下来以便维护时使用
频率[可选]
参与则访问此用例的频率，如用户是每日访问一次还是每月访问一次
用例“处理订单”的描述
用例名称
处理订单
标识符
UC1701
用例描述
可选操作流程
（可能有4个可选操作流程）
顾客来订购一个吉他，并且使用汇票的方式…..
顾客来订购一个风琴，并且提供信用卡作为支付手段……
顾客使用信用卡下订单，但那张信用卡是无效的…….
顾客来下订单，但他想要的商品没有存货……
被泛化的用例
无
被包含的用例
无
被扩展的用例
无
修改历史记录
张三，定义基本操作流程，2004年3月20日
张三，定义可选操作流程，2004年3月28日
用例“添加图书”的描述
用例名称
添加图书
标识符
UC0001
用例描述
图书管理员在收到新采购的图书后对之进行入库。
参与者
图书管理员
优先级
1
状态
通过审查
前置条件
图书管理员登录进入系统
用例文档（最终版）
用例文档（最终版）超市运营管理系统系统用例文档超市运营管理系统开发小组：姓名学号罗振强20刘发胜48徐壁38黄伟浩392010月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 超市运营系统顶层用例图会计员顾客经理图22 用例说明超市运营系统登陆系统用例图UC1 ：身份验证范围：登陆系统级别：用户目标用例描述：超市员工要进入系统的时候，首先要通过身份验证，验证成功后才能进入系统。
登陆成功后系统根据员工的职能权限判断验证员工的身份并进入相应的系统界面。
参与者：员工前置条件：输入员工正确后置条件：登陆相应的系统成功涉众及其关注点：员工：希望能够准确地输入员工号，成功登陆相应的系统。
基本路径：1. 输入员工号2. 系统验证员工信息1.验证失败，返回12.进入相应的系统界面扩展点：销售系统，采购系统，财务系统补充说明：要确保输入员工号准确，才能成功登陆相应的系统对应的用例图图3超市运营系统销售系统用例图销售管理子系统：UC2 ：录入商品信息范围：销售系统级别：子功能（销售管理）用例描述：售货员按顾客提交的购买商品，录入商品的条形码，系统根据条形码查询商品，并计算数量，返回信息。
并修改销售情况表和仓库表。
参与者：销售员前置条件：修改销售情况表成功后置条件：修改仓库表涉众及其关注点：销售员：希望能够准确地录入商品信息，成功修改销售情况表和仓库表。