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

测试部管理文档系列 测试用例编写标准及原则测试用例编写标准及原则 拟拟制制日日期期 审审核核日日期期 批批准准日日期期 修订历史记录修订历史记录 版本版本日期日期AMD修订者修订者说明说明 1.0A初稿 1.1M （A-添加，M-修改，D-删除） 目 录 引言引言.4 1.1背景4 1.2目的4 1.3适用范围4 1.测试用例测试用例4 1.1.概念4 1.2.用途4 1.3.设计依据5 1.4.编号规则5 1.5.用例内容5 1.6.用例设计方法5 1.6.1.等价类划分法5 1.6.2.边界值分析法6 1.7.功能性测试方法7 1.7.1.输入非法数据7 1.7.2.输入默认值7 1.7.3.输入使缓冲区溢出的数据7 1.7.4.输出不符合业务规则的无效输出7 1.7.5.数据结构溢出8 1.7.6.文件内容受损8 2.用例设计步骤用例设计步骤8 3.用例规范用例规范9 3.1.编写用例规范9 3.2.编写用例标准9 3.3.用例说明9 4.用例的维护用例的维护10 5.风险分析风险分析11 6.测试用例模板测试用例模板12 引言引言 1.1背景背景 为保证测试用例对需求的覆盖率，即对一个系统从整体功能到单个功能，都尽可能的高的覆 盖。而单个功能点主要强调的是不同的输入及其组合所带来的各种输入动作，系统是否都做了处 理；测试用例设计首先要明确该系统存在多少功能点，要通过各种常用的测试方法来保证用例的 完整性，然后再对各功能点的边界范围进行考虑。所以要保证测试用例的设计按照一种合理的结 构组织进行，这样才能够更有效的保证系统所有功能点的覆盖率。 1.2目的目的 为测试用例的质量负责，使测试工作能有序、合理化的进行，从而提高实施测试时对所测产 品、系统或者模块的测试质量，也是作为各测试人员在设计用例时的一种规范，使之设计的用例 能有效的被管理。 1.3适用范围适用范围 本文档适用于测试人员 1. 测试用例测试用例 1.1.概念概念 是指为了实施测试而编写的一组有规范性、有据可依的输入数据与输出数据的组合，也指为 了实施测试而向被测对象提供的一组输入、输出数据以及由各种执行条件和期望结果相组合的一 个特定集合，以便测试某个程序路径或者来核实是否满足某个特定的需求。 1.2.用途用途 指导测试工作有序进行，使实施测试的数据有据可依 确保所实现的功能与客户预期的需求相符合 完善软件不同版本之间的重复性测试 跟踪测试进度，确定测试重点 评估测试结果的度量标准 增强软件的可信任度 分析缺陷的标准 1.3.设计依据设计依据 需求说明书 项目测试需求功能点 所属行业的业务知识掌握程度 测试工程师本人的理解程度（个人经验） 1.4.编号规则编号规则 以各项目制定的规范为依据 1.5.用例内容用例内容 系统模块功能点案例编号案例名称案例性质判断条件步骤预期结果 系统模块：要测试的模块 案例编号：唯一标识 功能点：要测试的功能点 案例名称：测试案例的名称(概述) 案例性质：正面/反面 判断条件：执行案例需要的逻辑判断条件 步骤：执行该动作需要完成的操作 预期结果：执行完该动作后程序的表现结果 1.6.用例设计方法用例设计方法 1.6.1.等价类划分法等价类划分法 1)1)概念概念 是一种最典型的黑盒测试方法，它完全不考虑程序的内部结构，而是只根据对程序的要求和 说明进行测试用例的设计。测试人员要求对需求说明书中的各项功能需求进行细致分析，把程序 的输入域划分成若干个部分，然后从每个部分中选取少数代表性数据作为测试用例，经过这种划 分后，每一类的代表性数据在测试中的作用都等价于这一类中的其他值。 2)2)分类分类 有效等价类：是指对于程序的规格说明来说是合理的、有意义的输入数据构成 的集合 无效等价类：是指对程序的规格说明来说是不合理的、无意义的输入数据构成 的集合 3)步骤步骤 从需求说明书中找出各个输入条件 对找出的每个输入条件划分两个或两个以上的等价类 4)方法方法 在输入条件规定了取值范围或值的个数时，可以确定一个有效等价类和两个无效等价类 在输入条件规定了输入值的集合或者规定了“必须如何”的条件情况下，可以确定一个有效 等价类和一个无效等价类 在输入条件是一个布尔量时，可以确定一个有效等价类和一个无效等价类 在规定了输入数据的一组值（假定 n 个） ，并且程序要求对每一个输入值分别处理的情况下， 可确定 n 个有效等价类和一个无效等价类 1.6.2.边界值分析法边界值分析法 是等价类测试的特例，主要考虑等价类的边界条件，在等价类的边缘处选择元素，是指输入 和输出的等价类中那些恰好处在边界，恰好超过边界或恰好在边界以内的数据集合组成的用例。 对边界值设计测试用例原则： 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超出 这个范围边界的值作为测试输入数据 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数小 1、比最 大个数多 1 的数作为测试数据 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元 素和最后一个元素作为测试用例 如果程序中使用了一个内部数据结构，则应选择这个内部数据结构边界上的值作为 测试用例 分析规格说明，找出其他可能的边界条件 1.7.功能性测试方法功能性测试方法 1.7.1.输入非法数据输入非法数据 处理非法数据的方法： 防止不正确的输入进入被测软件 输入了不正确的数据后，软件提示错误信息，拒绝不正确输入 允许不正确的输入进入系统并处理，软件失效时调用异常处理程序 测试的方法： 输入数据的类型 输入数据的长度 输入数据边界值 1.7.2.输入默认值输入默认值 测试方法： 接收软件显示的默认值 键入空值 将默认值改为另一个值，这样会使应用程序以不同值来允许 将默认值改为另一个值，然后再变为空值 1.7.3.输入使缓冲区溢出的数据输入使缓冲区溢出的数据 测试方法： 弄清楚测试的输入域长度，输入最大字符串测试 输入一个比最大字符串更长的字符串 1.7.4.输出不符合业务规则的无效输出输出不符合业务规则的无效输出 测试方法： 列出所有无效输出，然后逐一测试 熟悉业务规则及行业背景知识（如日期、时间、金额等小数问题） 1.7.5.数据结构溢出数据结构溢出 所有数据结构的大小都有上限，开发人员经常对有关数据结构的内容进行编码，忘记结构本 身的物理局限。 测试方法： 尝试将过多的值输入数据结构，测试上溢 尝试多删除一个数据，测试下溢 全面理解需求文档，确定数据结构的界限 1.7.6.文件内容受损文件内容受损 当文件上传时，需要对上传文件的类型及内容进行测试 测试方法： 上传不同类型的文件，检查系统怎样处理 上传内容受损的文件，检查系统怎样处理 上传不同路径的文件，检查系统怎样处理 2. 用例设计步骤用例设计步骤 测试需求分析：从软件需求分析文档中，找出待测软件/模块的需求，通过自己的分 析、理解，整理成为测试需求，要清楚被测对象具体包含哪些功能点 业务流程分析：对所在行业的业务知识要熟悉，然后对被测软件/模块的业务流程要 进行全盘的整理出来（可画简单的流程图作为参考） ，主要包含该业务流程的主流程、 备选流程、数据流向、关键判断条件以及完成该操作的非必要条件 测试用例设计：测试用例设计的类型主要包括功能测试、边界测试、异常测试、性 能测试、压力测试等，在设计用例时要尽量考虑边界、异常等情况 测试用例评审：由测试用例设计者发起，参加的人员需包括测试负责人、项目经理、 开发人员及其他相关的测试人员 测试用例完善：测试用例编写完成之后需不断完善，软件产品新增功能或更新需求 后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需 要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是 因测试用例存在漏洞造成，也需要对测试用例进行完善 3. 用例规范用例规范 3.1.编写用例规范编写用例规范 系统性。对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及 它们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关 系 连贯性。对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子 系统之间是否有正确的接口，若是依靠页面链接，则页面的链接是否正确；对模块业务 流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯 全面性。应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据 以及大数据量并发测试的准备 正确性。输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数 据发生的业务吻合 符合正常业务规则。测试数据要符合用户实际工作中的业务流程，同时也要兼顾各种业 务的变化以及当前该业务行业的法律、法规 可操作性。测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结 果 3.2.编写用例标准编写用例标准 测试案例编写应该制订统一的模板进行，并约定模板的使用方法； 测试案例编写应当根据项目实际情况编写测试案例编写手册，包括案例编号规则、案例编 写方法、案例编写内容、案例维护等内容； 案例编写应根据手册中约定的编写方法、内容等进行编写； 案例编写要步骤明确，输入输出要素清晰，并且与需求和缺陷相对应； 案例编写应严格根据需求规格说明书及测试需求功能分析点进行，要求覆盖全部需求功能 点； 注重案例的可复用性，即在以后相似系统的测试过程中可以重复使用，减少测试设计工作 量。 3.3.用例说明用例说明 用例步骤 1)编写完整的测试用例步骤 2)列出必要的前提条件 3)列出明确的输入数据 4)语言表达清晰明确 预期输出 1)测试结果的可判定性，即测试执行结果的正确性是可判定的，每一个测试用例都应有相 应的期望结果 2)测试结果的可再现性，即对同样的测试用例，系统的执行结果应当是相同的 编写测试用例顺序 1)验证整体页面的元素，验证各个功能点，包括文本框、链接、按钮等（注：按照页面从 上而下，从左至右的顺序验证） 2)验证业务流程 4. 用例的维护用例的维护 删除过时的测试用例 因为需求的改变等原因可能会使一个基线测试用例不再适合被测系统，那么这些测试用 例就会过时，需要对这些测试用例进行及时的删除，在删除过程中，不能够将整行的测 试用例删除，应该将要删除的测试用例整行置灰，并将该行的用例计数器清为空；当整 个功能模块需要删除时，则将整个 SHEET 状态置灰，并将用例计数器清空 修改的测试用例 随着软件项目的进展，测试需求可能会有部分变更，甚至大范围的变更，这个时候我们 就会根据需求的变化相应的对测试用例进行维护，修改已经不符合目前需求的内容，并 在备注栏中加以说明 删除冗余的测试用例 如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行