功能测试用例编写指南.docx
《功能测试用例编写指南.docx》由会员分享，可在线阅读，更多相关《功能测试用例编写指南.docx（24页珍藏版）》请在冰点文库上搜索。
功能测试用例编写指南
LELEwasfinallyrevisedonthemorningofDecember16,2020
功能测试用例编写指南
测试用例规范指南
变更记录
序号
修改日期
修改内容
修改人
审核人
批准人
批准日期
1
2010-12-28
创建
孔春梅
2
一．前言
本规范主要目的作为我们日常工作的指导方法，快速提高工作效率。
1．问题
我们在编写用例中实际遇到哪些问题？
1.新增“应用“用例，用例中描述操作几次算是一个完整的用例？
2.
3.多个用例的前提都一致时，这个前提写哪里？
都要写。
什么情况下要写前提？
4.功能套功能—颗粒度划分--一个独立功能建立一个文件夹。
里面还有SRD
父级功能与子功能有关联时，可在父级下面描述
5.用例粒度：
写到什么程度就可达到标准？
6.一个用例要执行几次才算pass取决于最后一次执行状况。
不同轮次的选择执行。
7.
8.复杂度较高的业务，用例如何划分？
独立功能拆分。
在业务流程里覆盖
9.用例多为数据或场景的描述，提交bug时重现情景需要写明。
10.合法校验的用例哪个轮次执行？
第3轮策略里体现
11.公共用例：
如何引用
12.
13.用例框架设计（左侧是箱子，右侧是内容）
（1）如何划分箱子（
14.2）内容决定结果，要设计哪些内容（
15.3）用例编写的粒度如何把握（粗细）
16.如何达到用例的内容清晰、主次程度分明？
17.问题：
当该功能点暂时没想出子功能点，但后期想出来了，是否再转为文件夹？
18.一个测试目标有多个测试场景，有的分了多个R，有的是一个R中。
19.页面导航要不要单独拿出一个R？
20.
21.特殊业务的划分，如精确执行--计划编制
2．目的
测试的重点不在于找出更多的bug，而是为了用“设计用例覆盖业务功能/场景”的手段来保证产品的准确性，能满足和解决客户实际工作的快捷高效且不发生错误。
※统一测试用例编写的规范
※以最有效的测试用例达到最大的覆盖率，更快速的辅助测试执行，不仅提高软件质量，也提高了工作效率。
※形成用例库集，不断的补充和完善，积累项目测试经验
3．编写用例的好处
※具有计划性、组织性、步骤性，从而避免盲目测试并提高测试效率，减少测试的不完全性；
※制定公共用例，不同的项目进行复用，节省了不同项目用例设计时间
※用例的层次性、条理性，使得bug也有层次性，使开发人员不同阶段关注不同的缺陷
※可以根据测试用例的优先等级，不同策略实施不同级别的测试
※软件测试的实施重点突出、目的明确；
※根据测试用例的多少和执行难度，估算测试工作量，便于测试项目的时间和资源管理与跟踪；
※减少回归测试的复杂程度，在软件版本更新后只需修正少量的测试用例便可展开测试工作，降低工作强度、缩短项目周期；
※若顾客有要求，测试用例会是交付产品中的一部分。
提高软件的可信度。
4．适用范围
测试部内部成员。
二．测试用例设计阶段
1．测试用例设计原则
1．用例设计与维护的工作原则
用例的设计不是一劳永逸的事情，要保持时时更新（用例评审后、需求变更后、有疑问的需求得以确认后、任何时候发现遗漏的用例后）
1）遵从测试用例组织框架划分标准
2）根据每个“独立功能点”细致地设计测试用例
3）执行完一轮测试之后，都要对测试用例进行补充和整理
4）测试结束之后，根据测试用例整理出测试思路进行总结
2．优先级原则
按照不同轮次所要求的测试策略来选取优先级用例。
优先级如何划分什么样的轮次应选取什么优先级别的用例
3．公共用例引用原则
通过共性用例提高测试效率
4.一切以客户为中心
多从用户的角度考虑软件的“有用”和“好用”。
（1）有用：
是指产品是能满足客户的业务需求，能给客户带来价值。
（2）好用：
是指客户能够非常快捷方便的使用产品来满足实际工作需求。
客户使用产品是一个过程，包括从如何能容易的获得产品，容易安装，容易使用，容易升级和维护，文档清晰等。
5.测试用例编写要求
测试用例是基于需求的，写好用例必须非常理解需求，能从全局上把握。
可以用等价类划分、边界值、路径法、矩阵表、正交法、判定表、因果图等方法设计用例。
想做到对需求的100%覆盖，必须对需求进行必要的分析，不能一上来就盲目的写用例。
用例编写完成后必须明确哪些是核心功能的用例。
编写用例过程中，要考虑以下几点：
（1）有效性：
本用例有明确的“测试目标”
（2）可理解性：
每个step必须描述清晰，不能出现模棱两可或重复的话语，用例写完最好看一遍，让单条用例流畅。
（3）清晰性：
用例的验证点要明确清晰、重点突出，一个用例进行一个功能点的验证。
一个step对应一个业务场景，测试用例包含前置条件的必须将前置条件描述清楚，以及入口等。
（4）可维护性：
可以应对需求的变更。
当需求变更时，及时维护用例，做到用例的实时性与有效性。
2．测试需求的确定过程
根据开发过程和实际工作需要将测试阶段划分为：
确定测试需求、设计测试用例、执行测试、编写bug、回归测试、结束测试、测试总结阶段。
需求阶段中的主要工作和规范如下：
（1）需求熟悉阶段：
充分理解用户需求和产品需求文档，对于歧义的要及时记录下来，添加到《需求跟踪表》，根据事先约定好的工作流程对需求问题进行确认；
（2）需求评审结束前后：
测试人员在任何阶段发现的需求问题（有疑问的或不明确的）都要记录下来，添加到《需求跟踪表》，根据事先约定好的工作流程对需求问题进行确认。
（若问题不多，也可以私下找项目经理或开发人员进行确认，但均需添加到《需求跟踪表》中）。
3．编写测试用例的路径
（1）熟悉和分析需求后，首先在TD的Requirements中将需求转化为需求测试点，需求粒度要细化到最小的功能点（比如添加、修改等）；
（2）然后切换需求到TESTPLAN中，在TESTPLAN中编写测试用例。
4．测试用例的设计原理
编写用例的目的就是更好的辅助测试来保证软件质量。
那么何为质量？
基本包含两个层次的含义，即“正确的软件”及“软件运行正确”。
（1）正确的软件：
是指一个软件要能够满足用户的需求，为用户创造价值。
此价值可以体现两方面，即为用户创造利润或者减少成本。
（2）软件运行正确：
是指在软件符合用户需求的基础上，软件没有或不影响正常功能的小缺陷，扩展性很强，性能良好，易用性高等。
为了用例达到最大覆盖率，我们设计用例是从“用户实际业务应用”、“需求开发实现”（即纵向和横向）2个维度设计用例，目前我们较好的方式就是用这种冗余的办法来保证软件质量。
我们在编写用例时，要对需求进行科学合理的颗粒度划分，我们先来看下以下几种负面例子。
[用例框架]每个UserCase都要有对应的一个用例集合对其进行测试
负面例子：
在界面或者需求里经常会出现很多功能写在一起的需求，所以会导致编写的测试用例也放在了一起，这样就会发现很大的功能却只有一个用例对应，所以导致测试用例无法展开。
所以我们在实际测试用例框架搭建中，要考虑对立的用户操作（比如日记录入、日记补给、日记修改、日记审阅等等）设计独立功能测试目录集，在这个目录集下存放所有用于验证它的测试用例。
[用例框架]协助功能要建立在主功能下，根据复杂度建立子目录或者R用例
每个协助功能（比如日记录入时的导入计划），由于其不作为一个独立日记功能存在所以在建立框架时要把它建立在录入日记下
[测试点要求]每个用例都是针对于某个测试点在进行测试
针对于某个UserCase，需要通过设计多个测试点来全面对其进行测试，而每个测试用例必须是针对于某个测试点展开验证
[测试点要求]测试点要重业务数据测试设计
负面例子：
以前写的很多测试过多的是在描述测试什么，描述步骤，缺少怎么测试的内容；所以现在必须强调轻步骤、重业务数据设计。
步骤用于测试导航
[公共用例]通过共性用例提高测试效率
基于以上情况，我们对用例框架设计从以下3方面着手：
功能测试用例FVT、业务数据流用例FIVT、用户验收用例UAT
4.1功能测试用例FVT
4.1.1功能用例设计思路
是从开发实现角度测试，描述功能的逻辑规则及页面元素，分层描述逻辑规则，对逻辑规则细化可直接作为用例的操作步骤描述。
以正向和逆向思维考虑设计用例。
（1）正向思维：
验证被测对象是不是做了它该做的事情。
（2）逆向思维：
验证被测对象有没有做它不该做的事情。
•01冒烟S//基础的操作（包括所有属性的输入）
•02规则R//详细的业务规则，如唯一性，权限，数据（计算正确性、完整性，排序），逻辑等
•03接口D//定义与使用。
如定义处对使用处的影响。
•04边界B//数据临界、事务操作临界，即一般人很少用到的情况
•05并发C//实时、异步并发
•06合法检测E//数据项的完整性约束，包括异常的情况，事务中断等
以上6类用例统一记为“F”规则。
4.1.2功能用例框架划分规则
目的是保持用例层次结构分明、清晰和设计风格一致性。
1.框架划分原则
（1）原则一：
基础的增删改查
用例框架的文件夹，按功能特性逐级进行划分，直到细化为具体的独立“功能点”（如增加、修改等）。
用例应该按照增删改的顺序进行安排，这样执行的时候效率比较高，避免不必要的重复测试。
当某功能点为独立时（不可再拆分），则写为F规则。
当某功能点又能拆分出多个子功能点，则形成文件夹。
里面再分自己的F规则。
（2）原则二：
[父功能]下存在[子功能]
（a）当[子功能]为独立功能点，则在[父功能]文件夹下建立[子功能]的文件夹。
该文件夹下包含用例：
[子功能]自身的F规则//注：
这里的F规则，请参考：
4.1.1
父子功能的逻辑关联规则。
当[子功能]有N种不同类的输出作为父功能的输入时，则需要有N个此类用例。
//即子功能的多种输出都会对父功能产生不同的影响。
命名方式请见下面第4条。
（b）[子功能]又有[子功能]时，用例划分方法同（a）
2.文件夹层级要求
子业务模块（如计划录入）按根节点算起，其下属子文件夹最好不要超过3层级。
比如超出3层级时，若[子功能]对[父功能]相对独立时，则可把[子功能]放到[父功能]的同级。
（具体情况具体分析）
3.文件夹及用例的命名方式
要求：
所有文件夹用01打头的数字标识其顺序。
如：
同级的文件夹以01、02、03等打头标识。
如上图所示，子业务模块[计划录入]文件夹记为父功能（或根节点）
举例：
[计划录入]这个父功能体现在“保存”这个动作上，所以把[计划录入]作为父功能文件夹。
文件夹/用例
命名规则
举例
备注
父功能文件夹
编号+父功能
01计划录入，02计划查询
父功能用例命名方式
01FVT_父功能_S01_xx
01FVT_父功能_R01_xx
01FVT_计划录入_S01_xx
子功能文件夹
父功能_子功能_BP01
计划录入_加入任务_BP01
子功能用例
01FVT_父功能_子功能_S01_xx
01FVT_计划录入_加入任务_S01_xx
父子功能的业务逻辑用例
02FVT_父功能_子功能_RP01_R01_xx
02FVT_加入任务_任务查询_RP01_R02_xx
提醒1：
本表中黄色标注，只有关于“父子功能的用例”命名才加RP标记。
提醒2：
上述用例中的xx，是指该用例是验证什么的一个描述。
举例：
01FVT_岗位新增_S01_验证给单位添加岗位，02FVT_岗位新增_R03_验证必填
用例框架举例：
上图解释:
父功能记为L，子功能记为M，子功能的子功能记为N
父功能文件夹命名：
编号+L//编号从01、02。
。
。
开始
子功能文件夹命名：
L_M_RP01//注意：
是下划线
子功能的子功能文件夹命名：
M_N_RP01
4.1.3功能用例粒度划分
4.1.3.1用例颗粒度划分的规范
何谓“测试目标”，假设你要测试一个新增界面某些字段的必填项，那么对新增【必填项】的验证就可以分出一个用例，即称为唯一的“测试目标”。
具体划分请参考《VER系统测试-公共用例.xlsx》
（1）一个用例对应唯一的“测试目标”。
（2）一个用例内部包含验证该“测试目标”的多种场景。
a）有多种场景，则分别用不同step描述。
b）每个step，在stepname列要简要描述本步骤的目的。
（3）一个用例应该有多少步骤？
分步测试的一个比较好的长度最大到10-15步骤，达到更高的用例可测性。
a）每个step，被执行测试的时间很短
b）测试人员不太可能迷失方向，犯错误或需要援助
c）测试组长可以估算需要多少时间来进行测试
d）结果更容易追踪
（4）当多个功能点之间存在制约关系时，可以采用矩阵表、路径或正交法进行用例编写。
4.1.3.2用例颗粒度划分的例子
下图为“寻呼发布”的界面，我们如何把握用例粒度呢？
接下来我们看如何分解用例：
4.1.3.3用例的前置条件
前置条件：
主要是对特殊情况的描述说明。
大家公认的默认规则可不写。
1.一个用例中需要描述公共的前置条件时，则第1个step为公共的前置条件（第2个step为导航）
2.一个用例中不同的step有各自的前置条件时，则在本step的Description中进行前置条件的描述。
什么时候必须加前置条件？
具体情况具体分析。
举一个删除“已使用的组织”的例子：
Stepname（描述目的）
Description（测试点描述）
ExpectedResult（期望结果）
前置条件
xxxx
导航
点击左侧菜单[系统管理—组织管理]
进入[组织管理]页面，当前路径显示正确
删除特殊状态的组织
前置条件：
组织为启用状态
选中已启用状态的组织，执行删除
不允许删除，给出友好提醒
删除被其他模块引用的组织
选中已被其他模块使用的组织，执行删除
不允许删除，给出友好提醒
4.1.3.4用例的公共导航
所有用例都涉及进入当前路径的描述，我们统一称为“导航”，即路径。
格式举例：
Stepname（描述目的）
Description（测试点描述）
ExpectedResult（期望结果）
导航
1.点击左侧菜单xx—xx—xx
2.点击“新增”按钮
1.正常进入xx页面，当前路径显示正确
2.弹出新增页面
5用例的step要求及格式
1、一个step有自己独立的明确的测试目的，即不同的step是对本测试目标进行怎么测的业务场景。
要重业务数据，轻步骤。
格式：
step的书写规范
Stepname
Description
ExpectedResult（期望结果）
描述本step的目的
该目的输入信息
输出信息，本输出可能存在多个验证点。
（分别用1,2,3标识出。
）
注意：
“描述”和“期望结果”二者一定要明确，不要互相混淆；不能存在模棱两可的字样；比如几乎、大概、一般等。
2、各步骤顺序依次为前提、导航、各场景。
举例：
组织管理--新增页面2有个“必填项”（组织名称、组织编号），验证必填项的用例如下。
Stepname（描述目的）
Description（测试点描述）
ExpectedResult（期望结果）
1导航
1.点击左侧菜单[系统管理—组织管理]
2.选中某组织，点击“新增”按钮
1.正常进入[组织管理]页面，当前路径显示正确
2.弹出新增页面
2查看必填标识
检测所有必填项的标识
对必填项都已进行红星标识
3不填写组织名称
4不填写组织编号
5必填项都不填写
Step中的标题简述必须要有，数字可以根据自己习惯而定。
4.2业务数据流用例FIVT
4.2.1业务流用例设计思路
注重数据传递，侧重业务逻辑的场景。
可以先画出业务数据流，针对主流程与备选流程进行用例设计。
•FIVT_cycle_C01//周期性，如与时间相关，跨周、月、年，先分析业务数据的时间特性，考虑最适中的周期。
•FIVT_data_S01//基本数据流（主业务数据流）
•FIVT_flow_A01//路径（包含所有路径、所有分支的用例覆盖），以业务数据为节点，每个分支路径为一个用例。
•FIVT_status_B01//业务数据的状态变化性（如流程状态、会议室闲忙状态），以状态为节点，不同的状态流转路径为一个用例
•FIVT_colateral_D01//业务数据的并发处理（实时、异步）
注：
上述中的A、B、C、D分别代表用例的重要程度。
以高到低排序。
4.2.2业务流用例粒度划分
一个流程路径：
分一个用例。
建议按照流程顺序进行用例安排，从第一个验证点到最后一个验证点，组成流程的开始到结束，方便测试执行。
4.3用户验收用例UAT
4.3.1用户验收用例设计思路
UAT：
UserAcceptanceTest
*脱离系统提供功能，站在用户角度来设计用例，从用户实际可能的操作场景考虑。
*基本是按业务特性制定的用例，模拟用户实际操作，描述用户的主要业务目标，包含完整的系统级场景和模拟用户实际操作的不同场景，几个功能点的组合也算是用户场景。
4.3.2用户验收用例粒度划分
业务应用是面向不同的使用对象：
普通员工、经理级、总裁级、管理员等。
主要体现：
员工级、管理者所关注的信息。
用户验收测试的每一个相对独立的部分，都应该有目标（本步骤的目的）、启动（着手本步骤必须满足的条件）、活动（构成本步骤的具体活动）、完成标准（完成本步骤要满足的条件）和度量（应该收集的产品与过程数据）。
5．测试用例优先级
接收软件测试前，我们已获取明确的质量目标。
在制定测试计划时，会根据质量目标制定不同的测试策略。
包含：
测试重点要求、类型的选取、测试活动的先后序列、资源调度与安排等。
各优先级所占全部测试用例比例通常如下：
P130%-45%，P240%-60%，P310%-15%。
1.划分优先级前，我们先对功能用例进行细分：
前提：
版本控制到位。
该问题如何避免？
（QTP录制回放）
01冒烟S
基础的操作（包括所有属性的输入）
每轮执行
回归测试
02规则R
详细的业务规则，如唯一性，权限，数据（计算正确性、完整性，排序），逻辑等
R1（核心主业务）
必经业务，缺少它则不可继续下一步业务操作。
如发寻呼，必须先添加组织/用户，否则无法发送寻呼。
每轮执行
回归测试
R2（经常使用的规则）
如寻呼中“转发”寻呼
每轮执行
回归测试
R3（较少使用的规则）
如寻呼中“发短信”功能
执行2次
R4（极少使用的复杂业务逻辑）
执行1次
03接口D
定义与使用。
D1：
定义处新增，使用处获取更新
【岗位管理】新增后，【用户管理】中可选择使用
执行2次
如定义处对使用处的影响
D2：
定义处修改，使用处获取更新
【岗位管理】修改，【用户管理】中同步更新
执行2次
D3：
定义处删除，使用处已获取更新
【岗位管理】删除，【用户管理】中不再显示
执行2次
04边界B
数据临界、事务操作临界，即一般人很少用到的情况
以删除为例：
1）无数据时，点击删除
2）同时删除“未被引用”和“已被引用”的记录
执行1次
05并发C
实时并发
执行1次
异步并发
06合法检测E
数据项的完整性约束，包括异常的情况，事务中断等
执行1次
FIVT_cycle_C01
周期性，如与时间相关，跨周、月、年
后期执行1次
FIVT_data_S01
基本数据流（主业务数据流）
每轮执行
FIVT_flow_A01
路径（包含所有路径、所有分支的用例覆盖）
执行2-3次
FIVT_status_B01
业务数据的状态变化性（如流程状态、会议室闲忙状态）
执行2-3次
FIVT_colateral_D01
业务数据的并发处理（实时、异步）
执行1次
验收用例
执行1次
2.优先级原则
需求优先级高，涉及的各类用例优先级也高
使用频度高、业务失败对客户产生严重影响、失败风险
3.优先级别
可以分为以下4类级别：
P1、P2、P3、P4，高到低。
级别
定义
用例执行要求
举例
备注
P1
冒烟测试用例
确保系统基本功能及主业务流的用例。
该级用例，每个测试版本都需执行且通过
S、R1（核心主业务）
考虑场景被使用频度、使用人员的比例，角色重要程度。
如员工/管理者/管理员有80%的频率在使用某功能
P2
关键路径测试用例
经常使用的核心业务。
是确保系统功能的完善方面的用例
该级用例，每个测试版本都需执行且通过
R2（经常使用的规则）
D
S2
该级测试用例均通过，意味着软件功能趋于稳定。
P3
可接受级测试用例
关于用户体验，输入输出的验证及其他较少使用或辅助功能的用例。
该级用例，只要执行一次通过即可
B，E，C，R3（较少使用的规则）
D
S3
P4
建议执行用例
极少被使用
如果有时间，最好执行该级用例，但不作为发布的必要条件。
R4（极少使用的复杂业务逻辑）
6．测试用例维护与共享
6.1测试用例维护
6.1.1当前版本的用例维护
需求
用例库目录
用例
需求增加
按颗粒度划分规则，来决策是否需要建立文件夹
增加新用例
需求修改
在本模块一级目录下增加【无效用例】子文件夹
1）在【无效用例】文件夹下先建立“无效用例”的所在目录
2）复制“原无效用例”到1）中
3）在“原无效用例”中修改“已变更”需求的用例
需求删除
若存在【无效用例】文件夹，则无需再建立
1）将“原无效用例”剪切到【无效用例】文件夹下
注：
【无效用例】文件夹只建立一个即可。
主要目的是储存垃圾用例，以便预防需求来回变更的情况。
6.1.2不同版本的用例维护
一个产品，随着时间会不断发布多个版本，使测试用例不断完善，同时也与产品功能、特性的变化保持一致，所以测试用例是和产品版本相关联的。
当产品有多个版本共存，为不同客户群提供服务，这时测试用例势必也会存在版本之分。
根据测试用例与产品需求保持一致性的原则，分以下几种情况：
产品需求
用例变更原因
对旧版本用例的影响
对新版本用例的影响
1
新版本中需求未变
新版本发现了bug或用例需要补充
有效。
如何保证新版本中修改的同步更新旧版本？
有效。
新版本中修改用例
2
新版本中需求变化（功能增强）
非新功能，是对原功能的功能增强
有效。
当前用例不可修改
新版本中修改或增加用例
3
新版本中需求取消
需求删除
有效
当前新版本的对应用例无效。
置为无效
4
新版本中完全新增的需求
需求新增
无效
新版本中增加用例
2．用例是否要有状态标识要制定几个状态有效、无效、维护中
6.2测试用例共享
在编写用例过程中，常常遇到不同模块下有相同功能的情况。
这种情况下，我们在设计用例时，就可以考虑公共用例的复用。
1．公共用例的框架
公共用例单独制定一个文件夹，里面包含各类可以共享的功能。
举例：
2．公共用例的引用
当其他模块需要引用公共用例时，我们要求复制粘贴的方式，然后调整为适合本功能的用例。
好处有以下几点：
（1
升级会员 