浅谈易用性测试及GUI常见的测试要求
对于一个需要面对用户的软件产品来说，最直观的UI和使用感受也是产品能否获得用户认可的关键一环。个人认为，在毒霸的产品传统中，从设计到开发再到测试，对产品的易用性和GUI的规范往往给予的关注较少。我在测试过程中就遇到了很多影响使用心情的非关功能方面的 BUG。希望此文可以在毒霸的易用性和GUI方面的测试中给同学们提供一些参考。
易用性测试
易用性(Useability)是交互的适应性、功能性和有效性的集中体现。
在《软件工程产品质量》质量模型中，提出易用性包含易理解性、易学习性和易操作性；即易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。易用性测试包括针对应用程序的测试，同时还包括对用户手册系统文档的测试。通常采用质量外部模型来评价易用性。包括如下方面的测试：
(1) 易理解性测试
(2) 易学性测试
(3) 易操作性测试
(4) 吸引性测试
(5) 易用的依从性测试
易用性测试方法有：静态测试；动态测试；动态和静态结合测试。
由于易用性缺陷的主观性，因此测试人员和UI设计人员经常产生不同意见。UI通常被当作创造者的作品，而测试人员说某处是错误，就可能挫伤“艺术家”。易用性是软件缺陷中的敏感问题。
人体工程学(ergonomics)是一门将日常使用的东西设计为易于使用和实用性强的学科。人体工程学的主要目标是达到易用性。
1、用户界面测试
用于与软件交互的方式称为用户界面或UI。
2、优秀UI的构成
软件测试员要负责测试软件的易用性，包括其用户界面。
记住，软件测试员不需要去设计UI，只需要把自己当作用户，然后去找出UI中的问题。
优秀UI具备的七个要素
(1) 符合标准和规范
重要的用户界面要符合现行标准和规范，这些标准和规范由软件易用性专家开发。它们是由大量正式测试、经验、技巧和错误得出的方便用户的规则。如果软件严格遵守这些规则，优秀UI的其他要素就自然具备。
(2) 直观性
* 用户界面是否洁净、不唐突、不拥挤？
* UI的组织和布局合理吗？
* 是否允许用户轻松地从一个功能转移到另一个功能？
* 下一步做什么明显吗？
* 任何时候都可以决定放弃或者退回、退出吗？
* 菜单或者窗口是否深藏不露？
* 有多余功能吗？软件整体抑或局部是否做得太深？
* 帮助系统有效吗？
(3) 一致性
* 用户的使用习惯性强，希望一个程序的操作方式能够带到另一个程序中。在审查软件一致性时要考虑一下术语：
* 快捷键和菜单选项
* 术语和命名
* 听众
* 诸如OK和Cancel按钮的位置
(4) 灵活性
* 灵活性表现在：用户喜欢选择不要太多，但是足以允许他们选择做什么和怎么做。
* 状态跳转
* 状态终止和跳过
* 数据输入和输出
(5) 舒适性
* 软件使用起来应该舒适，不能给用户工作制造障碍和困难。如何鉴别软件舒适性的一些好想法：
* 恰当。软件外观和感觉应该与所做的工作和使用者相符。
* 错误处理。程序应该在用户执行严重错误的操作之前提出警告，并且允许用户恢复由于错误操作导致丢失的数据。
* 性能。快不见得是好事。不少程序的错误提示信息一闪而过，无法看清。如果操作缓慢，应该让用户得到相应的信息。
(6) 正确性
* 要测试正确性，就是测试UI是否做了该做的事。
* 市场定位偏差：有没有多余的或者遗漏的功能，或者某些功能执行了与市场宣传材料不符的操作？
* 语言和拼写：程序员常常能制造出非常有趣的用户信息。
* 不良媒体：图标是否同样大小？是否具有相同的调色板？声音是否应该有相同的格式和采样率？
* 所见即所得：保证UI所说的就是实际得到的。
(7) 实用性
* 是否实用是优秀用户界面的最后一个要素。
* 不是指软件本身是否实用，而是指具体特性是否实用。
* 在审查产品说明书、准备测试或者实际测试时，想一想看到的特性对软件是否有实际价值。它们有助于用户执行软件设计的功能吗？如果认为它们没必要，就要研究一下找出它们存在于软件中的原因。
总之，不要让易用性测试的模糊性和主观性阻碍测试工作。易用性测试的模糊和主观是固然的，即使设计用户界面的专家也会承认有的地方是这样的
GUI常见的测试要求
窗口
* 窗口能否基于相关的输入或菜单命令适当的打开
* 窗口能否改变大小、移动和滚动
* 窗口中的数据能否用鼠标、功能键、方向箭头和键盘操作
* 当被覆盖的窗口重新调用后，所有相关功能是否可操作
* 能否使用所有窗口的相关功能，所有相关功能是否可操作
* 相关的下拉式菜单，工具条，滚动条，对话框，按钮，图标和其它控制有否？能否正常显示？完全可用？
* 显示多窗口时，窗口名能否正确显示，活动窗口是否加亮
* 使用多用户时，所有窗口是否能实时更新
* 多次或不正确按鼠标是否会产生无法预测的结果
* 窗口的声音、颜色提示和窗口的操作顺序是否符合需求
* 窗口能否正确关闭
数据项
* 字母、数据能否正确显示且输入系统
* 图象方式数据项（如滚动条）是否正常工作
* 数据输入、消失是否可以理解，能否识别非法数据
下列式菜单和鼠标操作
* 菜单条显示在合适语言环境中
* 应用程序的菜单是否显示系统相关特性
* 下拉式操作是否正确，功能是否正确
* 菜单、调色板和工具条是否能正常的工作
* 能否列出所有菜单功能和下拉式功能
* 能否通过鼠标操作所有菜单的功能，通过文本命令激活每个菜单功能
* 菜单功能随当前窗口操作加亮或变灰
* 如果要求多次点击鼠标或鼠标有多个按钮时能否正确识别
* 光标、处理指示器和识别指针能否随操作而适当改变
UI测试常见BUG
录入界面
1. 输入字段要完整，且要与列表字段相符合（参照数据库进行检查）
2. 必填项一律在后面用*表示（必填项为空在处理之前要有相关的提示信息）
3. 字段需要做校验，如果校验不对需要在处理之前要有相关的提示信息
(1) 长度校验
(2) 数字、字母、日期等等的校验
(3) 范围的校验
4. 录入字段的排序按照流程或使用习惯，字段特别多的时候需要进行分组显示
5. 下拉框不选值的时候应该提供默认值
6. 相同字段的录入方式应该统一（录入方式有以下几种：手动输入 、点选 、下拉选择、参照）
7. 录入后自动计算的字段要随着别的字段修改更新（如单价变后，金额也变）
8. 日期参照应该既能输入，又能从文本框选择
界面格式
1. 字体颜色、大小、对齐方式（根据字段的性质确定）、加粗的一致性
2. 文本框、按钮、滚动条、列表等控件的大小、对齐、位置的一致性
3. 所有新增、修改、查看页面加上页面说明（如：XXX新增、XXX编辑、XXX查看等说明字样），（弹出的）界面要有标题，标题与内容要一致
4. 不同界面显示相同字段的一致性（如列表界面和编辑界面）
5. 界面按钮显示要求（查询、新增、删除顺序）
6. 列表的顺序排列应该统一（按照某些特定条件排序）
7. 下拉框中的排列顺序需要符合使用习惯或者是按照特定的规则排定
8. 所有弹出窗口居中显示或者最大化显示
9. 信息列表中如果某个字段显示过长用“…”或者分行显示
10. 人员、时间的缺省值一般取当前登录人员和时间
11. 对于带有单位的字段，需要字段的标签后面添加如下内容：“（单位）”
功能问题
1. 按钮功能的实现（如返回按钮能否返回）
2. 信息保存提交后系统给出“保存/提交成功”提示信息，并自动更新显示
3. 所有有提交按钮的页面都要有保存按钮（每个界面风格一致）
4. 凡是点选或者下拉选择的界面，如果一旦选择完了无法回到不选择的情况，需要加上“清除选择”功能按钮（即空白选项）、还需要有一个‘全部’选项。
5. 没有选择记录点击删除/修改按钮要提示“请先选择记录”
6. 选择记录后点击删除按钮要提示“确实要删除吗？”
7. 需要考虑删除的关联性，即删除某一个内容需要同时删除其关联的某些内容（当存在关联的数据时，此记录应该不能删除，必须将其关联的记录先删除，才能再回到此界面将此记录删除）
8. 界面只读的时候（查询、统计、导入）等，应该不能编辑。
查询问题
1. 查询条件缺少一些可以查询的字段（在查询条件中应当将可以进行查询的字段都列举出来并支持该字段的查询），
查询条件分为：可输入和枚举型（点选、框选、下拉框选择、日期选择：‘年月日分开选择’或‘弹出日期选择界面’）等两大类。
2. 有些查询条件需要支持模糊查询：关键字查询即部分匹配
3. 需要考虑有些查询条件本身的关联性（即某个查询条件的取值范围是依赖于其它查询条件的取值）：
即查询条件的过滤功能
（比如第一个下拉框选择选择‘浙江省’，则第二个下拉框自动过滤出属于浙江的地区名称如‘绍兴市、宁波市、杭州市…等’；选择其中一个，则在第三个下拉框中出现该地区包括的县级城市名称）
4. 查询条件名称与信息列表及信息编辑页面相应的字段名称完全统一
5. 不同模块相同字段的查询方式应该统一（手动输入 、点选 、下拉选择）
不同模块相同字段显示的字段名称应该完全统一。
6. 出报表的时候，查询条件需要显示在报表标题的下面，这样看报表的时候知道数据的依据是什么。
7. 对于范围的查询采用全闭的形式。
输入数据的设计方法和测试用例设计方法
测试用例的设计是测试设计的重要内容，关于测试用例的设计方法，当前不少出版的测试书和发表的测试文章，不少存在着表述错误，主要是把测试用例中的输入数据的设计方法与测试用例的设计方法混为一谈，对测试初学者和测试用例设计人员产生误导。
这种错误的主要表现举例如下：
测试用例的设计方法包括：
(1)等价类划分法
(2)边界值法
(3)功能图与判定表法
(4)错误推测法
(5)用户场景法
(6)......
其实，测试用例中输入数据的设计方法只是测试用例设计方法的一个子集，上面列出的集中方法都是确定黑盒测试用例的输入测试数据的一般方法，而不是测试用例的设计方法。
除了确定输入数据之外，测试用例的设计还包括如何确定测试用例的设计策略，如何组织设计用例，如何从测试需求等文档创建完整的测试用例。
对测试执行人员来说，测试用例的表示内容包括以下几个方面：
(1)测试用例的测试目标
(2)测试用例的被测功能点描述
(3)测试用例的测试运行环境
(4)测试用例的执行方法(包括测试步骤，输入测试数据或测试脚本)
(5)测试期望的结果
(6)执行测试的实际结果
(7)其他辅助说明
从以上几点，我们可以看到输入测试数据只是设计测试用例的一个步骤，而不是全部。
测试用例的设计是一项复杂的测试工作，测试用例的设计方法需要考虑测试的目标，被测试软件的特性，测试者人力资源的技术和能力，测试组织形式，测试进度、测试成本等多个方面。