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

1、测试部管理文档系列测试用例编写标准及原则测试用例编写标准及原则拟制拟制日期日期审核审核日期日期批准批准日期日期修订历史记录修订历史记录版本版本日期日期AMD修订者修订者说明说明1.0A初稿1.1M（A-添加，M-修改，D-删除）目录引言引言.41.1背景.41.2目的.41.3适用范围.41.测试用例测试用例.41.1.概念.41.2.用途.41.3.设计依据.51.4.编号规则.51.5.用例内容.51.6.用例设计方法.51.6.1.等价类划分法. 51.6.2.边界值分析法. 61.7.功能性测试方法.71.7.1.输入非法数据. 71.7.2.输入默认值. 71.7.3.输入使缓冲区溢

2、出的数据.71.7.4.输出不符合业务规则的无效输出.71.7.5.数据结构溢出. 81.7.6.文件内容受损. 82.用例设计步骤用例设计步骤.83.用例规范用例规范.93.1.编写用例规范.93.2.编写用例标准.93.3.用例说明.94.用例的维护用例的维护.105.风险分析风险分析.116.测试用例模板测试用例模板.12引言引言1.1背景背景为保证测试用例对需求的覆盖率， 即对一个系统从整体功能到单个功能， 都尽可能的高的覆盖。而单个功能点主要强调的是不同的输入及其组合所带来的各种输入动作，系统是否都做了处理；测试用例设计首先要明确该系统存在多少功能点，要通过各种常用的测试方法来保证用

3、例的完整性，然后再对各功能点的边界范围进行考虑。所以要保证测试用例的设计按照一种合理的结构组织进行，这样才能够更有效的保证系统所有功能点的覆盖率。1.2目的目的为测试用例的质量负责， 使测试工作能有序、 合理化的进行， 从而提高实施测试时对所测产品、系统或者模块的测试质量，也是作为各测试人员在设计用例时的一种规范，使之设计的用例能有效的被管理。1.3适用范围适用范围本文档适用于测试人员1. 测试用例测试用例1.1.概念概念是指为了实施测试而编写的一组有规范性、有据可依的输入数据与输出数据的组合，也指为了实施测试而向被测对象提供的一组输入、 输出数据以及由各种执行条件和期望结果相组合的一个特定集

4、合，以便测试某个程序路径或者来核实是否满足某个特定的需求。1.2.用途用途指导测试工作有序进行，使实施测试的数据有据可依确保所实现的功能与客户预期的需求相符合完善软件不同版本之间的重复性测试跟踪测试进度，确定测试重点评估测试结果的度量标准增强软件的可信任度分析缺陷的标准1.3.设计依据设计依据需求说明书项目测试需求功能点所属行业的业务知识掌握程度测试工程师本人的理解程度（个人经验）1.4.编号规则编号规则以各项目制定的规范为依据1.5.用例内容用例内容系统模块功能点案例编号案例名称案例性质判断条件步骤预期结果系统模块：要测试的模块案例编号：唯一标识功能点：要测试的功能点案例名称：测试案例的名称

5、(概述)案例性质：正面/反面判断条件：执行案例需要的逻辑判断条件步骤：执行该动作需要完成的操作预期结果：执行完该动作后程序的表现结果1.6.用例设计方法用例设计方法1.6.1.等价类划分法等价类划分法1)1)概念概念是一种最典型的黑盒测试方法，它完全不考虑程序的内部结构，而是只根据对程序的要求和说明进行测试用例的设计。测试人员要求对需求说明书中的各项功能需求进行细致分析，把程序的输入域划分成若干个部分，然后从每个部分中选取少数代表性数据作为测试用例，经过这种划分后，每一类的代表性数据在测试中的作用都等价于这一类中的其他值。2)2)分类分类有效等价类：是指对于程序的规格说明来说是合理的、有意义的

6、输入数据构成的集合无效等价类：是指对程序的规格说明来说是不合理的、无意义的输入数据构成的集合3)步骤步骤从需求说明书中找出各个输入条件对找出的每个输入条件划分两个或两个以上的等价类4)方法方法在输入条件规定了取值范围或值的个数时，可以确定一个有效等价类和两个无效等价类在输入条件规定了输入值的集合或者规定了“必须如何”的条件情况下，可以确定一个有效等价类和一个无效等价类在输入条件是一个布尔量时，可以确定一个有效等价类和一个无效等价类在规定了输入数据的一组值（假定 n 个） ，并且程序要求对每一个输入值分别处理的情况下，可确定 n 个有效等价类和一个无效等价类1.6.2.边界值分析法边界值分析法是

7、等价类测试的特例，主要考虑等价类的边界条件，在等价类的边缘处选择元素，是指输入和输出的等价类中那些恰好处在边界，恰好超过边界或恰好在边界以内的数据集合组成的用例。对边界值设计测试用例原则：如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超出这个范围边界的值作为测试输入数据如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数小 1、比最大个数多 1 的数作为测试数据如果程序的规格说明给出的输入域或输出域是有序集合， 则应选取集合的第一个元素和最后一个元素作为测试用例如果程序中使用了一个内部数据结构， 则应选择这个内部数据结构边界上的值作为测试用例分析规格说明，找出其

8、他可能的边界条件1.7.功能性测试方法功能性测试方法1.7.1.输入非法数据输入非法数据处理非法数据的方法：防止不正确的输入进入被测软件输入了不正确的数据后，软件提示错误信息，拒绝不正确输入允许不正确的输入进入系统并处理，软件失效时调用异常处理程序测试的方法：输入数据的类型输入数据的长度输入数据边界值1.7.2.输入默认值输入默认值测试方法：接收软件显示的默认值键入空值将默认值改为另一个值，这样会使应用程序以不同值来允许将默认值改为另一个值，然后再变为空值1.7.3.输入使缓冲区溢出的数据输入使缓冲区溢出的数据测试方法：弄清楚测试的输入域长度，输入最大字符串测试输入一个比最大字符串更长的字符串

9、1.7.4.输出不符合业务规则的无效输出输出不符合业务规则的无效输出测试方法：列出所有无效输出，然后逐一测试熟悉业务规则及行业背景知识（如日期、时间、金额等小数问题）1.7.5.数据结构溢出数据结构溢出所有数据结构的大小都有上限，开发人员经常对有关数据结构的内容进行编码，忘记结构本身的物理局限。测试方法：尝试将过多的值输入数据结构，测试上溢尝试多删除一个数据，测试下溢全面理解需求文档，确定数据结构的界限1.7.6.文件内容受损文件内容受损当文件上传时，需要对上传文件的类型及内容进行测试测试方法：上传不同类型的文件，检查系统怎样处理上传内容受损的文件，检查系统怎样处理上传不同路径的文件，检查系统

10、怎样处理2. 用例设计步骤用例设计步骤测试需求分析：从软件需求分析文档中，找出待测软件/模块的需求，通过自己的分析、理解，整理成为测试需求，要清楚被测对象具体包含哪些功能点业务流程分析：对所在行业的业务知识要熟悉，然后对被测软件/模块的业务流程要进行全盘的整理出来（可画简单的流程图作为参考） ，主要包含该业务流程的主流程、备选流程、数据流向、关键判断条件以及完成该操作的非必要条件测试用例设计：测试用例设计的类型主要包括功能测试、边界测试、异常测试、性能测试、压力测试等，在设计用例时要尽量考虑边界、异常等情况测试用例评审：由测试用例设计者发起，参加的人员需包括测试负责人、项目经理、开发人员及其他

11、相关的测试人员测试用例完善： 测试用例编写完成之后需不断完善， 软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善3. 用例规范用例规范3.1.编写用例规范编写用例规范系统性。对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系连贯性。对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系统之间是否有正确的接口，若是依靠

12、页面链接，则页面的链接是否正确；对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯全面性。应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备正确性。输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据发生的业务吻合符合正常业务规则。测试数据要符合用户实际工作中的业务流程，同时也要兼顾各种业务的变化以及当前该业务行业的法律、法规可操作性。测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果3.2.编写用例标准编写用例标准测试案例编写应该制订统一的模板进行，并约定模板的使用方法；测试案

13、例编写应当根据项目实际情况编写测试案例编写手册，包括案例编号规则、案例编写方法、案例编写内容、案例维护等内容；案例编写应根据手册中约定的编写方法、内容等进行编写；案例编写要步骤明确，输入输出要素清晰，并且与需求和缺陷相对应；案例编写应严格根据需求规格说明书及测试需求功能分析点进行，要求覆盖全部需求功能点；注重案例的可复用性，即在以后相似系统的测试过程中可以重复使用，减少测试设计工作量。3.3.用例说明用例说明用例步骤1)编写完整的测试用例步骤2)列出必要的前提条件3)列出明确的输入数据4)语言表达清晰明确预期输出1)测试结果的可判定性，即测试执行结果的正确性是可判定的，每一个测试用例都应有相应

14、的期望结果2)测试结果的可再现性，即对同样的测试用例，系统的执行结果应当是相同的编写测试用例顺序1)验证整体页面的元素，验证各个功能点，包括文本框、链接、按钮等（注：按照页面从上而下，从左至右的顺序验证）2)验证业务流程4. 用例的维护用例的维护删除过时的测试用例因为需求的改变等原因可能会使一个基线测试用例不再适合被测系统， 那么这些测试用例就会过时，需要对这些测试用例进行及时的删除，在删除过程中，不能够将整行的测试用例删除，应该将要删除的测试用例整行置灰，并将该行的用例计数器清为空；当整个功能模块需要删除时，则将整个 SHEET 状态置灰，并将用例计数器清空修改的测试用例随着软件项目的进展，

15、测试需求可能会有部分变更，甚至大范围的变更，这个时候我们就会根据需求的变化相应的对测试用例进行维护，修改已经不符合目前需求的内容，并在备注栏中加以说明删除冗余的测试用例如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行删除，只需留下其中的一个增添新的测试用例对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现 BUG 但是没有与之对应的测试用例，需要按照测试用例的设计标准进行增添，增加测试用例时，需要在相应功能模块的最下方插入新增的测试用例，并在备注栏中加以说明5. 风险分析风险分析没有正式需求的测试用例。用例编写进度跟不上项目进度用例的评审只是走形式需求变更后未及时通知测试人员测试人员后期加入项目，对需求了解不透彻6. 测试用例模板测试用例模板