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

[XXXX]

系统测试用例设计规范

撰写部门：测试部

撰写时间：xxx年xx月xx日

发行范围：开发部和测试部

文档审批信息

文档记录

*变化状态：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结合工具使用 (8)

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

5.2测试执行管理 (14)

5.3缺陷管理 (14)

1目的

统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。

2适用范围

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

3术语解释

系统测试：系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正

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

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

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测试用例设计方法

➢等价类划分。把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。

➢边界值分析。通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。

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