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

　　――不能配合手边的硬件

　　有些程序被锁定针对了特定的输入输出程序。升级或更换了设备的用户可能就无法使用这些功能了。这是令人遗憾的。同时，也会让用户觉得是否是一种商业捆绑的模式而拒绝使用此产品。尽量让开发人员编写通用的硬件接口代码以适应大部分通用的硬件设备。

　　――不能改变设备初始化

　　一个应用程序应该能够发送用户定义的初始状态，或者至少应该让它保持现状。每次启动都需要重新配置将会是很烦人的工作。假定你想要向一个打印机发送 控制代码，以转换到压缩字符，如果打印数据的程序不让你初始化打印机，你就不得不从设备来改变打印机的模式和状态，然后重新运行程序。如果程序阻挠了你的 打印机设置，那就是一个设计错误。

　　――不能关闭自动保存

　　自动保存是件好事，不过无事生非也是一件糟糕的事情。过于频繁的自动保存可能会让用户觉得程序不可靠。所以还是老老实实加上关闭自动保存的选项吧。

　　――不能改变滚动速度

　　严格来说，这不是一个很严重的问题。目前很多的设备驱动中已经提供了此类选项。

　　――不能重复上次的操作

　　这样的例子比如Word软件中的Redo。

　　――无法找到你上次完成的内容

　　此类问题对数据编辑特别是文本编辑类的程序较为常见。应当提供保存的文件列表，除非用户禁止了它。

　　――无法执行一个定制的命令

　　在程序选项中，一旦对其更改，应该立即生效，不需要再次重新启动程序进行加载――特殊情况除外(如果你无法避免)。

　　――无法保存定制的命令

　　你不应该只告诉程序此次运行关闭了警告声，而是应该让程序永远可以关闭这些――只要设置没有发生变化。

　　――特征更改的副作用

　　这种情况较常见，修改了某一个特征，相关的特征也会改变。如果确实存在副作用，应当在手册和屏幕中提供详实的文档证明和提示。

　　――无限可调整性

　　开发人员可以改变某些程序的方方面面。但是在开篇时说过，提供了太多灵活性的程序并非一直都是一件好事。好好斟酌再做决定要比草率地修改来得更好。

　　2)控制方式

　　有些程序很“霸道”。它们的错误信息和帮助消息自认为高人一等，它们的风格不可原谅的不便――你甚至无法放弃命令或者在输入数据后进行更改。程序应该使你觉得能更容易，更惬意地完成一个任务。至少，它不应该浪费你的时间。

　　――一个概念风格的不必要和不合理要求

　　有些程序要求你以某种顺序输入数据，或要求你在进行下一步之前先完成某项任务，再要么就要求你再考虑它们的潜在后果之前做出决定。例如：

　　当设计一种数据录入格式时，为何你必须再屏幕显示之前确定一个数据录入域的名称，类型，宽度或者计算顺序?当你察觉不同的域放在一起看起来有神么不 妥的时候，你是否会更改某些域，把它们的位置换来换去，甚至去掉少数域?你可能不得不在使用该格式之前输入域的规格说明，但是在该约束条件下，你应该决定 何时填充细节。

　　当向一个项目管理系统描述任务时，为何你必须首先列出所有的任务，然后列出说有可用的人员，接着在为下一项工作输入任何数据之前就把分配给某个人的工作完全对应?既然你可能试着决定什么工作分配给什么人，那么你不想看到结果后再更改这些数据么?

　　限制的数量如此多，是因为有些开发人员认为，人们应该以某种方式组织它们的工作。但是他们所想的最佳途径未必都是最佳的。我们应该更清醒地意识到，除了业务流程上的禁锢，不需要再对用户在风格上多加任何的限制――当然，如果用户需要的话。

　　――对新手友好，但是对老手并不一定友好

　　为初学者设计的进行过优化的过程可能为他们掌握系统会有帮助，但是同时会令一些有经验的老手带来烦恼。他们更希望能自由地使用软件;其中一个解决办法就是提供两条以上地路径实现对不同层次用户的需求。

　　――人工智能与自动化

　　有些更智能和更便利的程序会猜测你的下一步动作，并枉加执行这些猜测;自动纠错的程序的确很好，除非它“纠正”了正确的数据。而有时候，用户并不一定希望这样做。提供可用的选项可以缓冲一下这方面的矛盾。

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