测试用例规范
一、概述
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会员权限；
6）数据准备：数据准备完整正确，覆盖到线上环境的所有情况；标识出业务流程处于的条；件，写明数据库表字段值，如OFFER.status=TBD；对于复杂的数据准备，写清具体SQL
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位不正常
- 因果图
因果图法考虑输入条件之间的联系，相互组合等，
- 场景法
根据需求说明书中的描述将包含事件流信息构造场景并设计响应的测试用例，使每个场景至少发生一次
- 错误推断法
错误推测法是基于经验和直接推测程序中可能存在的各种错误,针对这些错误设计相应的测试用例
四、测试用例等级
|
序号 |
用例级别 |
描述 |
|
1 |
P1 |
冒烟测试用例，以确定这个build版本是否可测的测试用例。 |
|
2 |
P2 |
基本功能的测试用例，保证功能稳定，目标的行为和能力可以正常的工作，包括重要的错误和边界被测试的测试用例的集合。 |
|
3 |
P3 |
检查功能细节的测试用例，包括边界，配置测试，这是使给出的功能区域或功能变得更详细，检查功能的多数方面，包括边界，错误和配置测试的测试用例集合。 |
|
4 |
P4 |
最少被执行的测试用例，在项目的生命期间里不是常常被运行，包括验证非功能性，例如易用性等测试用例集合。 |
五、用例维护
5.1 新增测试用例
对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现BUG但是没有与之对应的测试用例，需要按照测试用例的设计标准进行增添，增加测试用例时，需要在相应功能模块的最下方插入新增的测试用例，并在备注栏中加以说明
5.2 修改测试用例
随着软件项目的进展，测试需求可能会有部分变更，甚至大范围的变更，这个时候我们就会根据需求的变化相应的对测试用例进行维护，修改已经不符合目前需求的内容，并在备注栏中加以说明
5.3 删除冗余测试用例
如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行删除，只需留下其中的一个增添新的测试用例
5.4 归档过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测系统，那么这些测试用例就会过时，需要对这些测试用例进行及时的归档。当前测试用例状态会被更改为Obsolete并且移动到归档测试用例目录下。
六、常用检查点
|
检查类型 |
检查点 |
|
输入数据 |
边界值+1、边界值-1 |
|
最大数+1、最大数-1 |
|
|
空值、空表 |
|
|
极限值：0值、负数、非法字符 |
|
|
日期、时间控制 |
|
|
复选框 |
多个复选框可以被同时选中 |
|
多个复选框可以被部分选中 |
|
|
多个复选框可以都不被选中 |
|
|
逐一执行每个复选框的功能 |
|
|
复选框换页要被记录 |
|
|
保存操作 |
保存必填项校验 |
|
保存成功/失败给出提示信息 |
|
|
连续点击保存按钮 |
|
|
删除操作 |
删除二次确认弹窗 |
|
删除成功/失败是否有提示信息 |
|
|
删除成功/失败查看数据库 |
|
|
删除后，页面是否刷新 |
|
|
有附件的表单被删除 |
|
|
上传操作 |
对上传文件格式规定 |
|
文件的大小是否限制 |
|
|
上传失败后，后台不该有上传的文件 |
|
|
上传文件名字长、本地路径复杂、路径含有中文名称 |
|
|
加密附件查看能否原格式打开 |
|
|
权限 |
复制带有权限的页面url，去浏览器直接打开，提示没权限 |
|
功能操作权限（对应用户展示对应权限页面） |
|
|
数据权限（检查不同权限用户是否具有响应的权限） |
|
|
手机号 |
为必填项时，不输入任何字符或输入空格 |
|
超过11位 |
|
|
低于11位 |
|
|
测试是否对数字型数据是否进行了格式化输入 |
|
|
提示信息 |
检查应有提示信息是否提示 |
|
相应提示信息的内容用户是否接受 |
|
|
提示信息表达是否正确 |
|
|
确认后是否可以正常运行 |
|
|
用户登陆 |
用户权限 |
|
不存在用户名密码有提示信息 |
|
|
用户名和密码不填写有提示信息 |
|
|
重置按钮测试 |
|
|
正确账号密码进入响应系统 |
|
|
密码加密传输 |
|
|
Sql注入测试 |
