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