1.1 文本框、按钮等控件测试 1.1.1 文本框的测试 如何对文本框进行测试 在测试过程中所用到的测试方法: 1,输入非法数据; 命令按钮控件的测试 测试方法: a,点击按钮正确响应操作。如,单击确定,正确执行操作;单击取消,退出窗口; 单选按钮控件的测试 测试方法: a,一组单选按钮不能同时选中,只能选中一个。 up-down控件文本框的测试 测试方法: a,直接输入数字或用上下箭头控制,如,在“数目”中直接输入10,或者单击向上的箭头,使数目变为10; 组合列表框的测试 测试方法: a,条目内容正确,其详细条目内容可以根据需求说明确定; 复选框的测试 测试方法: a,多个复选框可以被同时选中; 列表框控件的测试 测试方法: a,条目内容正确;同组合列表框类似,根据需求说明书确定列表的各项内容正确,没有丢失或错误; 滚动条控件的测试 要注意一下几点: a,滚动条的长度根据显示信息的长度或宽度及时变换,这样有利于用户了解显示信息的位置和百分比,如,word中浏览100页文档,浏览到50页时,滚动条位置应处于中间; 各种控件在窗体中混和使用时的测试 a,控件间的相互作用; 在测试中,应遵循由简入繁的原则,先进行单个控件功能的测试,确保实现无误后,再进行多个控件的的功能组合的测试。 ps:密码输入框测试时要特别注意进行字母大写输入的测试。 |
-
功能测试用例的书写方式(适于新手学习)
2007-06-08 09:38:43
功能性测试用例
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) -
测试用例容易遗漏的内容
2007-06-08 09:37:51
大家在编写测试用例的时候往往把输入数据、操作步骤、输出、结果、以及一些过程信息等都包含很全,但是往往忽略掉对执行该测试的检查点,这些检查点往往是测试用例设计和编写的人的经验或对被测对象的深入的理解基础上,很多检查内容参加我写的测试检查点的文章。因此我建议在描述操作步骤的时候还要把检查点列上去,如下:
VP即时Verifacation Point:
VP1(重点检查点):每个列表列出的人员、机构信息是正确的,没有重复、不缺少用户
VP2: 组合这两部分的接收者,比如:用户user1在机构1 user2属于本公司人员
选择user1、无群组: user1能收到刚才发布的文件,user2没有
选择user1、本公司人员:user1、user2都能接收到刚才发布的文件
选择user3、本公司人员:user1不能接收到,user2能收到
VP3:坚持非空域,标题、时间必须为非空等
VP4:附件,测试各种格式,如doc、gif、xls、ppt、pdf格式的文件,文件大小分别为100k、1M、5M、10M
VP5:添加图片,浏览gif、tif、jpg、bmp格式的图片,查看现实上传是否正确。
VP6:检查文件状态,如暂存文件显示 “审核中“,发布文件显示”已审核“。 -
设计功能和界面测试用例
2007-06-08 09:36:30
设计功能和界面测试用例
发布时间: 2007-4-12 09:37 作者: ruance 来源: 个人博客
-
覆盖率测试用例设计
2007-06-08 09:29:43
1, 语句覆盖:程序中每个语句必须执行一次
440){this.resized=true;this.style.width=440;}" border=0 resized="true">
2判定覆盖
440){this.resized=true;this.style.width=440;}" border=0 resized="true">
3条件覆盖
第一条件判定判定:
设条件 A>1 取真 记为 T1
假 T1
条件 B=0 取真 记为 T2
假 T2
第二条件判定:
设条件 A=2 取真 记为 T3
假 T3
条件 X>1 取真 记为 T4
假 T4
440){this.resized=true;this.style.width=440;}" border=0 resized="true">
测试用例ABX
通过路径
满足的条件
覆盖分支
1 0 3
abe
T1,T2,T3,T4
b,e
2 1 1
abe
T1,T2,T3,T4
b,e
-
前期测试用例编写规范和流程
2007-06-08 09:23:10
前期测试用例编写规范和流程
发布时间: 2007-4-12 11:56 作者: Allen 来源: 51testing博客
1.编制目的
本文件作为编写前期测试用例期间的规范和流程,旨在合理有效的对该阶段质量进行控制,同时为编写前期测试用例的人员提供参考。
2.主要内容与适用范围
2.1主要内容
本标准规定了编写前期测试用例时的书写规范和操作流程。
2.2适用范围
本标准适用于项目提交测试后进行的路径分析和前期测试用例编写。
3.前期测试用例编写流程
4.路径图制作规范
4.1 所用工具及模型
l 制作路径图一律使用office_2003_visio_pro进行,所用模型可以在两种中选择其一:
1. 基本流程图;
2.UML模型图;
4.2 制作方法及原则
l 路径图的制作完全依照《需求规格书》中的相关业务逻辑描述来完成,一般情况下一个模块的业务逻辑用一个路径图来进行分析,如果该模块业务逻辑过于复杂,可以拆分为若干块进行分析。
l 所画出的路径图必须包括所有业务逻辑,考虑到任何可能的分支。
l 路径图命名必须可以完全说明该图所分析的是什么业务
5.前期测试用例编写规范
5.1 前期测试用例所包含的项
l 用例编号
l 类型
l 设计人
l 用例标题
l 测试方法
l 所属项目
l 测试点
l 步骤
l 期望结果
l 覆盖路径
5.2 各项的编写规范
l 用例编号:项目英文缩写+3位流水号
例:测试POS支付核销系统,第一个用例的编号为 :POS001
l 类型 : 该用例岁对应的测试方法类型,这里一般都写“前期测试用例”
l 设计人:编写改测试用例的人员
l 用例标题:对该用例究竟测试什么而定义的描述语句,一般为疑问句
例:输入正常值,是否可以成功新增销售订单
l 测试方法 :对该用例是用什么测试方法所设计的描述,关于测试方法的种类和方法请参见《测试方法举例》
l 所属项目:该用例所在项目
l 测试点:一般为所测试的模块
l 步骤:对用例如何执行的描述。具体描述时分为步骤1、步骤2……….等,对于所操作步骤的描述,应清晰准确,包括登陆系统,输入什么值等。
例:
步骤1
打开POS刷卡机
步骤2
选择进入“IC卡支付”
步骤3
输入操作员号01,密码 1111,登陆
步骤4
按提示插入IC卡
步骤5
查看界面中显示的IC卡余额
l 期望结果 :按步骤中描述操作后所应该得到结果
例:正确显示IC余额且金额正确
l 覆盖路径 :即该用例是按哪个路径所设计
-
界面测试
2007-06-08 09:21:40
界面测试
发布时间: 2007-4-12 13:53 作者: 51testing会员 来源: 51testing论坛
界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够,直到最近网页制作的兴起,才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。
目前流行的界面风格有三种方式:多窗体、单窗体以及资源管理器风格,无论那种风格,以下规则是应该被重视的。
1:易用性:
按钮名称应该易懂,用词准确,屏弃没楞两可的字眼,要与同一界面上的其他按钮易于区分,能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
易用性细则:
1):完成相同或相近功能的按钮用Frame框起来,常用按钮要支持快捷方式。
2):完成同一功能或任务的元素放在集中位置,减少鼠标移动的距离。
3):按功能将界面划分区域块,用Frame框括起来,并要有功能说明或标题。
4):界面要支持键盘自动浏览按钮功能,即按Tab键、回車鍵的自动切换功能。
5):界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
6):同一界面上的控件数最好不要超过10个,多于10个时可以考虑使用分页界面显示。
7):分页界面要支持在页面间的快捷切换,常用组合快捷键Ctrl+Tab
8):默认按钮要支持Enter及选操作,即按Enter后自动执行默认按钮对应操作。9):可寫控制項檢測到非法輸入後應給出說明並能自動獲得焦點。
10):Tab键的顺序与控件排列顺序要一致,目前流行总体从上到下,同时行间从左到右的方式。
11):核取方塊和選項框按選擇幾率的高底而先後排列。
12):核取方塊和選項框要有默認選項,並支援Tab選擇。
13):選項數相同時多用選項框而不用下拉清單框。
14):界面空间较小时使用下拉框而不用选项框。
15):选项数較少时使用选项框,相反使用下拉列表框。
16):专业性强的软件要使用相关的专业术语,通用性界面则提倡使用通用性词语。
2: 规范性:
通常界面设计都按Windows界面的规范来设计,可以说:界面遵循规范化的程度越高,则易用性相应的就越好。小型软件一般不提供工具厢。
规范性细则:
1):常用菜单要有命令快捷方式。
2):完成相同或相近功能的菜单用横线隔开放在同一位置。
3):菜单前的图标能直观的代表要完成的操作。
4):菜单深度一般要求最多控制在三层以内。
5):工具栏要求可以根据用户的要求自己选择定制。
6):相同或相近功能的工具栏放在一起。
7):工具栏中的每一个按钮要有及时提示信息。
8):一条工具栏的长度最长不能超出屏幕宽度。
9): 工具栏的图标能直观的代表要完成的操作。
10):系统常用的工具栏设置默认放置位置。
11):工具栏太多时可以考虑使用工具箱。
12):工具箱要具有可增减性,由用户自己根据需求定制。
13):工具箱的默认总宽度不要超过屏幕宽度的1/5。
14): 状态条要能显示用户切实需要的信息,常用的有:
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等,如果某一操作需要的时间较长,还应该显示进度条和进程提示。
15):滚动条的长度要根据显示信息的长度或宽度能及时变换,以利于用户了解显示信息的位置和百分比。
16):状态条的高度以放置五好字为宜,滚动条的宽度比状态条的略窄。
17):菜单和工具条要有清楚的界限;菜单要求凸出显示,这样在移走工具条时仍有立体感。
18):菜单和状态条中通常使用5号字体。工具条一般比菜单要宽,但不要宽的太多,否则看起来很不协调。
19): 右键快捷菜单采用与菜单相同的准则。
3:帮助设施:
系统应该提供详尽而可靠的帮助文档,在用户使用产生迷惑时可以自己寻求解决方法。
帮助设施细则:
1):帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明,让人困惑)。
2):打包新系统时,对作了修改的地方在帮助文档中要做相应的修改。
3):操作时要提供及时调用系统帮助的功能。常用F1。
4):在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
5):最好提供目前流行的联机帮助格式或HTML帮助格式。
6):用户可以用关键词在帮助索引中搜索所要的帮助,当然也应该提供帮助主题词。
7):如果没有提供书面的帮助文档的话,最好有打印帮助的功能。
8):在帮助中应该提供我们的技术支持方式,一旦用户难以自己解决可以方便的寻求新的帮助方式。4:合理性:
屏幕对角线相交的位置是用户直视的地方,正上方四分之一处为易吸引用户注意力的位置,在放置窗体时要注意利用这两个位置。
合理性细则:
1):父窗体或主窗体的中心位置应该在对角线焦点附近。
2):子窗体位置应该在主窗体的左上角或正中。
3):多个子窗体弹出时应该依次向右下方偏移,以显示窗体出标题为宜。
4):重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
5):错误使用容易引起界面退出或关闭的按钮不应该放在易点击的位置。横排开头或最后与竖排最后为易点位置。
6):与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示,没法使用该按钮)。
7):对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
8):非法的输入或操作应有足够的提示说明。
9): 对运行过程中出现问题而引起错误的地方要有提示,让用户明白错误出处,避免形成无限期的等待。
10): 提示、警告、或错误说明应该清楚、明了、恰当。
5:美观与协调性:
界面应该大小适合美学观点,感觉协调舒适,能在有效的范围内吸引用户的注意力。
美观与协调性细则:
1): 长宽接近黄金点比例,切忌长宽比例失调、或宽度超过长度。
2): 布局要合理,不宜过于密集,也不能过于空旷,合理的利用空间。
3): 按钮大小基本相近,忌用太长的名称,免得占用过多的界面位置。
4): 按钮的大小要与界面的大小和空间要协调。
5): 避免空旷的界面上放置很大的按钮。
6):放置完控件后界面不应有很大的空缺位置。
7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观,很少使用超过12号的字体。
8): 前景与背景色搭配合理协调,反差不宜太大,最好少用深色,如大红、大绿等。常用色考虑使用Windows界面色调。
9): 如果使用其他颜色,主色调要柔和,具有亲和力与磁力,坚决杜绝刺目的颜色。
10): 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
11): 界面风格要保持一致,字的大小、颜色、字体要相同,除非是需要艺术处理或有特殊要求的地方。
12): 如果窗体支持最小化和最大化或放大时,窗体上的控件也要随着窗体而缩放;切忌只放大窗体而忽略控件的缩放。
13):对于含有按钮的界面一般不应该支持缩放,即右上角只有关闭功能。
14): 通常父窗体支持缩放时,子窗体没有必要缩放。
15):如果能给用户提供自定义界面风格则更好,由用户自己选择颜色、字体等。
6:菜单位置:
菜单是界面上最重要的元素,菜单位置按照按功能来组织。
菜单测试细则:
1): 菜单通常采用“常用--主要--次要--工具--帮助”的位置排列,符合流行的Windows风格。
2): 常用的有“文件”、“編輯”,“查看”等,幾乎每個系統都有這些選項,當然要根據不同的系統有所取捨。
3): 下拉菜单要根据菜单选项的含义进行分组,並且按照一定的规则进行排列,用横线隔开。
4): 一组菜单的使用有先后要求或有向导作用时,应该按先后次序排列。
5): 没有顺序要求的菜单项按使用频率和重要性排列,常用的放在开头, 不常用的靠后放置;重要的放在开头,次要的放在后边。
6): 如果菜单选项较多,应该采用加长菜单的长度而减少深度的原则排列。
7): 菜单深度一般要求最多控制在三层以内。
8): 对常用的菜单要有快捷命令方式,组合原则见8。
9): 对与进行的操作无关的菜单要用屏蔽的方式加以处理,如果采用动态加载方式——即只有需要的菜单才显示——最好。
10): 菜单前的图标不宜太大,与字高保持一直最好。
11): 主菜单的宽度要接近,字数不应多于四个,每个菜单的字数能相同最好。
12): 主菜单数目不应太多,最好为单排布置。13):菜单条是否显示在合适的语境中?
14):应用程序的菜单条是否显示系统相关的特性(如时钟显示)?
15):下拉式操作能正确工作吗?
16):菜单、调色板和工具条是否工作正确?
17):是否适当地列出了所有的菜单功能和下拉式子功能?
18):是否可能通过鼠标访问所有的菜单功能?
19):相同功能按钮的图标和文字是否一致?
20):是否能够用其他的文本命令激活每个菜单功能?
21):菜单功能是否随当前的窗口操作加亮或变灰?
22):菜单功能是否正确执行?
23):菜单功能的名字是否具有自解释性?
24):菜单项是否有帮助,是否语境相关?
25):在整个交互式语境中,是否可以识别鼠标操作?
26):如果要求多次点击鼠标,是否能够在语境正确识别?
27):如果鼠标有多个按钮,是否能够在语境中正确识别?
28):光标、处理指示器和识别指针是否随操作恰当地改变?
7:独特性:
如果一味的遵循业界的界面标准,则会丧失自己的个性.在框架符合以上规范的情况下,设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
测试细则:
1): 安装界面上应有单位介绍或产品介绍,并有自己的图标。
2): 主界面,最好是大多数界面上要有公司图标。
3): 登录界面上要有本产品的标志,同时包含公司图标。
4): 帮助菜单的“关于”中应有版权和产品信息。
5): 公司的系列产品要保持一直的界面风格,如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。8:快捷方式的组合
在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些在西文Windows及其应用软件中快捷键的使用大多是一致的。
菜单中:
1):面向事务的组合有:
Ctrl-D 删除 ;Ctrl-F 寻找 ;Ctrl –H替换;Ctrl-I 插入 ;Ctrl-N 新记录 ;Ctrl-S 保存 Ctrl-O 打开。
2):列表:
Ctrl-R ,Ctrl-G定位;Ctrl-Tab下一分页窗口或反序浏览同一页面控件;。
3):编辑:
Ctrl-A全选;Ctrl-C 拷贝;Ctrl-V 粘贴;Ctrl-X 剪切;Ctrl-Z撤消操作;Ctrl-Y恢复操作。
4)文件操作:
Ctrl-P 打印;Ctrl-W 关闭。
5):系统菜单
Alt-A文件;Alt-E编辑;Alt-T工具;Alt-W窗口;Alt-H帮助。
6):MS Windows保留键:
Ctrl-Esc 任务列表 ;Ctrl-F4 关闭窗口; Alt-F4 结束应用;Alt-Tab 下一应用 ;Enter 缺省按钮/确认操作 ;Esc 取消按钮/取消操作;Shift-F1 上下文相关帮助。
按钮中:
可以根据系统需要而调节,以下只是常用的组合。
Alt-Y确定(是);Alt-C取消;Alt-N 否;Alt-D删除;Alt-Q退出;Alt-A添加;Alt-E编辑;Alt-B浏览;Alt-R读;Alt-W写。
这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。
9:安全性考虑:
在界面上通过下列方式来控制出错几率,会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。
安全性细则:
1):最重要的是排除可能会使应用非正常中止的错误。
2):应当注意尽可能避免用户无意录入无效的数据。
3):采用相关控件限制用户输入值的种类。
4):当用户作出选择的可能性只有两个时,可以采用单选框。
5):当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
6):当选项特别多时,可以采用列表框,下拉式列表框。
7):在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
8):对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
11):对错误操作最好支持可逆性处理,如取消系列操作。
12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
13):对可能造成等待时间较长的操作应该提供取消功能。
14):特殊字符常有;;’”><,`‘:“[”{、\|}]+=)-(_*&&^%$#@!
,.。?/还有空格。
15):与系统采用的保留字符冲突的要加以限制。
16):在读入用户所输入的信息时,根据需要选择是否去掉前后空格。
17):有些读入数据库的字段不支持中间有空格,但用户切实需要输入中间空格,这时要在程序中加以处理。
10:多窗口的应用与系统资源:
设计良好的软件不仅要有完备的功能,而且要尽可能的占用最底限度的资源。
1):在多窗口系统中,有些界面要求必须保持在最顶层,避免用户在打开多个窗口时,不停的切换甚至最小化其他窗口来显示该窗口。
2):在主界面载入完毕后自动卸出内存,让出所占用的WINDOWS系统资源。
3):关闭所有窗体,系统退出后要释放所占的所有系统资源 ,除非是需要后台运行的系统。
4):尽量防止对系统的独占使用。5):窗口能否基于相关的输入或菜单命令适当地打开?
6):窗口能否改变大小、移动和滚动?
7):窗口中的数据内容能否使用鼠标、功能键、方向箭头和键盘访问?
8):当被覆盖并重调用后,窗口能否正确地再生?
9):需要时能否使用所有窗口相关的功能?
10):所有窗口相关的功能是可操作的吗?
11):是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口可用,并适当地显示?
12):显示多个窗口时,窗口的名称是否被适当地表示?
13):活动窗口是否被适当地加亮?
14):如果使用多任务,是否所有的窗口被实时更新?
15):多次或不正确按鼠标是否会导致无法预料的副作用?
16):窗口的声音和颜色提示和窗口的操作顺序是否符合需求?
17):窗口是否正确地关闭?
-
黑盒测试的测试用例设计方法
2007-06-08 09:20:13
黑盒测试的测试用例设计方法
发布时间: 2007-4-13 09:29 作者: 未知 来源: 网络
·等价类划分方法
·边界值分析方法
·错误推测方法
·因果图方法等价类划分:
是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.
1) 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.
无效等价类:与有效等价类的定义恰巧相反.
设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.2)划分等价类的方法:下面给出六条确定等价类的原则.
①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.
③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.
④在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.
⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则).
⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.3)设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:
输入条件 有效等价类 无效等价类
... ... ...
... ... ...
然后从划分出的等价类中按以下三个原则设计测试用例:
①为每一个等价类规定一个唯一的编号.
②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.
③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.边界值分析法
边界值分析方法是对等价类划分方法的补充.
(1)边界值分析方法的考虑:
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
(2)基于边界值分析方法选择测试用例的原则:
1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.
2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.
3)根据规格说明的每个输出条件,使用前面的原则1).
4)根据规格说明的每个输出条件,应用前面的原则2).
5)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.
6)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.
7)分析规格说明,找出其它可能的边界条件.错误推测法
错误推测法: 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型).
因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
利用因果图生成测试用例的基本步骤:
(1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.
(2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.
(3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.
(4) 把因果图转换为判定表.
(5) 把判定表的每一列拿出来作为依据,设计测试用例.
从因果图生成的测试用例(局部,组合关系下的)包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.除了上述几种黑盒测试的测试用例设计方法之外其他方法还包括判定表驱动分析方法、正交实验设计方法、功能图分析方法等
-
谈谈关于测试覆盖
2007-06-08 09:19:09
谈谈关于测试覆盖
发布时间: 2007-4-13 09:53 作者: jerry 来源: 网络
软件测试覆盖包括分支覆盖,语句覆盖以及条件覆盖,这是白盒测试中一个很基本的测试概念,但是最近和几位搞了多年测试的朋友谈及此事,大家都搞不大清楚。下面我通过一个例子来深入探讨一下这个问题:
我们首先来看一下这几些测试覆盖的定义:
定义一、语句覆盖:它要求被测程序的每一可执行语句在测试中尽可能都检验过;
定义二、分支覆盖:要求程序中所有判定的分支尽可能得到检验;
定义三、条件覆盖:当判定式中含有多个条件时,要求每个条件的取值均得到检验;
从这些定义我们可以很容易理解到语句覆盖是把程序中的所有的语句都给覆盖到;分支覆盖是把程序中每个分支都给覆盖到;条件覆盖是把判断条件中所有的条件都给覆盖到。
下面我们通过一个简单的例子来描述一下
0:
1:if ((a<150)||(b<200)){
2: for (i=a;i<100;i++)
3: {
4: println(“A”);}
5:}else{
6:println (“B”);
7:}
分支覆盖:
1)在0处设置a=120,b 任意
将执行1,2,5
2)在0处设置a=200,b=400
将执行1,5,6,7
这里所有的分支都走到,也就是说要达到分支覆盖率100%,要设计2组测试用例
a b 120 任意 200 400 语句覆盖:
1)在0处设置a=40,b 任意
将执行1,2,3,4,5
2)在0处设置a=200,b=400
将执行1,5,6,7
这里所有的语句都走到了,也就是说要达到语句覆盖率100%,要设计2组测试用例
a b 40 任意 200 400 而在分支覆盖中语句3,4没有走到
条件覆盖:
由于第一个条件是if ((a<150)||(b<200)) 所以需要设计测试用例
a b 备注 40 50 全部满足 160 150 a不满足,b满足 40 250 a满足,b不满足 150 250 a,b都不满足 条件覆盖只要求把所有的条件都覆盖就可以了。
这样一来我们就把这几个概念搞得很清楚了。
顺便我在这里想说一句心里话,我们现在的不管是书籍还是网站上的文章都太倾向于理论了,而到实际运用上来就说不清楚了,我希望能够有更多又讲理论又讲实践的文章和书籍能够出现。
-
用路径分析的方法编写测试用例
2007-06-08 09:15:39
用路径分析的方法编写测试用例
发布时间: 2007-4-13 14:12 作者: skinapi 来源: 51testing论坛
说明:这段文字可以看成是Testing from use cases using path analysis technique, Naresh Ahlowalia Object System Group的读书笔记,目前还没有很好的系统的尝试过,以后尝试了再给大家谈谈具体的感受吧。或者哪位大虾用过类似的方法可以介绍介绍嘛。
熟悉测试理论的人都知道,路径覆盖是白盒测试中一种很重要的方法,广泛应用于单元测试。那么基于路径覆盖的分析方法是不是只能应用于单元测试呢,能不能将其推而广之呢。一般而言,在单元测试中,路径就是指函数代码的某个分支,而实际上如果我们将软件系统的某个流程也看成路径的话,我们将可以尝试着用路径分析的方法来设计测试用例。采用路径分析的方法设计测试用例有两点好处:一是降低了测试用例设计的难度,只要搞清了各种流程,就可以设计出高质量的测试用例来,而不用太多测试方面的经验;二是在测试时间较紧的情况下,可以有的放矢的选择测试用例,而不用完全根据经验来取舍。下面就具体的介绍一下如何用路径分析的方法编写测试用例。
首先是将系统运行过程中所涉及到的各种流程图表化,可以先从最基本的流程入手,将流程抽象成为不同功能的顺序执行。在最基本流程的基础上再去考虑次要或者异常的流程,这样将各种流程逐渐细化,这样既可以逐渐加深对流程的理解,还可以将各个看似孤立的流程关联起来。完成所有流程的图表化后就完成了所有路径的设定。
找出了所有的路径,下面的工作就是给每条路径设定优先级,这样在测试时就可以先测优先级高的,再测优先级低的,在时间紧迫的情况下甚至可以考虑忽略一些低优先级的路径。优先级根据两个原则来选取:一是路径使用的频率,使用越频繁的优先级越高;二是路径的重要程度,如果失败对系统影响越大的优先级越高。将根据两个原则所分别得到的优先级相加就得到了整个路径的优先级。根据优先级的排序就可以更有针对性的进行测试。
为每条路径设定好优先级后,接下来的工作就是为每条路径选取测试数据,构造测试用例。一条路径可以对应多个测试用例,在选取测试数据时,可以充分利用边界值选取等方法,通过表格将各种测试数据的输入输出对应起来,这样就完成了测试用例的设计。
对于测试人员而言,测试用例的设计是一件非常困难的工作,而同时测试用例的设计好坏又直接关系到整个系统的设计质量。本文介绍了一种更理论化的设计方法来尽量简化这种工作,将一般应用于单元测试的路径分析方法推广到集成测试、系统测试等后续测试过程中,希望能给大家一点启示。 -
快速划分测试用例的优先级
2007-06-08 09:12:20
快速划分测试用例的优先级
发布时间: 2007-4-13 14:28 作者: Kiki翻译 来源: 转载
从未有足够的时间做所有我们需要做的事情,这是在软件项目,尤其在测试中的一个普通的话题。假使你在可用的有限时间内,你如何知道你的测试工作做的最好?你知道当应用程序发布时,总会有些遗漏的缺陷没有被发现。对于测试而言,目标是通过改进产品质量使风险减到最小,并且这可以部分的通过建造一套具体的测试用例来将应用程序按照它的速度完成等方法实现。
IEEE Standard 610 (1990) 中定义测试用例为:
1. 为一个为特定目标而开发一组测试输入,执行条件和的期望结果,例如测试某个程序路径或核实是否满足某个特定的需求。
2.指定输入,预期结果和一组测试项的执行条件的文档 (IEEE Std 829-1983)。
当然,你将发现在项目的生命周期里的每一个应用程序的版本上执行你全部的测试用例是很困难的。但是你将如何知道哪个测试用例必须在每一个版本中执行,什么应该被执行,同时如果你有时间的话,什么又可以被执行?
给你的测试用例划分优先级别
你的应用程序不需要十全十美,但它必须迎合你目标用户的需求和期望。为了了解你项目的期望,你需要确定什么是应用程序中最重要的,目标和风险又是什么。
Sue Bartlett在“How to Find the Level of Quality Your Sponsor Wants”一文中详细的讨论了这个问题,她在文中注解到:“当我们在详细的计划,设计或编码之前沟通质量目标时,我们有一个更好的机会来避免在最后时刻的质量不匹配,那意味着迎合计划,弥补花费并且赢利将有一个更好的成功的机会。”
为了测试计划的目的,在你项目版本的进度下,测试执行的组织和安排你的测试用例将帮助达到这些目标。作为这种组织的一部分,我们要考虑每一个测试用例的优先级别。根据优先级别分组你的测试用例将帮助你决定不同类型的版本需要什么样的测试用例,因此计算需要的时间。如果你只有有限的时间,你可以查看什么是最合适。
Ross Collard在"Use Case Testing"一文中说:“测试用例的前10%到15%可以发现75%到90%的重要缺陷”。
测试用例的优先级划分将帮助确定找出了这前10%到15%的测试用例。
如何划分测试用例的优先级别
你曾查看过多少次你的测试用例并且能够很容易的挑选出最重要的一个小的子集?这个答案可能是不经常。停止思考“所有的测试用例都是同等重要”这个问题是非常困难的。当设计测试用例时,分配优先级别是不容易,并且在项目期间里不一定是静止的。然而,我们可以通过构造一个划分优先级别流程的例子来开始处理划分测试用例优先级别的第一步。让我们假设你刚刚根据功能说明书, 用例和其他一些关于你应用程序的目标行为和能力的信息源完成了建立测试用例。现在是时候来为每个测试用例分配一个优先级别了。
测试用例的优先级别
首先,你必须确定什么是你优先级别的类型和其暗示着什么。就我们的目的来说, 我们将用一个假设开始,那就是我们可能发现的缺陷的严重程度和那些相应测试用例的优先级别之间是平行的。
1 –小版本确认测试(Build Verification Tests (BVTs):也叫做“冒烟测试”,一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。如果你不能访问每一个功能区域或执行其他测试用例依赖的基本操作,那么在执行这个优先的测试用例之前,试图做其他任何的测试都是没有意义的,因为他们大多数肯定要失败。
2 – 高(Highs):最常执行以保证功能性是稳定的,目标的行为和能力可以正常的工作,和重要的错误和边界被测试的测试用例的集合。
3 – 中(Mediums):这是使给出的功能区域或功能变得更详细,检查功能的多数方面包括边界,错误和配置测试的测试用例
4 – 低(Lows):这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要,只是说他们在项目的生命期间里不是常常被运行,例如GUI,错误信息,可用性,压力和性能测试。
我们将测试用例分成4类:BVTs,高,中和低。现在的问题是将测试用例分到不同的优先级别里。毕竟,优先级别将指出哪些测试用例被认为是需要更频繁的执行的,哪些又不是。
怎样着手分配优先级别
1) 随意地分配:
基于如果你没有足够的时间测试却又至少要保证所有的产品需求已经被确认可以在设想的良好状况下象它们被期望的那样工作的想法,前面这3 步将让你任意的分组测试用例,如果你也停下来思考每个测试用例的测试的内容,它们都将变的很重要。因此只需要:
I) 把你所有功能性验证(或基本路径(Happy Path))的测试标注为高优先级别
II) 把你所有错误和边界值或确认测试标注为中优先级别
III) 把你所有非功能性的测试(例如性能和可用性)标注为低优先级别.
2) 提升和降级:
并非所有的功能性测试都一样的重要,并且和边界和非功能性测试一样的重要。思考一下测试的重要性及相对于其他同等优先级别的测试,你想要检查这个功能的频率-考虑质量目标和你项目的需求。
I) 把功能性验证测试分为两组:重要和不是十分重要。
II) 将“不是十分重要”的能性验证测试降级为中优先级别
III) 把错误和边界测试分成两组:重要和不是十分重要
IV) 将“重要”的错误和边界测试升级为高优先级别
V) 把非功能性测试分成两组:重要和不是十分重要
VI) 把“重要”的非功能性测试升级为中优先级别
VII) 针对每组高,中和低优先级别的测试用例,重复划分和升级/降级流程直到你达到一个点,可以在不同优先级别之间移动的测试用例的数量到最小。
3) 识别小版本验证测试用例(Build Verification Tests):
现在,为了确保小版本是可以测试的并准备好给小组其他成员开始测试,哪些测试用例是必须在每个小版本中都检查呢?
I) 将好优先级别的测试用例分成两组:严重和重要的
II) 将“严重”的高优先级的测试用例升级为BVT优先级
注意:不要先识别BVT测试用例!BVT只是高优先级别测试用例的精选,它们已经被确定为对系统和测试是非常重要的。
在这个流程的最后,就是要检查优先级别的百分比分布情况是:BVT为10-15%,高为20-30%,,中为40-60%,低为10-15% 。
在升级和降级测试用例时,需要考虑的方面是用户将要求这个功能或功能性的频率是怎样。同样的,对于用户日常的或月尾的活动而言,这种行为的严重性是如何。Robyn Brilliant在测试进度报告中提供了一个清单,你可以在考虑降级或升级测试用例的时候使用
使用从一到五的一个刻度,从最严重到最少的严重程度,量化可靠性风险如下:
I) 这个功能的失败将影响用户。
II) 这个功能的失败将给公司造成重大的影响
III) 这个功能的失败将引起一个潜在的延期给客户
IV) 这个功能的失败对公司将有较小的影响
V) 这个功能的失败没有任何影响
这个和其相似的刻度可以帮助你达到你测试用例优先级别划分的最后一步。
总结
这是一个简化的划分测试用例优先级别过程的例子。然而,在快速组织测试用例和安排测试进度和工作量,及制订项目计划时需要完成哪些测试用例等方面,它可以给你很多帮助。
记住,你怎样给你的测试任务划分优先级和如何执行测试用例将取决于你在你的项目周期的位置。当你朝发布前进并通过调查和观察确定危险和缺陷出现的地方时,你可能会重新给你的测试用例划分优先级别。向上为每个阶段建立你的测试目标并保证他们在你的测试用例的优先级别上被反映,当它在解释并执行你的计划时,将使你的生活变得容易得多。
最后,拥有划分了优先级别的测试用例也为你潜在的,待定的自动化项目给出了一个好的起点。比如,自动化BVT中的测试用例,度量收益,改进测试自动化,自动化高优先级的测试用例等方面。
-
外企面试智力题
2007-06-08 09:05:17
外企面试智力题
发布时间: 2007-6-04 11:29 作者: 未知 来源: 网络
1.击鼠标
击鼠标比赛现在开始!参赛者有拉尔夫、威利和保罗。
拉尔夫10秒钟能击10下鼠标;威利20秒钟能击20下鼠标;保罗5秒钟能击5下鼠标。以上各人所用的时间是这样计算的;从第一击开始,到最后一击结束。
他们是否打平手?如果不是,谁最先击完40下鼠标?
2.感觉
用第一感觉判断8+8=91这个等式正确吗?说明理由。
3.谎话
如果下列每个人说的话都是假话,那么是谁打碎了花瓶?
夏克:吉姆打碎了花瓶。
汤姆:夏克会告诉你谁打碎了花瓶。
埃普尔:汤姆,夏克和我不太可能打碎花瓶。
克力斯:我没打碎花瓶。
艾力克:夏克打碎了花瓶,所以汤姆和埃普尔不太可能打碎花瓶。
吉姆:我打碎了花瓶,汤姆是无辜的。
4.大有作为
鲁道夫、菲利普、罗伯特三位青年,一个当了歌手,一个考上大学,一个加入美军陆战队,个个未来都大有作为。现已知:
A. 罗伯特的年龄比战士的大;
B. 大学生的年龄比菲利普小;
C. 鲁道夫的年龄和大学生的年龄不一样。
请问:三个人中谁是歌手?谁是大学生?谁是士兵?
5.麻省理工大学的学生
美国麻省理大学的学生来自不同国家。
大卫、比利、特德三名学生,一个是法国人,一个是日本人,一个是美国人。现已知:
1、 大卫不喜欢面条,特德不喜欢汉堡包;
2、 喜欢面条的不是法国人;
3、 喜欢汉堡包的是日本人;
4、 比利不是美国人。
请推测出这三名留学生分别来自哪些国家?
6.宴会桌旁
在某宾馆的宴会厅里,有4位朋友正围桌而坐,侃侃而谈。他们用了中、英、法、日4种语言。现已知:
A.甲、乙、丙各会两种语言,丁只会一种语言;
B.有一种语言4人中有3人都会;
C.甲会日语,丁不会日语,乙不会英语;
D. 甲与丙、丙与丁不能直接交谈,乙与丙可以直接交谈;
E. 没有人既会日语,又会法语。
请问:甲乙丙丁各会什么语言?
7.借机发财
从前有A、B两个相邻的国家,它们的关系很好,不但互相之间贸易交往频繁,货币可以通用,汇率也相同。也就是说A国的100元等于B国的100元。可是两国关系因为一次事件而破裂了,虽然贸易往来仍然继续,但两国国王却互相宣布对方货币的100元只能兑换本国货币的90元。有一个聪明人,他手里只有A国的100元钞票,却借机捞了一大把,发了一笔横财。请你想一想,这个聪明人是怎样从中发财的?
8.不合理的安排
S先生正在家里休息时,接到了一个陌生人打来的预约电话。对方很想在下下个星期的周五去他家里拜访他。但是S先生并不想见这个陌生人,于是他连忙说:“下下个礼拜五我非常忙。上午要开会,下午1点钟要去参加一个学生的婚礼,接着4点钟要去参加一个朋友的孩子的葬礼,随后是我的叔叔的七十寿辰宴会。所以那天我实在是没有时间来接待您的来访了。”
请仔细看题,S先生的话里有一处是不可信的,是哪个地方?
9.快马加鞭
墨西哥农村现在仍然可以看到人们用马和驴运载货物。一位商人把四匹马从甲村拉到乙村,而从甲村到乙村,A马要花一小时,B马要花两小时,C马要花四小时,D马要花五小时。
这位商人一次只能拉两匹马,回来时他还要骑一匹马,其中以走得慢的那匹马作为从甲村拉到乙村所需的时间。听说有人花了12小时就把四匹马全部从甲村拉到乙村,请问:他是如何办到的?
标题搜索
我的存档
数据统计
- 访问量: 174849
- 日志数: 291
- 图片数: 2
- 书签数: 1
- 建立时间: 2007-06-08
- 更新时间: 2009-10-17