浅谈功能测试用例

发表于:2009-11-10来源:作者:点击数: 标签:功能
浅谈功能测试用例 软件测试 一、功能测试用例的书写方式 功能性测试用例 1. 测试的来源,即测试的 需求 测试用例的主要来源有: 1) 需求说明”及相关文档 2)相关的设计说明(概要设计,详细设计等) 3)与开发组交流对需求理解的 记录(可以是开发人员的一

浅谈功能测试用例           软件测试

一、功能测试用例的书写方式

 

功能性测试用例

  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,选择"帮助"->"关于"命令,应 看见相关版权和产品信息

 

 

 

 

 

 

 

 

     

原文转自:http://www.ltesting.net