黑盒测试常见错误类型及说明.doc

黑盒测试心得与经验[Written By Steven Wang, 2004-08-30] PAGE 1 - 软件黑盒测试心得与经验 Written by Steven Wang Version 1.00 HYPERLINK /index.php?blogId=6 我的博客 版本更新历史 1.00版本 创建最初版本――由正文，版本历史与封面构成，主要描述了在软件黑盒测试过程中可能会发生的问题及防范建议。此文档对大多数软件的黑盒测试工作适用，但不适用于软件项目的测试管理及其他类型的测试方法，仅适用于黑盒测试； 目前正在筹划对此版本的部分内容进行更新与增补；此文档对应的《白盒测试方法与实践》的初版正在进行资料整理与筹备工作。 黑盒测试常见错误类型及说明 用户界面错误 功能性 易用性（用户学习使用程序的时间和记住怎样使用程序的时间） 执行速度（多数是启动速度，查询速度，刷新速度及响应速度等） 用户使用时产生错误的比率（在允许用户任意使用的情况下，越低越好） 用户满意度（很大程度上决定UI设计及功能设计的好坏） 功能性 如果出现了以下情况之一，认为程序可能存在功能性错误： 程序可以完成的某些事进行得非常困难，笨拙（繁琐），令人迷惑甚至难以忍受。 主要表现为以下几个方面： 过度功能性 将简单功能复杂化，这是设计上一个较常见的问题。尝试进行太多工作任务的系统将很难学习和掌握，而且容易忘记。它要求大量的文档（开发文档，帮助文档和屏幕）。性能相对可能会好些，但是复杂化所花费的时间相对于性能（功能）提高不值得；而且，若功能模块间模块紧密，则发生关联错误的几率要提高不少。 夸大的功能性印象 用户手册和营销传单不能使程序功能实现得更多。记住，在用户手册中哪怕宁愿对功能略微轻描淡写也不能夸大其词（当然，我们并不希望这样，我们总是要如实地记录）。 对手头任务的不适当性 由于功能关键事项不存在、太有限（多数是因为没有完成）或者太慢（需要改进程序结构或是内部算法）而不能完成真正的工作。举例来说，查询一个有8000条记录的数据库需要1个小时（天哪，我想我连10分钟都等不了），虽然说具备了查询的功能，但是实在很怀疑此项功能是否会有人使用。 遗漏功能 功能没有实现，却出现在了用户手册中。或者是本来应该具备地特征性功能，在程序只能看到一个“影子”（有其名无其实）。多半情况下是由于需求变更时没有对手册进行检查和更新，也有是因为遗漏了需求说明中应包含的功能。 错误功能 一个本来应该完成查询工作的功能却干了排序的活儿。这种疏忽一般不是因为没有实现功能，而是在分配功能的时候出现了问题。 功能性必须由用户创建 最常见的情况之一就是要求用户自己配置软环境（如配置数据源，一般都可以在程序中自动完成；当然还包括程序用到的组件在系统中不存在，用户还需要自己购买，这对用户是不能接受的）。 不能做用户期望的工作 例如，极少有人会期望一个本来编写用来对姓名进行排序的程序却按照ASCII码的顺序排序。他们也不会指望用它来计算首位空格或区分大小写。当然用户名的排序还是要做的，问题是开发者需要重新构想一个新的排序规则来满足用户需求。 人机交互 人机交互，程序与操作者之间的通信与交流。这不是科幻电影，我们也许每天都要做，在取款机前，在自动售卖机前―― 遗漏信息 你应该知道，所有的事都能从计算机屏幕上得到有效的消息。 没有任何屏幕指令 如何找到程序的名称？如何退出程序？你应该怎么样获取帮助？如果程序使用了某种命令语言，如何才能得到命令列表？程序可能仅仅只在它启动时显示这些内容。当然你也可以从帮助手册中获取这些信息，但并不是必要的。没有任何屏幕指令的程序可能会让人受不了，查询手册的话需要花费的时间可能会更长——这可能就会让用户觉得软件学习起来太复杂了。 假定打印出的文件随时可得 丢了用户手册怎么办？有经验的用户不会非要依赖打印好的文档，提供一份电子版的吧。 无正式文件证明（说明）的功能特征 如果大多数的功能特征或命令在屏幕上提供文件说明，那么所有的都应如此。仅略过几个功能特征将会导致混乱。同样，如果程序为很多命令描述其“特殊情况”下的行为，那么所有的命令都需要提供这类说明。 看起来不可能退出的状态 如何取消一条命令或在一个深层菜单树中进行备份？程序应该允许你可以避免那些你不希望遇到的情况。比如，在软件安装时，要求插入磁盘，如果不插入正确磁盘就不能退出安装程序。没有告诉你如何避免就和没有提供一条逃逸路径一样糟糕。 没有光标 大多数用户都依赖与光标。一个光标可以让用户觉得计算机仍然在正常运转（尽管有时候死机也是如此），每个交互程序都应该显示光标，当然，在关闭光标时别忘了告诉用户。 没有对输入做出响应 每个程序都应该对输入做出回应。如果没有，呵呵，保管80％以上的用户会对软件产生怀疑：怎么没有响应