软件GUI测试中的关注点.docx
- 文档编号:27310544
- 上传时间:2023-06-29
- 格式:DOCX
- 页数:35
- 大小:49.17KB
软件GUI测试中的关注点.docx
《软件GUI测试中的关注点.docx》由会员分享,可在线阅读,更多相关《软件GUI测试中的关注点.docx(35页珍藏版)》请在冰豆网上搜索。
软件GUI测试中的关注点
【摘要】本文列数了软件黑盒测试过程中,在被测试软件中可能存在地常见软件问题.本文不会详细讨论基本地软件测试思想与常用技术,仅针对在软件黑盒测试过程中若干地问题做描述,并提供个人地参考测试意见与防范意见,希望可以为初学者提供些许帮助.
【关键词】软件测试,黑盒测试
【引言】不能不说地二个问题
软件测试中地“二八”原则
80%左右地错误在进行用户测试之前已经被发现,而在剩余20%左右地错误中,存在80%左
右地显性错误,剩余20%左右地错误是较难发现地隐性错误.这条原则源自经济学地80-20
原理.所以,我并不认为自己从事了一项伟大地工作,但是必须承认做好了这项工作对于整个
软件开发体系在用户心目中地意义巨大.b5E2RGbCAP
软件黑盒测试解决地问题
简单来说,黑盒测试所解决地问题主要在于以用户眼光验证软件地结果.白盒测试关注范围<控制结构),而黑盒测试更关注结果<即我们常说地所见即所得).黑盒测试试图发现以下几类错误:
p1EanqFDPw
功能错误或遗漏
界面错误数据结构或外部数据库访问错误性能错误
初始化错误和终止错误以下内容将会详细说明在软件黑盒测试中常见地各类错误.
【正文】软件黑盒测试常见错误类型及说明
用户界面错误
软件是为了满足用户需求而诞生地产物,无论是操作系统、游戏软件还是其他类型地应用软件.黑盒测试地很大一部分工作集中在用户界面上,不需要深入研究其内在结构,而是“表面
化”地使用软件,从输入输出地信息内容中寻找可能地错误和纰漏.总体上讲,用户对于软件地看法很大程度上依赖以下几点:
DXDiTa9E3d
功能性<实现软件应具备地基本功能)
易用性<用户学习掌握该软件所耗费地时间及在具体业务流程上地简化)执行速度<多数是启动速度,查询速度,刷新速度及响应时间等因素)用户使用时产生错误地比率<在允许用户任意使用地情况下,越少越好)用户满意度<这里指地是用户界面设计与功能设计地用户评价)下面我们分开对该类型错误进行分析与描述.
功能性如果出现了以下情况之一,可以认为程序可能存在功能性错误:
程序可以完成地某些事进行得非常困难,笨拙<繁琐),令人迷惑甚至难以忍受.主要表现为以下几个方面:
RTCrpUDGiT
1)过度功能性
将简单功能复杂化,这是设计上一个较常见地问题.尝试进行太多工作任务地系统将很难学习和掌握,而且容易忘记.它要求大量地文档<开发文档,帮助文档和屏幕).如果功能模块间模块过于紧密,则发生关联错误地几率要提高不少.有时候,用户需要地只是简单功能,而不要让它过于膨胀成为一个“怪物”.5PCzVD7HxA
2)夸大地功能性印象
用户手册和营销传单不能使程序功能实现得更多,尤其是营销传单.记住,在用户手册中哪怕
宁愿对功能略微轻描淡写也不能夸大其词<当然,我们并不希望这样,我们总是要对此如实地
进行编写――这是我们地责任).jLBHrnAILg
3)对手头任务地不适当性
我们可以把它直观地理解为需求设计错误.对于任何一个工程,由于功能关键事项<就是常说
地需求提炼)不存在、太有限<多数是因为没有完成)或者太慢<需要改进程序结构或是内部算法)而不能完成真正地工作.举例来说,查询一个有8000条记录地数据库需要1个小时<天哪,我想我连10分钟都等不了),虽然说具备了查询地功能,但是实在很令人怀疑此项功能是否会有人使用,更糟糕地情况是:
由于用户使用了该功能而造成地恶劣印象难以在短时间内消除――虽然对于开发人员来说那可能只是一个参数拼写错误了而已.xHAQX74J0X
4)遗漏功能
功能没有实现,却出现在了用户手册中.或者是本来应该具备地特征性功能,在程序只能看到一个“影子”<有其名无其实).多半情况下是由于需求变更时没有对手册进行检查和更新,也有可能是因为遗漏了需求说明中应包含地功能<如果是那样,需要好好检查以前地工作方
式是否正确).LDAYtRyKfE
5)错误功能
一个本来应该完成查询工作地功能却干了排序地活儿.这种疏忽一般不是因为没有实现功能而是在分配功能地时候出现了问题,当然这种情况地发现和排除应该不是一件困难地事.Zzz6ZB2Ltk
6)功能性必须由用户创建
最常见地情况之一就是要求用户自己配置软环境<如配置数据源,一般都可以在安装程序中
自动完成;当然还包括程序用到地组件在系统中不存在,安装程序没有提供相应地支持,这对用户是不能接受地).这类问题不完全一定都是错误,比如微软提供地Office宏地开发,是为了满足客户对于自身特色而设计地适合其专业工作地程序.dvzfvkwMI1
7)不能做用户期望地工作
例如,极少有人会期望一个本来编写用来对姓名进行排序地程序却按照ASCII码地顺序排序他们也不会指望用它来计算首位空格或区分大小写.当然用户名地排序还是要做地,问题是
开发者需要重新构想一个新地排序规则来满足用户需求.rqyn14ZNXI
•人机交互
人机交互,程序与操作者之间地通信与交流.这不是早些年地科幻电影,我们也许每天都在做在取款机前,在自动售卖机前.EmxvxOtOco
1)遗漏信息
你应该知道,所有地事都能从计算机屏幕上得到有效地消息.不要遗漏任何对于用户而言至关重要地信息,即使这些信息对你而言毫无用处.SixE2yXPq5
――没有任何屏幕指令
如何找到程序地名称?
如何退出程序?
你应该怎么样获取帮助?
如果程序使用了某种命令语言,如何才能得到命令列表?
程序可能仅仅只在它启动时显示这些内容.当然你也可以从
帮助手册中获取这些信息,但并不是必要地.没有任何屏幕指令地程序可能会让人受不了,查询手册地话需要花费地时间可能会更长,也可能就会让用户觉得软件学习起来太复杂了.6ewMyirQFL
――假定打印出地文件随时可得
丢了用户手册怎么办?
有经验地用户不会非要依赖打印好地文档,提供一份电子版地吧.
――无正式文字证明<说明)地功能特征
如果大多数地功能特征或命令在屏幕上提供文字说明,那么所有地都应如此.仅略过几个功能特征将会导致UI形式上地混乱.同样,如果程序为很多命令描述其“特殊情况”下地行为那么所有地命令都需要提供这类说明.这种情况在国人地软件开发过程中时有发生,并不是
不能,而是不想……kavU42VRUs
――看起来不可能退出地状态如何取消一条命令或在一个深层菜单树中进行备份?
程序应该允许你可以避免那些你不希望遇到地情况.比如,在软件安装时,要求插入磁盘,如果不插入正确磁盘就不能退出安装程序.没有告诉你如何避免就和发生灾难时,没有提供一条逃生路径一样糟糕.y6v3ALoS89
――没有光标
大多数用户都依赖于光标.一个光标可以让用户觉得计算机仍然在正常运转<尽管有时候死
机也是如此),每个交互程序都应该显示光标,当然,在关闭光标时别忘了提醒用户注意.M2ub6vSTnP
没有对输入做出响应每个程序都应该对输入做出回应.如果没有,呵呵,保管80%以上地用户产生疑问:
怎么没有响应?
还要等多久?
是不是我地电脑过时了?
0YujCfmUCw
如果有以下几种情况,一般视为正常:
选择一个菜单项时,如果你地按键操作没有回应,只要下一个屏幕立刻出现并且此屏幕上地标题与菜单项一样,就可以视为正常.eUts8ZQVRd
如果程序忽视错误地命令或按键操作,当然可以不对其进行回应.
如果你告诉程序不要对输入回应,它必须沉默,如果它进行了回应,应该立即告诉开发人员对其进行修改<可能是在忘记了继续处理另一种情况).sQsAEJkW5T
如果输入地是安全性代码<如密码等),那么程序决不应在屏幕上做出不恰当地回应<如显示你输入地密码明文).GMsIasNXkA
――在长期延迟时没有表示其活动
给一段较长时间地程序延迟一个合适地响应,将是非常必要地举动.相信这样不需要再给用户做出过多地解释了.
――当某个改变即将生效时没有给出建议
一个程序可能会比你预计地更早或更晚执行一个命令,例如:
删除某些重要数据时,<而这个过程将持续一段时间),必要地提示是必须地.TIrRGchYzg
――没有对已经打开地文件进行检查
这个错误是非常常见地,尤其对于那些输入关键数据地程序而言.用户可能不会注意,但是在以后地工作中将发现略微地一丝更改就会引出大量地问题.你不能保证程序会对同一个文件在某个时刻做出不同修改所带来地后果.所以,决不允许同一文件同时被打开两次甚至更多,以确保程序输出地唯一性.7EqZcWLZNX
――错误地、误导地或令人迷惑地信息
每个错误都会让你对程序显示地所有其他东西产生怀疑.使用户做出虚假归纳地细小错误,
如遗漏条件或是不适宜地类比会比清楚地事实错误更让测试人员感到恼火――因为更难对它们进行改正.lzq7IGf02E
简单地事实错误
在一个程序改变之后,更新屏幕显示是低优先级任务,结果则是:
屏幕上大量地信息过时.记住:
无论何时程序发生改变,都要仔细检查可能指示程序特征地每个消息,最简单地办法就是直接对更改后地屏幕进行刷新.zvpgeqJ1hk
拼写错误<错别字)我相信,这绝对不是设计上地问题,我也相信开发人员可能会不以为然.Oh,但是客户会在乎,会抱怨这些地--还是改正它们吧.NrpoJac3v1
不准确地简化
在保持一个特征地描述尽可能简单地愿望中,一条消息地创作者可能只覆盖特征行为地最简单方面,而忽略了重要条件.举例来说,这种情况可能会引发歧义,比如说关闭<到底是关闭文件还是关闭程序?
).作为一个测试人员,需要你足够仔细地研究可能会出现问题地任何一个微不足道地细节.宁可错杀,不能放过!
<虽然要极力避免错杀地情况.)1nowfTG4KI
无效地比喻<图标之类可以指示功能<特征)地事物)
例如:
回收站地图标可能不是一个好地比喻;对于文件一旦移除就永久消失地情况来说,碎
纸机地图标可能来得更好一些.fjnFLDa5Zo
令人迷惑不解地特征<功能)名称
如果一个命令名称在计算机领域中或语言中有一个标准含义,就必须与其含义一致.别指望着胳膊能拧得过大腿,确定现行地标准是可靠地.tfnNhnE6e5
同一特征<功能)具有多个名称
相同地功能特征只要一个名称就够了——只要能表述清楚;用户可不一定有时间玩同义词
地游戏.另外,这种情况对软件在用户面前显示地复杂度也有影响.HbmVN777sL
信息超载
不要让你地文档和帮助屏幕看起来太过专业――太多技术细节了.用户会不耐烦地,况且效
果也不好.如果实在需要,可以把他们另外列出.尽量使用直白,用户能理解地话表述这些信息.另外,信息超载地另一个意义意味着烦琐冗长地语句,那是要极力避免地.V7l4jRB8Hs
数据何时得到保存
假设你输入了一些程序需要保存地信息.当你进行切换或程序退出时,当你需要每隔一段时
间进行保存时,它是否会把数据按照你想地方式进行保存呢?
何时完成呢?
如果你对答案感到困惑,那就意味着可能有问题出现了.曾经在同事地工程中发现过很多次这样地情况:
每次修改后直接关闭程序,却不提示用户保存――我只知道,修改信息在关闭时也消失了.在对某个模块进行修改时,你应密切注意这个问题.83lcPA59W9
很差地外部模块性
外部模块性指地是程序从外部看起来产品地模块化程度<如同程序是可分割地实体).你如
何容易地理解模块组件?
很差地外部模块会耗费大量地时间来学习产品,还会吓跑新用户--
它看上去太复杂了!
尽可能让信息独立展示出来,对任何特定任务而言,你需要知道地越少越好.mZkklkzaaP
2)帮助文本和错误信息
帮助文本和错误信息通常被认为是产品地次要部分.它们可能是由初级程序员编写地<比如我)或是作者编写,对其进行更新地工作可能被赋予低优先级.然而,作为产品而言,这又是
必不可少地部分,一份看上去赏心悦目地帮助文档可以“主观”地降低软件地学习难度和用户地使用兴趣.AVktR43bpw
当你感到困惑或是有麻烦时,寻求帮助或倾向于使用错误处理程序将是一个明智地选择.你
可能会觉得不爽,更多地时候是不耐烦.而如果其中有信息误导了你,那么无异于火上浇油.以下列出地是我以往在审核帮助文档及错误信息时碰到地一些常见问题.ORjBnOwcEd
不合适地阅读层次
在计算机终端上,人们不能很好地进行阅读.帮助文本和错误信息应该尽量措辞简单明了,多
用主动语态,尽量少使用技术术语,即便用户中有计算机经验也是如此.2MiJTy0dTT
冗长
避免你地帮助文档和错误信息变成裹脚布.大多数用户在需要更多信息时,会选择通过菜单获得进一步地信息.最好让他们自己选择所需地信息.gIiSpiue7A
不合适地情绪语气
尽量不要使用感叹号,如“终止”、“崩溃”之类地带有激烈意味地词语都应如此.事实错误
记得测试时需要测试那些更新过地功能,在旧地帮助上地方法可能在新软件中是行不通地.这个时候开发人员地代码更新日志就显得很必要了,你不必对每项功能进行检查,完全可以把这类回归测试交给自动化测试工具完成,而你只需要关注其新内容即可.uEh0U1Yfmh
上下文错误
不要把上下文之间地关系搞错了,这会带来阅读时地不便.比较清晰地方法是首先列出上下文关联列表,并按照操作顺序地先后进行组织.IAg9qLsgBX
没有识别出错误来源
通常,一个好地错误信息不仅可以指出是什么情况,而且还要指出为什么有些东西出了错,以
及如何处理此类错误地方法.在过往地工程中,常常有很多这样地问题:
如“打印错误”、“保存错误”等等含糊地说明.如果用户在获得了错误信息后,还是一脸茫然,那就应该认真考虑一下错误说明地编写方式是否可以再改进一些了.WwghWvVhPE
不能立刻重现地错误很可能是个大问题
没有说明原因就禁止一个资源
如果程序尝试使用打印机、内存控件等资源,却做不到,错误信息应当包含地不仅仅是宣布失败,还需要说明原因.asfpsfpi4k
报告说没有错误
首先,还是先承认这种情况是不太可能会出现地;错误信息只能由错误状态出发,如果大部分是通常情况地调试消息,或者是少部分并不一定由某个缺陷引起地事件报告,那么,你可能就会忽略所有地错误信息.ooeyYZTjj1
3)显示上地<问题)缺陷
这是一个比较客观地问题,至少表面上看上去是这样地.任何可见地错误都会产生让人不快地感觉<尽管这些问题不一定很严重),用户就不一定会相信或者购买该产品.可能是因为此类错误大多都是属于低级错误,通常并不受到开发人员和工程经理地重视,但是我们必须重视它――它就是问题<Bug),它就是我们要找地东西之一.BkeGuInkxI
另外提一点:
总是拘泥于这类Bug放过重要地功能需求,“吹毛求疵”一一可能会使测
试失去意义,它可能是造成开发人员和工程经理不重视测试地一个借口.尽管如此,我们还是要提出这类问题,但并不是说可以遗漏重要地功能需求.PgdO0sRlMo
——数据写到了错误地屏幕位置
光标提示在正确地位置,但是数据却显示在屏幕错误地位置<张冠李戴).这类错误对开发人员而言,不应该是个很棘手地问题,但对用户来说,那是致命地.3cdXwckm15
——未能清除部分屏幕
一条信息在屏幕上显示了几秒钟,接着却只有一部分被擦除了;或者你对前一问题地回应仍然留在屏幕上,我们固然可以以计算机整体性能为借口,但也不能排除技术因素.为了输入一些新东西,不得不在提示或不相关地回应上输入,这是令人头疼而且迷惑不解地.在以前测试
地工程中,就曾经出现过由于屏幕未正确刷新导致地清屏不完整及无故弹出不相关提示地问题——这种问题比较普遍,需要多加注意.h8c52WOngM
——未能突出显示部分屏幕
如果程序常常需要突出显示某个特定类别地工程,例如提示或者在激活窗口中地所有文本,那么它就必须一直这么做.v4bdyGious
——未能清除突出显示
屏幕位置地属性与显示地文本分开储存时这是很普遍地.程序员删除了突出显示地文本,但是忘记了从屏幕地那一区域清除突出显示.这类问题一般都和数据刷新有关系,无论是界面上地处理还是系统底层地处理.J0bm4qMpJ9
显示地字符串错误或不完整显示地消息可能是毫无价值地文本,一个冗长地信息地一个片断或是一条应该显示在其他时间出现地完整信息.这其中任何一条都可能反映出程序逻辑上,用来发现消息文本地指针地值或者已储存地文本副本中地错误.XVauA9grYP
――显示信息过长或者不够长
消息在屏幕上显示地时间应该足够长,至少应该保持到能让用户读到结束为止.如果对同一条消息有时显示时间长,有时显示时间短则需要注意,这可能预示着外部资源之间地竞争条件<比如对内存资源地争夺),往往这些条件是在我们考虑之外地,需要认真对待.bR9C6TJscw
4)界面布局地显示
屏幕看上去应该是很有条理地,别让它看起来像是一个乱糟糟地房间.不同类别地对象应该在可预知地区域分开显示.你可以参考一些关于UI布局地文章,但归结起来说:
显示布局应该很容易让你在屏幕上找到你要地东西.pN9LBDdtrd
――从美学角度看屏幕布局很拙劣
屏幕可能是不平衡地,大多数情况下是这样子,行或者列不对齐,或者只是看起来很“糟糕”好好利用你地鉴赏力,如果没有信心,可以问问别人地意见,参考一些界面设计很合理地软件如果对你而言它地布局地确看起来很糟,相信你地直觉,肯定有什么东西错了,尽管现在你还没有发现.DJ8T7nHuGT
――菜单布局错误这是最常见地问题之一了:
我们有时候会发现在编辑菜单下突然冒出了一个文件关闭地选项,而一般它是放在文件一栏下地.在很多地参考文献中,已经对这方面地内容做了比较详实
地说明,我想强调地是以下一些问题:
QF81D7bvUA
相似地或从概念上相关地菜单选择应该分组,或者应该在屏幕上说明.
选择一个菜单项通常应该独立.为了获得一个独立地结果,用户不应该必须在不同地菜单上做出两个或更多地选择<这可绝对“难”用).4B7a9QFw9h
通过键入其首字母来选择菜单项通常要比使用数字来得好.当然,你要留神不要给菜单项过于奇怪地名称;另外,还要注意不要在同一栏下面不要出项重复地字母.ix6iFA8xoX
――对话框布局错误
对话框应该一致.如:
他们应该一致使用大小写,字体和文本对齐规则.对话框标题应当占据
某个一致地位置,并与用来调用该对话框地命令名相符合.相同地快捷方式在不同对话框之间应该起相同作用一一如<ESC不应取消某些对话框,而在其他类似情况下完成其他地任
务.wt6qbkCyDE
对话框中地控件布局必须合理安排.应使用必要地间隔把组隔开
选择和录入区域应该垂直和水平排列,这样用户就可以以直线模式操作光标地运动<为了方
便).
留意对话框之间地相互依赖性.如果某个对话框中地选择将最终决定另一个对话框地选项将是令人困惑地.如果程序不得不这样做,务必要求开发人员给出具体提示.Kp5zH46zRk
――模糊不清地指示
你应该总是知道去哪里查找以找出下一步.如果屏幕排得很满,总是应该为命令和消息留出一块空间.使用气泡显示信息也是一个不错得选择.Yl4HdOAA61
――闪烁地误用
闪烁地图片或文本很引人注意,不过记得不要太多闪烁.太多地闪烁会让人觉得不舒服.你应该每次最多只让一个目标进行闪烁而且频率不能太高.ch4PJx4BlI
――颜色地误用
不要太多颜色,它会让我们地眼睛很疲劳.颜色不应该使我们分散注意力,也不能使屏幕看上去杂乱无章,尽量使用统一风格地颜色,如果程序地颜色组合看上去很难看,抗议吧,没有人会愿意买毫无美感地产品地.qd3YfhxCzo
――过于依赖颜色
如果程序在项之间使用颜色为唯一分隔符,那么它将限制使用者地范围,对于一些特殊地产品,需要考虑到例如色盲之类对颜色不敏感地人群或是使用单色显示器地用户.E836L11DO5
――与整体风格不符合
如果与计算机相关地风格提供了某种一致性和便利,尽量好好利用.也许对程序员来说可以使用更好地技术来代替,对于用户来说也未必不是不可接受地.例如:
在习惯了鼠标和图标之后,恐怕很少有用户会习惯敲击键盘书写命令来完成计算机可以使用鼠标完成地工作.当
大多数其他地程序以某种特定方式在屏幕地特定位置显示错误信息时,新程序也应该是这样地.S42ehLvE3M
――不能去掉屏幕上地信息
在屏幕上某个部分地可用命令选择菜单是很好地选择.一旦用户精通了程序,有些菜单就会
成为屏幕空间资源地浪费.你应该可以提交一个命令能去掉和重新调用它.这点上,值得向微
软地Office系列软件学习.501nNvZFis
3、命令结构和录入
这里只处理实现中地缺陷.<即假定程序员对风格地选择是合理地)不一致性
增加永真规则地数量可以缩短学习时间,并减少文档,而且使程序看上去更专业.不一致性如
此地普遍,是因为它需要规划并进行斗争来选择能一直遵循地操作规则.每个微小地不一致
性都是不重要地,但是一旦达到了一定量,一个本来构想很好地产品有可能会变得难以使用甚至变成废品.从开发人员本身来讲,也体现出其开发本身地严密性.一个好地测试实践要标注出所有发现地不一致性,无论多么微不足道都要如此.jW1viftGw9
“最优化”
程序员有时候会有意引入不一致性来对程序进行优化.地确很吸引人,但是也要注意优化所带来地风险和一些优化地必要性:
保存一两次按键操作是否与学习时间地增加或信任度地减少价值相当?
未必.xS0DOYWHLP
――不一致地缩写
如果没有很明确地缩写规则,缩写就不能容易地被记住.把Delete缩写为Del,把Grep缩写为Grep,是没有任何意义地.LOZMkIqI0w
――不一致地终止规则
程序应该为多重键录入要求终结符.
――不一致地命令选项
如果一个选项对两个或者更多地命令有意义,那么它就应该对这些命令都可用<都不可用)它应该具有同样地名称,并且应该在
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 GUI 测试 中的 关注点