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

　　6)功能性必须由用户创建

　　最常见的情况之一就是要求用户自己配置软环境(如配置数据源，一般都可以在安装程序中自动完成;当然还包括程序用到的组件在系统中不存在，安装程序 没有提供相应的支持，这对用户是不能接受的)。这类问题不完全一定都是错误，比如微软提供的Office宏的开发，是为了满足客户对于自身特色而设计的适 合其专业工作的程序。

　　7)不能做用户期望的工作

　　例如，极少有人会期望一个本来编写用来对姓名进行排序的程序却按照ASCII码的顺序排序。他们也不会指望用它来计算首位空格或区分大小写。当然用户名的排序还是要做的，问题是开发者需要重新构想一个新的排序规则来满足用户需求。

　　· 人机交互

　　人机交互，程序与操作者之间的通信与交流。这不是早些年的科幻电影，我们也许每天都在做，在取款机前，在自动售卖机前。

　　1)遗漏信息

　　你应该知道，所有的事都能从计算机屏幕上得到有效的消息。不要遗漏任何对于用户而言至关重要的信息，即使这些信息对你而言毫无用处。

　　――没有任何屏幕指令

　　如何找到程序的名称?如何退出程序?你应该怎么样获取帮助?如果程序使用了某种命令语言，如何才能得到命令列表?程序可能仅仅只在它启动时显示这些 内容。当然你也可以从帮助手册中获取这些信息，但并不是必要的。没有任何屏幕指令的程序可能会让人受不了，查询手册的话需要花费的时间可能会更长，也可能 就会让用户觉得软件学习起来太复杂了。

　　――假定打印出的文件随时可得

　　丢了用户手册怎么办?有经验的用户不会非要依赖打印好的文档，提供一份电子版的吧。

　　――无正式文字证明(说明)的功能特征

　　如果大多数的功能特征或命令在屏幕上提供文字说明，那么所有的都应如此。仅略过几个功能特征将会导致UI形式上的混乱。同样，如果程序为很多命令描 述其“特殊情况”下的行为，那么所有的命令都需要提供这类说明。这种情况在国人的软件开发过程中时有发生，并不是不能，而是不想……

　　――看起来不可能退出的状态

　　如何取消一条命令或在一个深层菜单树中进行备份?程序应该允许你可以避免那些你不希望遇到的情况。比如，在软件安装时，要求插入磁盘，如果不插入正确磁盘就不能退出安装程序。没有告诉你如何避免就和发生灾难时，没有提供一条逃生路径一样糟糕。

　　――没有光标

　　大多数用户都依赖于光标。一个光标可以让用户觉得计算机仍然在正常运转(尽管有时候死机也是如此)，每个交互程序都应该显示光标，当然，在关闭光标时别忘了提醒用户注意。

　　――没有对输入做出响应

　　每个程序都应该对输入做出回应。如果没有，呵呵，保管80%以上的用户产生疑问：怎么没有响应?还要等多久?是不是我的电脑过时了?

　　如果有以下几种情况，一般视为正常：

　　选择一个菜单项时，如果你的按键操作没有回应，只要下一个屏幕立刻出现并且此屏幕上的标题与菜单项一样，就可以视为正常。

　　如果程序忽视错误的命令或按键操作，当然可以不对其进行回应。

　　如果你告诉程序不要对输入回应，它必须沉默，如果它进行了回应，应该立即告诉开发人员对其进行修改(可能是在忘记了继续处理另一种情况)。

　　如果输入的是安全性代码(如密码等)，那么程序决不应在屏幕上做出不恰当的回应(如显示你输入的密码明文)。

　　――在长期延迟时没有表示其活动

　　给一段较长时间的程序延迟一个合适的响应，将是非常必要的举动。相信这样不需要再给用户做出过多的解释了。

　　――当某个改变即将生效时没有给出建议

　　一个程序可能会比你预计的更早或更晚执行一个命令，例如：删除某些重要数据时，(而这个过程将持续一段时间)，必要的提示是必须的。

　　――没有对已经打开的文件进行检查

　　这个错误是非常常见的，尤其对于那些输入关键数据的程序而言。用户可能不会注意，但是在以后的工作中将发现略微的一丝更改就会引出大量的问题。你不 能保证程序会对同一个文件在某个时刻做出不同修改所带来的后果。所以，决不允许同一文件同时被打开两次甚至更多，以确保程序输出的唯一性。

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