1.软件测试用例文档怎么写原发布者：xuzikun76
RUP模版------《测试计划》测试计划版本[注：以下提供的模板用于 。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除 。按此样式输入的段落将被自动设置为普通样式（样式=BodyText） 。][要定制MicrosoftWord中的自动字段（选中时显示灰色背景），请选择File>Properties，然后将Title、Subject和Company等字段替换为此文档的相应信息 。关闭该对话框后，通过选择Edit>SelectAll（或Ctrl-A）并按F9，或只是在字段上单击并按F9，可以在整个文档中更新自动字段 。对于页眉和页脚，这一操作必须单独进行 。按Alt-F9，将在显示字段名称和字段内容之间切换 。有关字段处理的详细信息，请参见Word帮助 。]修订历史记录目录1.简介31.1目的31.2背景31.3范围31.4项目标识32.测试需求33.测试策略33.1测试类型33.1.1数据和数据库完整性测试33.1.2功能测试33.1.3业务周期测试33.1.4用户界面测试33.1.5性能评价33.1.6负载测试33.1.7强度测试33.1.8容量测试33.1.9安全性和访问控制测试33.1.10故障转移和恢复测试33.1.11配置测试33.1.12安装测试33.2工具34.资源34.1角色34.2系
2.如何编写用例文档本文由《The Object Primer 2nd Edition》的第三章改编而来 。
当记录基于组件的系统的行为需求时，用例是最常用的技术之一 。开发人员常问的一个问题是，“用例文档应该包括哪些信息？”尽管我在此提到的一些部分是可选的，但在我看来，将这些部分包括在用例文档中不失为一个好主意 。
当编写基本用例的文档时（另请参阅前一篇技巧 Modelling essential use cases），我倾向于略去可选部分（因为基本用例关注的是是什么，而不是为什么，因此不必像系统用例那样复杂） 。当编写系统用例时，我通常将所有部分都包括在内 。
回顾一下，基本用例和系统用例之间的主要区别是，系统用例包括了高级实现决策，而基本用例是要以与技术和实现无关的方式捕捉用户的意图 。参与者 （actor） 和被包含的用例这两个部分实际上只看用例图即可确定 。
但是，按我的经验，各个用例最好相互独立 — 换句话说，用例应该包含理解它们所需的全部关键信息以及它们所在的上下文 。这使您的主题问题专家 （SME） 能够分别充实各个用例 。
（他们可能上午以小组为单位协同工作，下午则各自独立地以最快的速度充实所分配的用例，从而提高了整个小组的生产效率 。） 用例的各个组成部分 名称 。
名称无疑应该表明用户的意图或用例的用途，如“研究班招生” 。标识符 [可选] 。
唯一标识符，如 "UC1701"，在项目的其他元素（如类模型）中可用它来引用这个用例 。说明 。
概述用例的几句话 。参与者 [可选] 。
与此用例相关的参与者列表 。尽管这则信息包含在用例本身中，但在没有用例图时，它有助于增加对该用例的理解 。
状态[可选] 。指示用例的状态，通常为以下几种之一：进行中、等待审查、通过审查或未通过审查 。
频率 。参与者访问此用例的频率 。
这是一个自由式问题，如用户每次录访问一次或每月一次 。前置条件 。
一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足 。后置条件 。
一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足 。被扩展的用例 [可选] 。
此用例所扩展的用例（如果存在） 。扩展关联是一种广义关系，其中扩展用例接续基用例的行为 。
这是通过扩展用例向基用例的操作序列中插入附加的操作序列来实现的 。这总是使用带有