QA测试用例设计规范.docx

QA测试用例设计规范.docx

《QA测试用例设计规范.docx》由会员分享，可在线阅读，更多相关《QA测试用例设计规范.docx（17页珍藏版）》请在冰点文库上搜索。

QA测试用例设计规范

保密级别

公开

版本号

V1.0

文档编号

[XXXX]

系统测试用例设计规范

撰写部门：

测试部

撰写时间：

2014年3月4日

发行范围：

开发部和测试部

文档记录

版本编号

变化状态

简要说明

撰写/变更人

批准人

批准日期

V1.0

C

创建测试部相关流程文档

张梅娟

*变化状态：

C――创建、A――增加、M――修改（+修改说明）、D――删除（+删除说明）

文档审批信息

序号

角色

审批人签字

审批日期

备注

目录

1目的4

2适用范围4

3术语解释4

4测试用例设计4

4.1测试用例作用4

4.2设计思路4

4.2.1完整项目型用例设计5

4.2.2集成产品型用例设计5

4.3编写规范5

4.3.1测试用例设计范围和原则5

4.3.2测试用例设计方法6

4.3.3功能和业务用例设计规范7

4.3.4角色模块功能点用例设计规范7

4.3.5业务用例设计规范8

5结合工具使用9

5.1测试用例管理（直接建立测试需求和测试项）9

5.2测试执行管理15

5.3缺陷管理15

1目的

统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。

为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。

2适用范围

本规范适用于[XXX]系统测试用例的管理和缺陷的管理。

3术语解释

系统测试：

系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。

系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正

测试用例（TestCase）：

是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

需求用例驱动测试用例设计：

通过需求文档来推动整个测试用例的设计进行，但需求测试驱动测试用例的设计并不只是单纯的用例设计工作，而是把需求分析，测试用例的设计的量化的过程。

4测试用例设计

4.1测试用例作用

Ø便于测试经理检查测试人员对系统的理解程度。

Ø便于测试人员和开发人员就测试内容和范围达成一致，利于交流。

Ø指导测试人员的执行过程，使测试过程有序不重复。

Ø方便测试经理把握测试的实际进度，做到心中有数。

Ø便于测试结果分析。

4.2设计思路

系统测试的目的在于与系统的需求定义做比较，发现软件与系统需求定义不符合或相矛盾的地方。

所以编写系统测试用例前，测试人员要根据需求规格说明书和测试需求整理文档，详细理解用户的真正需求，并对软件所实现的业务目标准确理解。

研发中心软件产品根据开发形式大致有完整项目型和集成产品型之分，所以我们针对不同性质的产品要采用不同的用例设计思路。

软件产品的定义由研发中心高层经理决定。

本文中涉及的设计思路包含两种，以软件功能模块划分进行设计和需求用例驱动设计方法。

【完整项目型：

（需求+知识学习）与集成产品型：

（项目紧急，需求定义不明确）划分，不同项目有不同的测试用例设计方法】

4.2.1完整项目型用例设计

这种类型的产品是一个完整的项目产品，可直接适应于用户，所以产品经理（后续角色）或测试人员在这类产品的需求编写阶段就要介入，对系统需求进行全面的了解和相关知识的学习。

这种类型的产品采用以需求用例驱动的设计思路。

（1）以产品需求为依据，产品经理或测试人员用面向对象的思想对产品需求进行二次加工，提炼加工出测试需求文档。

（2）针对提炼出的测试需求文档，产品经理或测试人员要和开发人员进行讨论确认。

确认之后进行步骤3，否则重新执行步骤1。

（3）根据提炼出的测试需求文档进行系统测试用例设计，按业务流程和角色模块功能设计测试用例。

（4）测试用例设计完成后，要进行用例评审。

评审不通过时，重新执行步骤3.4。

4.2.2集成产品型用例设计

这种类型的产品不是直接面向用户的，是一个框架体系结构。

这种产品采用业务流程和功能模块划分的方法进行设计。

（1）以需求规格说明书中提供的功能列表和功能模块划分为依据，测试人员在此基础上进行细化，提取出业务用例。

（2）在业务用例的基础之上提取界面元素和各功能业务规则中的功能点。

（3）根据1和2中提取的功能点和基本业务流程设计系统测试用例。

（4）测试用例设计完成后，要进行用例评审。

评审不通过时，重新执行步骤1.2.3.4。

4.3编写规范

本部分内容作为具体编写系统测试用例的依据。

4.3.1测试用例设计范围和原则

测试用例按安装配置测试、业务流程测试、角色模块功能点测试（或模块功能点测试）、产品接口测试、数据权限测试、故障转移与恢复、用户界面测试、性能测试进行测试范围划分和管理，测试用例按基本流和异常流进行设计，基本流和异常流中每一个测试点标题明确测试目的，每个测试集（业务目标或功能点）开始明确测试范围和前置条件（可选），每个测试点前置条件，紧跟测试标题，测试目录和测试集按测试优先级进行编号排序，基本流和异常流中的测试点也按测试优先级进行编号排序，测试用例管理如下图所示。

（1）安装配置测试

正确性验证，依据安装配置手册设计基本流测试用例，按角色操作设计测试用例，突出操作（用绿色字体显示）。

（2）业务流程测试

依据产品需求规格说明书、产品测试需求整理文档、沟通测试需求理清业务目标。

（3）角色模块功能点测试（或模块功能点）

依据产品需求规格说明书、产品测试需求整理文档、沟通测试需求理清角色模块功能点。

（4）产品接口测试

产品或者各模块之间的接口测试，供第三方调用的接口测试等。

（5）数据权限验证

角色权限、不同管辖范围数据权限，交叉管理数据权限测试等。

（6）用户界面测试

分辨率、显示器、IE版本一定情况下，界面完整性、分页显示、页面跳转、提示窗口、标题、易用性等测试。

（7）性能测试

大数据量查询测试，并发测试，压力测试，稳定性测试等。

（8）故障转移与恢复

正常执行操作过程中服务器、客户端异常断电，异常关闭测试等。

4.3.2测试用例设计方法

Ø等价类划分。

把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。

每一类的代表性数据在测试中的作用等价于这一类中的其他值。

Ø边界值分析。

通过选择等价类边界的测试用例。

边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。

Ø错误推测设计方法。

该方法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

Ø因果图方法。

该方法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可以通过因果图转换为判定表。

Ø正交试验设计法。

该方法是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。

Ø功能图法。

该方法是由状态迁移图和布尔函数组成，状态迁移图用状态和迁移来表示。

一个状态指出数据输入的位置（或时间），一个迁移指明状态的改变，同时要依靠判定表或因果图表示的逻辑功能。

4.3.3功能和业务用例设计规范

本部分内容主要是用来避免功能测试用例中过多包含业务用例的现象。

这种现象会造成用例设计者工作量得增大，执行者重复执行用例的后果。

我们以研发中心测试管理工具TestDirestor进行系统测试用例的管理，所以下面的规范结合TestDirestor中项目进行说明。

4.3.4角色模块功能点用例设计规范

1、依据产品需求规格说明书、产品测试需求整理文档、沟通测试需求理清角色模块功能点，每个功能点设计基本流和异常流测试用例，基本流和异常流测试用例包含测试点，测试点标题明确测试目的，测试点按测试优先级编号排序（高优先级在前），每个测试点按角色操作设计测试步骤（如果测试点目的明确，可以不设计操作步骤），突出操作（用绿色字体显示），下图为某服务平台角色模块功能测试用例。

2、考虑全面。

针对测试的功能点，除了编写正常流验证功能点的正常功能外，还有考虑功能点的容错能力，依赖性等，即异常流。

依赖性测试点前置条件准备数据或验证结果超过两个模块应归入业务目标测试用例中，功能点部分正常流测试用例业务流程用例已验证过可标注说明，每个测试点测试目的明确，避免测试点之间的套用的情况发生。

4.3.5业务用例设计规范

1、依据产品需求规格说明书、产品测试需求整理文档、沟通测试需求理清业务目标，每个业务目标设计基本流和异常流测试用例，基本流和异常流测试用例包含测试点，测试点标题明确测试目的，测试点按测试优先级编号排序（高优先级在前），每个测试点按角色操作设计测试步骤，突出操作（用绿色字体显示），下图为某系统业务流程测试用例。

2、考虑全面。

每个业务目标清晰，做到有经验的测试人员看到业务目标就能想到一部分相应的测试点，测试点目的明确，步骤清晰，步骤如出现分枝，要拆分为两个测试点。

5结合工具使用

研发中心使用测试管理工具TestDirestor8.0对测试项目的测试需求整理、测试用例设计、执行和缺陷提交等一系列活动进行管理，那么下面简单给出在TD中建立测试项目的流程实例供大家参考。

进行下面操作的前提是管理员admin已建好测试项目并设置了项目所需用户和权限。

5.1测试用例管理（直接建立测试需求和测试项）

1、测试人员登陆TD后进入“TESTPLAN”模块，如图所示

【说明】：

该视图是以“显示为测试计划树”进行查看的。

2、点击左上角的“计划”，如图1：

图1图2

选择“新建文件夹”或者图2所示工具栏中简易图标创建测试需求。

选择“新建测试”或者图2所示工具栏中简易图标可以为已建好的测试需求建立测试项。

3、测试需求粒度划分。

测试需求粒度划分的好坏，影响测试用例编写的质量，测试需求粒度划分过粗会导致测试用例步骤增多，部分预期结果繁多，影响测试执行人员的积极性。

测试需求以业务流程和角色模块进行划分，测试项以业务目标和功能点进行划分。

测试需求编号命名规范。

为了使测试需求显示有条理性，测试人员需要为每个需求编号，具体的命名规则如下：

测试目录以‘大写T+具体编号’命名；测试业务目标或功能点（非目录）以‘大写F+具体编号’命名。

编号命名，按优先级进行编号，优先级最高的为01，然后按优先级依次编号。

若不明白，参考下图：

图3测试需求和测试项编号展示

5、需求确认。

测试人员创建测试需求和测试项之后，测试经理或项目经理需要确认已建测试需求和测试项的完整性和正确性。

如果测试人员是根据测试计划创建的测试需求项或测试项，并且测试计划已经过评审，测试经理或项目经理可以不进行确认，只需QA检查这些测试需求项、测试项和测试计划中所列需求项的一致性即可。

6、测试人员对业务目标或功能点设计测试点，具体设计格式参考下图：

测试范围、前置条件、说明、正常流、异常流不必都使用。

7、测试点按执行优先级进行编号，步骤名称命名规范

TD中默认的步骤名称为‘stepx’，但这不利于测试点的展现，所以我们采用自命名形式。

步骤命名以‘序号+、+描述’命名。

序号，就是1、2、3……阿拉伯数字。

描述要求，一是对测试点表达的准确性；二是表达语言精练性。

步骤描述规范

步骤描述格式如下：

执行步骤1；

执行步骤2；

……

【说明】：

如果测试步骤或其中的数据不易表达，可以借助测试步骤中的附件功能，上传步骤或测试数据截图来帮助表达。

图4带附件的测试用例

步骤描述要求，一是步骤描述准确简练，可读性要好；二是测试数据真实有效，可执行性要好。

预期结果描述规范

8、部分项目开发和测试周期比较紧，不适合采用7中的步骤规范。

针对这类项目，可以简化步骤规范。

简化后的规范如下：

步骤名称以‘详细信息’中的每条测试点命名。

步骤描述为空。

【说明】：

为保证测试进度，这部分内容暂时不写但是测试后期有时间了要进行补充。

预期结果正常。

图5密码修改的测试要点概述

图6为简化流程测试步骤

9、测试点按执行优先级进行编号，测试步骤编写建立基本流和异常流两个测试步骤（不规范，但好维护，如果工期允许可以细化到每一个测试点），如下图所示。

5.2测试执行管理

测试用例设计完成并通过评审后，需要在TD的TESTLAB中根据版本号和测试范围创建测试集。

测试集命名和结构规定。

测试集的一级目录以‘第X轮-V版本号’如‘第一轮-V1.0.0’进行命名；

二级目录是测试范围，三级目录是测试需求的一级目录；四级目录是测试需求的二级目录等等以此类推。

一级目录下面均是业务流程或功能点时，将各个业务流程和功能点作为单独的测试集；

一级目录下面有功能点和二级目录共存时，将各个功能点作为单独的测试集，若二级目录下面没有嵌套三级目录，则将该二级目录作为一个测试集，若二级目录嵌套有三级目录，按照一级目录下面的二级目录的处理方式处理三级目录；

测试执行------测试项状态描述。

Failed------测试项中部分测试实例执行未通过。

N/A------由于某种原因，测试项中的测试实例无法执行。

NoRun------测试项中所有的测试实例没有执行。

NotCompleted------测试项中部分测试实例没有执行。

Passed------测试项中所有的测试实例执行通过。

测试缺陷与测试用例的绑定。

测试用例执行流程中的缺陷绑定。

测试用例执行流程外有关其它流程的缺陷绑定。

自由测试中的缺陷绑定。

5.3缺陷管理

缺陷提交时必填项的定义。

缺陷严重级别、优先级别和具体的描述规范参看测试管理规范当中的定义。