登录
如果有以下几种情况，一般视为正常：
选择一个菜单项时，如果你的按键操作没有回应，只要下一个屏幕立刻出现并且此屏幕上的标题与菜单项一样，就可以视为正常。
如果程序忽视错误的命令或按键操作，当然可以不对其进行回应。
如果你告诉程序不要对输入回应，它必须沉默，如果它进行了回应，应该立即告诉开发人员对其进行修改（可能是在忘记了继续处理另一种情况）。
如果输入的是安全性代码（如密码等），那么程序决不应在屏幕上做出不恰当的回应（如显示你输入的密码明文）。
――在长期延迟时没有表示其活动
给一段较长时间的程序延迟一个合适的响应，将是非常必要的举动。相信这样不需要再给用户做出过多的解释了。
――当某个改变即将生效时没有给出建议
一个程序可能会比你预计的更早或更晚执行一个命令，例如：删除某些重要数据时，（而这个过程将持续一段时间），必要的提示是必须的。
――没有对已经打开的文件进行检查
这个错误是非常常见的，尤其对于那些输入关键数据的程序而言。用户可能不会注意，但是在以后的工作中将发现略微的一丝更改就会引出大量的问题。你不 能保证程序会对同一个文件在某个时刻做出不同修改所带来的后果。所以，决不允许同一文件同时被打开两次甚至更多，以确保程序输出的唯一性。
――错误的、误导的或令人迷惑的信息
每个错误都会让你对程序显示的所有其他东西产生怀疑。使用户做出虚假归纳的细小错误，如遗漏条件或是不适宜的类比会比清楚的事实错误更让测试人员感到恼火――因为更难对它们进行改正。
简单的事实错误
在一个程序改变之后，更新屏幕显示是低优先级任务，结果则是：屏幕上大量的信息过时。记住：无论何时程序发生改变，都要仔细检查可能指示程序特征的每个消息，最简单的办法就是直接对更改后的屏幕进行刷新。
拼写错误（错别字）
我相信，这绝对不是设计上的问题，我也相信开发人员可能会不以为然。Oh，但是客户会在乎，会抱怨这些的--还是改正它们吧。
不准确的简化
在保持一个特征的描述尽可能简单的愿望中，一条消息的创作者可能只覆盖特征行为的最简单方面，而忽略了重要条件。举例来说，这种情况可能会引发歧 义，比如说关闭（到底是关闭文件还是关闭程序？）。作为一个测试人员，需要你足够仔细的研究可能会出现问题的任何一个微不足道的细节。宁可错杀，不能放 过！（虽然要极力避免错杀的情况。）
无效的比喻（图标之类可以指示功能（特征）的事物）
例如：回收站的图标可能不是一个好的比喻；对于文件一旦移除就永久消失的情况来说，碎纸机的图标可能来得更好一些。
令人迷惑不解的特征（功能）名称
如果一个命令名称在计算机领域中或语言中有一个标准含义，就必须与其含义一致。别指望着胳膊能拧得过大腿，确定现行的标准是可靠的。
同一特征（功能）具有多个名称
相同的功能特征只要一个名称就够了――只要能表述清楚；用户可不一定有时间玩同义词的游戏。另外，这种情况对软件在用户面前显示的复杂度也有影响。
信息超载
不要让你的文档和帮助屏幕看起来太过专业――太多技术细节了。用户会不耐烦的，况且效果也不好。如果实在需要，可以把他们另外列出。尽量使用直白，用户能理解的话表述这些信息。另外，信息超载的另一个意义意味着烦琐冗长的语句，那是要极力避免的。
数据何时得到保存
假设你输入了一些程序需要保存的信息。当你进行切换或程序退出时，当你需要每隔一段时间进行保存时，它是否会把数据按照你想的方式进行保存呢？何时 完成呢？如果你对答案感到困惑，那就意味着可能有问题出现了。曾经在同事的项目中发现过很多次这样的情况：每次修改后直接关闭程序，却不提示用户保存―― 我只知道，修改信息在关闭时也消失了。在对某个模块进行修改时，你应密切注意这个问题。
很差的外部模块性
外部模块性指的是程序从外部看起来产品的模块化程度（如同程序是可分割的实体）。你如何容易地理解模块组件？很差的外部模块会耗费大量的时间来学习产品，还会吓跑新用户--它看上去太复杂了！尽可能让信息独立展示出来，对任何特定任务而言，你需要知道的越少越好。
2）帮助文本和错误信息
帮助文本和错误信息通常被认为是产品的次要部分。它们可能是由初级程序员编写的（比如我）或是作者编写，对其进行更新的工作可能被赋予低优先级。然 而，作为产品而言，这又是必不可少的部分，一份看上去赏心悦目的帮助文档可以“主观 ”的降低软件的学习难度和用户的使用兴趣。
当你感到困惑或是有麻烦时，寻求帮助或倾向于使用错误处理程序将是一个明智的选择。你可能会觉得不爽，更多的时候是不耐烦。而如果其中有信息误导了你，那么无异于火上浇油。以下列出的是我以往在审核帮助文档及错误信息时碰到的一些常见问题。
不合适的阅读层次
在计算机终端上，人们不能很好的进行阅读。帮助文本和错误信息应该尽量措辞简单明了，多用主动语态，尽量少使用技术术语，即便用户中有计算机经验也是如此。
冗长
避免你的帮助文档和错误信息变成裹脚布。大多数用户在需要更多信息时，会选择通过菜单获得进一步的信息。最好让他们自己选择所需的信息。
不合适的情绪语气
尽量不要使用感叹号，如“终止”、“崩溃”之类的带有激烈意味的词语都应如此。
事实错误
记得测试时需要测试那些更新过的功能，在旧的帮助上的方法可能在新软件中是行不通的。这个时候开发人员的代码更新日志就显得很必要了，你不必对每项功能进行检查，完全可以把这类回归测试交给自动化测试工具完成，而你只需要关注其新内容即可。
上下文错误
不要把上下文之间的关系搞错了，这会带来阅读时的不便。比较清晰的方法是首先列出上下文关联列表，并按照操作顺序的先后进行组织。
没有识别出错误来源
通常，一个好的错误信息不仅可以指出是什么情况，而且还要指出为什么有些东西出了错，以及如何处理此类错误的方法。在过往的项目中，常常有很多这样 的问题：如“打印错误”、“保存错误”等等含糊的说明。如果用户在获得了错误信息后，还是一脸茫然，那就应该认真考虑一下错误说明的编写方式是否可以再改 进一些了。
不能立刻重现的错误很可能是个大问题
没有说明原因就禁止一个资源
如果程序尝试使用打印机、内存控件等资源，却做不到，错误信息应当包含的不仅仅是宣布失败，还需要说明原因。
报告说没有错误
首先，还是先承认这种情况是不太可能会出现的；错误信息只能由错误状态出发，如果大部分是通常情况的调试消息，或者是少部分并不一定由某个缺陷引起的事件报告，那么，你可能就会忽略所有的错误信息。
