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

　　事实错误

　　记得测试时需要测试那些更新过的功能，在旧的帮助上的方法可能在新软件中是行不通的。这个时候开发人员的代码更新日志就显得很必要了，你不必对每项功能进行检查，完全可以把这类回归测试交给自动化测试工具完成，而你只需要关注其新内容即可。

　　上下文错误

　　不要把上下文之间的关系搞错了，这会带来阅读时的不便。比较清晰的方法是首先列出上下文关联列表，并按照操作顺序的先后进行组织。

　　没有识别出错误来源

　　通常，一个好的错误信息不仅可以指出是什么情况，而且还要指出为什么有些东西出了错，以及如何处理此类错误的方法。在过往的项目中，常常有很多这样 的问题：如“打印错误”、“保存错误”等等含糊的说明。如果用户在获得了错误信息后，还是一脸茫然，那就应该认真考虑一下错误说明的编写方式是否可以再改 进一些了。

　　不能立刻重现的错误很可能是个大问题

　　没有说明原因就禁止一个资源

　　如果程序尝试使用打印机、内存控件等资源，却做不到，错误信息应当包含的不仅仅是宣布失败，还需要说明原因。

　　报告说没有错误

　　首先，还是先承认这种情况是不太可能会出现的;错误信息只能由错误状态出发，如果大部分是通常情况的调试消息，或者是少部分并不一定由某个缺陷引起的事件报告，那么，你可能就会忽略所有的错误信息。

　　3)显示上的(问题)缺陷

　　这是一个比较客观的问题，至少表面上看上去是这样的。任何可见的错误都会产生让人不快的感觉(尽管这些问题不一定很严重)，用户就不一定会相信或者 购买该产品。可能是因为此类错误大多都是属于低级错误，通常并不受到开发人员和项目经理的重视，但是我们必须重视它――它就是问题(Bug)，它就是我们 要找的东西之一。

　　另外提一点：总是拘泥于这类Bug――放过重要的功能需求，“吹毛求疵”――可能会使测试失去意义，它可能是造成开发人员和项目经理不重视测试的一个借口。尽管如此，我们还是要提出这类问题，但并不是说可以遗漏重要的功能需求。

　　――数据写到了错误的屏幕位置

　　光标提示在正确的位置，但是数据却显示在屏幕错误的位置(张冠李戴)。这类错误对开发人员而言，不应该是个很棘手的问题，但对用户来说，那是致命的。

　　――未能清除部分屏幕

　　一条信息在屏幕上显示了几秒钟，接着却只有一部分被擦除了;或者你对前一问题的回应仍然留在屏幕上，我们固然可以以计算机整体性能为借口，但也不能 排除技术因素。为了输入一些新东西，不得不在提示或不相关的回应上输入，这是令人头疼而且迷惑不解的。在以前测试的项目中，就曾经出现过由于屏幕未正确刷 新导致的清屏不完整及无故弹出不相关提示的问题――这种问题比较普遍，需要多加注意。

　　――未能突出显示部分屏幕

　　如果程序常常需要突出显示某个特定类别的项目，例如提示或者在激活窗口中的所有文本，那么它就必须一直这么做。

　　――未能清除突出显示

　　屏幕位置的属性与显示的文本分开储存时这是很普遍的。程序员删除了突出显示的文本，但是忘记了从屏幕的那一区域清除突出显示。这类问题一般都和数据刷新有关系，无论是界面上的处理还是系统底层的处理。

　　――显示的字符串错误或不完整

　　显示的消息可能是毫无价值的文本，一个冗长的信息的一个片断或是一条应该显示在其他时间出现的完整信息。这其中任何一条都可能反映出程序逻辑上，用来发现消息文本的指针的值或者已储存的文本副本中的错误。

　　――显示信息过长或者不够长

　　消息在屏幕上显示的时间应该足够长，至少应该保持到能让用户读到结束为止。如果对同一条消息有时显示时间长，有时显示时间短则需要注意，这可能预示着外部资源之间的竞争条件(比如对内存资源的争夺)，往往这些条件是在我们考虑之外的，需要认真对待。

　　4)界面布局的显示

　　屏幕看上去应该是很有条理的，别让它看起来像是一个乱糟糟的房间。不同类别的对象应该在可预知的区域分开显示。你可以参考一些关于UI布局的文章，但归结起来说：显示布局应该很容易让你在屏幕上找到你要的东西。

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