文档介绍：该【软件黑盒测试人机交互问题介绍 】是由【夏天教育】上传分享，文档一共【10】页，该文档可以免费在线阅读，需要了解更多关于【软件黑盒测试人机交互问题介绍 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。件黑盒之人机交互介
人机交互,程序与操作者之的通讯与交流。不是早些年的科幻影,我也每天都在做,在取款机前,在自售机前。
1)漏信息
你知道,全部的事都能从算机屏幕上获取有效的信息。不要漏任何于用而言至关重要的信息,即使些信息你而言毫无用。――没有任何屏幕指令
如何找到程序的名称?如何退出程序?你怎么取帮助?假如程序使用了某种命令言,如何才能获取命令列表?程序可能只在它启迪些内容。自然你也可以从帮助手册中取些信息,但其实不是必需的。没有任何屏幕指令的程序可能会人受不了,手册的需要花的可能会更,也可能就会用得件学起来太复了。――假设打印出的文件随可得
了用手册怎么?有的用不会非要依打印好的文档,供给一份子版的吧。
――无正式文字明(明)的功能特色
假如大多数的功能特色或命令在屏幕上供给文字明,那么全部的都这样。
略几个功能特色将会致UI形式上的凌乱。同,假如程序很多命令描述其“特别状况”下的行,那么全部的命令都需要供给明。种状况在国人的件开程中有生,其实不是不可以,而是不想⋯⋯――看起来不行能退出的状
如何撤消一条命令或在一个深菜中行份?程序允你可以防备那些你不希望遇到的状况。比方,在件安装,要求插入磁,假如不插入
正确磁盘就不可以退出安装程序。没有告诉你如何防备就和发生灾害时,没有提
供一条逃活路径相同糟糕。
――没有光标
大多数用户都依赖于光标。一个光标可以让用户感觉计算机依旧在正常运行(尽管有时死机也是这样),每个交互程序都应该显示光标,自然,在关闭光标时别忘了提示用户注意。
――没有对输入做出响应
每个程序都应该对输入做出回应。假如没有,呵呵,保存80%以上的用户产生疑问:怎么没有响应?还要等多久?能否是我的电脑过时了?假如有以下几种状况,一般视为正常:
选择一个菜单项时,假如你的按键操作没有回应,只要下一个屏幕马上出现并且此屏幕上的标题与菜单项相同,就可以视为正常。
假如程序忽视错误的命令或按键操作,自然可以不对其进行回应。
假如你告诉程序不要对输入回应,它一定缄默,假如它进行了回应,应该马上告诉开发人员对其进行改正(可能是在忘掉了连续办理另一种状况)。
假如输入的是安全性代码(如密码等),那么程序决不该在屏幕上做出不适合的回应(如显示你输入的密码明文)。――在长远延缓时没有表示其活动
给一段较长时间的程序延缓一个适合的响应,将是特别必需的行为。相信这样
不需要再给用户做出过多的解说了。
――当某个改变马上奏效时没有给出建议
一个程序可能会比你估计的更早或更晚执行一个命令,比方:删除某些重要数据时,(而这个过程将连续一段时间),必需的提示是一定的。
――没有对已经打开的文件进行检查
这个错误是非常常有的,特别关于那些输入要点数据的程序而言。用户可能不会注意,但是在今后的工作中将发现稍微的一丝改正就会引出大批的问题。你不可以保证程序会对同一个文件在某个时刻做出不一样改正所带来的结果。因此,决不一样意同一文件同时被打开两次甚至更多,以保证程序输出的独一性。――错误的、误导的或令人迷惑的信息
每个错误都会让你对程序显示的全部其余东西产生思疑。使用户做出虚假归纳的渺小错误,如遗漏条件或是不适合的类比会比清楚的事实错误更让测试人员感觉恼火――因为更难对它们进行改正。简单的事实错误
在一个程序改变以后,更新屏幕显示是低优先级任务,结果则是:屏幕上大批的信息过时。记住:无论何时程序发生改变,都要仔细检查可能指示程序特色的每个信息,最简单的方法就是直接对改正后的屏幕进行刷新。拼写错误(错别字)
我相信,这绝对不是设计上的问题,我也相信开发人员可能会不认为然。Oh,但是客户会在意,会诉苦这些的--还是改正它们吧。不正确的简化
在保持一个特色的描述尽可能简单的梦想中,一条信息的创作者可能只覆盖特色行为的最简一方面,而忽视了重要条件。举例来说,这种状况可能会引起歧义,比方说关闭(究竟是关闭文件还是关闭程序?)。作为一个测试人员,需要你足够仔细的研究可能会出现问题的任何一个不足挂齿的细节。情愿错杀,不可以放过!(固然要全力防备错杀的状况。)
无效的比喻(图标之类可以指示功能(特色)的事物)
比方:回收站的图标可能不是一个好的比喻;关于文件一旦移除就永久消逝的状况来说,碎纸机的图标可能来得更好一些。令人百思不解的特色(功能)名称
假如一个命令名称在计算机领域中或语言中有一个标准含义,就一定与其含义一致。别盼望着胳膊能拧得过大腿,确立现行的标准是靠谱的。同一特色(功能)拥有多个名称
相同的功能特色只要一个名称就够了――只要能表述清楚;用户可不必定有时间玩同义词的游戏。别的,这种状况对软件在用户眼前显示的复杂度也有影响。信息超载
不要让你的文档和帮助屏幕看起来太甚专业――太多技术细节了。用户会不耐
烦的,何况成效也不好。假如实在需要,可以把他们别的列出。尽量使用直白,用户能理解的话表述这些信息。别的,信息超载的另一个意义意味着烦杂冗长的语句,那是要全力防备的。
数据何时获取保存
假设你输入了一些程序需要保存的信息。当你进行切换或程序退出时,当你需要每隔一段时间进行保存时,它能否会把数据依据你想的方式进行保存呢?何时完成呢?假如你对答案感觉疑惑,那就意味着可能有问题出现了。以前在同事的项目中发现过很多次这样的状况:每次改正后直接关闭程序,却不提示用
户保存――我只知道,改正信息在关闭时也消逝了。在对某个模块进行改正时,
你应亲近注意这个问题。
很差的外面模块性
外面模块性指的是程序从外面看起来产品的模块化程度(仿佛程序是可切割的实体)。你如何简单地理解模块组件?很差的外面模块会耗费大批的时间来学<br****产品,还会吓跑新用户--它看上去太复杂了!尽可能让信息独立展现出来,
对任何特定任务而言,你需要知道的越少越好。
2)帮助文本和错误信息
帮助文本和错误信息平时被认为是产品的次要部分。它们可能是由初级程序员编写的(比方我)或是作者编写,对其进行更新的工作可能被给予低优先级。但是,作为产品而言,这又是必不行少的部分,一份看上去神清气爽的帮助文档可以“主观”的降低软件的学****难度和用户的使用兴趣。
当你感觉疑惑或是有麻烦时,追求帮助或偏向于使用错误办理程序将是一个明
智的选择。你可能会感觉不爽,更多的时候是不耐烦。而假如此中有信息误导
了你,那么无异于火上加油。以以下出的是我过去在审查帮助文档及错误信息
时遇到的一些常有问题。
不适合的阅读层次
在计算机终端上,人们不可以很好的进行阅读。帮助文本和错误信息应该尽量措
辞简单了然,多用主动语态,尽量少使用技术术语,即使用户中有计算机经验
也是这样。
冗长
防备你的帮助文档和错误信息变为裹脚布。大多数用户在需要更多信息时,会选择经过菜单获取进一步的信息。最好让他们自己选择所需的信息。不适合的情绪语气
尽量不要使用惋惜号,如“停止”、“崩溃”之类的带有激烈意味的词语都应
这样。
事实错误
记得测试时需要测试那些更新过的功能,在旧的帮助上的方法可能在新软件中
是行不通的。这个时候开发人员的代码更新日记就显得很必需了,你不用对每
项功能进行检查,完好可以把这种回归测试交给自动化测试工具完成,而你只
需要关注其新内容即可。
上下文错误
不要把上下文之间的关系搞错了,这会带来阅读时的不便。比较清楚的方法是第一列出上下文关系列表,并依据操作序次的先后进行组织。没有鉴别出错误本源
平时,一个好的错误信息不但可以指出是什么状况,并且还要指出为何有些东西出了错,以及如何办理此类错误的方法。在过往的项目中,常常有很多这样的问题:如“打印错误”、“保存错误”等等含糊的说明。假如用户在获取了错误信息后,还是一脸茫然,那就应该仔细考虑一下错误说明的编写方式能否可以再改进一些了。
不可以马上重现的错误很可能是个大问题
没有说明原由就严禁一个资源
假如程序试试使用打印机、内存控件等资源,却做不到,错误信息应该包括的不不过是宣告失败,还需要说明原由。报告说没有错误
第一,还是先认可这种状况是不太可能会出现的;错误信息只好由错误状态出发,假如大多数是平时状况的调试信息,也许是少部分其实不必定由某个缺点引起的事件报告,那么,你可能就会忽视全部的错误信息。
3)显示上的(问题)缺点
这是一个比较客观的问题,最少表面上看上去是这样的。任何可见的错误都会
产生让人不快的感觉(尽管这些问题不必定很严重),用户就不必定会相信或
者购买该产品。可能是因为此类错误大多都是属于初级错误,平时其实不遇到开
发人员和项目经理的重视,但是我们一定重视它――它就是问题(Bug),它就是我们要找的东西之一。
别的提一点:总是拘泥于这种Bug――放过重要的功能需求,“吹毛求疵”――可能会使测试失掉意义,它可能是造成开发人员和项目经理不重视测试的一个
借口。尽管这样,我们还是要提出这种问题,但其实不是说可以遗漏重要的功能
需求。
――数据写到了错误的屏幕地址
光标提示在正确的地址,但是数据却显示在屏幕错误的地址(张冠李戴)。这
类错误对开发人员而言,不该该是个很棘手的问题,但对用户来说,那是致命
的。
――未能除去部分屏幕
一条信息在屏幕上显示了几秒钟,接着却只有一部分被擦除了;也许你对前一
问题的回应依旧留在屏幕上,我们诚然可以以计算机整体性能为借口,但也不
能除去技术要素。为了输入一些新东西,不得不在提示或不相关的回应上输入,
这是令人头疼并且百思不解的。在以前测试的项目中,就以前出现过因为屏幕
未正确刷新以致的清屏不完好及无故弹出不相关提示的问题――这种问题比较
广泛,需要多加注意。
――未能突出显示部分屏幕
假如程序常常需要突出显示某个特定类其余项目,比方提示也许在激活窗口中的全部文本,那么它就一定向来这么做。――未能除去突出显示
屏幕地址的属性与显示的文安分开储蓄时这是很广泛的。程序员删除了突出显
示的文本,但是忘掉了从屏幕的那一地域除去突出显示。这种问题一般都和数据刷新相关系,无论是界面上的办理还是系统基层的办理。――显示的字符串错误或不完好
显示的信息可能是毫无价值的文本,一个冗长的信息的一个片断或是一条应该显示在其余时间出现的完好信息。这此中任何一条都可能反响出程序逻辑上,用来发现信息文本的指针的值也许已储蓄的文本副本中的错误。――显示信息过长也许不够长
信息在屏幕上显示的时间应该足够长,最少应该保持到能让用户读到结束为止。假如对同一条信息有时显示时间长,有时显示时间短则需要注意,这可能预示着外面资源之间的竞争条件(比方对内存资源的抢夺),常常这些条件是在我们考虑以外的,需要仔细对待。
4)界面布局的显示
屏幕看上去应该是很有条理的,别让它看起来像是一个乱糟糟的房间。不一样类
其余对象应该在可预知的地域分开显示。你可以参照一些关于UI布局的文章,
但归纳起来说:显示布局应该很简单让你在屏幕上找到你要的东西。
――从美学角度看屏幕布局很拙劣
屏幕可能是不均衡的,大多数状况下是这样子,行也许列不对齐,也许不过看
起来很“糟糕”。好好利用你的鉴赏力,假如没有信心,可以问问他人的建议,
参照一些界面设计很合理的软件。假如对你而言它的布局的确看起来很糟,相
信你的直觉,必定有什么东西错了,尽管此刻你还没有发现。
――菜单布局错误
这是最常有的问题之一了:我们有时会发此刻编写菜单下忽然冒出了一个文
件关闭的选项,而一般它是放在文件一栏下的。在很多的参照文件中,已经对
这方面的内容做了比较详确的说明,我想重申的是以下一些问题:
相似的或从看法上相关的菜单项选择择应该分组,也许应该在屏幕上说明。
选择一个菜单项平时应该独立。为了获取一个独立的结果,用户不该该一定在不一样的菜单上做出两个或更多的选择(这可绝对“难”用)。
经过键入其首字母来选择菜单项平时要比使用数字来得好。自然,你要留意不
要给菜单项过于奇异的名称;别的,还要注意不要在同一栏下边不要出项重复
的字母。
――对话框布局错误
对话框应该一致。如:他们应该一以致用大小写,字体和文本对齐规则。对话框标题应该据有某个一致的地址,并与用来调用该对话框的命令名相吻合。相
同的快捷方式在不一样对话框之间应该起相同作用――如<ESC>不该撤消某些对话框,而在其余近似状况下完成其余的任务。
对话框中的控件布局一定合理安排。应使用必需的间隔把组分开。
选择和录入地域应该垂直和水平摆列,这样用户就可以以直线模式操作光标的运动(为了方便)。
留意对话框之间的互相依赖性。假如某个对话框中的选择将最后决定另一个对
话框的选项将是令人疑惑的。假如程序不得不这样做,务必需求开发人员给出
详尽提示。
――模糊不清的指示
你应该总是知道去哪里查找以找出下一步。假如屏幕排得很满,总是应该为命令和信息留出一块空间。使用气泡显示信息也是一个不错得选择。――闪耀的误用
闪耀的图片或文本很引人注意,但是记得不要太多闪耀。太多的闪耀会让人觉
得不舒畅。你应该每次最多只让一个目标进行闪耀并且频率不可以太高。――颜色的误用
不要太多颜色,它会让我们的眼睛很疲惫。颜色不该该使我们分别注意力,也不可以使屏幕看上去纷乱无章,尽量使用一致风格的颜色,假如程序的颜色组合看上去很难看,抗议吧,没有人会愿意买毫无美感的产品的。――过于依赖颜色
假如程序在项之间使用颜色为独一分开符,那么它将限制使用者的范围,关于
一些特别的产品,需要考虑到比方色盲之类对颜色不敏感的人群或是使用单色
显示器的用户。
――与整体风格不吻合
假如与计算机相关的风格供给了某种一致性和便利,尽量好好利用。也许对程序员来说可以使用更好的技术来取代,关于用户来说也未必不是不行接受的。比方:在****惯了鼠标和图标以后,生怕极少实用户会****惯敲击键盘书写命令来完成计算机可以使用鼠标完成的工作。当大多数其余的程序以某种特定方式在屏幕的特定地址显示错误信息时,新程序也应该是这样的。――不可以去掉屏幕上的信息
在屏幕上某个部分的可用命令选择菜单是很好的选择。一旦用户精晓了程序,有些菜单就会成为屏幕空间资源的浪费。你应该可以提交一个命令能去掉和重新调用它。这点上,值得向微软的Office系列软件学****