用例描述模板--整合2018-12-22
用例模板
6、非功能性需求：
可用性：<容易学习、容易使用，例如多长时间内可以学会，多少操作可以完成><优先级别><状态跟踪>
安全性：<保护硬件、软件和数据不因偶然和恶意的原因遭到破坏、更改和泄露><优先级别><状态跟踪>
可靠性：<可靠性是指系统能够保持正常运行的能力><优先级别><状态跟踪>
2.2备选场景:<被改变的步骤><条件><优先级别><状态跟踪>
<步骤编号><动作描述>
2.3异常场景:<被改变的步骤><条件><优先级别><状态跟踪>
<步骤编号><动作描述>
3、数据实体：<实体名称>
<实体属性><数据规则>
4、业务规则：<业务要求的规则>
5、设计约束：
界面样式：<对界面特殊要求，必须采用什么样的界面格式><优先级别><状态跟踪>
1.3参与者：<要求系统实现某个目标的人员，通常由主参与者发起与系统的交互>
1.4利益相关者：<利益人名称><所获利益>
1.5前置条件：<用例执行需要达到什么条件，必须是系统能检测到的>
1.6后置条件：<用例执行后系统所处的状态>
1.7触发事件：<什么引发了用例>
2、用例场景
用例描述文档模板
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秒之内
用例说明
二．用例描述1.信息查询用例名称：信息查询用例描述：学生到教务系统中查询有关信息参与者：学生前置条件：学生已经登录到系统中后置条件：教务系统中存在相关信息基本操作流程：1.学生登录系统；2.系统验证学生身份；3.学生请求查询信息；4.系统接收请求，显示信息；可选操作流程：2-（1）、如果学生密码输入错误，系统验证学生身份错误，返回第一步，学生重新登录。
被包含的用例：无被泛化的用例：无被扩展的用例：无。
2.网上选课用例名称：网上选课用例描述：学生登陆教务系统进行网上选课。
参与者：学生前置条件：学生已经登录到系统中后置条件：教务系统中存在相关信息基本操作流程：1.学生登录系统；2.系统验证学生身份；3.学生请求网上选课；4.系统接收请求，显示信息；可选操作流程：如果学生密码输入错误，系统验证学生身份错误，返回第一步，学生重新登录。
被包含的用例：无被泛化的用例：无被扩展的用例：无。
3.网上报名用例名称：网上报名参与者：用例描述：学生登陆教务系统进行网上报名前置条件：学生已经登录到系统中后置条件：教务系统中存在相关信息基本操作流程：1.学生登录系统；2.系统验证学生身份；3.学生请求网上报名；4.系统接收请求，显示信息；可选操作流程：如果学生密码输入错误，系统验证学生身份错误，返回第一步，学生重新登录。
被包含的用例：无被泛化的用例：无被扩展的用例：无4.教学质量评估用例名称：教学质量评估用例描述：学生到教务系统进行教学质量评估参与者：学生前置条件：学生已经登录到系统中后置条件：教务系统中存在相关信息基本操作流程：1.学生登录系统；2.系统验证学生身份；3.学生请求进行教学质量评估；4.系统接收请求，显示信息；可选操作流程：如果学生密码输入错误，系统验证学生身份错误，返回第一步，学生重新登录。
被包含的用例：查询教师信息被泛化的用例：无被扩展的用例：无5.课表查询用例名称：课表查询用例描述：学生发出学生个人课表查询请求，系统接收后显示该学生指定学期内课表参与者：学生前置条件：用户已经登陆系统，系统数据库存在各人各学期课表信息后置条件：学生获取其个人指定学期课表基本操作流程：1. 学生发出学生个人课表查询请求2. 系统接受，整合该学生指定学期课表3. 学生查看完关闭可选操作流程：如果数据库不存在课表信息，则输出“课表不存在”，返回上一级菜单选择被包含的用例：无被泛化的用例：无被扩展的用例：信息查询6.考试查询用例名称：考试查询用例描述：学生发出学生考试查询请求，系统接收后显示考试的相关信息，如时间地点等参与者：学生前置条件：用户已经登陆系统，系统数据库存在该学生考试信息后置条件：学生获取其考试相关信息基本操作流程：1. 学生发出学生考试查询请求2. 系统接受，整合该学生考试相关信息3. 学生查看完关闭可选操作流程：如果数据库不存在该学生考试相关信息，则输出“考试信息不存在”，返回上一级菜单选择被包含的用例：无被泛化的用例：无被扩展的用例：信息查询7.成绩查询用例名称：成绩查询用例描述：学生发出学生成绩查询请求，系统接收后显示考试的相关信息，如科目，分数等参与者：学生前置条件：用户已经登陆系统，系统数据库存在该学生成绩信息后置条件：学生获取其成绩相关信息基本操作流程：1. 学生发出学生成绩查询请求2. 系统接受，整合该学生成绩相关信息3. 学生查看完关闭可选操作流程：如果数据库不存在该学生成绩相关信息，则输出“成绩不存在”，返回上一级菜单选择被包含的用例：无被泛化的用例：无被扩展的用例：信息查询8.补考查询用例名称：补考查询用例描述：学生发出学生补考查询请求，系统接收后显示补考的相关信息，如科目、地点、时间等参与者：学生前置条件：用户已经登陆系统，系统数据库存在该学生补考信息后置条件：学生获取其补考相关信息基本操作流程：1. 学生发出学生补考查询请求2. 系统接受，整合该学生补考相关信息3. 学生查看完关闭可选操作流程：如果数据库不存在该学生补考相关信息，则输出“不存在”，返回上一级菜单选择被包含的用例：无被泛化的用例：无被扩展的用例：信息查询9.公共选修课报名用例名称：公共选修课报名用例描述：学生登陆教务系统在网上选课中选择公共选修课参与者：学生前置条件：用户已经登陆系统，系统数据库存在该学生课程信息后置条件：学生选择公共选修课基本操作流程：1. 学生发出公共选修课选课请求2. 系统接受，整合该学生课程信息3. 学生选择课程可选操作流程：如果学生课程冲突，系统显示“课程冲突，该课不可选”。
测试用例模板范文
测试用例模板范文1.测试用例信息：-用例编号：每个用例都应有一个唯一的编号，以便进行跟踪和管理。
-测试项：用例所涉及的功能或模块。
-测试标题：用例的简洁、明确的名称。
-设计者：编写和设计用例的测试人员的姓名。
-设计日期：编写和设计用例的日期。
2.测试目的：-描述测试的目标和目的，例如验证特定功能的正确性、检测潜在的缺陷等。
3.测试条件：-需要提供的预置条件、环境条件等。
4.测试步骤：-详细描述测试人员需要执行的操作步骤，包括输入的数据、预期的结果等。
5.预期结果：-预期的测试结果，通常是基于特定的输入和操作步骤得出的预期输出。
6.实际结果：-在执行测试用例后，记录实际的测试结果和观察到的输出。
7.结果比对：-将预期结果与实际结果进行比对，确定是否一致。
8.结论：-根据结果比对的结果，给出该测试用例的通过或失败的结论。
9.备注：-可选字段，用于提供任何与用例相关的补充信息或注释。
使用该测试用例模板，可以帮助测试人员更加系统地设计和执行测试用例，并能够更容易地跟踪和记录测试结果。
以下是一个具体的测试用例示例：1.测试用例信息：-用例编号：TC001-测试项：用户登录-测试标题：验证用户登录功能-设计者：张三-设计日期：2024年1月1日2.测试目的：-验证用户登录功能是否能够正常工作，包括输入验证、身份验证等。
3.测试条件：-已安装最新版本的登录系统。
-已注册并激活用户账户。
4.测试步骤：1.打开登录页面。
2.输入有效的用户名和密码。
3.点击登录按钮。
5.预期结果：-用户成功登录，并进入系统主页。
6.实际结果：-用户成功登录，并进入系统主页。
7.结果比对：-预期结果与实际结果一致。
8.结论：-该测试用例通过。
9.备注：-无。
以上是一个简单的测试用例模板示例，你可以根据实际情况和需求进行修改和扩展。
测试用例模板的关键在于提供清晰的测试目标、条件和步骤，以及对预期结果和实际结果的比对和验证。
通过使用测试用例模板，测试人员可以更好地组织和管理测试工作，并确保测试的全面性和一致性。
单元测试用例模板
单元测试用例模板1.用例标识符：每个用例都应该有一个唯一的标识符，以帮助在测试结果中跟踪用例。
2.用例名称：用于描述测试用例的名称。
3.用例描述：用于详细描述测试用例的目的和测试步骤。
4.输入：这一部分应该列出用例所需的输入数据。
5.预期输出：这一部分应该列出期望的输出结果。
6.实际输出：这一部分应该列出实际的输出结果。
7.执行结果：这一部分应该描述用例执行的结果（通过/失败）。
8.测试人员：这一部分应该列出参与测试用例的测试人员的姓名。
9.日期：这一部分应该列出测试用例创建和执行的日期。
10.优先级：这一部分应该用于确定测试用例的优先级（高、中、低）。
下面是一个具体示例：用例标识符：TC001用例名称：登录功能测试用例描述：测试登录功能是否按预期工作。
输入正确的用户名和密码，检查是否成功登录。
输入：用户名：testuser，密码：testpassword预期输出：登录成功实际输出：登录成功执行结果：通过测试人员：John日期：2024年1月15日优先级：高在实际测试中，还可以扩展用例模板以包括更多的细节和测试步骤，以确保对软件的所有功能进行全面的测试。
以下是一些可能的扩展：-输入为空：测试当输入为空时，软件的行为是否符合预期，例如是否显示错误消息或进行验证。
-输入非法字符：测试当输入包含非法字符时，软件的行为是否正确，例如是否进行输入验证和过滤。
-输入边界测试：测试当输入接近边界值时，软件的行为是否正确，例如测试输入最小值、最大值和临界值的情况。
-异常处理：测试当遇到异常情况时，软件的行为是否符合预期，例如测试当网络连接中断或数据库服务不可用时的情况。
-性能测试：测试软件在负载下的性能和响应时间是否满足要求，例如测试在高并发情况下的性能表现。
-回归测试：测试修改或添加新功能后，软件的旧有功能是否仍然按照预期工作。
通过使用这些模板和扩展，可以创建出全面而有效的单元测试用例。
在实际测试过程中，测试人员可以根据具体的需求和软件的特点进行适当的修改和调整，以确保对软件的每个功能进行全面的测试。
用例描述模板
实验一编写用例（以下给出用例描述模板），并画出用例图（编写时可参照下面的实例）用例描述模板是一种被广泛使用的用于发现和记录需求(特别是功能需求)的机制。
写出用例是一种最好的理解和描述需求的技巧。
注意：这个模板列出可以定义用例的典型标题，但应当强调的是，实用上更重要的是专注于写出完整的可理解的事件路径，而不是按指定的模板填写每个部分。
名称用例的名称应当用简短的动词短语表达，说明用户使用用例完成的任务。
概述或简要描述单列一节概述该用例完成什么通常是有益的。
参与者列出此用例涉及的参与者和负责发起此用例执行的主要参与者。
触发器触发器是开始此用例的事件。
触发者并不必须向该系统输入事件，例如，在预约系统示例中，“预约”用例的触发者可能是“一个潜在的客户打给餐馆的一个预约电话”。
而在另一种情况下，触发者可能是此用例中第一个系统事件。
前置条件前置条件概述在用例可以开始前，什么必须为真。
通常前置条件说明在指定的一个用例运行前，另一个什么用例必须运行。
典型的前置条件可以是“用户已成功登陆”。
后置条件后置条件概述当用例完成时什么是真。
在许多情况下，这将依赖于在一个特定用例实例中发生的确切的一系列交互。
区分“最低保证”和“成功保证”可能是实用的，前者描述在所有情况下发生什么和不发生什么，后者描述如果正常的事件路径成功地完成将会发生什么。
事件路径或脚本基本的或正常的事件路径，通常应当作为不中止的交互序列出现。
对事件路径中的交互通常加以编号，以便于以后的参考。
可选和例外事件路径可选和例外事件路径可以完整地写出。
然而通常只须在基本事件路径中的分叉点简单地指明可选事件流，对行为可能改变的位置予以编号，并指明导致分叉的事件。
扩展点这一节应当列出在事件路径中可能发生扩展的位置，并给出确定扩展是否发生的条件或事件。
扩展本身应当作为单独的用例写出；否则，可以指明可选的事件路径。
例如，订餐系统中“记录未预约顾客”的用例可以作为“记录达到”用例的扩展。
系统用例描述
瑞天图书管理系统用例描述-、图书借阅该用例提供了用户借阅图书时管理员更新图书信息以及日志、记 录借阅信息、创建和修改借阅者账户以及信息等 1、用例图如下：2、用例描述: 用例名称：图书借阅简要说明：图书管理员输入读者编号和图书编号来完成图书借阅。
参与者：图书管理员前置条件：读者出示的借阅证必须是有效的借阅证(from 图书管理系统参与创建新的借阅者帐户其他用户修改借阅者的帐户信息管理员已还书)(from 图书管理系统参与记录图书数量与价格学生(from 图书管理系统参与后置条件：显示读者的全部借阅信息假设条件：图书管理员已经成功登录图书管理系统基本操作流程：(1)图书管理员输入借阅证信息(2)系统检查读者是否有超期的借阅信息和读者的借书数量是否已经达到借书限额(4)图书管理员输入要借阅的图书信息(5)系统将读者的借阅信息保存到数据库中可选操作流程：读者有超期的借阅信息，或者读者的借书数量已经达到借书限额，系统显示不能借阅图书的信息，图书管理员进行超期处理。
二、归还图书1、用例图如下:2、用例描述: 用例名称：归还图书简要说明：图书管理员收到要归还的图书，进行还书操作。
参与者：图书管理员、学生、其他用户前置条件：无后置条件：显示读者的全部借阅信息假设条件：图书管理员已经成功登录图书管理系统 基本操作流程：(1) 图书管理员输入读者要归还的图书信息 (2) 系统检索与该图书相关的借阅者信息 (3) 系统检查该借阅者是否有超期的借阅信息 (4) 系统将借阅者的还书信息保存到数据库中(from))登录(5)系统将该图书的状态改变为可借阅状态可选操作流程：读者归还图书，图书管理员查看是否超出期限，并进行相应处罚，并且图书管理员将借阅信息删除。
三、图书查询1、用例图如下:输入书籍信息2、用例描述:用例名称：图书查询简要说明：用户登录网站进行查询参与者：用户前置条件：必须有登录账户后置条件：显示要借图书的全部信息假设条件：用户已经成功登录图书管理系统3、操作流程：(1)用户输入登录信息(2)系统检查读者是否有账号(3)用户输入要查询的图书信息(4)系统检查读者的借书信息是否存在可选操作流程：读者有超期的借阅信息，图书管理员进行超期处理; 读者的借书数量已经达到借书限额，系统显示不能借阅图书的信息。
功能的用例描述
功能的用例描述1. 用户注册：- 用户打开应用，点击注册按钮。
- 系统显示注册页面，要求用户输入用户名、密码和邮箱。
- 用户输入完毕后，点击确认按钮。
- 系统验证用户输入的信息是否合法，如果合法则将用户信息保存到数据库中，并显示注册成功的提示信息。
- 如果用户输入的信息不合法，则系统显示相应的错误提示信息。
2. 用户登录：- 用户打开应用，点击登录按钮。
- 系统显示登录页面，要求用户输入用户名和密码。
- 用户输入完毕后，点击确认按钮。
- 系统验证用户输入的用户名和密码是否匹配，如果匹配则登录成功，并显示登录成功的提示信息。
- 如果用户名和密码不匹配，则系统显示登录失败的提示信息。
3. 发布文章：- 用户登录后，进入个人主页。
- 用户点击发布文章按钮。
- 系统显示发布文章页面，要求用户输入文章标题和内容。
- 用户输入完毕后，点击确认按钮。
- 系统验证用户输入的信息是否合法，如果合法则将文章信息保存到数据库中，并显示发布成功的提示信息。
- 如果用户输入的信息不合法，则系统显示相应的错误提示信息。
4. 查看文章：- 用户登录后，进入个人主页。
- 用户点击查看文章按钮。
- 系统显示用户已发布的文章列表。
- 用户点击某篇文章的标题。
- 系统显示该篇文章的详细内容。
5. 编辑文章：- 用户登录后，进入个人主页。
- 用户点击查看文章按钮。
- 系统显示用户已发布的文章列表。
- 用户点击某篇文章的编辑按钮。
- 系统显示编辑文章页面，展示该篇文章的标题和内容。
- 用户修改文章的标题和内容后，点击确认按钮。
- 系统验证用户输入的信息是否合法，如果合法则更新文章信息，并显示编辑成功的提示信息。
- 如果用户输入的信息不合法，则系统显示相应的错误提示信息。
6. 删除文章：- 用户登录后，进入个人主页。
- 用户点击查看文章按钮。
- 系统显示用户已发布的文章列表。
- 用户点击某篇文章的删除按钮。
- 系统弹出确认删除的提示框，用户点击确认按钮。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。
在用例图中，角色和用例都能够泛化。
角色的泛化/继承很容易理解，因为角色本来就是类（Class），它是一种版型（stereotype）为Actor的类，所以角色的继承直观而自然。
但是用例的继承实际上分为两种情况，并不是简单的使用泛化，而是使用扩展（extended）和包含（include）两种泛化的特例。
扩展用于子用例的动作步骤基本上和父用例的动作步骤相同，只是增加了另外的一些步骤的情况下。
包含用于子用例包含了所有父用例的动作，它将父用例作为了自己的一个大步骤，子用例常常包含一个以上的父用例。
对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。
用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。
下面说说各个部分的意思：
简要描述：对用例的角色、目的的简要描述；
前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件；
基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流；
其他事件流：表示这个行为或流程是可选的或备选的，并不是总要执行它们；
异常事件流：表示发生了某些非正常的事情所要执行的流程；
后置条件：用例一旦执行后系统所处的状态；
用例描述模板。