功能测试用例的书写方式（实例）

发起投票 | 删除

功能测试用例实例

1. 测试的来源，即测试的需求

测试用例的主要来源有：

1） 需求说明”及相关文档

2）相关的设计说明（概要设计，详细设计等）

3）与开发组交流对需求理解的 记录（可以是开发人员的一个解释）

4）已经基本成型的UI（可以有针对性地补充一些用例）

简而言之，所有你能得到的项目文档，都尽量拿到。 从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。

2. 用例的组织方式

不同的公司有不同的做法，原则上，只要方便管理和跟踪，怎么组织都可以的。 用例可以按大的功能块组织，如查询功能模块的用例，可以组织在一起，打印模块的测试用例，可以另外组织在一起。

在没有专门的测试用例管理工具的情况下，用例执行后会产生2种状态：“通过”、“失败”——这样加上“未 执行”的用例的状态，共3种状态。

即从“未执行”用例中执行一个用例后，该用例状态应为“失败”或“通 过”。将同一状态的用例组织在一起。

至于用例文件格式，可以是.DOC或.XLS（如果有专门的测试用例管理工具另当别论）。

3. 用例与其他材料的关联方式，即如何解决用例跟踪的问题

测试用例面临的比较大的风险有：需求的变更、设计的修改、需求的错误和遗漏等等。

由于用例的主要来源是需求和设计的说明，所以对用例的跟踪其实就是对需求和设计的跟踪，需求和设计的 变更势必引起测试用例的变更。

如前所说，将分解的功能点编号，与相应的用例联系起来。例如，你可以列一个表格，列出各个（编号的）功 能点和测试用例间的关联关系。

这样，当需求和设计发生变化时，你只需要跟踪“功能点”是否变化，是否增加了新的功能点。

4. 一个好的用例的表述要点，即用例中应当包含的信息

一个优秀的测试用例，应该包含以下信息：

1） 软件或项目的名称

2） 软件或项目的版本（内部版本号）

3） 功能模块名

4） 测试用例的简单描述，即该用例执行的目的或方法

5） 测试用例的参考信息（便于跟踪和参考）

6） 本测试用例与其他测试用例间的依赖关系

7） 本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限

8） 用例的编号（ID），如可以是 软件名称简写-功能块简写-NO.。

9） 步骤号、操作步骤描述、测试数据描述

10）预期结果（这是最重要的）和实际结果（如果有BUG管理工具，这条可以省略）

11）开发人员（必须有）和测试人员（可有可无）

12）测试执行日期

5. 给出一个测试用例的例子该范例已经包含一个测试用例的模板。

备注：本用例未考虑“企业代码”的输入情况；测试用例并未涵盖所有的非法输入，如非法输入中可能会有 “user=*,pw=*”的组合，对回车的默认操作，空格输入，对输入上溢的处理的处理（可能会跳过身份验证） 等等。

如果你有兴趣，至少可以再补充5-10条左右的输入组合（当然，如果步骤超过15步，用例的易操作 性就降低，你可以再创建一个测试用例如

TC-TEP_Login_2）

来自: /55313184/blog/item/8b9b0ab50d4cd1cb37d3ca29.html

 

第二篇：测试用例书写标准

测试用例书写标准

在编写测试用例过程中，需要参考和规范一些基本的测试用例编写标准，在ANSI/IEEE829-1983标准中列出了和测试设计相关的测试用例编写规范和模板。标准模板中主要元素如下。

? 标识符（identification）：每个测试用例应该有一个唯一的标识符，它将成为所有和测试用例相关的文档/表格引用和参考的基本元素，这些文档/表格包括设计规格说明书、测试日志表、测试报告等。

? 测试项（test item）：测试用例应该准确地描述所需要测试地项及其特征，测试项应该比测试设计说明书中所列出地特性描述更加具体，例如做windows计算器应用程序地窗口设计，测试对象是整个地应用程序用户界面，这样测试项就应该是应用程序地界面地特性要求，例如缩放测试、界面布局、菜单等。

? 测试环境要求（test environment）：用来表征执行该测试用例需要地测试环境，一般来说，在整个的测试模块里面应该包含整个的测试环境的特殊要求，而单个测试用例的测试环境需要表征该测试用例所单独需要的特殊环境需求。

? 输入标准（input criteria）：用来执行测试用例的输入需求。这些输入可能包括数据、文件，或者操作（例如鼠标的左键单击，鼠标的按键处理等），必要的时候，相关的数据库、文件也必须被罗列。

? 输出标准（output criteria）：标识按照指定的环境和输入标准得到的期望输出结果。如果可能的话，尽量提供适当的系统规格说明书来证明期望的结果。

? 测试用例之间的关联：用来标识该测试用例与其它的测试（或其它测试用例）之间的依赖关系，例如，用例A需要基于B的测试结果正确的基础上才能进行，此时需要在A的测试用例中表明对B的依赖性，从而保证测试用例的严谨性。

综上所述，如果使用一个数据库的表来表征测试用例的话，它应该有以下的格式：

例一：对Windows记事本程序进行测试，选取其中的一个测试项――文件菜单栏的测试 测试对象：记事本程序文件菜单栏（测试用例标识1000，下同），所包含的子测试用例描述如下：

|---------文件/新建（1001）

|---------文件/打开（1002）

|---------文件/保存（1003）

|---------文件/另存（1004）

|---------文件/页面设置（1005）

|---------文件/打印（1006）

|---------文件/退出（1007）

|---------菜单布局（1008）

|---------快捷键（1009）

选取其中的一个子测试用例――文件/退出（1007）作为例子，测试用例如下表所示：

通过这个例子了解了测试用例的组成方法。要组织成一个完整的良好测试用例，还需要更多的技巧，并要考虑一些常见的因素。

测试用例设计考虑因素

测试是不可能实现穷举测试的，因此试图用所有的测试用例来覆盖所有测试可能遇到的情形是不可能的，所以，在测试用例的编写、组织过程中，尽量考虑有代表性的典型的测试用例，来实现以点带面的穷举测试。这要求在测试用例设计中考虑一些基本因素： ? 测试用例必须具有代表性、典型性。

? 测试用例设计时，要浓缩系统设计。

例二：常见的web登录页面，通过这个例子来阐述从功能规格说明书到具体测试用例编写的过程

A） 用户登录的功能设计规格说明书（摘选）

―――――――――――――――――――――――――――――――――――――――

1． 用户登录

1．1满足基本页面布局（图示，略）

1．2当用户没有输入用户名和密码时，不立即弹出错误对话框，而是在页面上使用红色字体来提示，见2描述

1．3用户密码使用掩码号（*）来标识。

1．4*代表必选字段，将出现在输入文本框的后面。

2． 登录出现错误

当出现错误时，在页面的顶部会出现相应的错误提示。错误提示的内容见3。错误提示是高亮的红色字体实现。

3． 错误信息描述

3．1

3．2密码为空

3，3用户名/

（注：本例子中的页面图示，消息编号如WMSG001的描述均为给出。）

―――――――――――――――――――――――――――――――――――――――

B） 通用安全性设计规格说明书（摘选）

―――――――――――――――――――――――――――――――――――――――

1． 安全性描述

1．1 输入安全性：在用户登录或者信用卡验证过程中，如果三次输入不正确，页面将需要重新打开才能生效。

1．2 密码：在所有的用户密码中，都必须使用掩码符号（*），数据在数据库中存储使用统一的加密和解密算法。

1．3 Cookie：在信用卡信息验证，用户名输入时，Cookie都是被禁止的，当用户第一次输入后，浏览器将不再提供是否保存信息的提示，自动完成功能将被禁用。

1．4 SSL校验：所有的站点访问时，都必须经过SSL校验。

2． 错误描述（略）

―――――――――――――――――――――――――――――――――――――――

C） 测试用例

结合相关的规格说明书，理解和掌握测试用例设计的关键点，测试用例设计如下表所示。

? 测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分

析怎样使得这样的错误或者异常能够发生。

用户登录功能测试用例

完善的测试用例

? 用户测试用例的设计，要多考虑用户实际使用场景。