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测试用例书写规则
用例元素说明
用例名称：指明要测试的内容，如被测模块名称、业务流程名称等。
功能(业务)描述、规则、逻辑：对要进行测试的功能或业务进行简要的描述.
根据需求规格说明书、实际业务情况或其它相关文档列出本用例的规则、逻辑关系或需求点。
操作描述（输入\\动作）：描述本条测试用例的输入步骤，首先简要描述本条
测试用例的测试点，再对本测试点进行详细步骤描述或输入数据设置（需要详细进行描写）。
预期结果(输出）：描述输入数据后程序应该输出的结果。
前提条件\\数据准备：执行测试用例前需先要执行的操作或配置.
最基本的要求
1。具有清晰名称、前提条件、操作步骤、期望结果的；
2。可被他人理解的；
3。可被他人执行的；
具体元素要求
1。用例名称
1）一定要包含测试的业务流程。（鉴于公司使用的TD在Test）
2)名称简洁易懂，不要包括具体操作步骤；
2。前置条件
1)执行用例测试步骤前需要做的所有必备条件,原则上所有用例都有前置条件；
2)不可将其他用例作为前置条件，前置条件需要语言描述；
3）完整清楚，包括入口、帐号类型、账号权限、数据准备等，具体要求如下:
3.1）入口：覆盖所有功能入口,包含URL直接访问；
3.2）账号类型和权限：覆盖全部会员类型,注意业务权限控制,比如子账号权限，disable会员权限；
3。3）数据准备：数据准备完整正确，覆盖到线上环境的所有情况;标识出业务流程处于的条；件，写明数据库表字段值，如OFFER.status=TBD；对于复杂的数据准备,写清具体SQL
3。操作步骤
1)操作步骤描述清晰。如:在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；
2）操作和结果是一一对应的,但操作中不要包含结果的检查；
3）用例描述中不允许存在连词、介词,比如:而且，和，还（这种情况可以拆分为多个点)；
4）用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等；
5）用例描述中不允许出现二义性语句；
4.预期结果
1）原则上每个用例必需要有预期结果，结果不能为空；
2）结果中只能包含结果，不能有步骤；
3）一个结果有多个检查点时，确保检查点完整:
3.1）结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等；
3。2)结果涉及页面,需明确页面提示结果、数据变化；
3.3）结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化；
3。4）结果涉及消息:需明确关键查看内容；
3.5）结果对应不同输入数据有差别时需分别对应描述清晰；
用例维护规范
测试用例编写完成后，应对测试用例进行持续的维护：
1。 新项目需求变更，应及时对测试用例进行修改；
2。 维护期项目,可根据项目组情况周期对用例进行维护；
3. 所有发现的bug和故障，基于测试用例无法发现，需转化为测试用例；
4。 项目发布后的三个工作日内,需将项目用例根据具体情况归入产品功能用例库下
4.2测试用例编写流程
1.根据需求文档先编写测试计划和分析测试点。
2.根据测试点编写测试用例,细化用例详细操作步骤。
3。在本轮测试完毕后,测试人员提交测试用例更新表,对测试点分析和测试用例进行更新.
因篇幅问题不能全部显示，请点此查看更多更全内容