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

　　――过剩或多余的必需信息

　　过剩和多余的必需信息就像我们身上的赘肉一样讨厌。有些程序会请求他们从来不会使用或者只会用来在屏幕上显示一次的信息，或者会要求你重新输入你已经输入过的数据――并非是为了验证，仅仅只是重新获取一次数据，这对时间的浪费是非常惊人的。

　　――不必要的步骤重复

　　如果你在输入一个较长的命令步骤或数据时犯了一个错误，有些程序就不管青红皂白让你重新输入;有的程序则强迫你重新输入或确定可能有错误的任何命令。为了某些任务，你甚至可能需要确认每个步骤。相信我：不必要的重复或确认都是浪费时间。

　　――不必要的限制

　　为什么要把一个数据库限定为如此多的字段或记录，或限制一个电子表格仅使用数字，把一个项目经理限制在如此多的任务中，一个字处理程序限制在如此多的字符呢?对性能或可靠性而言并非必要的限制不应该成为约束条件。

　　6、性能

　　许多有经验的用户认为性能是最重要的可用性因素：使用一个快速程序，他们感到更能集中精神工作，而且更多的东西处在掌握之中。在极少出现异常的情况下，程序越快越好。

　　性能有很多定义，大致来说主要有如下的感性认识：

　　程序速度：执行标准任务的速度有多快?

　　用户吞吐量：你能使用程序执行标准任务的速度有多快?

　　感觉到的性能：在用户看来，该程序速度有多块?它是否令你满意?

　　无论如何定义，程序速度总是一个关键因素。但是一个界面设计拙劣的快速程序无论怎么看都要比它实际的运行和处理速度要慢得多。

　　1)降低程序速度

　　很多设计和代码错误会降低一个程序的执行错误。程序可能会执行很多不必要的工作，如对一个在读前会被重写的内存区域进行初始化;也可能会对工作进行 不必要的重复，如在一个在循环中执行的任务可以在循环外完成;设计的决策也会影响到程序的速度，而且通常要比明显错误导致的慢速情况更加严重。

　　2)缓慢回应

　　程序应立即对输入做出响应，如果在你输入一个字母的时刻和你看到这个字母的时刻有延迟，显然，程序就太慢了。快速反馈对任何输入事件都必须是有效而且是必要的，它包括：鼠标，键盘，轨迹球，键盘等等。

　　3)如何减少用户吞吐量

　　一个闪电般快的程序执行任务时可能比蜗牛还要慢。这包括：

　　任何可能使用户错误更可能发生的事情。(培训不周，用户习惯，程序风格等等)

　　缓慢的错误恢复。如：在输入一长串字符后发现错误却必须要重新输入。

　　任何使你感到迷惑，却得不到帮助文档或手册提供资料的事情。

　　输入很多，却做得很少的程序――这不是一个好程序。如：把一个简单任务划分成很小的子任务，要求对所有事情进行确认等等。

　　在测试时，使用比较性测试是个有效的方法：即把开发中的产品与竞争对手的产品进行比较，如果人们使用你的产品花费的时间要更长，那么发现这个问题就是有意义的。

　　4)反应拙劣

　　我曾经测试过一个产品，在输入第一条数据后，居然花了将近一分钟才从数据库中将数据取回。这不能不说是一个反应很慢的程序。一份表单做下来将近 300条数据，按此速度计算，我将花上至少半天才能完成输入。这种情况是不能允许的。迅速地对输入做出回应是一个程序最最基本的功能。一个反应迅速的程序 不会强迫你在提交下一个命令之前让你持续等待，而是让你继续做其他事。

　　5)没有提前输入

　　一个允许提前输入的程序会让你在它从事其他工作的时候仍然可以键入，它会记住输入内容，加以显示并在稍后进行处理。你不应该等着输入下一个命令。

　　6)没有给出某个操作会花很长时间的警告

　　如果程度需要超过几秒钟的时间来进行某事，程序应该告知用户。对于较长时间的任务，它应该给你一个大概的时间印象而不是让你干等着它结束。给出大致需要完成的时间或是进度条是处理此类问题一般的方法。

　　7)程序太多提示和询问

　　提示，警告以及询问可能很有用，不过如果它们出现得太频繁，就会让人很窝火。

　　8)尽量使用简单命令和提示

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