关键词不能为空

当前您在: 主页 > 英语 >

功能测试用例编写指南

作者:高考题库网
来源:https://www.bjmy2z.cn/gaokao
2020-10-31 10:44
tags:5655

柯普-歌咏的意思

2020年10月31日发(作者:沈克非)









测试用例规范指南
















1



变更记录

序号
1
2


































2
修改日期
2010-12-28

创建

修改内容 修改人
孔春梅

审核人


批准人


批准日期





一.前言
本规范主要目的作为我们日常工作的指导方法,快速提高工作效率。
1.问题
我们在编写用例中实际遇到哪些问题?
1. 新增“应用“用例,用例中描述操作几次算是一个完整的用例?
2. 多个用例的前提都一致时,这个前提写哪里?都要写。什么情况下要写前提?
3. 功能套功能—颗粒度划分 --一个独立功能建立一个文件夹。里面还有S R D
父级功能 与 子功能有关联时,可在 父级下面描述
4. 用例粒度:写到什么程度就可达到标准?
5. 一个用例要执行几次才算pass?取决于最后一次执行状况。不同轮次的选择执行。
6. 复杂度较高的业务,用例如何划分?独立功能拆分。在业务流程里覆盖
7. 用例多为数据或场景的描述,提交bug时重现情景需要写明。
8. 合法校验的用例哪个轮次执行?第3轮策略里体现
9. 公共用例:如何引用?
10. 用例框架设计(左侧是箱子,右侧是内容)(1)如何划分箱子?(2)内容决定结果,要设计哪些内容?(3) 用例编
写的粒度如何把握(粗?细?)
11. 如何达到用例的内容清晰、主次程度分明?
12. 问题:当该功能点暂时没想出子功能点,但后期想出来了,是否再转为文件夹?
13. 一个测试目标有多个测试场景,有的分了多个R,有的是一个R中。
14. 页面导航要不要单独拿出一个R?
15. 特殊业务的划分,如精确执行--计划编制
2.目的
测试的重点不在于找出更多的bug ,而是为了用“设计用例覆盖业务功能场景” 的手段来保证产品的准确性,能
满足和解决客户实际工作的快捷高效且不发生错误。
※ 统一测试用例编写的规范
※ 以最有效的测试用例达到最大的覆盖率,更快速的辅助测试执行,不仅提高软件质量,也提高了工作效率。
※ 形成用例库集,不断的补充和完善,积累项目测试经验

3



3.编写用例的好处
※ 具有计划性、组织性、步骤性,从而避免盲目测试并提高测试效率,减少测试的不完全性;
※ 制定公共用例,不同的项目进行复用,节省了不同项目用例设计时间
※ 用例的层次性、条理性,使得bug也有层次性,使开发人员不同阶段关注不同的缺陷
※ 可以根据测试用例的优先等级,不同策略实施不同级别的测试
※ 软件测试的实施重点突出、目的明确;
※ 根据测试用例的多少和执行难度,估算测试工作量,便于测试项目的时间和资源管理与跟踪;
※ 减少 回归测试的复杂程度,在软件版本更新后只需修正少量的测试用例便可展开测试工作,降低工作强度、缩短项目周期;
※ 若顾客有要求,测试用例会是交付产品中的一部分。提高软件的可信度。
4.适用范围
测试部内部成员。
二.测试用例设计阶段
1.测试用例设计原则
1.用例设计与维护的工作原则
用例的设计不是一劳永逸的 事情,要保持时时更新(用例评审后、需求变更后、有疑问的需求得以确认后、任何时候
发现遗漏的用例 后)
1) 遵从测试用例组织框架划分标准
2) 根据每个“独立功能点”细致地设计测试用例
3) 执行完一轮测试之后,都要对测试用例进行补充和整理
4) 测试结束之后,根据测试用例整理出测试思路进行总结
2.优先级原则
按照不同轮次所要求的测试策略来选取优先级用例。 优先级如何划分?什么样的轮次应选取什么优先级别的用例?
3.公共用例引用原则
通过共性用例提高测试效率
4. 一切以客户为中心
多从用户的角度考虑软件的“有用”和“好用”。
(1)有用:是指产品是能满足客户的业务需求,能给客户带来价值。
(2)好用:是指客户 能够非常快捷方便的使用产品来满足实际工作需求。客户使用产品是一个过程,包括从如何能容易
的获得 产品,容易安装,容易使用,容易升级和维护,文档清晰等。
5. 测试用例编写要求
测试用例是基于需求的,写好用例必须非常理解需求,能从全局上把握。可以用等价类划分、边界值、路径法、矩 阵

4



表、正交法、判定表、因果图等方法设计用例。想做到对需求的100%覆盖,必须对需求进行必要的分析,不 能一上来就
盲目的写用例。用例编写完成后必须明确哪些是核心功能的用例。编写用例过程中,要考虑以 下几点:
(1)有效性:本用例有明确的“测试目标”
(2)可理解性:每个step必须 描述清晰,不能出现模棱两可或重复的话语,用例写完最好看一遍,让单条用例流畅。
(3)清晰性: 用例的验证点要明确清晰、重点突出,一个用例进行一个功能点的验证。一个step对应一个业务场景,测试用例包含前置条件的必须将前置条件描述清楚,以及入口等。
(4)可维护性:可以应对需求的变更。当需求变更时,及时维护用例,做到用例的实时性与有效性。

2.测试需求的确定过程
根据开发过程和实际工作需要将测试阶段划分为:确定测 试需求、设计测试用例、执行测试、编写bug、回归测试、
结束测试、测试总结阶段。需求阶段中的主 要工作和规范如下:
(1)需求熟悉阶段:充分理解用户需求和产品需求文档,对于歧义的要及时记录 下来,添加到《需求跟踪表》,根据事先
约定好的工作流程对需求问题进行确认;
(2)需求 评审结束前后:测试人员在任何阶段发现的需求问题(有疑问的或不明确的)都要记录下来,添加到《需求跟踪表》,根据事先约定好的工作流程对需求问题进行确认。(若问题不多,也可以私下找项目经理或开发人员 进行确认,但
均需添加到《需求跟踪表》中)。
3.编写测试用例的路径
(1)熟 悉和分析需求后,首先在TD的Requirements中将需求转化为需求测试点,需求粒度要细化到最小的功能点(比如添加、修改等);
(2)然后切换需求到TEST PLAN中,在TEST PLAN中编写测试用例。
4.测试用例的设计原理
编写用例的目的就是更好的辅助测试来 保证软件质量。那么何为质量?基本包含两个层次的含义,即“正确的软件”
及“软件运行正确”。 < br>(1)正确的软件:是指一个软件要能够满足用户的需求,为用户创造价值。此价值可以体现两方面,即为 用户创造利润
或者减少成本。
(2)软件运行正确:是指在软件符合用户需求的基础上,软件 没有或不影响正常功能的小缺陷,扩展性很强,性能良好,
易用性高等。
为了用例达到最大覆盖率,我们设计用例是从 “用户实际业务应用”、“需求开发实现”(即纵向和横 向)2个维度设计
用例,目前我们较好的方式就是用这种冗余的办法来保证软件质量。我们在编写用例时 ,要对需求进行科学合理的颗粒度
划分,我们先来看下以下几种负面例子。
? [用例框架] 每个UserCase都要有对应的一个用例集合对其进行测试
? 负面例子:在界面或者需求里经常 会出现很多功能写在一起的需求,所以会导致编写的测试用例也放在了一起,
这样就会发现很大的功能却 只有一个用例对应,所以导致测试用例无法展开。所以我们在实际测试用例框架搭
建中,要考虑对立的用 户操作(比如 日记录入、日记补给、日记修改、日记审阅等等)设计独立功能测试目录

5



集,在这个目录集下存放所有用于验证它的测试用例。
? [用例框架] 协助功能要建立在主功能下,根据复杂度建立子目录或者R用例
? 每个协助功能(比如 日记录入时 的导入计划),由于其不作为一个独立日记功能存在所以在建立框架时要把它
建立在录入日记下
? [测试点要求]每个用例都是针对于某个测试点在进行测试
? 针对于某个UserCa se,需要通过设计多个测试点来全面对其进行测试,而每个测试用例必须是针对于某个测试
点展开验证
? [测试点要求]测试点要重业务数据测试设计
? 负面例子:以前写的很多测试过多的是 在描述测试什么,描述步骤,缺少怎么测试的内容;所以现在必须强调
轻步骤、重业务数据设计。步骤用 于测试导航
? [公共用例] 通过共性用例提高测试效率
基于以上情况,我们对用例框架 设计从以下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) 当[子功能]为独立功能点,则在[父功能]文件夹下建立[子功能]的文件夹。该文件夹下包含用例:

6



? [子功能]自身的F规则
注:这里的
F
规则,请参考:
4.1.1
? 父子功能的逻辑关联规则。当[子功能]有N种不同类的输出作为父功能的输入时,则需要有N个此类用例。

即子功能的多种输出都会对父功能产生不同的影响。命名方式请见下面第
4
条。

(b) [子功能]又有[子功能]时,用例划分方法同(a)
2. 文件夹层级要求
子业务模块(如计划录入)按根节点算起,其下属子文件夹最好不要超过3层 级。比如超出3层级时,若[子功
能]对[父功能]相对独立时,则可把[子功能]放到[父功能]的同 级。(具体情况具体分析)
3. 文件夹及用例的命名方式
要求:所有文件夹用01打头的数字标识其顺序。如:同级的文件夹以01、02、03等打头标识。
如上图所示,子业务模块[计划录入]文件夹记为父功能(或根节点)
举例:[计划录入]这个父功能体现在“保存”这个动作上,所以把[计划录入]作为父功能文件夹。
文件夹用例
父功能文件夹
父功能用例命名
方式
子功能文件夹
子功能用例
父子功能的业务
逻辑用例
提醒1:本表中黄色标注,只有关于“父子功能的用例”命名才加RP标记。
提醒2:上述用例中的xx,是指该用例是验证什么的一个描述。举例:01 FVT_岗位新增_S01_验证给单位添加岗位,02 FVT_
岗位新增_R03_验证必填
用例框架举例:
命名规则
编号+父功能
01FVT_父功能_S01_xx
01FVT_父功能_R01_xx
父功能_子功能_BP01
01FVT_父功能_子功能_S01_xx
02FVT_父功能_子功能_RP01_R01_xx
计划录入_加入任务_BP01
01FVT_计划录入_加入任务_S01_xx
02FVT_加入任务_任务查询_RP01_R02_xx



举例
01计划录入, 02计划查询
01FVT_计划录入_S01_xx
备注



7




上图解释:父功能记为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,在step name列要简要描述本步骤的目的。
(3)一个用例应该有多少步骤?分步测试的一个比较好的长度 最大到10-15步骤,达到更高的用例可测性。
a)每个step,被执行测试的时间很短
b)测试人员不太可能迷失方向,犯错误或需要援助
c)测试组长可以估算需要多少时间来进行测试

8



d)结果更容易追踪
(4)当多个功能点之间存在制约关系时,可以采用矩阵表、路径或正交法进行用例编写。
4.1.3.2用例颗粒度划分的例子
下图为“寻呼发布”的界面,我们如何把握用例粒度呢?

接下来我们看如何分解用例:

9



01网络寻呼
01寻呼发布
01寻呼发布_查询_RP01
01查询_常用查 询_RP01
01FVT查询__常用查询_R01_按姓名查询
02FVT查询__常用查询 _R01_按姓名查询
02FVT查询__常用查询_R02_按在线查询
02查询_自定义查 询_RP02
02寻呼发布_设置主送_RP02
03寻呼发布_查看已选_RP03
04寻呼发布_发短信_RP04
05寻呼发布_发邮件_RP05
01FVT_寻呼发布_S 01_选择人员发布寻呼
02FVT_寻呼发布_R01_关联下级
02FVT_寻呼发布_R 02_人员颜色显示
02FVT_寻呼发布_R03_点击人员可查看信息
02FVT_寻呼发 布_R04_鼠标放上可查看信息
02FVT_寻呼发布_R05_全部展开
02已收寻呼03已发寻呼

4.1.3.3用例的前置条件
前置条件:主要是对特殊情况的描述说明。大家公认的默认规则可不写。
1. 一个用例中需要描述公共的前置条件时,则第1个step为公共的前置条件(第2个step为导航)
2. 一个用例中不同的step有各自的前置条件时,则在本step的Description中进 行前置条件的描述。
什么时候必须加前置条件?具体情况具体分析。
举一个删除“已使用的组织”的例子:
Step name(描述目的) Description(测试点描述) Expected Result(期望结果)
前置条件 xxxx
导航 点击左侧菜单[系统管理—组织管理] 进入[组织管理]页面,当前路径显示正确
删除特殊状态的组织 前置条件:组织为启用状态 不允许删除,给出友好提醒
选中已启用状态的组织,执行删除
删除被其他模块引用的选中已被其他模块使用的组织,执行删除 不允许删除,给出友好提醒
组织

4.1.3.4用例的公共导航
所有用例都涉及进入当前路径的描述,我们统一称为“导航”,即路径。
格式举例:

10



Step name(描述目
的)
导航
Description(测试点描述) Expected Result(期望结果)
1.点击左侧菜单xx—xx—xx
2.点击“新增”按钮
1.正常进入xx页面,当前路径显示正确
2.弹出新增页面

4.1.3.5用例的step要求及格式
1、一个step有自己独立的明确的测试目的, 即不同的step是对本测试目标进行怎么测的业务场景。要重业务数据,轻
步骤。
格式: step的书写规范
Step name
描述本step的目的
Description
该目的输入信息
Expected Result(期望结果)
输出信息,本输出可能存在多个验证点。
(分别用1,2,3标识出。)
注意:“描 述”和“期望结果”二者一定要明确,不要互相混淆;不能存在模棱两可的字样;比如几乎、大概、一般等。
2、各步骤顺序依次为 前提、导航、各场景。
举例:组织管理-- 新增页面2有个“必填项”(组织名称、组织编号),验证必填项的用例如下。
Step name(描述目的) Description(测试点描述)
1导航 1. 点击左侧菜单[系统管理—组织
管理]
2. 选中某组织,点击“新增”按钮
2查看必填标识
3不填写组织名称
4不填写组织编号
5必填项都不填写
检测所有必填项的标识



Expected Result(期望结果)
1.正常进入[组织管理]页面,当前路径显
示正确
2.弹出新增页面
对必填项都已进行红星标识



Step中的标题简述必须要有,数字可以根据自己习惯而定。
4.2业务数据流用例FIVT
4.2.1业务流用例设计思路
注重数据传递,侧重业务逻辑的场景。可以先画出业务数据流,针对主流程与备选流程进行用例设计。
? FIVT_cycle _C01 周期性,如与时间相关,跨周、月、年 ,先分析业务数据的时间特性, 考虑最适中的
周期。
?
?
FIVT_data_S01 基本数据流(主业务数据流)
FIVT_flow_A01 路径(包含所有路径、所有分支的用例覆盖),以业务数据为节点,每个分支路径为一
个用例。
? FIVT_status_B01 业务数据的状态变化性(如流程状态、会议室闲忙状态),以状态为节点,不同的状态
流转路径为一个用例

11



? FIVT_colateral _D01 业务数据的并发处理(实时、异步)
注:上述中的A、B、C、D分别代表用例的重要程度。以高到低排序。
4.2.2业务流用例粒度划分
一个流程路径:分一个用例。
建议按照流程顺序进 行用例安排,从第一个验证点到最后一个验证点,组成流程的开始到结束,方便测试执行。
4.3用户验收用例UAT
4.3.1用户验收用例设计思路
UAT :User Acceptance Test
* 脱离系统提供功能,站在用户角度来设计用例,从用户实际可能的操作场景考虑。
* 基本是按业务特 性制定的用例,模拟用户实际操作,描述用户的主要业务目标,包含完整的系统级场景和模拟用户
实际操 作的不同场景,几个功能点的组合也算是用户场景。
4.3.2用户验收用例粒度划分
业务应用是面向不同的使用对象:普通员工、经理级、总裁级、管理员等。主要体现:员工级、管理者 所关注的信
息。用户验收测试的每一个相对独立的部分,都应该有目标(本步骤的目的)、启动标准(着 手本步骤必须满足的条件)、活
动(构成本步骤的具体活动)、完成标准(完成本步骤要满足的条件)和 度量(应该收集的产品与过程数据)。
5.测试用例优先级
接收软件测试前,我们已获取明 确的质量目标。在制定测试计划时,会根据质量目标制定不同的测试策略。包含:测
试重点要求、测试技 术类型的选取、测试活动的先后序列、资源调度与安排等。
各优先级所占全部测试用例比例通常如下: P1 30%-45%,P2 40%-60%, P3 10%-15%。
1. 划分优先级前,我们先对功能用例进行细分:
前提:版本控制到位。该问题如何避免?(QTP录制回放)
类型 含义 细分 业务举例 执行次

01 冒烟 S 基础的操作(包括所有
属性的输入)
每轮执

回归测

02 规则 R 详细的业务规则,如唯
一性,权限,数据(计
算正确性、完整性,排
序),逻辑等
R1(核心主业务) 必经业务,缺少它
则不可继续下一步
业务操作。如发寻
呼,必须先添加组
织用户,否则无法
发送寻呼。
每轮执

回归测

执行阶段





12



R2(经常使用的规
则)
如寻呼中“转发”
寻呼
每轮执

回归测

R3(较少使用的规
则)
R4(极少使用的复
杂业务逻辑)
03 接口 D 定义与使用。 D1:定义处新增,
使用处获取更新
【岗位管理】新增
后,【用户管理】
中可选择使用
如定义处对使用处的影

D2:定义处修改,
使用处获取更新
【岗位管理】修改,执行2次
【用户管理】中同
步更新
执行2次
如寻呼中“发短信”执行2次
功能
执行1次







D3:定义处删除,【岗位管理】删除,执行2次
使用处已获取更新 【用户管理】中不
再显示
04 边界 B 数据临界、事务操作临
界,即一般人很少用到
的情况
以删除为例:
1)无数据时,点击
删除
2)同时删除“未被
引用”和“已被引
用”的记录
05 并发 C 实时并发
异步并发
06 合法检测 E 数据项的完整性约束,
包括异常的情况,事务
中断等
FIVT_cycle _C01 周期性,如与时间相关,
跨周、月、年
FIVT_data_S01 基本数据流(主业务数
据流)
FIVT_flow_A01 路径(包含所有路径、
所有分支的用例覆盖)
FIVT_status_B01 业务数据的状态变化性
(如流程状态、会议室
闲忙状态)
FIVT_colateral _D01 业务数据的并发处理
(实时、异步)
验收用例

2. 优先级原则
? 需求优先级高,涉及的各类用例优先级也高
执行1次
执行1次



后期执
行1次
每轮执

执行2-3

执行2-3

执行1次
执行1次
执行1次












13



? 使用频度高、 业务失败对客户产生严重影响、失败风险
3. 优先级别
可以分为以下4类级别:P1、P2、P3、P4,高到低。
级别
P1
冒烟测试
用例
定义
确保系统基本功能及
主业务流的用例。
用例执行要求
该级用例,每个测试版本都需执
行且通过
举例
S、R1(核心主业务)

备注
考虑场景被使用频
度、使用人员 的比例,
角色重要程度。如员
工管理者管理员有
80%的频率在使用某
功能
P2
关键路径
测试用例
P3
可接受级
测试用例
经常使用的核心业务。
是确保系统功能的完
善方面的用例
关于用户体验,输入输
出的验证及其他较少
使用或辅助功能的用
例。
P4
建议执行
用例




6.测试用例维护与共享
极少被使用 如果有时间,最好执行该级用
该级用例,只要执行一次通过即

该级用例,每个测试版本都需执
行且通过
R2(经常使用的规则)
D ?
S2
B,E,C,R3(较少使用的
规则)
D ?
S3
R4(极少使用的复杂业务

该级测试用例均通
过,意味着软件功能
趋于稳定。

例,但不作为发布的必要条件。 逻辑)
6.1测试用例维护
6.1.1当前版本的用例维护
需求
需求增加
用例库目录
按颗粒度划分规则,来决策是否需要建立文
件夹
用例
增加新用例
需求修改 在本模块一级目录下增加【无效用例】子文
件夹
1) 在【无效用例】文件夹下先建立“无
效用例”的所在目录
2) 复制“原无效用例”到1)中
3) 在“原无效用例”中修改“已变更”
需求的用例

14



需求删除 若存在【无效用例】文件夹,则无需再建立 1)将“原无效用例”剪切到【无效用例】
文件夹下
注:【无效用例】文件夹只建立一个即可。主要目的是储存垃圾用例,以便预防需求来回变更的情况。
6.1.2不同版本的用例维护
一个产品,随着时间会不断发布多个版本,使测试用例不断完 善,同时也与产品功能、特性的变化保持一致,所以测试
用例是和产品版本相关联的。当产品有多个版本 共存,为不同客户群提供服务,这时测试用例势必也会存在版本之分。
根据测试用例与产品需求保持一致性的原则,分以下几种情况:

1
产品需求
新版本中需求未变
用例变更原因
新版本发现了bug或用例需要
补充
对旧版本用例的影响
有效。如何保证新版本
中修改的同步更新旧
版本?
2 新版本中需求变化(功能
增强)
3 新版本中需求取消
非新功能,是对原功能的功能
增强
需求删除
有效。当前用例 不可
修改
有效 当前新版本的对应用例无
效。置为无效
4 新版本中完全新增的需求 需求新增 无效 新版本中增加用例
新版本中修改或增加用例
对新版本用例的影响
有效。新版本中修改用例
2. 用例是否要有状态标识?要制定几个状态? 有效、无效、维护中
6.2测试用例共享
在编写用例过程中,常常遇到不同模块下有相同功能的情况。这种情况下,我们在设计用例时,就可以考虑公共用 例
的复用。
1. 公共用例的框架
公共用例单独制定一个文件夹,里面包含各类可以共享的功能。举例:
公共用例
01 新增
02修改
03删除
01FVT_删除_S01_冒烟测试
02FVT_删 除_R01_不选记录直接删除
02FVT_删除_R02_取消删除
02FVT_删除_R0 3_删除多条
02FVT_删除_R04_删除已使用的数据
03FVT_删除_D01_xx
04FVT_删除_B01_xx
05FVT_删除_C01_xx
04查询
05导入
06导出
07附件


15



2. 公共用例的引用
当其他模块需要引用公共用例时,我们要求复制粘贴的方式,然后调整 为适合本功能的用例。好处有以下几点:
(1) 共享过来的全部用例不一定吻合本功能点,需要适当修改调整;
(2) 为了用例集的完整性;
(3) 统计时要考虑用例的个数,更好的评估工作量
3. 公共用例的变更
(1)当公共用例的变更会对“引用处”产生影响时,则“引用处”要及时做适当调整。
(2)被引用公共用例文件夹的“描述”处记录由谁谁引用,方便公共用例变更后的可追踪更改。
三.测试用例评审
测试用例的评审能够使用例的结构更清晰,覆盖的用户场景更全面;对于测 试工程师来说也是一个快速提高测
试用例设计能力的过程。
1. 需要评审原因和目的 测试用例是软件测试的准则,但它并不是一经编制完成就成为准则。由于用例编写人员的设计经验和对需求理 解
的深度各不相同,所以用例的质量难免会有不同程度的差异。用例评审的主要目的就是集众人的经验及 认识于一体,
对测试用例进入查漏补缺,使得测试用例的有效性进一步提升。
2、进行评审的时机
一般会有两个时间点。第一,是在用例的初步设计完成之后进行评审; 第二是在整个详细用例全部完成之后进行二
次评审。如果项目时间比较紧张,尽可能保证对用例设计进行 评审,提前发现其中的不足之处。
3、参与评审人员
这里会分为多个级别进行评审。
1) 内部评审,测试部门全体成员参与的评审。
2) 组织评审,这里包括了项目经理、产品经理、需求人员、架构师、开发人员、UE和测试人员。
3) 客户评审,包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。
4、评审的内容
见《测试用例检查单》
5、评审的方式
1)非正式评审:通过通讯工具或少数相关人口头交流
2)正式评审:召开评审会议。与会者在设计人员讲解之后给出意见和建议,同时进行详细的评审记录。
方式只是手段,得到其它人员对于用例的反馈信息才是目的。
无论采用那种方式,都 应该在沟通之前把用例设计的相关文档发送给对方进行前期的熟悉和了解,以节省沟通成
本。
6、评审结束标准
在评审活动中会收集到用例的反馈信息,在此基础上进行用例更新,直到通过评审。

16



四.测试用例执行阶段
1.建立测试套件
首先在TEST LAB中建立测试集,在此建立的目录结构与TEST PLAN中一致。
2.选择用例
将TEST PLAN中编写的用例转到TEST LAB中(鼠标拖拽)。
3.执行用例
严格按照测试用例来执行测试。
(1)首 次执行测试集时选择‘手动运行’;若需要执行上次未执行完的测试,下次再执行测试集时选
择‘继续手 工运行’即可;若下次想放弃上次的执行,重新执行的话,则选择‘手动运行’,系统会新建
一个运行历 史;
(2)执行用例时若不通过,则将此用例的Status修改为Failed,并填写bug;若 通过的话将此用例的
状态修改为Passed。
附录
1.冒烟测试定义
(1)冒烟测试的含义
顾名思义,最基本的测试,能保证系统能简单跑起来。包含基础功能和主业务流的测试。
冒烟的原始说 法:汽车生产出来以后,首先发动汽车,看汽车能否冒烟,如果能,证明汽车最起码可以
开动了。说明完 成了最基本的功能。
(2)冒烟用例的定义
所有属性都有输入。
(3)什么情况下需要写冒烟用例
子功能为独立的增、删、改、查。
(4)冒烟用例的级别定义
S1:最基础的增删改查、不可缺少的核心功能、主业务流
S2:关键功能、备选流
S3:辅助功能 如 查询 ---新增---- 快速查询(这个“快速查询”就是辅助功能)



2.什么是核心业务
优先级
分类
高频率使用



17
核心业务。不可缺少的主功能,高频率使用(80%)



的功能
中频率使用
低频率使用


次核心业务。备选功能
辅助业务。










举个手机例子
高频率使用:如打电话、接听电话、收发短信 是核心功能。
中频率使用:拍照,听音乐、玩游戏
低频率使用:购物消费
3.用例设计方法
4.如何避免漏测
(1)需求评审
进行严格的需求评审,在编码前找出需求的b ug,虽然不可能找出所有不合理的地方,这是减少风
险的一种手段。
Q1:需求总是不能固定?不固定就会引出问题,然后引出一系列的bug,
Q2:需求已经定义,是否吻合客户实际应用? (如何有效的需求评审)
Q3:需求与代码实现差异?要变更统一
Q4:待实现的需求都能归入文档吗?脑子里的需求如何多角色一致化?
Q5:规格说明书没有的需求?但却是客户实际需要的。
(2)梳理需求,尽早与开发人员、需求人员进行需求确认,统一不同角色对需求的认识
开发测试人员 都可能存在对需求的认识不一致。越早进行,越能够避免出现因为对需求的认识不同
而导致出现的问题( 最可怕的是因此产生的隐性bug),这样也能减少后期很多不必要的资源浪费
(3)用例设计与评审
* 前期的模块支持数据量的调研和要求
* 用例编写考虑面要广,包括:使用不同的测试方 法,不同的测试数据类型(要齐全),正常流与异
常流等来覆盖所有的需求。
* 如果缺少评审,自己抽时间找研发同事沟通用例的覆盖度,查漏补缺(这一条非常重要)
(4)测试执行
在固定的时间内,尽可能全面地执行测试用例。(a)在测试过程中不断的添加遗漏的 用例(一定要
在发现时及时补充,有些用例是在实践中得来的灵感)。(b)详细标识每一个被执行过的 用例。
(5)bug回归
除了回归前面发现的bug(思考:我们一般只回归被fixed 的bug,那么4,5级closed的bug要
不要回归?),还要重视回归那些bug相关的模块。
测试过程中,遇到过一个小小的参数变动可能引起一个比较远的功能点的大bug,开发不知道,测试不清晰,势必引发遗漏。所以TD的bug备注就非常重要了。开发人员熟知代码,知道改动的地方会被哪些模块调用或者会引起哪些变化,因此开发人员需要通知测试人员测试关注点以及加强自测(我们
遇到过太多类似的问题,不自测就更新,或者自测了这一个点,关联地方没有测试,引发了一些未知的
bug,当时没有发现,而在后面发现了bug,一轮一轮,没完没了,这是个非常致命的因素。
思考:如何约束开发人员与测试人员的相互沟通协作,避免这种bug的遗漏减少?
(6)发布前的功能回归

18



首先保证所有fixed的bug验证通过
回归基础用例(思考:如何规范回归用例?)
如果时间允许的话,自动化脚本,方便回归。
细心细心再细心。只要一步步走下来,那么就可以把遗漏的bug数量减到最低。
一句话,减少漏测的方法就是相关的文档全面化,标准化,统一化。
小结:
1.在 意识上重视测试用例的重要性,注重积累可重复利用的用例,吸取测试用例不全又不及时补充用例
而后续 测试凭着感觉走的教训
2.多从自身找问题,认真严谨执行测试,养成分析bug的习惯,多与研发沟 通问题和解决bug的情况
3.在执行回归测试bug时,多考虑测试过程中的覆盖面(有时本bug 没有表现出异常,但修复bug带出了其
他本该不存在的问题)




19

陡峭的意思-工程造价实习周记


礼貌的英语-少儿英语培训费用


昨日重现英文-八大洲


婉婉-馒


羊入虎口意思-秸


assistive-瓶颈的意思


捣衣-戒急用忍


浮现的反义词-至亲是什么意思



本文更新与2020-10-31 10:44,由作者提供,不代表本网站立场,转载请注明出处:https://www.bjmy2z.cn/gaokao/434936.html

功能测试用例编写指南的相关文章