一、概述
1.1 编写目的
测试用例不仅仅用于QA阅读和执行。它们也可能会被开发、PD、PM等阅读审查或执行；也更可能被其他测试人员或者新员工作为业务学习、测试执行的参照。
编写测试用例的最终目标是：一个对于产品毫无所知的人员，也能够快速的熟悉用例并执行用例。
1.2 使用范围
适用于对产品需求的业务流程、功能测试用例的编写。
1.3 约定
测试用例采用Excel的方式编写，产出结果为禅道用例。
用例包含全功能以及冒烟测试用例。
修改测试用例内容后需及时通知本业务线测试相关人员。
二、测试用例编写原则
2.1 基本要求
1.具有清晰名称、前提条件、操作步骤、期望结果
2.可被他人理解的
3.可被他人执行的
2.2 用例名称
1）常用的结构 “主、谓、宾”
2）名称简介易懂，不要包含具体操作步骤
2.3 前提条件
1）执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件
2）不可将其他用例作为前置条件，前置条件需要语言描述；
3）完整清楚，包括入口、帐号类型、账号权限、数据准备等，具体要求如下：
4）入口：覆盖所有功能入口，包含URL直接访问；
5）账号类型和权限：覆盖全部会员类型，注意业务权限控制，比如子账号权限，disable会员权限；
2.4 操作步骤
1）操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；
2）操作和结果是一一对应的，但操作中不要包含结果的检查；
3）用例描述中不允许存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）；
4）用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等；
5）用例描述中不允许出现二义性语句；
2.5 预期结果
1）原则上每个用例必需要有预期结果，结果不能为空；
2）结果中只能包含结果，不能有步骤；
3）一个结果有多个检查点时，确保检查点完整；
3.1）结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等；
3.2）结果涉及页面，需明确页面提示结果、数据变化；
3.3）结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化；
3.4）结果涉及消息：需明确关键查看内容；
3.5）结果对应不同输入数据有差别时需分别对应描述清晰；
2.6 用例维护规范
测试用例编写完成后，应对测试用例进行持续的维护：
1.新项目需求变更，应及时对测试用例进行修改；
2.维护期项目，可根据项目组情况周期对用例进行维护；
3.所有发现的bug和故障，基于测试用例无法发现，需转化为测试用例；
4.项目发布后的三个工作日内，需将项目用例根据具体情况归入产品功能用例库下
三、编写测试用例方法
边界值
错误更可能出现在输入的附近趋势 +1和-1，用此边界值需考虑三点：上点，离点，内点 一般会选择6个数据进行测试
例1：注册账号可输入6-10位字符可注册
边界：离点：5、7 上点：6、10 内点：7、9
等价类
有效等价类 -- 在取值范围内
无效等价类 -- 在取值范围外
例2：注册账号可输入6-10位字符可注册
答：有效等价类：大于等于6位、小于等于10位，例如：6，9属于正常
无效等价类：小于6位、大于10位 例如 5位 11位不正常
因果图
因果图法考虑输入条件之间的联系，相互组合等。
场景法
根据需求说明书中的描述将包含事件流信息构造场景并设计响应的测试用例，使每个场景至少发生一次
错误推断法
错误推测法是基于经验和直接推测程序中可能存在的各种错误,针对这些错误设计相应的测试用例
四、测试用例等级
五、用例维护
5.1 新增测试用例
对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现BUG但是没有与之对应的测试用例，需要按照测试用例的设计标准进行增添，增加测试用例时，需要在相应功能模块的最下方插入新增的测试用例，并在备注栏中加以说明。
5.2 修改测试用例
随着软件项目的进展，测试需求可能会有部分变更，甚至大范围的变更，这个时候我们就会根据需求的变化相应的对测试用例进行维护，修改已经不符合目前需求的内容，并在备注栏中加以说明。
5.3 删除冗余测试用例
如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行删除，只需留下其中的一个增添新的测试用例。
5.4 归档过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测系统，那么这些测试用例就会过时，需要对这些测试用例进行及时的归档。当前测试用例状态会被更改为Obsolete并且移动到归档测试用例目录下。
六、常用检查点
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
