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