QA完整的测试用例设计规范样本.docx

QA完整的测试用例设计规范样本.docx

《QA完整的测试用例设计规范样本.docx》由会员分享，可在线阅读，更多相关《QA完整的测试用例设计规范样本.docx（14页珍藏版）》请在冰豆网上搜索。

QA完整的测试用例设计规范样本

[XXXX]

系统测试用例设计规范

撰写部门：

测试部

撰写时间：

xxx年xx月xx日

发行范畴：

开发部和测试部

文档审批信息

序号

角色

审批人签字

审批日期

备注

文档记录

版本编号

变化状态

简要阐明

撰写/变更人

批准人

批准日期

V1.0

C

创立测试部有关流程文档

XXX

*变化状态：

C――创立、A――增长、M――修改（+修改阐明）、D――删除（+删除阐明）

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测试执行管理

测试用例设计完毕并通过评审后，需要在TDTES