GUI测试中的关注点edit.doc

GUI测试中的关注点 Steven Wang Archonwang1981@ 【摘要】本文列数了软件黑盒测试过程中，在被测试软件中可能存在的常见软件问题。本文不会详细讨论基本的软件测试思想与常用技术，仅针对在软件黑盒测试过程中若干的问题作描述并提供个人的参考测试意见与防范意见，希冀可以为初学者提供些许帮助。 【关键词】软件测试，黑盒测试 引言――不能不说的二个问题 软件测试中的“二八”原则 80％左右的错误在进行用户测试之前已经被发现，而在剩余20％左右的错误中，存在80％左右的显性错误，剩余20％左右的错误是较难发现的隐性错误。这条原则源自经济学的二八法则（注）。所以，我并不认为自己从事了一项伟大的工作，但是必须承认做好了这项工作对于整个软件开发体系在用户心目中的意义巨大。 软件黑盒测试解决的问题 简单来说，黑盒测试所解决的问题主要在于以用户眼光验证软件的结果。白盒测试关注范围（控制结构），而黑盒测试更关注结果（即我们常说的所见即所得）。黑盒测试试图发现以下几类错误： 功能错误或遗漏 界面错误 数据结构或外部数据库访问错误 性能错误 初始化错误和终止错误 以下内容将会详细说明在软件黑盒测试中常见的各类错误。 正文――软件黑盒测试常见错误类型及说明 一、用户界面错误 软件是为了满足用户需求而诞生的产物，无论是操作系统、游戏软件还是其他类型的应用软件。黑盒测试的很大一部分工作集中在用户界面上，不需要深入研究其内在结构，而是“表面化”地使用软件，从输入输出的信息内容中寻找可能的错误和纰漏。总体上讲，用户对于软件的看法很大程度上依赖以下几点： 功能性（实现软件应具备的基本功能） 易用性（用户学习掌握该软件所耗费的时间及在具体业务流程上的简化） 执行速度（多数是启动速度，查询速度，刷新速度及响应时间等因素） 用户使用时产生错误的比率（在允许用户任意使用的情况下，越少越好） 用户满意度（这里指的是用户界面设计与功能设计的用户评价） 下面我们分开对该类型错误进行分析与描述。 1、功能性 如果出现了以下情况之一，可以认为程序可能存在功能性错误：程序可以完成的某些事进行得非常困难，笨拙（繁琐），令人迷惑甚至难以忍受。主要表现为以下几个方面： 1）过度功能性 将简单功能复杂化，这是设计上一个较常见的问题。尝试进行太多工作任务的系统将很难学习和掌握，而且容易忘记。它要求大量的文档（开发文档，帮助文档和屏幕）。如果功能模块间模块过于紧密，则发生关联错误的几率要提高不少。有时候，用户需要的只是简单功能，而不要让它过于膨胀成为一个“怪物”。 2）夸大的功能性印象 用户手册和营销传单不能使程序功能实现得更多，尤其是营销传单。记住，在用户手册中哪怕宁愿对功能略微轻描淡写也不能夸大其词（当然，我们并不希望这样，我们总是要对此如实地进行编写――这是我们的责任）。 3）对手头任务的不适当性 我们可以把它直观的理解为需求设计错误。对于任何一个项目，由于功能关键事项（就是常说的需求提炼）不存在、太有限（多数是因为没有完成）或者太慢（需要改进程序结构或是内部算法）而不能完成真正的工作。举例来说，查询一个有8000条记录的数据库需要1个小时（天哪，我想我连10分钟都等不了），虽然说具备了查询的功能，但是实在很令人怀疑此项功能是否会有人使用，更糟糕的情况是：由于用户使用了该功能而造成的恶劣印象难以在短时间内消除――虽然对于开发人员来说那可能只是一个参数拼写错误了而已。 4）遗漏功能 功能没有实现，却出现在了用户手册中。或者是本来应该具备地特征性功能，在程序只能看到一个“影子”（有其名无其实）。多半情况下是由于需求变更时没有对手册进行检查和更新，也有可能是因为遗漏了需求说明中应包含的功能（如果是那样，需要好好检查以前的工作方式是否正确）。 5）错误功能 一个本来应该完成查询工作的功能却干了排序的活儿。这种疏忽一般不是因为没有实现功能，而是在分配功能的时候出现了问题，当然这种情况的发现和排除应该不是一件困难的事。 6）功能性必须由用户创建 最常见的情况之一就是要求用户自己配置软环境（如配置数据源，一般都可以在安装程序中自动完成；当然还包括程序用到的组件在系统中不存在，安装程序没有提供相应的支持，这对用户是不能接受的）。这类问题不完全一定都是错误，比如微软提供的Office宏的开发，是为了满足客户对于自身特色而设计的适合其专业工作的程序。 7）不能做用户期望的工作 例如，极少有人会期望一个本来编写用来对姓名进行排序的程序却按照ASCII码的顺序排序。他们也不会指望用它来计算首位空格或区分大小写。当然用户名的排序还是要做的，问题是开发者需要重新构想一个新的排序规则来满足用户需求。 2、人机交互 人机交互，程序与操作者之间的通信与交流。这不是早些年的科幻电影，我们也许每天都在做，在