与此用例相关的参与者列表 。尽管这则信息包含在用例本身中 ， 但在没有用例图时 ， 它有助于增加对该用例的理解 。
状态[可选] 。指示用例的状态 ， 通常为以下几种之一：进行中、等待审查、通过审查或未通过审查 。
频率 。参与者访问此用例的频率 。
这是一个自由式问题 ， 如用户每次录访问一次或每月一次 。前置条件 。
一个条件列表 ， 如果其中包含条件 ， 则这些条件必须在访问用例之前得到满足 。后置条件 。
一个条件列表 ， 如果其中包含条件 ， 则这些条件将在用例成功完成以后得到满足 。被扩展的用例 [可选] 。
此用例所扩展的用例（如果存在） 。扩展关联是一种广义关系 ， 其中扩展用例接续基用例的行为 。
这是通过扩展用例向基用例的操作序列中插入附加的操作序列来实现的 。这总是使用带有 <> 的用例关联来建模的 。
被包含的用例 [可选] 。此用例所包含用例的列表 。
包含关联是一种广义关系 ， 它表明对处于另一个用例之中的用例所描述的行为的包含关系 。这总是使用带有 <> 的用例关联来建模的 。
也称为使用或具有 （has-a） 关系 。假设[可选] 。
对编写此用例时所创建的域的任何重要假设 。您应该在一定的时候检验这些假设 ， 或者将它们变为决策的一部分（请参阅下文） ， 或者将它们添加到操作的基本流程或可选流程中 。
基本操作流程 。参与者在用例中所遵循的主逻辑路径 。
因为它描述了当各项工作都正常进行时用例的工作方式 ， 所以通常称其为适当路径 （happy path） 或主路径 （main path）。可选操作流程 。
用例中很少使用的逻辑路径 ， 那些在变更工作方式、出现异常或发生错误的情况下所遵循的路径 。修改历史记录 [可选] 。
关于用例的修改时间、修改原因和修改人的详细信息 。问题[可选] 。
如果存在 ， 则为与此用例的开发相关的问题或操作项目的列表 。决策 。
关键决策的列表 ， 这些决策通常由您的 SME 作出 ， 并属于用例的内容 。将这些决策记录下来对于维护团体记忆库 （group memory） 是相当重要的 。
为了让用例建模工作变得轻松一点 ， 我制作了一个模板 ， 它反映了本技巧说明的内容 ， 可通过以下链接下载这个模板：Ronin International Reusable Templates 。
7.如何编写一个好的测试用例我一直在想 ， 作为测试人员应该用脑袋去测试 ， 也就是说应该在工作中不断的总结经验 ， 把自己的发现应用到测试中去 ， 这样你才能有真正的提高 ， 你所具备的理论和能力才有竞争力 。
回到测试用例中来 ， 我觉得做好以下三点就是一个好的用例 。
第一：依据分明
众所周知 ， 一个项目首先立项 ， 然后经过一系列的动作到了需求分析 ， 昨晚需求分析后 ， 测试就可以做测试需求 ， 然后就可以写测试用例了 。所以写测试用例的依据就是需求 。这么说太笼统 ， 举一个例子 。一个系统经过前期的需求分析 ， 详细设计 ， 模块设计等一系列的动作 ， 最后生成了详细的需求说明和详细设计文档等等 ， 在这些文档中 ， 已经很详细的描述了所有的需求点和功能点 ， 也有较详细的技术说明 ， 接下来的工作就是怎么把这些功能点和需求点变成测试点 ， 这就需要做好测试需求分析和测试方案工作 ， 生成一个个可测试的测试点 。这也是需求必须可测的一个体现 。