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

1、部门管理文档系列*公司测试用例编写标准及原则拟制日期审核日期批准日期修订历史记录版本日期AMD修订者说明1.0A初稿1.1M（A-添加，M-修改，D-删除）目 录1.引言41.1背景41.2目的51.3适用范围51.4缩写和术语52.测试用例52.1.概念52.2.用途52.3.设计依据62.4.编号规则62.5.用例内容62.6.用例设计方法72.6.1.等价类划分法72.6.2.边界值分析法72.6.3.错误推测法82.7.功能性测试方法82.7.1.输入非法数据82.7.2.输入默认值82.7.3.输入使缓冲区溢出的数据92.7.4.输出不符合业务规则的无效输出92.7.5.数据结构溢出

2、92.7.6.文件内容受损92.8.软件环境兼容性测试92.8.1.与操作系统的兼容性93.用例设计步骤103.1.用例评审113.1.1.评审原因113.1.2.评审内容113.1.3.评审过程113.1.4.评审人员113.1.5.评审方式123.1.6.结束标准124.用例规范124.1.编写用例规范124.2.编写用例标准124.3.用例实例说明134.3.1.字段说明134.3.2.用例说明134.4.用例级别划分145.用例的维护156.风险分析167.测试用例模板161. 引言1.1 背景为保证测试用例对需求的覆盖率，即对一个系统从整体功能到单个功能，都尽可能的高的覆盖。而单个功

3、能点主要强调的是不同的输入及其组合所带来的各种输入动作，系统是否都做了处理；测试用例设计首先要明确该系统存在多少功能点，要通过各种常用的测试方法来保证用例的完整性，然后再对各功能点的边界范围进行考虑。所以要保证测试用例的设计按照一种合理的结构组织进行，这样才能够更有效的保证系统所有功能点的覆盖率。1.2 目的为测试用例的质量负责，使测试工作能有序、合理化的进行，从而提高实施测试时对所测产品、系统或者模块的测试质量，也是作为各测试人员在设计用例时的一种规范，使之设计的用例能有效的被管理。1.3 适用范围Ø 本文档适用于测试人员Ø 本文档适用于××系统进行测

4、试时的测试案例设计Ø 本文档适用于××案例补充时的测试案例1.4 缩写和术语无2. 测试用例2.1. 概念是指为了实施测试而编写的一组有规范性、有据可依的输入数据与输出数据的组合，也指为了实施测试而向被测对象提供的一组输入、输出数据以及由各种执行条件和期望结果相组合的一个特定集合，以便测试某个程序路径或者来核实是否满足某个特定的需求。2.2. 用途Ø 指导测试工作有序进行，使实施测试的数据有据可依Ø 确保所实现的功能与客户预期的需求相符合Ø 完善软件不同版本之间的重复性测试Ø 跟踪测试进度，确定测试重点Ø 评估测试

5、结果的度量标准Ø 增强软件的可信任度Ø 分析缺陷的标准2.3. 设计依据Ø 需求说明书Ø 项目测试需求功能点Ø 所属行业的业务知识掌握程度Ø 测试工程师本人的理解程度（个人经验）2.4. 编号规则Ø 以 ××Ø 以各项目制定的规范为依据2.5. 用例内容用例编号功能点用例级别标题概述前置条件用例步骤输入数据预期结果实际结果问题描述执行结果Bug编号需求编号用例编写者测试执行者执行日期备注Ø 用例编号： 唯一标识，与需求编号对应，为多对一关系Ø 用例编写者：设计用例的人员

6、16; 被测对象： 要测试的功能点（模块、系统）Ø 用例标题： 对测试项简短的描述Ø 用例级别： 确定用例执行的级别。参考5.4Ø 前提条件： 执行用例时需要的预置条件Ø 输入条件： 执行该动作需要输入的数据Ø 操作步骤： 执行该动作需要完成的操作Ø 预期结果： 执行完该动作后程序的表现结果Ø 实际结果： 实际输出的结果Ø 问题描述： 执行该用例出现后系统显示的错误Ø 验证结果： 该测试用例是否执行通过Ø BUG编号： 填写BUGBASE中对应此用例的BUG编号Ø 需求编号： 唯一标识

7、，与用例编号对应，为一对多关系Ø 测试执行者：按照该用例执行测试的人员Ø 测试日期： 执行测试的时间Ø 备注：对未执行或不能进行执行的用例进行说明2.6. 用例设计方法2.6.1. 等价类划分法1) 概念是一种最典型的黑盒测试方法，它完全不考虑程序的内部结构，而是只根据对程序的要求和说明进行测试用例的设计。测试人员要求对需求说明书中的各项功能需求进行细致分析，把程序的输入域划分成若干个部分，然后从每个部分中选取少数代表性数据作为测试用例，经过这种划分后，每一类的代表性数据在测试中的作用都等价于这一类中的其他值。2) 分类Ø 有效等价类：是指对于程序的规格

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

9、要求对每一个输入值分别处理的情况下，可确定n个有效等价类和一个无效等价类2.6.2. 边界值分析法是等价类测试的特例，主要考虑等价类的边界条件，在等价类的边缘处选择元素，是指输入和输出的等价类中那些恰好处在边界，恰好超过边界或恰好在边界以内的数据集合组成的用例。对边界值设计测试用例原则：Ø 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超出这个范围边界的值作为测试输入数据Ø 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数小1、比最大个数多1的数作为测试数据Ø 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一

10、个元素和最后一个元素作为测试用例Ø 如果程序中使用了一个内部数据结构，则应选择这个内部数据结构边界上的值作为测试用例Ø 分析规格说明，找出其他可能的边界条件2.6.3. 错误推测法是根据经验和直觉设计测试用例。其思想是：如某处发现了缺陷，则该处可能会隐藏更多的缺陷，在实际操作中，列出程序中所有可能的错误和容易发生的特殊情况，然后依据测试者经验作出选择；而该用例设计方法不是一个系统的测试方法，只是作为辅助手段，其优点是测试者能快速且容易的切入，并能体会到程序的易用与否，缺点是难以知道测试的覆盖率，可能丢失大量的未知区域。2.7. 功能性测试方法2.7.1. 输入非法数据处理非

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

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

13、件，检查系统怎样处理Ø 上传内容受损的文件，检查系统怎样处理Ø 上传不同路径的文件，检查系统怎样处理2.8. 软件环境兼容性测试2.8.1. 与操作系统的兼容性操作系统的兼容性测试内容不仅包括软件的安装，还需对关键流程和功能点进行检查。而需要测试哪些操作系统的兼容性，首先取决于软件用户文档上对用户的承诺，其次就需要对一些常用操作系统兼容的检查。手机操作系统包括WAP版及CS版 WAP版：Ø AndroidØ iPhone OSØ LinuxØ Linux Smartphone OSØ MymobileØ Palm

14、OSØ RIM OSØ Symbian OSØ webOSØ Windows Mobile OSCS版：Ø iPhone OSØ LinuxØ Linux Smartphone OSØ RIM OSØ Symbian OSØ Windows Mobile OS系统兼容的浏览器为ie6 、IE7、IE8、火狐、火狐C/S或B/S系统兼容操作系统 windows XP 、windows2000、windows2003、windows7等等3. 用例设计步骤Ø 测试需求分析：从软件需求分析文

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

16、测试用例完善：测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善3.1. 用例评审3.1.1. 评审原因测试用例是软件测试的原则，但由于软件人员对在需求理解、设计等理解程度不同等因素的影响，首次产生的测试用例质量难以避免会有不同程度的差异，故对编写的测试用例进行评审是很有必要的，其作用是测试用例的评审过程能够起到用例结构清晰化、场景覆盖全面化以及优先用例的合理化安排等。3.1.2. 评审内容

17、16; 用例设计的结构安排是否清晰合理，是否高效的需求进行覆盖Ø 用例的优先级别是否安排合理Ø 是否覆盖了测试需求的所有功能点，包括需求中的业务规则、所有用户可能使用的流程或场景等Ø 用例是否有很好的可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确Ø 是否已经删除了冗余的测试用例Ø 是否包含充分的负面测试用例Ø 是否简洁、复用性强Ø 是否易于管理3.1.3. 评审过程Ø 基于项目需求的测试计划完成之后，进行初审，主要是对测试范围和测试要点进行审查Ø 在测试用例的设计完成之后进行复审

18、，主要是对测试用例的结构和覆盖率进行评审Ø 所有测试用例结束后，主要是对测试用例的具体描述是否有很好的可执行性，是否有冗余用例的存在进行评审3.1.4. 评审人员Ø 部门评审：测试部全体成员参与的评审Ø 项目评审：项目组全体测试人员与部分开发人员、需求人员等组成的小组Ø 公司评审：包括项目经理、需求分析人员、开发人员、测试人员Ø 客户评审：包括客户方的开发人员和测试人员Ø 内部评审：全部参与测试的人员3.1.5. 评审方式Ø 会议评审（包括内部评审及客户评审）。由设计该用例的人员进行讲解，参与会议评审的相关人员给出意见或建议

19、，并记录评审的意见和建议Ø 其他类形式。非正式的评审，话聊、主动请教周边同事等3.1.6. 结束标准经评审的用例由用例设计者根据评审的建议或意见进行修改，更新用例，再次发起评审、修改、更新用例，反复评审后，直至用例达到要求。（反复评审时存在时间问题）4. 用例规范4.1. 编写用例规范Ø 系统性。对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系Ø 连贯性。对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系统之间是否有正确的接口，若是依靠页面链接，则

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

21、制订统一的模板进行，并约定模板的使用方法；Ø 测试案例编写应当根据项目实际情况编写测试案例编写手册，包括案例编号规则、案例编写方法、案例编写内容、案例维护等内容；Ø 案例编写应根据手册中约定的编写方法、内容等进行编写；Ø 案例编写要步骤明确，输入输出要素清晰，并且与需求和缺陷相对应；Ø 案例编写应严格根据需求规格说明书及测试需求功能分析点进行，要求覆盖全部需求功能点；Ø 注重案例的可复用性，即在以后相似系统的测试过程中可以重复使用，减少测试设计工作量。4.3. 用例实例说明4.3.1. 字段说明序号功能点用例总数结果Y结果N结果H执行率Y%N%

22、H%编写人执行人备注登录首页账户管理转帐汇款网上支付网上催款总计Ø 功能点：按照系统一级菜单名称列出整个系统的大功能点，功能点顺序与系统菜单顺序相符Ø 结果为Y：表示用例执行通过，软件实现的功能与用例描述相符Ø 结果为N：用例执行不通过，软件功能与用例描述不相符，软件功能错误Ø 结果为H：用例暂不执行，现有软件暂不能达到该条用例的执行条件Ø 编写人：编写该功能点测试用例的人员姓名Ø 执行人：执行该功能点测试用例的人员姓名Ø 备注：当此模块无法完成测试，或该模块被删除时，在备注中填写无法完成此功能测试的原因或不能进行测试的原因

23、4.3.2. 用例说明Ø Sheet表：每个一级菜单为一个单独的sheet表，每个sheet表中包含此一级菜单下所有二级菜单及功能点Ø 二级菜单命名规则：菜单序号二级菜单名称Ø 序号编写规则：以手机版本.需求一级菜单号.二级菜单号.用例排序为编号规则Ø 用例步骤1) 编写完整的测试用例步骤2) 列出必要的前提条件3) 列出明确的输入数据4) 语言表达清晰明确Ø 预期输出1) 测试结果的可判定性，即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果2) 测试结果的可再现性，即对同样的测试用例，系统的执行结果应当是相同的Ø

24、 编写测试用例顺序1) 验证整体页面的元素2) 验证各个功能点，包括文本框、链接、按钮等（注：按照页面从上而下，从左至右的顺序验证）3) 验证业务流程Ø 测试用例填写规范1) 当验证结果为Y时，需要填写需求编号、测试人和测试日期项2) 当验证结果为N时，需要填写问题描述（描述由此用例测试出的BUG）、BUG编号（提交到缺陷管理工具的BUG编号）、需求编号、测试人和测试日期项3) 当验证结果为H时，需要填写测试人、测试日期、需求编号和备注（备注信息填写Hold原因或由于某个BUG影响而无法进行测试）4.4. 用例级别划分目的：l 保证所设计的用例在实施测试时真正起到指导作用l 突出测试

25、的重点，可以有针对性的实施测试 对测试用例进行优先级的划分，一般需要从三个方面考虑：P1：确保系统基本功能及主要功能的测试用例P2：确保系统功能的完善方面的测试用例P3：关于用户体验，输入输出的验证以及其他较少使用或辅助功能的测试用例对应的，我们可以对测试用例分为三个级别：高、中、低高（优先执行）：即关键路径的测试用例，包括最常执行的功能、基本流程的输入以及界面数据有效性校验作为高级别的测试用例；若该级别的测试用例完全执行通过，则表示该软件功能渐趋稳定；中（次级执行）：即可接收级测试的用例，包括不常执行的功能、异常流程的输入、边界值以及异常数据的输入作为中等级别的测试用例；若该级别的测试用例完

26、全执行通过，则表示该软件可以进行发布了；低（最后执行）：即建议执行的测试用例，也就是说该级别的测试用例不是不重要，而是该级别的用例在整个项目的生命周期内不是常常被运行，包括：GUI、界面显示、错误信息提示不统一、可用性、压力和性能测试等。备注：对已有的用例级别说明，包括A-正常流程测试、B-异常流程测试、C-页面元素正常输入测试、D-页面元素异常输入测试、E-页面元素显示测试，可具体归类如下（仅供参考）：高：A-正常流程测试、C-页面元素正常输入测试中：B-异常流程测试、D-页面元素异常输入测试低：E-页面元素显示测试5. 用例的维护Ø 删除过时的测试用例因为需求的改变等原因可能会使

27、一个基线测试用例不再适合被测系统，那么这些测试用例就会过时，需要对这些测试用例进行及时的删除，在删除过程中，不能够将整行的测试用例删除，应该将要删除的测试用例整行置灰，并将该行的用例计数器清为空；当整个功能模块需要删除时，则将整个SHEET状态置灰，并将用例计数器清空Ø 修改的测试用例随着软件项目的进展，测试需求可能会有部分变更，甚至大范围的变更，这个时候我们就会根据需求的变化相应的对测试用例进行维护，修改已经不符合目前需求的内容，并在备注栏中加以说明Ø 删除冗余的测试用例如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行删除，只需留下其中的一个Ø 增添新的测试用例对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现BUG但是没有与之对应的测试用例，需要按照测试用例的设计标准进行增添，增加测试用例时，需要在相应功能模块的最下方插入新增的测试用例，并在备注栏中加以说明6. 风险分析u 没有正式需求的测试用例。u 用例编写进度跟不上项目进度u 用例的评审只是走形式u 需求变更后未及时通知测试人员u 测试人员后期加入项