《软件GUI测试中的关注点.doc》由会员分享，可在线阅读，更多相关《软件GUI测试中的关注点.doc（24页珍藏版）》请在金锄头文库上搜索。
1、软件GUI测试中的关注点文章出处： 作者：Steven Wang 发布时间：2005-10-19【摘要】 本文列数了软件黑盒测试过程中，在被测试软件中可能存在的常见软件问题。本文不会详细讨论基本的软件测试思想与常用技术，仅针对在软件黑盒测试过程中若干的问题做描述，并提供个人的参考测试意见与防范意见，希望可以为初学者提供些许帮助。【关键词】 软件测试，黑盒测试【引言】不能不说的二个问题 软件测试中的“二八”原则 80左右的错误在进行用户测试之前已经被发现，而在剩余20左右的错误中，存在80左右的显性错误，剩余20左右的错误是较难发现的隐性错误。这条原则源自经济学的80-20原理。所以，我并不认为
2、自己从事了一项伟大的工作，但是必须承认做好了这项工作对于整个软件开发体系在用户心目中的意义巨大。 软件黑盒测试解决的问题 简单来说，黑盒测试所解决的问题主要在于以用户眼光验证软件的结果。白盒测试关注范围（控制结构），而黑盒测试更关注结果（即我们常说的所见即所得）。黑盒测试试图发现以下几类错误： 功能错误或遗漏 界面错误 数据结构或外部数据库访问错误 性能错误 初始化错误和终止错误 以下内容将会详细说明在软件黑盒测试中常见的各类错误。【正文】软件黑盒测试常见错误类型及说明 用户界面错误 软件是为了满足用户需求而诞生的产物，无论是操作系统、游戏软件还是其他类型的应用软件。黑盒测试的很大一部分工作集
3、中在用户界面上，不需要深入研究其内在结构，而是“表面化”地使用软件，从输入输出的信息内容中寻找可能的错误和纰漏。总体上讲，用户对于软件的看法很大程度上依赖以下几点： 功能性（实现软件应具备的基本功能） 易用性（用户学习掌握该软件所耗费的时间及在具体业务流程上的简化） 执行速度（多数是启动速度，查询速度，刷新速度及响应时间等因素） 用户使用时产生错误的比率（在允许用户任意使用的情况下，越少越好） 用户满意度（这里指的是用户界面设计与功能设计的用户评价） 下面我们分开对该类型错误进行分析与描述。 功能性 如果出现了以下情况之一，可以认为程序可能存在功能性错误：程序可以完成的某些事进行得非常困难，笨
4、拙（繁琐），令人迷惑甚至难以忍受。主要表现为以下几个方面：1）过度功能性将简单功能复杂化，这是设计上一个较常见的问题。尝试进行太多工作任务的系统将很难学习和掌握，而且容易忘记。它要求大量的文档（开发文档，帮助文档和屏幕）。如果功能模块间模块过于紧密，则发生关联错误的几率要提高不少。有时候，用户需要的只是简单功能，而不要让它过于膨胀成为一个“怪物”。2）夸大的功能性印象用户手册和营销传单不能使程序功能实现得更多，尤其是营销传单。记住，在用户手册中哪怕宁愿对功能略微轻描淡写也不能夸大其词（当然，我们并不希望这样，我们总是要对此如实地进行编写这是我们的责任）。3）对手头任务的不适当性我们可以把它直观
5、的理解为需求设计错误。对于任何一个项目，由于功能关键事项（就是常说的需求提炼）不存在、太有限（多数是因为没有完成）或者太慢（需要改进程序结构或是内部算法）而不能完成真正的工作。举例来说，查询一个有8000条记录的数据库需要1个小时（天哪，我想我连10分钟都等不了），虽然说具备了查询的功能，但是实在很令人怀疑此项功能是否会有人使用，更糟糕的情况是：由于用户使用了该功能而造成的恶劣印象难以在短时间内消除虽然对于开发人员来说那可能只是一个参数拼写错误了而已。4）遗漏功能功能没有实现，却出现在了用户手册中。或者是本来应该具备地特征性功能，在程序只能看到一个“影子”（有其名无其实）。多半情况下是由于需求
6、变更时没有对手册进行检查和更新，也有可能是因为遗漏了需求说明中应包含的功能（如果是那样，需要好好检查以前的工作方式是否正确）。5）错误功能一个本来应该完成查询工作的功能却干了排序的活儿。这种疏忽一般不是因为没有实现功能，而是在分配功能的时候出现了问题，当然这种情况的发现和排除应该不是一件困难的事。6）功能性必须由用户创建最常见的情况之一就是要求用户自己配置软环境（如配置数据源，一般都可以在安装程序中自动完成；当然还包括程序用到的组件在系统中不存在，安装程序没有提供相应的支持，这对用户是不能接受的）。这类问题不完全一定都是错误，比如微软提供的Office宏的开发，是为了满足客户对于自身特色而设计
7、的适合其专业工作的程序。7）不能做用户期望的工作例如，极少有人会期望一个本来编写用来对姓名进行排序的程序却按照ASCII码的顺序排序。他们也不会指望用它来计算首位空格或区分大小写。当然用户名的排序还是要做的，问题是开发者需要重新构想一个新的排序规则来满足用户需求。 人机交互 人机交互，程序与操作者之间的通信与交流。这不是早些年的科幻电影，我们也许每天都在做，在取款机前，在自动售卖机前。1）遗漏信息你应该知道，所有的事都能从计算机屏幕上得到有效的消息。不要遗漏任何对于用户而言至关重要的信息，即使这些信息对你而言毫无用处。没有任何屏幕指令如何找到程序的名称？如何退出程序？你应该怎么样获取帮助？如果
8、程序使用了某种命令语言，如何才能得到命令列表？程序可能仅仅只在它启动时显示这些内容。当然你也可以从帮助手册中获取这些信息，但并不是必要的。没有任何屏幕指令的程序可能会让人受不了，查询手册的话需要花费的时间可能会更长，也可能就会让用户觉得软件学习起来太复杂了。假定打印出的文件随时可得丢了用户手册怎么办？有经验的用户不会非要依赖打印好的文档，提供一份电子版的吧。无正式文字证明（说明）的功能特征如果大多数的功能特征或命令在屏幕上提供文字说明，那么所有的都应如此。仅略过几个功能特征将会导致UI形式上的混乱。同样，如果程序为很多命令描述其“特殊情况”下的行为，那么所有的命令都需要提供这类说明。这种情况在
9、国人的软件开发过程中时有发生，并不是不能，而是不想看起来不可能退出的状态如何取消一条命令或在一个深层菜单树中进行备份？程序应该允许你可以避免那些你不希望遇到的情况。比如，在软件安装时，要求插入磁盘，如果不插入正确磁盘就不能退出安装程序。没有告诉你如何避免就和发生灾难时，没有提供一条逃生路径一样糟糕。没有光标大多数用户都依赖于光标。一个光标可以让用户觉得计算机仍然在正常运转（尽管有时候死机也是如此），每个交互程序都应该显示光标，当然，在关闭光标时别忘了提醒用户注意。没有对输入做出响应每个程序都应该对输入做出回应。如果没有，呵呵，保管80以上的用户产生疑问：怎么没有响应？还要等多久？是不是我的电脑
10、过时了？如果有以下几种情况，一般视为正常： o 选择一个菜单项时，如果你的按键操作没有回应，只要下一个屏幕立刻出现并且此屏幕上的标题与菜单项一样，就可以视为正常。 o 如果程序忽视错误的命令或按键操作，当然可以不对其进行回应。 o 如果你告诉程序不要对输入回应，它必须沉默，如果它进行了回应，应该立即告诉开发人员对其进行修改（可能是在忘记了继续处理另一种情况）。 o 如果输入的是安全性代码（如密码等），那么程序决不应在屏幕上做出不恰当的回应（如显示你输入的密码明文）。 在长期延迟时没有表示其活动给一段较长时间的程序延迟一个合适的响应，将是非常必要的举动。相信这样不需要再给用户做出过多的解释了。当
11、某个改变即将生效时没有给出建议一个程序可能会比你预计的更早或更晚执行一个命令，例如：删除某些重要数据时，（而这个过程将持续一段时间），必要的提示是必须的。没有对已经打开的文件进行检查这个错误是非常常见的，尤其对于那些输入关键数据的程序而言。用户可能不会注意，但是在以后的工作中将发现略微的一丝更改就会引出大量的问题。你不能保证程序会对同一个文件在某个时刻做出不同修改所带来的后果。所以，决不允许同一文件同时被打开两次甚至更多，以确保程序输出的唯一性。错误的、误导的或令人迷惑的信息每个错误都会让你对程序显示的所有其他东西产生怀疑。使用户做出虚假归纳的细小错误，如遗漏条件或是不适宜的类比会比清楚的事实
12、错误更让测试人员感到恼火因为更难对它们进行改正。 简单的事实错误 在一个程序改变之后，更新屏幕显示是低优先级任务，结果则是：屏幕上大量的信息过时。记住：无论何时程序发生改变，都要仔细检查可能指示程序特征的每个消息，最简单的办法就是直接对更改后的屏幕进行刷新。 拼写错误（错别字） 我相信，这绝对不是设计上的问题，我也相信开发人员可能会不以为然。Oh，但是客户会在乎，会抱怨这些的-还是改正它们吧。 不准确的简化 在保持一个特征的描述尽可能简单的愿望中，一条消息的创作者可能只覆盖特征行为的最简单方面，而忽略了重要条件。举例来说，这种情况可能会引发歧义，比如说关闭（到底是关闭文件还是关闭程序？）。作为
13、一个测试人员，需要你足够仔细的研究可能会出现问题的任何一个微不足道的细节。宁可错杀，不能放过！（虽然要极力避免错杀的情况。） 无效的比喻（图标之类可以指示功能（特征）的事物） 例如：回收站的图标可能不是一个好的比喻；对于文件一旦移除就永久消失的情况来说，碎纸机的图标可能来得更好一些。 令人迷惑不解的特征（功能）名称 如果一个命令名称在计算机领域中或语言中有一个标准含义，就必须与其含义一致。别指望着胳膊能拧得过大腿，确定现行的标准是可靠的。 同一特征（功能）具有多个名称 相同的功能特征只要一个名称就够了只要能表述清楚；用户可不一定有时间玩同义词的游戏。另外，这种情况对软件在用户面前显示的复杂度也
14、有影响。 信息超载 不要让你的文档和帮助屏幕看起来太过专业太多技术细节了。用户会不耐烦的，况且效果也不好。如果实在需要，可以把他们另外列出。尽量使用直白，用户能理解的话表述这些信息。另外，信息超载的另一个意义意味着烦琐冗长的语句，那是要极力避免的。 数据何时得到保存 假设你输入了一些程序需要保存的信息。当你进行切换或程序退出时，当你需要每隔一段时间进行保存时，它是否会把数据按照你想的方式进行保存呢？何时完成呢？如果你对答案感到困惑，那就意味着可能有问题出现了。曾经在同事的项目中发现过很多次这样的情况：每次修改后直接关闭程序，却不提示用户保存我只知道，修改信息在关闭时也消失了。在对某个模块进行修
15、改时，你应密切注意这个问题。 很差的外部模块性 外部模块性指的是程序从外部看起来产品的模块化程度（如同程序是可分割的实体）。你如何容易地理解模块组件？很差的外部模块会耗费大量的时间来学习产品，还会吓跑新用户-它看上去太复杂了！尽可能让信息独立展示出来，对任何特定任务而言，你需要知道的越少越好。2）帮助文本和错误信息帮助文本和错误信息通常被认为是产品的次要部分。它们可能是由初级程序员编写的（比如我）或是作者编写，对其进行更新的工作可能被赋予低优先级。然而，作为产品而言，这又是必不可少的部分，一份看上去赏心悦目的帮助文档可以“主观”的降低软件的学习难度和用户的使用兴趣。当你感到困惑或是有麻烦时，寻求帮助或倾向于使用错误处理程序将是一个明智的选择。你可能会觉得不爽，更多的时候是不耐烦。而如果其中有信息误导了你，那么无异于火上浇油。以下列出的是我以往在审核帮助文档及错误信息时碰到的一些常见问题。 不合适的阅读层次 在计算机终端上，人们不能很好的进行阅读。帮助文本和错误信息应该尽量措辞简单明了，多用主动语态，尽量少使用技术术语，即便用户中有计算机经验也是如此。 冗长 避免你的帮助文档和错误信息变成裹脚布
