<> 的用例关联来建模的 。
被包含的用例 [可选] 。此用例所包含用例的列表 。
包含关联是一种广义关系，它表明对处于另一个用例之中的用例所描述的行为的包含关系 。这总是使用带有 <> 的用例关联来建模的 。
也称为使用或具有 （has-a） 关系 。假设[可选] 。
对编写此用例时所创建的域的任何重要假设 。您应该在一定的时候检验这些假设，或者将它们变为决策的一部分（请参阅下文），或者将它们添加到操作的基本流程或可选流程中 。
基本操作流程 。参与者在用例中所遵循的主逻辑路径 。
因为它描述了当各项工作都正常进行时用例的工作方式，所以通常称其为适当路径 （happy path） 或主路径 （main path）。可选操作流程 。
用例中很少使用的逻辑路径，那些在变更工作方式、出现异常或发生错误的情况下所遵循的路径 。修改历史记录 [可选] 。
关于用例的修改时间、修改原因和修改人的详细信息 。问题[可选] 。
如果存在，则为与此用例的开发相关的问题或操作项目的列表 。决策 。
关键决策的列表，这些决策通常由您的 SME 作出，并属于用例的内容 。将这些决策记录下来对于维护团体记忆库 （group memory） 是相当重要的 。
为了让用例建模工作变得轻松一点，我制作了一个模板，它反映了本技巧说明的内容，可通过以下链接下载这个模板：Ronin International Reusable Templates 。
3.测试用例是按照哪些文档写的目前没有经典的定义 。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略 。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档 。
不同类别的软件，测试用例是不同的 。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快 。笔者主要从事企业管理软件的测试 。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来 。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案 。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例 。
随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展 。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门 。测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试 。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势 。
要使最终用户对软件感到满意，最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性 。测试用例反映了要核实的需求 。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施 。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成 。
既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败 。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果
4.单元测试用例该怎么写写单元测试用例？好像有些理想化 。
在实际工作中，能有个基本的详细设计文档就不错了，只要有了详细设计文档，就可以直接建立可执行的测试用例 。先写个文字的单元测试用例，费时费力，还要维护，项目不会给那么多时间吧？从我们的客户反馈来看，实际工作中，很多项目是没有规范的详细设计的，这时最容易范的错误就是：测试人员阅读代码来了解代码功能，以便设计用例，结果，测试几乎没有效果 。