功能用例编写指南V30.docx
- 文档编号:8121925
- 上传时间:2023-01-28
- 格式:DOCX
- 页数:32
- 大小:37.61KB
功能用例编写指南V30.docx
《功能用例编写指南V30.docx》由会员分享,可在线阅读,更多相关《功能用例编写指南V30.docx(32页珍藏版)》请在冰豆网上搜索。
功能用例编写指南V30
功能用例编写指南
文件类别
○手册●过程文件/程序文件○指南文件/作业指导○其他
文件编号
SZLY-Q-D-VER-01
版本号
2.3.0
发布日期
2007-7-31
密级
●普通○秘密
深圳联友科技有限公司
文档修订
版本
作成/修改日期
编制/修改人
批准
日期
批准人
描述(注明修改的条款或页)
1.1.0
2005-5-28
李荣芳
创建
2.3.0
2007-7-31
许聆
评审后统一发布
目录
1,用例设计思路……………………………………………………………1
2,用例设计思路详解………………………………………………………1
3,功能用例模板填写项说明………………………………………………2
4,模糊项填写说明…………………………………………………………3
5,测试项中重要级别如何区分……………………………………………4
6,元素检测指南……………………………………………………………5
1.文档目的
用来指导测试中心的同事编写功能用例。
2.适用范围
适用于联友科技综合测试中所需要编写的功能用例。
3.术语和定义
比较通常的测试用例(TestCase)概念是指:
指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。
内容包括测试项、测试步骤、检查点、预期结果等。
4.角色
●测试设计人员
编写测试用例,测试用例的维护(需求变更、设计变更)
●测试执行人员
根据测试用例执行测试,测试用例的维护(发布测试)
●测试用例检查人员
检查测试用例是否覆盖了业务需求,外设与内设的设计要求
5.编写指南
5.1.用例编写思路:
5.1.1.功能用例说明
功能用例:
是一个完整的任务,是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果的检验文档,以便测试某个程序路径或核实某个功能是否满足设计要求,需要从用户和系统之间进行交互的接口的角度,来观察系统外部应该具备的表现。
功能用例站在用户的角度上(从系统的外部)来描述如何检验系统的功能。
在编写用例过程中,我们把被编写的用例看作是一个黑箱,我们并不关心系统内部是如何通过具体的程序语句完成它所提供的功能的。
5.1.2.测试中心用例编写思路
事务流模式:
即“事件流”+“业务流”的模式。
事件流:
按照程序设计的思路,将功能中的事件(界面控件方法)对应的控件转换提取为测试项,并按照事件的响应顺序来从上到下排列测试项。
现在的程序基本上是通过触发事件来控制流程,触发事件的方式和顺序就形成了事件流
最基本事件有:
初始化事件、保存事件、下拉框点击事件、文本框输入等等
对应的测试项为:
页面静态检查、页面初始加载,保存按钮、××下拉框、××文本框。
基本上来说,引起页面或者数据发生变化的都称之为事件。
而对任何功能测试,页面静态检查、页面初始加载是排在最前的。
测试项的提取可参见“模板填写项说明”中相应内容,也可参考样例进行。
●业务流:
以业务人员或用户操作为指导,对功能界面的操作
实现方式:
采取事件流,加上用户(业务)的操作顺序的方式,具体表现是控件为主导测试项,操作项中用来描述用户(业务)的顺序操作。
首先提取该功能中的控件元素作为测试项,然后再结合业务逻辑先关注业务或用户的操作步骤和顺序,加上控件的检验点,生成一条测试子用例。
坚持一个大原则。
尽量以控件(或者事件)为测试项,测试项的顺序主要按照用户的操作习惯跟业务顺序从上到下,从左到右来放置。
首先是页面初始化(静态),其次是页面初始加载,然后是操作主控件之前所需要的页面数据的元素,这些元素写了之后是主控件,最后是一些该功能页面中重要级别较低的控件。
比如:
保存功能,首先是界面检查(静态),页面初始化,然后是一些动态关联下拉框,公共弹出框,然后是保存事件,保存事件之后才是编辑,删除,排序,翻页。
因为必须有保存之后才会有数据。
才方便做后面的检查。
比如查询功能,首先是界面检查(静态),页面初始化,然后才是查询控件,其次才是排序,翻页,清空(重置)
5.1.3.编写用例尽量注意的问题:
●测试子用例可以引用公共用例,但是必须明确注明出处,引用方式为:
“xxx项目名称(简称:
统一项目简称统一)”+公共用例+“公共用例名称”
●用户界面不要太多,用户界面应属于设计范畴,鼠标、按键等内容不应出现在用例中;
●较低目标层次上的用例不要太多,无法展示系统将会给其最终用户提供什么功能;
●使用用例表示非行为信息,性能需求、业务规则等不要在用例中描述;
●目标实现不完整,尤其是错误处理;
●句子片断,主、谓、宾尽量完整;
●不要使用模糊语言,比如“是否”,应当是就是“是”,否就是“否”
5.1.4.测试数据选取原则:
●如果输入了条件规定了取值范围,应以该范围的边界内及刚刚超范围的边界的值作为测试用例数据,如果以a和b为边界,测试数据应当包含a和b及略大于a和略小于b的值。
●若规定了值的个数,分别以最大,最小个数及梢小于最小,梢大于最大的个数作为测试数据
●一般采用以上2个原则。
●如果输入是个有序集合,注意选择有序集合的第一个和最后一个元素作为测试数据
5.2.模板填写项说明
模板元素分类
填写项
是否为空
描述
用例表头
用例编号
N
从测试方案中取对应的需要编写功能用例的功能点的相应的用例编写,命名规则:
FTC+项目编写+版本+功能命名
相关测试用例
名称
N
填写影响这个用例的用例名称,比如:
如果查询跟保存功能是分开的。
假设这个用例是查询功能,那么相关用例栏里面填写:
保存用例。
如果没有,请填写“无”,不能为空
(是指影响现用例的,来做为现用例的相关用例),基础数据不填
编写人员
N
填写编写用例的人的姓名。
不能为空。
如果是修改的话在修订记录页面增加记录
用例标题
N
填写格式:
一级菜单―>二级菜单。
如果系统分3层的话,格式:
大模块―>一级菜单―>二级菜单。
比如DMS3.0,新车管理―>新车业务―>新车订单。
如果有更多的话,依次增加。
不能为空。
重要级别
N
该功能的重要级别。
可按照设计文档定义的级别来定义
编写日期
N
填写编写用例的当天日期。
格式为:
YYYY-MM-DD。
如果编写时间跨天数,格式为YYYY-MM-DD—>YYYY-MM-DD
预置条件
N
前置条件所说明的状态应该是用户可以观察到的状态。
或者说那些数据已经设置好。
比如查询功能,就写明是保存功能中新增成功的一条数据。
如果是报表用例就说明最终会产生报表的子流程步骤。
填写方式:
1,“以“XX角色”登录“+“拥有操作该功能的权限”操作该功能的权限”
2,该功能用到的基础数据。
“基础数据1”/“基础数据2”/“基础数据3”+已经设置好
3,操作功能引起的数据来源。
说明简单的操作步骤。
比如:
审核功能。
数据来源有:
经过确认的,被驳回的。
那么这里说明“经过xx确认的/被xxx驳回的”
用例功能说明
N
编写该用例的功能的主要作用及实现目的。
对该功能进行详细说明,此部分内容可以从《功能设计说明书》(外设)业务概述,处理时机中所描述的内容中获取(备注:
如果在该项中说明了该功能的用户角色则不必产出《操作用户角色权限对照表》文档);
从需求中提取明确的测试需求。
用例主体
测试子用例编码
N
在用例编号的基础上加上后缀”_01”,然后依次递增
测试项
N
填写你需要测试的内容。
用语言概括简化,尽量以控件名称或者事件名来做测试项。
一般来说,最开始的时候是界面检查,其次是页面初始加载,其余为控件名称。
如果是页面内链接的页面,测试项为:
页面名称――测试项。
测试项的排列顺序按照业务操作顺序,从上到下,从左到右来排列。
一般是页面初始静态,其次是页面初始动态,然后是操作该功能中主控件之前所需要的数据控件。
比如xxx下拉框,xxx弹出框。
(文本框放入主控件)。
其后是主控件,主控件过后是一些排序,翻页功能条,返回等一些该功能中无关紧要的控件。
填写方式:
页面静态检查,页面初始加载,“名称+元素类型(下拉框/弹出框/按钮)“
重要级别
N
测试项的重要级别,H为最高级别,L为最低级别,M为中间级别。
如果是控件名或者事件名为测试项的话,请根据测试用例编写指南中:
划分主次控件说明来对应重要级别。
操作
Y
1,填写实际的操作顺序过程。
比如:
页面初始加载肯定在最前面,如果不page_load又怎么能做其他的操作呢。
2,填写作为测试项控件的操作的前置数据。
比如:
保存。
需要填写:
在所有必输框录入正常数据,然后点击保存。
3,填写方式:
第一步页面静态检查填写呈现功能页面的操作,如“点击一级菜单-二级菜单”,第二步页面初始加载是一样的,为空。
不用在写xxx登录,因为预制条件里面已经登录了。
4,如果是单控件,填写触发单控件的操作方式,比如“点击xxx
5,如果是主控件,填写实际选取数据的步骤
原则:
操作步骤反映执行步骤。
检验点
N
检查执行该用例之后,所影响其它那些用例或者功能,或者程序中某个地方。
(如果检验点跟预期结果相同,那么检验点可以为空)。
可以是该测试项的前置,跟后续。
检验点体现事件里面需检测的内容。
一个检验点为一行
预期结果
N
说明的是执行这一个测试项之后所得到的结果,一般为可见的结果,比如提示信息,结果插入列表等。
预期结果为事件执行后应该表现的结果
输入
数据
Y
对应测试项的输入数据
输出
数据
Y
根据输入数据经过该测试项的程序的逻辑处理最后可看见的产出。
备注
Y
对该子用例其它的说明信息。
常为空。
5.3.模板填写模糊项说明:
●预期结果VS检验点
问题:
将检验点写得跟预期结果一样或者类似。
解决办法:
如果一样,那么检测点可以为空。
而不是一定要在检测点处填充内容。
检验点:
是事件中的逻辑点。
是用来描述产生这一预期结果的约束,条件。
或者说预期结果还会影响那些地方。
比如象大家常要求的需要描述业务,状态的变化,数据的正确性。
这些是检验点需要做的事情。
检验点体现事件里面需检测的内容。
预期结果:
是事件响应执行逻辑点后的结果。
是执行测试项将会出现的结果的描述。
一般为可见的结果,不可见的结果放入检验点(比如:
保存的数据要用查询来验证的)。
预期结果为事件执行后应该表现的结果
下面来给个例子来说明二者的区别:
测试项
操作
检验点
预期结果
保存
录入数据点击保存
1,select*fromtableaawherename=’lixin’lixin
2,在查询功能中,用查询来验证刚才插入的值存在且正确
提示保存成功,列表刷新,数据插入列表中
5.4.测试项中的重要级别如何区分
功能用例编写过程实际是程序控件语言化,条理化的一个过程。
程序控件在使用过程中的频次,编写,实现他所需要的时间程度都是不一样的。
下面对程序控件做了一个简单的归类:
归类依据:
根据程序员编写控件所花费的时间来划分主次控件。
大致归类为:
该操作修改数据库跟该操作不修改数据库。
修改了数据库的为H级,查询数据库的为M级别,但是报表的查询,试算为H级别,单一控件为L级别。
具体细分参加下表:
类型
大类
小分类
重要级别
备注
修改数据库
按钮
保存(确认)
重要(H)
insert、update操作,操作失败需要回滚
更新(修改)
重要(H)
update操作,操作失败需要回滚
删除
重要(H)
delete操作,同步删除相关数据,操作失败需要回滚
上传(保存)
重要(H)
insert操作,操作失败需要回滚,注意上传文件大小。
审核(驳回)
重要(H)
引起数据状态的修改
输入框
文本输入
重要-(M)
数据格式校验
选择输入
重要-(M)
显示文本和数据库保存文本对应
下拉框
重要-(M)
显示数据和保存的文本进行对应
不修改数据库
按钮
编辑
重要-(M)
select操作,数据输出,显示文本和数据库保存数据对应
查询
重要-(M)
select操作,数据输入,校验单引号
链接
重要-(M)
select操作,数据输出,显示文本和数据库保存数据对应
取消
一般(L)
清空、初始化
输入框
文本输入
一般(L)
单引号校验
选择输入
一般(L)
显示文本和数据库保存文本对应
复选框
一般(L)
(单一控件,不会引起数据错误,最多会引起页面错误)
单选框
一般(L)
组合框(ComboBox)
一般(L)
单一控件
日期时间选择器(DateTimePicker)控件
一般(L)
热键(HotKey)控件
一般(L)
列表框(ListBox)
一般(L)
列表(List)控件
一般(L)
月历(MonthCalendar)控件
一般(L)
进度(Progress)控件
一般(L)
滚动条(ScrollBar)(垂直或水平)
一般(L)
滑块(Slider)控件
一般(L)
数值调节钮(Spin)控件
一般(L)
选项卡(Tab)控件
一般(L)
目录树(Tree)控件
一般(L)
可能会由于数据错误出现问题。
翻页功能条(包括上页,下页等等)
一般(L)
报表
按钮
查询
重要(H)
涉及到计算公式,数据需要计算得出。
数据长度,往往进行类型转换时会导致数据精度变化。
导出
重要(H)
将查询的数据一条条写入到excel或者其他格式的文件中,与查询数据保持对应。
或者有其他的对应转换规则导出到外界媒体中
页面检查(动态)
Page-load事件
重要-(M)
界面检查(静态)
重要-(L)
Label
重要-(L)
用来显示文字
Datagrid
重要-(H)
用来绑定数据
5.5.元素检测指南
元素类型
检验点
文本框
●超长(>字段长度)
●空白
●异常(异常类型参见:
异常说明)
●特殊字符(单引号,或者)或者file:
//c:
\aux参见:
异常说明)
●临界值(=字段长度)
●正常
●检查可编辑性;
●检查多余空格的截取;
●检查键入回车键的显示
●检查只读文本框和屏蔽文本框在TAB时的状态;
●对于所有可键入的文本框,必须列举出输入数据(数据区间:
正常,异常,空白,临界,超长)
下拉框
互相关联下拉框
●父子关联,一般来说,选择父数据,那么子下拉框的数也要动态绑定只属于父元素的数据
比如:
选择动物,然后另外一个下拉框关联显示:
狗,猫,老鼠
●绑定显示要与来源一致,一般来源为:
表或者程序中设定。
(必须覆盖)
●不做特殊要求的,一般值显示的为数据的名称,而不是编码
●如果源头被修改成功,那么下拉列表中的也要修改。
即:
动态绑定
●一般来说,如果下拉列表中的值已经被使用,那么反过来在源头中,该数值将不能被删除
●可选可用
IE检验点
●保存单据之后,按浏览器后退或者刷新,不会重复提交数据
●标题正确
●缩小或者放大浏览器,布局不会变动
●点击“搜索”时,检查界面元素不会错位、排列不整齐
并发操作
●同时作为2个客户端,数据不会串。
●举例:
同时打开2个浏览器,打开同一张单,其中一个窗口对该单进行审核,那么另外一个窗口如果要修改该单,那么系统提示,不可以修改
●同时打开2个浏览器,打开同一张单,其中一个达到审核状态,另外一个窗口对该单进行修改,修改成达不到审核条件,然后保存成功。
再返到第一个窗口进行审核操作。
那么不能审核成功。
●当同时打开2个浏览器,单据编号自动生成的时候,保存的时候只能保存一张单据号,或者都保存成功,但是另外一个单据号要自动跳号。
即:
编号不能重复。
●二个不同的程序同时保存或打开同一个文档
●共享一台打印机,通讯端口,或者其他的外围设备
●当软件处于读取或者修改状态的时候按键或者单击鼠标
●同时关闭或者启动软件的多个实例
●同时使用不同的程序访问一个共同的数据库
●并发操作的考虑范围:
修改数据库的地方,一般常用到的地方有:
保存,审核
链接安全性
●copy地址栏到新打开的浏览器,不能直接登录系统
●点击页面属性,copy页面地址到新打开的浏览器,不能直接登录系统。
日期框弹出框
●日期的年月日必须是有效数值
●如果是阶段时间,那么结束时间不能小于开始时间
●当天到当天,或者跨年度当天到当天
上传(导入)
●非指定的文件类型
●超过指定限度的文件(超大)
●符合指定类型的文件,但是里面的数值格式不符合。
●符合制定类型的文件,数据,数值格式都符合
●文件名称超长
●符合制定类型的文件,数据,数值格式都符合,但是字段值超长
排序Link
●页面无数据的时候点击排序
●有数据的时候进行排序,不会出现数据丢失
查询
●注意如果支持模糊查询的需要支持模糊查询
●每个查询条件单独查询一次(必须),列出参与查询的条件(精确/模糊)
●少于或等于4个查询条件的两两组合查询条件进行查询(必须),列出查询条件的组合形式,写到检测点栏位
●根据业务场景,组合3或多个查询条件进行查询,列出查询条件的组合形式
●可以翻页到中间页进行查询
●条件全部为空的时候的查询。
●条件全部键入精确值的时候的查询。
●查询功能要有数据支撑。
●前置条件须说明产生数据的步骤
审核
●审核分单次审核,层级审核(根据组织架构审核),
会签(根据角色同级会签)
●有记录的情况
●无记录的情况
●同时选择符合条件的记录,和不符合条件的记录
●只选择符合条件的记录
●只选择不符合条件的记录
●单条符合条件的记录,全选(针对当前页数据)
全选(针对所有的数据)
●全部审核完后再审核
此时不能审核也不应该报错不能审核
接口
●分表对表、文件对表的接口和通过页面进行业务操作产生的数据传递。
分源表,目的表
●接口如果不是通过界面进行的,必须另开sheet页用数据支撑。
数据用SQL语句写出来。
(insert,select,update,delete)
●源表新增数据,目的表查询
●源表删除数据,目的表随之删除
●源表更新数据,目的表相应字段随之更新
●源表字段键入最大值,目的表能完全接收。
●源表记录大的情况下,目的表能完全接受完整,不遗漏。
●如果涉及到业务界面的话,注意目的业务界面的数据对应。
重置(清空)
●清空到page_load状态,注意,不是什么都清空
保存(更新)
●数据插入到数据表,存放于表中的数据要跟输入的保持一致。
●数据表里需要记录操作人,操作时间(如果设计上没有做该要求或界面上无反应,可不必检查)
●保存如果影响其他表或者其他业务界面,注意其相关性检查
●重复数据的检查
●需要考虑必输项的检查
●文本检查请对应指南元素检验――文本框
●考虑并发保存
●需要用数据支撑
编辑(修改)
●检查在未选择修改记录情况下点击后的警告信息
●提取数据对应到相应的文本框,或者转到新增页,注意检查数据提取要对应,正确
●一般来说,主键是不允许修改的,为不可修改状态
●考虑修改成存在的数据(重复数据检测)
●考虑必输项,及文本框的检查
试算
●数据需要按照公式试算正确
删除
物理删除
●检查在未选择项目情况下点击后的警告信息
●删除成功之后,需要从数据库中验证,该记录已经不存在
●关联的地方的数据,在其他地方使用的该数据也应该不存在
●如果被使用了,或者正在使用中。
一般不允许删除
逻辑删除
●检查在未选择项目情况下点击后的警告信息
●删除成功之后,只是修改数据库中的flag值,并不从表中清除
●在其他使用该数据地方,如果是查询该数据还是存在。
因为是历史记录。
如果是新增,就不应该存在。
新增是现在时。
报表(查询/统计)
●前置条件须加入产出这个报表的子流程(简单说明产出报表数据的步骤)
●测试项的操作步骤,写明产出报表数据的动作。
比如:
新增订单,选择零件销售价,点击保存,然后对该单进行出库。
测试项的预期结果写明:
销售价增加多少,出库数量增加多少了。
测试项的检验点写明这2个字段变化的计算公式。
●比如工程管理:
操作步骤写明:
车辆从某个区域tracking移动到另外一个区域。
检验点写明:
报表页面各个字段内容跟表之间的关联关系,及计算公式,及产生的数据变化。
预期结果是说明这一动作之后,对应车型的字段值会加,那些字段值会减少。
●影响报表数据变动的操作
●数据产出正确
报表(打印)
●表头正确
●格式正确
●数据正确
添加(新增)
●弹出新增页面
●页面呈初始化
报表图片文件下载上传
●注意检查文件要按照指定目录存放,而不是放在服务器根目录下。
日志
●注意检查操作类型
●检查产出的日志文件中信息
明细链接
●标题正确
●关联数据要正确
●一般为不可修改状态
取消(Cancel)
●检查确认信息;
●检查是否有其他键执行同样功能;
●检测是否能能够正确处理;
返回
●检查返回到链接的页面
Label显示
●显示的字面意思,必须准确,无歧义
提示信息
●所有正确或者错误的提示信息,弹出位置保存一致
●提示必须详细而且清晰,异常操作的时候,必须提出用户(业务)具体错在那里。
可以说异常提示是一个业务操作步骤指导书)
安装测试
●检查安装过程中的问题
数据库恢复测试
●检查数据库备份,恢复后能否正常工作。
翻页
●检查定位到正确的页面
屏幕显示(界面检查――静态)
●检查显示的布局;
●检查文本框和按钮的顺序;
●检查文本框的尺寸;
●检查字体的大小和风格;
●检查文本的含义;
●检查拼写错误;
●检查屏蔽文本框;
●检查只读文本框;
●检查图片;
●检查按钮的状态;
●检查按钮的尺寸;
●检查按钮的图标和名字;
●检查重复的图标;
●检查指针是否在第一个可输入文本框;
●检查TAB键的次序;
●检查Logo
●检查必输项(即:
列出那些是必输项)
●检查输入元素的字段长度
●检查界面所有的元素(编写方式:
年龄,数值类型*)
数字文本框
●检查正数值;
●检查负数值;
●检查零值;
●检查小数点;
●检查特殊字符加数字;
●检查字母加数字;
●检查ASCII值;
●检查重复值;
●检查空值;
字符文本框
●检查仅有字母;
●检查仅有数字;
●检查字母数字;
●检查允许的特殊字符;
●检查禁止
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 功能 编写 指南 V30