功能测试用例的书写

时间 2020-02-15

标签功能测试书写繁體版

原文原文链接

功能测试用例的书写数据库

功能性测试用例网络

1.测试的来源，及测试的需求ide

测试用力的主要来源有：工具

1）需求说明及相关文档测试

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

3）与开发组交流对需求理解的记录（能够是开发人员的一个解释）设计

4）已经基本成型的UI（能够有针对性的补充一些用例）开发

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

2.用例的组织方式it

不一样的公司有不一样的作法，原则上，只要方便管理和跟踪，怎么组织均可以。

用例能够按大的功能块组织，如查询功能模块的用例，能够组织在一块儿，打印模块的测试用例，能够另外组织在一块儿。

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

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

至于用例文件格式，能够是。DOS或是。XLS（若是有专门的测试管理工具另当别论）

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

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

因为用力的主要来源是需求和设计的说明，全部对用例跟踪其实就是对需求和设计的跟踪，需求和设计的变动势必引发测试用例的变动。

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

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

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

一个优秀的测试用例应该包含如下信息:

1)软件或项目的名称

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

3)功能模块明

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

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

6)本测试用例与其余测试用例间的依赖关系

7)本测试用例的前置条件，及执行本用例必需要知足的条件，如对本数据库的访问权限

8)用例的编号（ID）,如能够是软件名称简写—功能块简写—NO. 。

9)步骤号、操做步骤描述、测试数据描述

10)预期结果（这是最重要的）和实际结果（若是有bug管理工具，这条能够省略）

11)开发人员（必须有）和测试人员（无关紧要）

12)测试执行日期

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