.精选范本测试用例编写规范技术部赖文举编写人赖文举编写日期2019年3月1日审核人审核日期批准人批准日期变更历史序号变更内容变更页变更类别变更者1.0新建///引言背景为保证测试用例对需求的覆盖率，即对一个系统从整体功能到单个功能，都尽可能的高的覆盖。而单个功能点主要强调的是不同的输入及其组合所带来的各种输入动作，系统是否都做了处理；测试用例设计首先要明确该系统存在多少功能点，要通过各种常用的测试方法来保证用例的完整性，然后再对各功能点的边界范围进行考虑。所以要保证测试用例的设计按照一种合理的结构组织进行，这样才能够更有效的保证系统所有功能点的覆盖率。目的为测试用例的质量负责，使测试工作能有序、合理化的进行，从而提高实施测试时对所测产品、系统或者模块的测试质量，也是作为各测试人员在设计用例时的一种规范，使之设计的用例能有效的被管理。概念是指为了实施测试而编写的一组有规范性、有据可依的输入数据与输出数据的组合，也指为了实施测试而向被测对象提供的一组输入、输出数据以及由各种执行条件和期望结果相组合的一个特定集合，以便测试某个程序路径或者来核实是否满足某个特定的需求。适用范围本文档适用于测试人员本文档适用于系统进行测试时的测试案例设计本文档适用于案例补充时的测试案例用例规范用途指导测试工作有序进行，使实施测试的数据有据可依确保所实现的功能与客户预期的需求相符合完善软件不同版本之间的重复性测试跟踪测试进度，确定测试重点评估测试结果的度量标准增强软件的可信任度分析缺陷的标准。设计依据需求说明书项目测试需求功能点所属行业的业务知识掌握程度测试工程师本人的理解程度（个人经验）用例内容1用例实际内容用例编号唯一标识。规则“模块名-功能点-编写人-001，单词或中文首字母。2模块名称模块名称3功能点测试的功能点4用例标题对测试项简短的描述5用例级别确定用例执行的级别[P0,P1,P2,P3]6前提条件执行用例时需要的预置条件7操作步骤执行该动作需要完成的操作，需要明确输入数据。8预期结果执行完该动作后程序的表现结果9执行结果执行状态用例的执行结果[通过，失败，延后]10实际结果实际输出的结果11问题描述执行该用例出现后系统显示的错误12BUG编号填写bug库中对应此用例的BUG编号13执行人按照该用例执行测试的人员编写用例原则系统性：对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系连贯性：对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系统之间是否有正确的接口，若是依靠页面链接，则页面的链接是否正确；对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯全面性：应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备正确性：输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据发生的业务吻合符合正常业务规则：测试数据要符合用户实际工作中的业务流程，同时也要兼顾各种业务的变化以及当前该业务行业的法律、法规、人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例；不允许出现与知名人士、小说中人物名等雷同情况。可操作性：测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果编写用例标准测试案例编写应该制订统一的模板进行，并约定模板的使用方法；测试案例编写应当根据项目实际情况编写测试案例编写手册，包括案例编号规则、案例编写方法、案例编写内容、案例维护等内容；案例编写应根据手册中约定的编写方法、内容等进行编写；案例编写要步骤明确，输入输出要素清晰，并且与需求和缺陷相对应；案例编写应严格根据需求规格说明书及测试需求功能分析点进行，要求覆盖全部需求功能点；注重案例的可复用性，即在以后相似系统的测试过程中可以重复使用，减少测试设计工作量。用例设计步骤测试需求分析：从软件需求分析文档中，找出待测软件/模块的需求，通过自己的分析、理解，整理成为测试需求，要清楚被测对象具体包含哪些功能点。业务流程分析：对所在行业的业务知识要熟悉，然后对被测软件/模块的业务流程要进行全盘的整理出来（可画简单的流程图作为参考），主要包含该业务流程的主流程、备选流程、数据流向、关键判断条件以及完成该操作的非必要条件。测试用例设计：测试用例设计的类型主要包括功能测试、边界测试、异常测试、性能测试、压力测试等，在设计用例时要尽量考虑边界、异常等情况。测试用例评审：由测试用例设计者发起，参加的人员需包括测