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

　　程序员有时候会有意引入不一致性来对程序进行优化。的确很吸引人，但是也要注意优化所带来的风险和一些优化的必要性：保存一两次按键操作是否与学习时间的增加或信任度的减少价值相当?未必。

　　――不一致的缩写

　　如果没有很明确的缩写规则，缩写就不能容易地被记住。把Delete缩写为Del，把Grep缩写为Grep，是没有任何意义的。

　　――不一致的终止规则

　　程序应该为多重键录入要求终结符。

　　――不一致的命令选项

　　如果一个选项对两个或者更多的命令有意义，那么它就应该对这些命令都可用(都不可用)，它应该具有同样的名称，并且应该在两种情况下以同样的顺序被调用。

　　――名称相似的命令

　　如果两个命令名称相似，就很容易搞混。尽量不要使用相似的名称命名命令。这个问题在中文界面的软件中表现得尤为突出。

　　――不一致的大写

　　如果命令录入是区分大小写的，所有命令的第一个字符都应该使用大写(小写)。命令中嵌入单词的第一个字符应该一直大写(小写)。另外，如非必要，不要在一个命令中使用多国语言。

　　――不一致的菜单位置

　　如果同一命令在不同子菜单中出现，那么要在不同菜单的同一位置保留同一命令是很困难的。这句话不是很好理解，不过把话说白了就好理解很多：要保持命令在同一子菜单中的位置，而不是让它东搬西迁在其他的子菜单中停留。

　　――不一致的功能键用途与其说明

　　功能键的意义在程序中应始终保持一致(颠倒或是功能冲突是不能接受的)。

　　――不一致的错误处理规则

　　当程序检测到一个错误之后，它可能会公布该错误，或者尝试更正错误。任何一个程序的行为都应该是可预测的。如果当提交错误数据时没有任何的提示或尝试更正错误的说明，那么用户就无法确认数据是否是干净的。

　　――不一致的编辑规则

　　当你输入或稍后检查任何数据时，同样的键和命令应该可以用来对其进行修改。

　　――不一致的数据保存规则

　　应该在每处都以同样的方式，在同样的时间和范围内保存数据。它不应该在每个区域输入数据时保存数据，而其他时间则在一个记录、一组记录的末尾保存数据，或恰好在退出前保存数据。

　　――浪费时间

　　看起来为了浪费时间而进行的设计会激怒每个人，应该把时间花在更有意义的事情上去。

　　――曲折路径

　　如果为了到达想要的命令，你必须一个接一个做出选择。结果到最后发现，该命令不存在、不能实现或者要求你先完成某件事甚至几件事后才能使用――明显 的欺诈行为!相信客户的不满和你(测试人员)的不满几乎没有任何区别。举个例子说：当用户辛辛苦苦填满了整整一页的数据，最后提交时发现：该页数据中的某 项已经被使用了时，用户的焦躁可想而知。

　　――不能采用的选择

　　事实上没有任何接口在一个不能建立的菜单中包含选择项。如果没有任何数据存在，你如何评审、保存和擦除数据?没有打印机，如何打印文档?有的命令不 适合出现在某些条件下(虽然对使用没有什么影响)，但是开发人员可能为了图方便而保留了此类命令(很遗憾地说：这太不专业了);有时候，程序会提示寻求帮 助，而当你真的去使用的时候，程序却告诉你“您没有使用帮助的权限”――面对可望而不可及的东西，很多人宁愿选择不去看见。这种情况很常见，至于常常被开 发人员和测试人员共同忽略――但这是不应该存在的错误。

　　――你真的，真的确定么?

　　严重毁坏数据的命令需要这样重复的确认。是的，这是必须的，如：对一个写满数据的硬盘进行格式化的确需要多次确认。但是没有必要对每个细小的删除操 作进行繁复的确认操作，用户会变得不耐烦，其结果有可能是：当用户真的在进行严重毁坏性命令时，无视屏幕提示，造成不可预计的后果。

　　――模糊不清或者带有个人风格的命令

　　命令名应该明确指示该命令的作用。不要让用户一边使用软件，一边查询用户手册中关于该命令的解释。调查表明：大多数用户在使用软件产品的时候只对软 件手册做大概的了解，甚至根本不阅读。别指望用户会很完整地阅读手册，那是我们的工作。没有任何理由在发布的程序中生成如：finger等带有明显个人风 格的命令，当然，如果在程序中出现了脏话，我希望(仅仅是希望)客户没有气到火冒三丈。

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