软件GUI测试中的关注点(3)

　　――错误的、误导的或令人迷惑的信息

　　每个错误都会让你对程序显示的所有其他东西产生怀疑。使用户做出虚假归纳的细小错误，如遗漏条件或是不适宜的类比会比清楚的事实错误更让测试人员感到恼火――因为更难对它们进行改正。

　　简单的事实错误

　　在一个程序改变之后，更新屏幕显示是低优先级任务，结果则是：屏幕上大量的信息过时。记住：无论何时程序发生改变，都要仔细检查可能指示程序特征的每个消息，最简单的办法就是直接对更改后的屏幕进行刷新。

　　拼写错误(错别字)

　　我相信，这绝对不是设计上的问题，我也相信开发人员可能会不以为然。Oh，但是客户会在乎，会抱怨这些的--还是改正它们吧。

　　不准确的简化

　　在保持一个特征的描述尽可能简单的愿望中，一条消息的创作者可能只覆盖特征行为的最简单方面，而忽略了重要条件。举例来说，这种情况可能会引发歧 义，比如说关闭(到底是关闭文件还是关闭程序?)。作为一个测试人员，需要你足够仔细的研究可能会出现问题的任何一个微不足道的细节。宁可错杀，不能放 过!(虽然要极力避免错杀的情况。)

　　无效的比喻(图标之类可以指示功能(特征)的事物)

　　例如：回收站的图标可能不是一个好的比喻;对于文件一旦移除就永久消失的情况来说，碎纸机的图标可能来得更好一些。

　　令人迷惑不解的特征(功能)名称

　　如果一个命令名称在计算机领域中或语言中有一个标准含义，就必须与其含义一致。别指望着胳膊能拧得过大腿，确定现行的标准是可靠的。

　　同一特征(功能)具有多个名称

　　相同的功能特征只要一个名称就够了――只要能表述清楚;用户可不一定有时间玩同义词的游戏。另外，这种情况对软件在用户面前显示的复杂度也有影响。

　　信息超载

　　不要让你的文档和帮助屏幕看起来太过专业――太多技术细节了。用户会不耐烦的，况且效果也不好。如果实在需要，可以把他们另外列出。尽量使用直白，用户能理解的话表述这些信息。另外，信息超载的另一个意义意味着烦琐冗长的语句，那是要极力避免的。

　　数据何时得到保存

　　假设你输入了一些程序需要保存的信息。当你进行切换或程序退出时，当你需要每隔一段时间进行保存时，它是否会把数据按照你想的方式进行保存呢?何时 完成呢?如果你对答案感到困惑，那就意味着可能有问题出现了。曾经在同事的项目中发现过很多次这样的情况：每次修改后直接关闭程序，却不提示用户保存―― 我只知道，修改信息在关闭时也消失了。在对某个模块进行修改时，你应密切注意这个问题。

　　很差的外部模块性

　　外部模块性指的是程序从外部看起来产品的模块化程度(如同程序是可分割的实体)。你如何容易地理解模块组件?很差的外部模块会耗费大量的时间来学习产品，还会吓跑新用户--它看上去太复杂了!尽可能让信息独立展示出来，对任何特定任务而言，你需要知道的越少越好。

　　2)帮助文本和错误信息

　　帮助文本和错误信息通常被认为是产品的次要部分。它们可能是由初级程序员编写的(比如我)或是作者编写，对其进行更新的工作可能被赋予低优先级。然 而，作为产品而言，这又是必不可少的部分，一份看上去赏心悦目的帮助文档可以“主观 ”的降低软件的学习难度和用户的使用兴趣。

　　当你感到困惑或是有麻烦时，寻求帮助或倾向于使用错误处理程序将是一个明智的选择。你可能会觉得不爽，更多的时候是不耐烦。而如果其中有信息误导了你，那么无异于火上浇油。以下列出的是我以往在审核帮助文档及错误信息时碰到的一些常见问题。

　　不合适的阅读层次

　　在计算机终端上，人们不能很好的进行阅读。帮助文本和错误信息应该尽量措辞简单明了，多用主动语态，尽量少使用技术术语，即便用户中有计算机经验也是如此。

　　冗长

　　避免你的帮助文档和错误信息变成裹脚布。大多数用户在需要更多信息时，会选择通过菜单获得进一步的信息。最好让他们自己选择所需的信息。

　　不合适的情绪语气

　　尽量不要使用感叹号，如“终止”、“崩溃”之类的带有激烈意味的词语都应如此。

原文转自：http://www.uml.org.cn/Test/200711195.asp