目录
1、用户界面错误
2、遗漏信息
3、错误的、误导的或令人迷惑的信息
1、用户界面错误
功能性
易用性（用户学习使用程序的时间和记住怎样使用程序的时间）
执行速度（多数是启动速度，查询速度，刷新速度及响应速度等）
用户使用时产生错误的比率（在允许用户任意使用的情况下，越低越好）
用户满意度（很大程度上决定UI设计及功能设计的好坏）
功能性
如果出现了以下情况之一，认为程序可能存在功能性错误：
程序可以完成的某些事进行得非常困难，笨拙（繁琐），令人迷惑甚至难以忍受。
主要表现为以下几个方面：
过度功能性
将简单功能复杂化，这是设计上一个比较常见的问题。尝试进行太多工作任务的系统将很难学习和掌握，而且容易忘记。它要求大量的文档（开发文档，帮助文档和屏幕）。性能相对可能会好些，但是复杂化所花费的时间相对于性能（功能）提高不值得；而且，若功能模块间模块紧密，则发生关联错误的几率要提高不少。
夸大的功能性印象
用户手册和营销传单不能使程序功能实现得更多。记住，在用户手册中哪怕宁愿对功能略微轻描淡写也不能夸大其词（当然，我们并不希望这样，我们总是要如实地记录）。
对手头任务的不适当性
由于功能关键事项不存在、太有限（多数是因为没有完成）或者太慢（需要改进程序结构或是内部算法）而不能完成真正的工作。举例来说，查询一个有8000条记录的数据库需要1个小时（天哪，我想我连10分钟都等不了），虽然说具备了查询的功能，但是实在很怀疑此项功能是否会有人使用。
遗漏功能
功能没有实现，却出现在了用户手册中。或者是本来应该具备的特征性功能，在程序只能看到一个“影子”（有其名无其实）。多半情况下是由于需求变更时没有对手册进行检查和更新，也有些是因为遗漏了需求说明中应包含的功能。
错误功能
一个本来应该完成查询工作的功能却干了排序的活儿。这种疏忽一般不是因为没有实现功能，而是在分配功能的时候出现了问题。
功能性必须由用户创建
最常见的情况之一就是要求用户自己配置软环境（如配置数据源，一般都可以在程序中自动完成；当然还包括程序用到的组件在系统中不存在，用户还需要自己购买，这对用户是不能接受的）。
不能做用户期望的工作
例如，极少有人会期望一个本来编写用来对姓名进行排序的程序却按照ASCII码的顺序排序。他们也不会指望用它来计算首位空格或区分大小写。当然用户名的排序还是要做的，问题是开发者需要重新构想一个新的排序规则来满足用户需求。
人机交互
人机交互，程序员与操作者之间的通信与交流。这不是科幻电影，我们也许每天都要做。
2、遗漏信息
你应该知道，所有的事都能从计算机屏幕上得到有效的消息。
没有任何屏幕指令
如何找到程序员的名称？如何退出程序？你应该怎么样获取帮助？如果程序使用了某种命令语言，如何才能得到命令列表？程序可能仅仅只在它启动时显示这些内容。当然你也可以从帮助手册中获取这些信息，但并不是必要的。没有任何屏幕指令的程序可能会让人受不了，查询手册的话需要花费的时间可能会更长——这可能就会让用户觉得软件学习起来太复杂了。
假定打印出的文件随时可得
丢了用户手册怎么办？有经验的用户不会非要依赖打印好的文档，提供一份电子版的吧。
无正式文件证明（说明）的功能特征
如果大多数的功能特征或命令在屏幕上提供文件说明，那么所有的都应如此。仅略过几个功能特征将会导致混乱。同样，如果程序员为很多命令描述其“特殊情况”下的行为，那么所有的命令都需要提供这类说明。
看起来是不可能退出的状态
如何取消一条命令或在一个深层菜单树中进行备份？程序应该允许你可以避免那些你不希望遇到的情况。比如，在软件安装时，要求插入磁盘，如果不插入正确磁盘就不能退出安装程序。没有告诉你如何避免就和没有提供一条逃逸路径一样糟糕。
没有光标
大多数用户都依赖于光标。一个光标可以让用户觉得计算机仍然在正常运转（尽管有时候死机也是如此），每个交互程序都应该显示光标，当然，在关闭光标时别忘了告诉用户。
没有对输入做出响应
每个程序都应该对输入做出回应。如果没有，呵呵，保管80％以上的用户会对软件产生怀疑：怎么没有响应？还要等多久？
如果有以下几种情况，一般视为正常：
1． 选择一个菜单项时，如果你的按键操作没有回应，只要下一个屏幕立刻出现并且此屏幕上的标题与菜单项那个一样，就可以视为正常。
2． 如果程序忽视错误的命令或按键操作，当然可以不对其进行回应。
3． 如果你告诉程序不要输入回应，它必须不回应，如果它进行了回应，应该告诉开发人员：嘿，看那，它不听话（可能是在忘记了继续处理另一种情况）。
4． 如果输入的是安全性代码（如密码等），那么程序决不应在屏幕上做出回应（如果你输入错误则是另外一回事）。
在长期延迟时没有表示其活动
给一段较长时间的程序延迟一个合适的响应，将是非常必要的举动。相信这样就不需要再给用户做出过多的解释了。
当某个改变即将生效时没有给出建议
一个程序可能会比你预计得更早或更晚执行一个命令，例如：删除某些重要数据时，（而这个过程将持续一段时间），必要的提示是必须的。
没有对已经打开的文件进行检查
据统计，这个错误是非常常见的。用户可能不会注意，但是在以后的工作中发现略微的一丝更改就会引出大量的问题。你不能保证程序会对同一个文件在某个时刻做出不同修改所带来的后果。所以，决不允许同一文件同时被打开两次甚至更多。
3、错误的、误导的或令人迷惑的信息
每个错误都会让你对程序显示的所有其他东西产生怀疑。使用户做出虚假归纳的细小错误，如遗漏条件或是不适宜的类比会比清楚的事实错误更让测试人员感到恼火――因为更难对它们进行改正。
1． 简单的事实错误
在一个程序改变之后，更新屏幕显示是低优先级任务，结果则是：屏幕上大量的信息过时。记住：无论何时程序发生改变，都要仔细检查可能指示程序特征的每个消息，最简单的办法就是直接对更改后的屏幕进行刷新。
2． 拼写错误（错别字）
我相信，这绝对不是设计上的问题，我也相信开发人员可能会不以为然。Oh，但是客户会在乎，会抱怨这些的――还是改正它们吧。
3． 不准确的简化
在保持一个特征的描述尽可能简单的愿望中，一条消息的创作者可能只覆盖特征行为的最简单方面，而忽略了重要条件。举例来说，这种情况可能会引发歧义，比如说关闭（到底是关闭文件还是关闭程序？）。作为一个测试人员，需要你足够仔细地研究可能会出现问题的任何一个微不足道的细节。宁可错杀，也不能放过！（虽然要极力避免错杀的情况。）
4． 无效的比喻（图表之类可以指示功能特征的事物）
例如：回收站的图标可能不是一个好的比喻；对于文件一旦移除就永久消失的情况来说，碎纸机的图标可能来得更好一些。
5． 令人迷惑不解的特征（功能）名称
如果一个命令名称在计算机领域中或语言中有一个标准含义，就必须与其含义一致。别指望着胳膊能拧得过大腿，确定现行的标准是可靠的。
6． 同一特征（功能）具有多个名称
相同的功能特征只要一个名称就够了――只要能表述清楚；用户可不一定有时间玩同义词的游戏。另外，这种情况对软件在用户面前显示的复杂度也有影响。
7． 信息超载
不要让你的文档和帮助屏幕看起来太专业――太多技术细节了。用户会不耐烦的，况且效果也不好。如果实在需要，可以把他们另外列出。尽量使用直白，用户能明白的话表述这些信息。
8． 数据何时得到保存
假设你输入了一些程序需要保存的信息。当你进行切换或程序退出时，当你需要每隔一段时间进行保存时，它是否会把数据按照你想的方式进行保存呢？何时完成呢？如果你对答案感到困惑，那就意味着可能有问题出现了。曾经在同事的项目中发现过很多次这样的情况：每次修改后进行切换，不提示保存――我只知道，我又白干了。在对某个模块进行修改时，你会发现，是遗漏了必要的步骤。
9． 很差的外部模块性
外部模块性指的是程序从外部看起来产品的模块化程度（就像程序是可分割的）。你如何容易地理解模块组件？很差的外部模块会耗费大量的时间来学习产品，还会吓跑新用户――天那，它看上去太复杂了！尽可能让信息独立展示出来，对任何特定任务而言，你需要知道的越少越好。
