测试用例编写规范说明及模板.doc

部门管理文档系列―― 测试用例编写标准及原则 拟制 日期 审核 日期 批准 日期  修订历史记录 版本 日期 AMD 修订者 说明 1.0 A 初稿 1.1 M （A-添加，M-修改，D-删除） 目 录 1. 引言 4 1.1 背景 4 1.2 目的 5 1.3 适用范围 5 1.4 缩写和术语 5 2. 测试用例 5 2.1. 概念 5 2.2. 用途 5 2.3. 设计依据 6 2.4. 编号规则 6 2.5. 用例内容 6 2.6. 用例设计方法 7 2.6.1. 等价类划分法 7 2.6.2. 边界值分析法 7 2.6.3. 错误推测法 8 2.7. 功能性测试方法 8 2.7.1. 输入非法数据 8 2.7.2. 输入默认值 8 2.7.3. 输入使缓冲区溢出的数据 9 2.7.4. 输出不符合业务规则的无效输出 9 2.7.5. 数据结构溢出 9 2.7.6. 文件内容受损 9 2.8. 软件环境兼容性测试 9 2.8.1. 与操作系统的兼容性 9 3. 用例设计步骤 10 3.1. 用例评审 11 3.1.1. 评审原因 11 3.1.2. 评审内容 11 3.1.3. 评审过程 11 3.1.4. 评审人员 11 3.1.5. 评审方式 12 3.1.6. 结束标准 12 4. 用例规范 12 4.1. 编写用例规范 12 4.2. 编写用例标准 12 4.3. 用例实例说明 13 4.3.1. 字段说明 13 4.3.2. 用例说明 13 4.4. 用例级别划分 14 5. 用例的维护 15 6. 风险分析 16 7. 测试用例模板 16 引言 背景 为保证测试用例对需求的覆盖率，即对一个系统从整体功能到单个功能，都尽可能的高的覆盖。而单个功能点主要强调的是不同的输入及其组合所带来的各种输入动作，系统是否都做了处理；测试用例设计首先要明确该系统存在多少功能点，要通过各种常用的测试方法来保证用例的完整性，然后再对各功能点的边界范围进行考虑。所以要保证测试用例的设计按照一种合理的结构组织进行，这样才能够更有效的保证系统所有功能点的覆盖率。 目的 为测试用例的质量负责，使测试工作能有序、合理化的进行，从而提高实施测试时对所测产品、系统或者模块的测试质量，也是作为各测试人员在设计用例时的一种规范，使之设计的用例能有效的被管理。 适用范围 本文档适用于测试人员 本文档适用于××系统进行测试时的测试案例设计 本文档适用于××案例补充时的测试案例 缩写和术语 无 测试用例 概念 是指为了实施测试而编写的一组有规范性、有据可依的输入数据与输出数据的组合，也指为了实施测试而向被测对象提供的一组输入、输出数据以及由各种执行条件和期望结果相组合的一个特定集合，以便测试某个程序路径或者来核实是否满足某个特定的需求。 用途 指导测试工作有序进行，使实施测试的数据有据可依 确保所实现的功能与客户预期的需求相符合 完善软件不同版本之间的重复性测试 跟踪测试进度，确定测试重点 评估测试结果的度量标准 增强软件的可信任度 分析缺陷的标准 设计依据 需求说明书 项目测试需求功能点 所属行业的业务知识掌握程度 测试工程师本人的理解程度（个人经验） 编号规则 以 ××版本.需求一级菜单号.二级菜单号.用例排序为编号规则，例如：CS.1.1.1 以各项目制定的规范为依据 用例内容 用例编号 功能点 用例级别 标题概述 前置条件 用例步骤 输入数据 预期 结果 实际结果 问题描述 执行结果 Bug编号 需求编号 用例编写者 测试执行者 执行日期 备注 用例编号： 唯一标识，与需求编号对应，为多对一关系 用例编写者：设计用例的人员 被测对象： 要测试的功能点（模块、系统） 用例标题： 对测试项简短的描述 用例级别： 确定用例执行的级别。参考5.4 前提条件： 执行用例时需要的预置条件 输入条件： 执行该动作需要输入的数据 操作步骤： 执行该动作需要完成的操作 预期结果： 执行完该动作后程序的表现结果 实际结果： 实际输出的结果 问题描述： 执行该用例出现后系统显示的错误 验证结果： 该测试用例是否执行通过 BUG编号： 填写BUGBASE中对应此用例的BUG编号 需求编号： 唯一标识，与用例编号对应，为一对多关系 测试执行者：按照该用例执行测试的人员 测试日期： 执行测试的时间 备注：对未执行或不能进行执行的用例进行说明 用例设计方法 等价类划分法 概念 是一种最典型的黑盒测试方法，它完全不考虑程序的内部结构，而是只根据对程序的要求和说明进行测试用例的设计。测试人员要求对需求说明书中的各项功能需求进行