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

　　菜单

　　菜单应该尽量简洁，当存在了太多风格不一，冗长和拙劣的图标或命令名，以及当选择隐藏在不明显的主题之下的子项时，理解它们将会变得非常复杂。一个菜单覆盖的命令越多，无论如何规划，都会变得复杂，如果没有良好的规划，这对用户的使用将是一大障碍。

　　――过于复杂的菜单层次

　　如果必须在最后到达你想要的命令之前很吃力地通过一个又一个菜单，那么我想我会选择使用另外一个功能相近的程序。创建深层菜单树的程序员所引用的设 计规则表明，没有哪个菜单应该具有七个以上的选项，这一点对新手来说可能时最好的。有经验的用户更倾向于每个菜单级别有更多选择，犯更少错误并更快速有效 的做出反应，只要选项能合理组织，整齐排版，而且没有可笑的拥挤或拼写错误就行了。

　　-不适当的菜单导航系统

　　即使在一个最适当的深层菜单系统中，你也必须能够返回到前一菜单，或者移到菜单结构的顶层，并能在任何时刻离开程序。

　　――太多路径到达相同位置

　　如果许多命令在菜单中重复出现，那么程序就需要重新组织。让一个命令在不同位置重复可能会很便捷，但是存在一定的限制。如果感觉上你可以从程序的任何位置到达另一个任意位置――那就得重新考虑下程序的内部结构和可靠性。

　　――相关的命令被归属到不相关的菜单

　　把一个复杂菜单中对命令或主题进行分组并不是一件容易的事情。人们都很容易忽视两项之间明显关系，并把它们分配到分开的菜单中去，当需要对此进行调整时，我们需要做的是：解释两项之间的关系，并建议两者都应属于哪个菜单。

　　――不相关命令被放置到同一菜单下

　　有些命令被扔到了完全无关的菜单下，这样并不好，宁可重新选择一个更高级别的标题并重新组织这些命令也不要那么做――如果那样做导致的混乱比较严重的话。

　　――键盘不能正确使用

　　不能正确使用键盘无论在何时都是一个问题。

　　――无法使用编辑键或功能键

　　如果一个程序从某些其他没有这些键的机器上移植过来，那没关系。相反可能就不行。要确保程序可以使用已有的编辑键和功能键。

　　――光标和编辑键的非标准使用

　　这些键应该按照他们通常在该机器上工作的方式进行工作，而不是按照他们通常在其他某个机器上工作的方式来工作。

　　――功能键的非标准使用

　　如果大多数程序用F1作为帮助键，那么如果在程序中将它定义为其他的功能，那将是不合适的。

　　――不能过滤无效键

　　程序应该能挡住并抛弃无效字符，比如进行数字相加时输入的字母。它不应该做出回应。与错误消息相比，这样做更快更有效。

　　――未能指示键盘状态的改变。

　　键盘上的灯或屏幕信息应该告诉你何时你的Num Lock键和其他类似的状态转换特征是开着的。

　　――未能扫描功能键或快捷键

　　你应该能够告诉计算机从它正在进行的工作中退出;程序应该总是能辨别出任何其他系统指定的键――即那些本机上的程序通常可以很快识别出来的键。

　　4、遗漏的命令

　　1)状态转换

　　大多数程序从一个状态转到另一个状态，在你选择某个菜单项或者提交一个命令之前，程序处于某种状态。为了回应你的选择，程序回到另一个状态。程序员通常会对他们的代码进行足够的测试，以确保你能达到任何你应该可以达到的状态。

　　――什么都不作就退出(状态返回)

　　你应该能够告诉应用程序，你做出的最后一个选择有误，并返回到其前一个状态。

　　――不能在程序中间退出

　　当使用一个程序但还没有对存储的数据造成不利影响时，你应该能够从中退出;如果你正在编辑的文件出现了预想不到的错误，在中止后应能回到先前保存过的状态。

　　――不能在命令中间停止

　　告诉程序停止一个命令很容易，而返回到起始点或选择一个其他的命令也应该不太难。如果其中任何一个方面出现了问题，就需要重新考量先前的设计是否真的合理了。

　　――不能暂停

　　如果程序限定了你输入的时间，时间一到，状态就改变，那么当你离开时你就需要它暂停一会儿。这中类型的情况在游戏软件中见得较多，比如说暂停游戏。

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