测试用例编写规范.doc

{项目名称}测试用例文件状态：[ ] 草稿[ ] 正式发布[ ] 正在修改文件标识：当前版本：作 者：完成日期：版 本 历 史版本/状态作者参与者起止日期备注目 录1. 概述 - 1 -1.1目的 - 1 -1.2使用范围 - 1 -1.3名词解释 - 1 -2. 测试用例编写原则 - 1 -2.1系统性 - 1 -2.2连贯性 - 1 -2.3全面性 - 2 -2.4正确性 - 2 -2.5符合正常业务惯例 - 2 -2.6仿真性 - 2 -2.7容错性（健壮性） - 2 -3. 测试用例设计方法 - 3 -4. 测试用例编写规范 - 5 -4.1测试用例命名规则 - 5 -4.2测试用例编号规则 - 5 -4.3测试用例书写规则 - 5 -4.4测试用例编写流程 - 8 -5. 测试用例模板 - 9 -5.1功能测试用例 - 9 -5.2健壮性测试用例 - 10 -5.3性能测试用例 - 11 -5.4图形用户界面测试用例 - 12 -5.5 用户界面测试的检查表 - 13 -5.6信息安全性测试用例 - 14 -1. 概述1.1目的统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。

为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量1.2使用范围适用于对产品的业务流程、功能测试用例的编写1.3名词解释系统测试：是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”测试分析：对重要业务、重要流程进行测试前的分析业务流程测试用例：关于产品业务、重要流程的测试用例2. 测试用例编写原则2.1系统性　　1、对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；　　2、对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系；2.2连贯性　　1、对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确；　　2、对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯；2.3全面性　　1、应尽可能覆盖程序的各种路径　　2、应尽可能覆盖系统的各个业务　　3、应考虑存在跨年、跨月的数据4、大量数据并发测试的准备5、系统中各功能、业务的异常情况2.4正确性1、输入用户实际数据以验证系统是否满足需求规格说明书的需求。

　　2、测试用例中的测试点应保证至少覆盖需求规格说明书中的各项功能2.5符合正常业务惯例　　1、测试数据应符合用户实际工作业务流程　　2、兼顾各种业务变化的可能　　3、要符合当前业务行业法律，法规2.6仿真性　　人名、地名、号码等应具有模拟功能，符合一般的命名惯例2.7容错性（健壮性）程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理3. 测试用例设计方法1. 等价类划分法：将所有可能的输入数据（有效的和无效的）划分成若干个等价类2. 边界值分析法：指对输入的边界条件进行分析，设计出针对边界值的测试用例3. 因果图法：　　就是利用图解法分析软件输入(原因)和输出条件(结果)之间的关系，以设计测试用例的方法因果图法适合于检查程序输入条件的多种情况的组合，并最终生成判定表，来获得对应的测试用例4. 功能图法　　功能图是描述程序状态变化、转移的过程，因为软件运行或操作的过程可以看作是其状态不断发生变化的过程测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。

5. 错误推测法推测法主要依赖经验、直觉来作出简单的判断甚至是猜测，给出可能存在缺陷的条件、场景等，在找到缺陷后，设计出相应的测试用例6. 正交实验设计方法　　主要步骤是：　　(1) 对软件需求规格说明中的功能要求进行划分(层层分解与展开)，分解成具体的、相对独立的基本功能　　(2) 根据基本功能的质量需求，找出影响其功能实现的操作对象和外部因素，每个因素的取值可以看作水平，多个取值就存在多个水平　　(3) 确定待测试软件中所有因素及其权值，这是测试用例设计的关键，确保全面、准确　　权值是依据各因素的影响范围、发生的频率和质量的需求来确定的　　(4) 加权筛选，生成因素分析表　　(5) 利用正交表构造测试数据集，正交表的每一行，就是一条测试用例考虑交互作用不可忽略的处理因素和不可混杂的原则，有交互作用的组合优先安排利用正交实验设计方法设计测试用例，可控制生成的测试用例数量，覆盖率高且测试效率高7.接口间测试测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性8.数据库测试依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试9.可理解（操作）性理解和使用该系统的难易程度（界面友好性）。

10.可移植性在不同操作系统及硬件配置情况下的运行性4. 测试用例编写规范4.1测试用例命名规则以功能模块和业务流程进行命名4.2测试用例编号规则功能编号规则：以测试模块名称的第一个字母进行命名（大写），若测试模块名称比较长时，可进行简写如：² 测试模块为“用户管理”，功能编号为“YHGL”；² 测试模块为“增值税一般人申报业务”，功能编号为“YBRSB”用例编号规则：功能编号 + 测试子项（功能点）+编号² 功能编号：同上；² 测试子项：为本测试项的测试点，如“用户管理”的测试点“添加用户”，测试子项为“TJYH”（如果测试子项比较长时，可以进行简写）；² 编号：从001开始进行顺延，如001、002……4.3测试用例书写规则1、被测试对象的介绍2、 测试范围与目的3、测试环境与测试辅助工具的描述4、 功能测试用例主要元素测试要点用例编号用例名称功能（业务）描述、规则、逻辑测试要点编号测试要点详细预期结果测试结果备注编写人审核方式及审核人备注：² 用例编号：以测试模块名称的第一个字母进行命名（大写），若测试模块名称比较长时，可进行简写² 用例名称：指明要测试的内容，如被测模块名称、业务流程名称等。

² 功能（业务）描述、规则、逻辑：对要进行测试的功能或业务进行简要的描述根据需求规格说明书、实际业务情况或其它相关文档列出本用例的规则、逻辑关系或需求点² 编号：功能编号 + 测试子项（功能点）+编号² 测试要点：对某一功能的功能点或业务点进行细化，形成本功能点的测试要点² 预期结果：描述输入数据后程序应该输出的结果² 测试结果：描述本条用例的实际测试情况，并判断实际测试结果与预期结果是否一致² 备注：记录测试过程中提交的bug编号或测试过程中遇到的问题² 编写人：编写本用例的设计人员² 审核方式及审核人：注明本用例由谁进行审核及审核人姓名详细用例编写表用例编号用例名称功能（业务）描述、规则、逻辑编号操作描述（输入/动作）预期结果（输出）测试结果备注对应有测试要点一:…………………………………………..…………………………………………..前提条件\数据准备：………………………对应有测试要点二:…………………………………………..…………………………………………..前提条件\数据准备：………………………编写人审核方式及审核人备注：² 用例编号：以测试模块名称的第一个字母进行命名（大写），若测试模块名称比较长时，可进行简写。

² 用例名称：指明要测试的内容，如被测模块名称、业务流程名称等² 功能（业务）描述、规则、逻辑：对要进行测试的功能或业务进行简要的描述根据需求规格说明书、实际业务情况或其它相关文档列出本用例的规则、逻辑关系或需求点² 编号：功能编号 + 测试子项（功能点）+编号² 操作描述（输入\动作）：描述本条测试用例的输入步骤，首先简要描述本条测试用例的测试点，再对本测试点进行详细步骤描述或输入数据设置（需要详细进行描写）² 预期结果（输出）：描述输入数据后程序应该输出的结果² 测试结果：描述本条用例的实际测试情况，并判断实际测试结果与预期结果是否一致² 备注：记录测试过程中提交的bug编号或测试过程中遇到的问题² 编写人：编写本用例的设计人员² 审核方式及审核人：注明本用例由谁进行审核及审核人姓名² 前提条件\数据准备：执行测试用例前需先要执行的操作或配置5、功能测试用例编写规则编写测试用例时对测试模块的功能点划分，先对本功能点的特性、配置或需求进行简要描述后再对该功能点进行用例的编写，如：测试用户管理，首先将用户管理划分为几个功能点，添加用户信息、修改用户信息、删除用户信息和查询用户信息在添加用户信息时，根据需求或实际业务情况获到用户属性信息，如：用户ID为4位，只能为数字；用户密码为6位字符…测试要点用例编号YHGL用例名称用户管理功能（业务）描述、规则、逻辑对用户进行添加、修改、删除及修改操作1、添加用户用户ID为4位，只能为数字；用户密码为6位字符…2、修改用户 …….测试要点编号测试要点详细预期结果测试结果备注添加用户信息：用户ID为4位，只能为数字；用户密码为6位字符…YHGL-TJYH-001正常添加用户信息可以添加成功、数据库中数据正确YHGL-TJYH-002添加的用户ID为非数字格式，查看是否进行校验只允许输入数字YHGL-TJYH-003…修改用户信息修改用户信息后查看数据库中的数据是否正确数据库中信息正确编写人XXX审核方式及审核人测试大纲评审\XXX备注：详细用例编写表。