浅谈功能测试用例 软件测试
一、功能测试用例的书写方式
功能性测试用例
1. 测试的来源,即测试的需求
测试用例的主要来源有:
1) 需求说明”及相关文档
2)相关的设计说明(概要设计,详细设计等)
3)与开发组交流对需求理解的 记录(可以是开发人员的一个解释)
4)已经基本成型的UI(可以有针对性地补充一些用例)
简而言之,所有你能得到的项目文档,都尽量拿到。 从所得到的资料中,分解出若干小的“功能点”,理解“功能点”,编写相应的测试用例。
2. 用例的组织方式
不同的公司有不同的做法,原则上,只要方便管理和跟踪,怎么组织都可以的。
用例可以按大的功能块组织,如查询功能模块的用例,可以组织在一起,打印模块的测试用例,可以另外组织在一起。
在没有专门的测试用例管理工具的情况下,用例执行后会产生2种状态:“通过”、“失败”——这样加上“未 执行”的用例的状态,共3种状态。
即从“未执行”用例中执行一个用例后,该用例状态应为“失败”或“通 过”。将同一状态的用例组织在一起。
至于用例文件格式,可以是.DOC或.XLS(如果有专门的测试用例管理工具另当别论)。
3. 用例与其他材料的关联方式,即如何解决用例跟踪的问题
测试用例面临的比较大的风险有:需求的变更、设计的修改、需求的错误和遗漏等等。
由于用例的主要来源是需求和设计的说明,所以对用例的跟踪其实就是对需求和设计的跟踪,需求和设计的 变更势必引起测试用例的变更。
如前所说,将分解的功能点编号,与相应的用例联系起来。例如,你可以列一个表格,列出各个(编号的)功 能点和测试用例间的关联关系。
这样,当需求和设计发生变化时,你只需要跟踪“功能点”是否变化,是否增加了新的功能点。
4. 一个好的用例的表述要点,即用例中应当包含的信息
一个优秀的测试用例,应该包含以下信息:
1) 软件或项目的名称
2) 软件或项目的版本(内部版本号)
3) 功能模块名
4) 测试用例的简单描述,即该用例执行的目的或方法
5) 测试用例的参考信息(便于跟踪和参考)
6) 本测试用例与其他测试用例间的依赖关系
7) 本用例的前置条件,即执行本用例必须要满足的条件,如对数据库的访问权限
8) 用例的编号(ID),如可以是 软件名称简写-功能块简写-NO.。
9) 步骤号、操作步骤描述、测试数据描述
10)预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略)
11)软件开发人员(必须有)和软件测试人员(可有可无)
12)测试执行日期
5. 给出一个测试用例的例子该范例已经包含一个测试用例的模板。
备注:本用例未考虑“企业代码”的输入情况;测试用例并未涵盖所有的非法输入,如非法输入中可能会有 “user=*,pw=*”的组合,对回车的默认操作,空格输入,对输入上溢的处理的处理(可能会跳过身份验证) 等等。
如果你有兴趣,至少可以再补充5-10条左右的输入组合(当然,如果步骤超过15步,用例的易操作 性就降低,你可以再创建一个测试用例如TC-TEP_Login_2)
二、功能测试用例模板设计
测试用例设计和执行是测试工作的核心,也是工作量最大的任务之一,设计良好的测试用例模板能提高测试用例的设计质量,便于跟踪测试用例的执行结果,自动生成测试用例覆盖率报告。这几年测试技术和理论有了长足的发展,就功能测试用例设计要素而言,样式上均大同小异,一般都包含主题、前置条件、执行步骤、期望结果等。
测试用例可以用数据库、Word 、Excel 、xml 等格式进行管理,市面亦有成熟的商业软件工具和开源工具等,对于一般中小软件企业,使用文档来管理测试用例是较为方便、经济的途径。 Word 格式的文档可以满足设计需要,但不利于跟踪和自动统计执行结果报告。下面我将介绍自己在多个项目中设计和改进的 Excel 模版,它可以方便地设计测试用例,记录执行结果并自动统计测试用例覆盖率。
测试用例 ID —— 用于唯一标识测试用例号,可根据自身需要定义规则,最好易于跟踪和维护;
测试前置条件 —— 如果有则描述之;
测试用例等级 —— 根据需求重要性区分测试用例等级,测试执行阶段可以根据测试用例等级安排测试任务,分为四级:
• 冒烟测试,即版本确认测试,每个测试版本需通过所有该级测试用例,否则拒绝继续测试;
• 关键路径测试,每个测试版本需执行该级测试用例,若该级测试用例均通过,意味着软件功能趋于稳定;
• 可接受级测试,该级测试用例只要执行一次通过即可,该级测试用例通过意味着可以准备发布了;
• 建议执行的用例,如果有时间,最好执行该级测试用例,但不作为发布的必要条件。
测试用例执行步骤、期望结果;
测试用例执行结果 —— 执行时填写,分为通过、失败、警告、阻塞、忽略。
通过开发 VBA 脚本,可以自动统计每轮测试用例执行结果,得到测试用例覆盖率结果报告,用于分析测试结果。
测试用例状态转换分析
队列中( In Queue ) -- 测试用例在排队等待中;
进程中( In Progress ) -- 表示测试正在进行,并且可能会持续一段时间,如果一个测试花费的时间少于一天或两天,只需将它显示在处于排队状态;
阻塞( Block ) -- 一些外部条件 — 如缺少部分功能 — 将无法执行测试;
忽略( Skip ) -- 已经决定(或被告知)跳过这个测试用例;
通过( Pass ) -- 终点状态,没问题;
失败( Fail ) -- 测试用例执行出错;
警告( Warn ) -- 结果处于 Pass 和 Fail 之间,错误严重性等级较轻,不影响功能和性能;
关闭( Closed ) -- 以前识别出的错误都已经被修正。
实际项目中,一个测试用例有多个执行步骤,每个步骤可能有不同结果,如步骤 1 通过,步骤 2 失败,步骤 3 被步骤 2 中的失败所阻塞,那么该测试状态如何?单纯指出这个测试用例阻塞或失败都将遗漏重要的信息。因此必须指定双重状态,如 Block/Fail , Block/Warn , Skip/Pass , Skip/Closed 等。然而,如果显示十几个状态,则测试结果可能更难以解释。如何使结果明了又能精确反映实际结果,需要精明选择包括哪些状态。
使用该模板优点:使用维护简便,方便测试任务分配,易于与项目组其他角色交流,结果报告自动生成。
不足之处:测试变更跟踪不方便,每个测试用例的规模不等,所以测试覆盖率结果只是作为参考,结果百分比不能精确反映工作量,需要具体分析项目情况。这个模版没有跟踪统计缺陷,同时考虑是否使用加权评估缺陷严重性,一个测试用例往往对应几个缺陷的统计分析。
结论:在实际项目中,应该根据项目特点和开发流程定义测试用例各项。在精确和简单两个特性相对立时,需要好好权衡。如果您有好的解决方案,我将很乐意知道。
三、常见的一些功能测试用例
一\登陆、添加、删除、查询模块的测试点
1. 登陆
2. 添加
3. 查询
4. 删除
1. 登陆
① 用户名和密码都符合要求(格式上的要求)
② 用户名和密码都不符合要求(格式上的要求)
③ 用户名符合要求,密码不符合要求(格式上的要求)
④ 密码符合要求,用户名不符合要求(格式上的要求)
⑤ 用户名或密码为空
⑥ 数据库中不存在的用户名,不存在的密码
⑦ 数据库中存在的用户名,错误的密码
⑧ 数据库中不存在的用户名,存在的密码
⑨ 输入的数据前存在空格
⑩ 输入正确的用户名密码以后按[enter]是否能登陆
2. 添加
① 要添加的数据项均合理,检查数据库中是否添加了相应的数据
② 留出一个必填数据为空
③ 按照边界值等价类设计测试用例的原则设计其他输入项的测试用例
④ 不符合要求的地方要有错误提示
⑤ 是否支持table键
⑥ 按enter是否能保存
⑦ 若提示不能保存,也要察看数据库里是否多了一条数据
3. 删除
① 删除一个数据库中存在的数据,然后查看数据库中是否删除
② 删除一个数据库中并不存在的数据,看书否有错误提示,并且数据库中没有数据被删除
③ 输入一个格式错误的数据,看是否有错误提示,并且数据库中没有数据被删除。
④ 输入的正确数据前加空格,看是否能正确删除数据
⑤ 什么也不输入
⑥ 是否指出table键
⑦ 是否支持enter键
4. 查询
精确查询:
① 输入的查询条件为数据库中存在的数据,看是否能正确地查出相应得数据
② 输入正确的查询条件以前加上空格,看是否能正确地查出相应的数据
③ 输入格式或范围不符合要求的数据,看是否有错误提示
④ 输入数据库中不存在的数据
⑤ 不输入任何数据
⑥ 是否支持table键
⑦ 是否支持enter键
模糊查询:
在精确查询的基础上加上以下一点
① 输入一些字符,看是否能查出数据库中所有的相关信息
2\设计功能和界面测试用例
1.1 文本框、按钮等控件测试
1.1.1 文本框的测试
如何对文本框进行测试
a,输入正常的字母或数字。
b,输入已存在的文件的名称;
c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符,假设最多255个字符,尝试输入 256个字符,检查程序能否正确处理;
d,输入默认值,空白,空格;
e,若只允许输入字母,尝试输入数字;反之;尝试输入字母;
f,利用复制,粘贴等操作强制输入程序不允许的输入数据;
g,输入特殊字符集,例如,NUL及\n等;
h,输入超过文本框长度的字符或文本,检查所输入的内容是否正常显示;
i,输入不符合格式的数据,检查程序是否正常校验,如,程序要求输入年月日格式为yy/mm/dd,实际输入yyyy/mm/dd,程序应该给出错误提示
在测试过程中所用到的测试方法:
1,输入非法数据;
2,输入默认值;
3,输入特殊字符集;
4,输入使缓冲区溢出的数据;
5,输入相同的文件名;
命令按钮控件的测试
测试方法:
a,点击按钮正确响应操作。如,单击确定,正确执行操作;单击取消,退出窗口;
b,对非法的输入或操作给出足够的提示说明,如,输入月工作天数为32时,单击”确定“后系统应提示:天数不能大于31;
c,对可能造成数据无法恢复的操作必须给出确认信息,给用户放弃选择的机会;
单选按钮控件的测试
测试方法:
a,一组单选按钮不能同时选中,只能选中一个。
b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后,保存到数据库的数据应该相应的分别为“男”“女”;
c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中,不能同时为空;
up-down控件文本框的测试
测试方法:
a,直接输入数字或用上下箭头控制,如,在“数目”中直接输入10,或者单击向上的箭头,使数目变为10;
b,利用上下箭头控制数字的自动循环,如,当最多数字为253时,单击向上箭头,数目自动变为1;反之亦适用;
c,直接输入超边界值,系统应该提示重新输入;
d,输入默认值,空白。如,“插入”数目为默认值,点击“确定”;或,删除默认值,使内容为空,单击“确定”进行测试;
e,输入字符。此时系统应提示输入有误。
组合列表框的测试
测试方法:
a,条目内容正确,其详细条目内容可以根据需求说明确定;
b,逐一执行列表框中每个条目的功能;
c,检查能否向组合列表框输入数据;
复选框的测试
测试方法:
a,多个复选框可以被同时选中;
b,多个复选框可以被部分选中;
c,多个复选框可以都不被选中;
d,逐一执行每个复选框的功能;
列表框控件的测试
测试方法:
a,条目内容正确;同组合列表框类似,根据需求说明书确定列表的各项内容正确,没有丢失或错误;
b,列表框的内容较多时要使用滚动条;
c,列表框允许多选时,要分别检查shift选中条目,按ctrl选中条目和直接用鼠标选中多项条目的情况;
滚动条控件的测试
要注意一下几点:
a,滚动条的长度根据显示信息的长度或宽度及时变换,这样有利于用户了解显示信息的位置和百分比,如,word中浏览100页文档,浏览到50页时,滚动条位置应处于中间;
b,拖动滚动条,检查屏幕刷新情况,并查看是否有乱码;
c,单击滚动条;
d,用滚轮控制滚动条;
e,滚动条的上下按钮。
各种控件在窗体中混和使用时的测试
a,控件间的相互作用;
b,tab键的顺序,一般是从上到下,从左到右;
c,热键的使用,逐一测试;
d,enter键和esc键的使用;
在测试中,应遵循由简入繁的原则,先进行单个控件功能的测试,确保实现无误后,再进行多个控件的的功能组合的测试。
ps:密码输入框测试时要特别注意进行字母大写输入的测试。
查找替换操作
案例演示:打开word中的"替换"对话框
测试本功能有通过测试和失败测试两种情况
通过测试:
1,输入内容直接查找,或查找全部
2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过"测试用例",再次进入不用重新输入查找内容,直接在文档中搜寻就可以.
失败测试:
1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试;
2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试;
替换测试大体相同.
关于编辑操作窗口的功能测试的用例:
1,关闭查找替换窗口.不执行任何操作,直接退出;
2,附件和选项测试.假如,设定"精确搜寻","向后"搜索等附件选项等等来测试;
3,控件间的相互作用.如,搜寻内容为空时,按钮"搜寻全部","搜寻","全部替换","替换"都为灰色.
4,热键, Tab键.回车键的使用.
插入操作
1,插入文件
测试的情况
a,插入文件;
b,插入图像;
c,在文档中插入文档本身;
d,移除插入的源文件;
e,更换插入的源文件的内容;
2,链接文件
测试方法:
a,插入链接文件;
b,在文档中链接文档本身;
c,移除插入的源文件;
d,更换插入的源文件的内容.
3,插入对象
要测试的内容
a,插入程序允许的对象,如,在word中插入excel工作表;
b,修改所插入对象的内容.插入的对象仍能正确显示;
c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.
编辑操作
编辑操作包括剪切,复制,粘贴操作.
测试剪切操作的方法
a,对文本,文本框,图文框进行剪切;
b,剪切图像
c,文本图像混合剪切
复制操作方法与剪切类似.
测试时,主要是对粘贴操作的测试,方法是:
a,粘贴剪切的文本,文本框及图文框;
b,粘贴所剪切的图像;
c,剪切后,在不同的程序中粘贴
d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次;
e,利用粘贴操作强制输入程序所不允许输入的数据.
界面测试用例的设计方法
1,窗体
测试窗体的方法:
a,窗体大小,大小要合适,控件布局合理;
b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确;
c,缩放窗体,窗体上的控件应随窗体的大小变化而变化;
d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常;
进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效,是否与菜单懒中图标显示一致;错误信息内容是否正确,无错别字,且明确等等;
2,控件
测试方法:
a,窗体或控件的字体和大小要一致;
b,注意全角,半角混合
c,无中英文混合.
菜单
进行测试时要注意
a,选择菜单是否可以正常工作,并与实际执行内容一致;
b,是否有错别字:
c,快捷键是否重复;
d,热键是否重复;
e,快捷键与热键操作是否有效
f,是否存在中英文混合
g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;
h,鼠标右键快捷菜单
特殊属性
1,安装界面应有公司介绍或产品介绍,有公司的图标
2,主界面及大多数界面最好有公司图标
3,选择"帮助"->"关于"命令,应 看见相关版权和产品信息