uml用例文档怎么写

用例文档怎么写

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"，在项目的其他元素（如类模型）中可用它来引用这个用例。说明。

概述用例的几句话。参与者 [可选]。

与此用例相关的参与者列表。尽管这则信息包含在用例本身中，但在没有用例图时，它有助于增加对该用例的理解。

状态[可选]。指示用例的状态，通常为以下几种之一：进行中、等待审查、通过审查或未通过审查。

频率。参与者访问此用例的频率。

这是一个自由式问题，如用户每次录访问一次或每月一次。前置条件。

一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足。后置条件。

一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足。被扩展的用例 [可选]。

此用例所扩展的用例（如果存在）。扩展关联是一种广义关系，其中扩展用例接续基用例的行为。

这是通过扩展用例向基用例的操作序列中插入附加的操作序列来实现的。这总是使用带有 <> 的用例关联来建模的。

被包含的用例 [可选]。此用例所包含用例的列表。

包含关联是一种广义关系，它表明对处于另一个用例之中的用例所描述的行为的包含关系。这总是使用带有 <> 的用例关联来建模的。

也称为使用或具有（has-a）关系。假设[可选]。

对编写此用例时所创建的域的任何重要假设。您应该在一定的时候检验这些假设，或者将它们变为决策的一部分（请参阅下文），或者将它们添加到操作的基本流程或可选流程中。

基本操作流程。参与者在用例中所遵循的主逻辑路径。

因为它描述了当各项工作都正常进行时用例的工作方式，所以通常称其为适当路径（happy path）或主路径（main path）。可选操作流程。

用例中很少使用的逻辑路径，那些在变更工作方式、出现异常或发生错误的情况下所遵循的路径。修改历史记录 [可选]。

关于用例的修改时间、修改原因和修改人的详细信息。问题[可选]。

如果存在，则为与此用例的开发相关的问题或操作项目的列表。决策。

关键决策的列表，这些决策通常由您的 SME 作出，并属于用例的内容。将这些决策记录下来对于维护团体记忆库（group memory）是相当重要的。

为了让用例建模工作变得轻松一点，我制作了一个模板，它反映了本技巧说明的内容，可通过以下链接下载这个模板：Ronin International Reusable Templates。

3.测试用例是按照哪些文档写的

目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。

要使最终用户对软件感到满意，最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。

既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果

4.单元测试用例该怎么写

写单元测试用例？好像有些理想化。

在实际工作中，能有个基本的详细设计文档就不错了，只要有了详细设计文档，就可以直接建立可执行的测试用例。先写个文字的单元测试用例，费时费力，还要维护，项目不会给那么多时间吧？从我们的客户反馈来看，实际工作中，很多项目是没有规范的详细设计的，这时最容易范的错误就是：测试人员阅读代码来了解代码功能，以便设计用例，结果，测试几乎没有效果。

所以，除非有规范的文档，否则单元测试要由开人员为主。如果连详细设计文档都没有，那依据什么来写文字版的单元测试用例？如果有，那就用不着写一个文字版的。