1.易用性
用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
易用性细则：
- 完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷键
- 完成同一功能或任务的元素放置在集中位置，减少鼠标移动的距离
- 按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题
- 界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能
- 界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前，位置也应放在窗口上比较项目的位置
- 同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示
- 分页界面要支持在页面间的快捷键切换，常用组合快捷键Ctrl+Tab
- 默认按钮要支持Enter以及选操作，即按Enter后自动执行默认按钮对应操作
- 可写控件检测到非法输入后应给出说明并能自动获得焦点
- Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式
- 复选框和选项框按选择几率的高底而先后排列
- 复选框和选项框要有默认选项，并支持Tab选择
- 选项数相同时多用选项框而不用下拉列表框
- 界面空间较小时使用下拉框而不用选项框
- 选项数叫少时使用选项框，相反使用下拉列表框
- 专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼
2.规范性：
通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。
规范性细则：
- 常用菜单要有命令快捷方式
- 完成相同或相近功能的菜单用横线隔开放在同一位置
- 菜单前的图标能直观的代表要完成的操作
- 菜单深度一般要求最多控制在三层以内
- 工具栏要求可以根据用户的要求自己选择定制
- 一条工具栏的长度最长不能超出屏幕宽度
- 工具栏的图标能直观的代表要完成的操作
- 工具栏太多时可以考虑使用工具厢
- 工具厢要具有可增减性，由用户自己根据需求定制
- 工具厢的默认总宽度不要超过屏幕宽度的1/5
- 状态条要能显示用户切实需要的信息，常用的有：
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示 - 滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比
- 状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄
- 菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感
- 菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调
- 右键快捷菜单采用与菜单相同的准则
3.美观与协调性界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。
美观与协调性细则：
- 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
- 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
- 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
- 按钮的大小要与界面的大小和空间要协调。
- 避免空旷的界面上放置很大的按钮。
- 放置完控件后界面不应有很大的空缺位置。
- 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
- 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。
- 如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
- 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
- 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
- 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。
- 对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
- 通常父窗体支持缩放时，子窗体没有必要缩放。
- 如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等
4.界面检查
- 进入一个页面测试，首先是检查title，页面排版，字段等，而不是马上进入文本框校验
- 页面名称title是否正确
- 当前位置是否可见你的位置：xxx>xxx
- 文字格式统一性
- 排版是否整齐
- 列表项显示字段是否齐全，列表项字段名称是否跟表单统一
- 同一页面，是否出现字段名称相同、取值不同的问题
- 数据加载情况：除文本框的值，还要注意:复选框，是否保存打√，或者保存不打√
- 下拉框，是否保存选择的值
- 多文本框，值是否都被保存，空格，换行是否保存
5.单文本框
- 边界：字段长度
- 判断：是否可以为空
- 唯一性：是否唯一
- 特殊符号测试输入：' or 1<>'1 ' or '1'='1 ' or '1'<>'2 "|?><
>>
- 特殊字段输入限定：框内容是否合法（tel，ip，url，email）序号等，直接限制输入数字，其他过滤掉
- 输入金额文本框，整数首位为0，过滤掉，小数点后面，一般保留两个有效数字
- 正确性测试：
1)、(字段长度输入最大允许长度时)数据允许长度的测试： a、页面是否被挤出的测试(都输入长英文字符串，是否断行)； b、数据库是否允许最大字符(都输入汉字、都输入英文、混合……)； c、最短长度的正确流程，最大长度的正确流程覆盖。 2）、对于允许为空的字段，不填入，再次数据传递后，看是否报500错误。 3）、未规定字段长度（或者数值大小），不按死板输入，输入非常多字符（或者非常大的数值）时，做允许动作的正确性校验，看是否报错。(要达到的结果：不管有没有长度限制(没有给最长、最大限制让你去测？)，最终页面不能抛数据库异常。)monkeytest 说明：通过不断输入长字符串，看是否有长度校验； 最终都会出现以下两种情况的一种： A、页面(前台)有校验长度、大小； 或者 B、无校验，数据库报错。 所以： 所有字段都要做长度、大小限制(不管需求有没有给出明确要求，不管测试颗粒度，都要限制长度，不允许报数据库错误，都要测！！！)。最大长度限制可限定方法：1、不允许再输入；2、自动截断处理，并且给用户提示。关于长度概念： 1、 数据库规定的字节长度A 2、 页面上可以输入的字符数B 控制方法： 1）、页面上，不管输入什么字符（全角如汉字、半角如字母），统一规定不能超过B个字符，此种限制， 测试点：全部输入全角B个，测试（B*3字节）会不会超过数据库字节长度 全部输入半角B个，测试（B*1字节）会不会超过数据库字节长度 混合输入全角X半角Y，测试（X*3+Y字节）会不会超过数据库长度 2）、页面上，不以字符统计，以总的输入字节数统计，比如，全部输入全角字符，允许可以输入A/3个字符，全部输入半角字符，允许输入A个字符（ 民生网的设计） 测试点：全部输入全角，看是否允许输入A/3个字符 全部输入半角，看是否允许输入A个字符 混合输入全角X，半角Y，看是否允许X*3+Y=A (5个：判空、唯一、边界值、特殊字符、正确流程(多种数据、多种分支)) +测试校验位置：ajax鼠标事件校验、前台提交按钮js校验，服务器拿到数据后再次验证6.多文本框
1)、空格和换行的问题，看需求，是否需要做支持HTML Encoding 输入全部空格时，是否判空处理？””空格， 。 输入折行，是否也显示折行？ 比如：列点说明原因，就需要支持。 2)、字母截断的问题 对于一串字母，开发人员往往会忘掉做截断，这样如果展示在我们的平台上的话，这一串字母就会把我们的UI撑开 3）、长度控制格式， 您还可以输入*个字符7.添加按钮
- 添加动作检查范围：
- 失败：是否提示
- 提示内容是否正确
- 失败时：保存用户已输入的内容，避免重新再输入
- 成功：对话框消失
- 记录是否可直接查看（还需要刷新？）
- 列表记录顺序
- 重复提交情况，点击一次后，是否变成disable
- 上传附件的添加：
A. 文件名称：文件名称很长；文件名称字符多样化(汉字，英文，符号)；文件名称重复。 B. 判空？ C. 附件格式类型支持？ D. 附件个数？ E. 附件空间大小8.移除按钮
- 一般都要在前后台先给出一个提示操作“确定移除该......”(二次确认)
- 相关联的东西，是否需要限制移除“该类型下存在应用，无法移除”有到后台比较
- 确定后，真正执行移除操作
结果:
移除后，列表中数据是否立即消失
必须有确认删除的提示信息9.列表
- 列表记录顺序
- 是否需要翻页、有没有翻页功能
- 字段名称是否与表单一致
10.搜索-文本框
- 功能点、需求点考虑：
是否提供模糊查询、输入数值有种类有限定时，是否考虑换成下拉框搜索；- 检查点：
文本框值是否消失（是否回填条件值），再次点击“查询”可查看所有记录
考虑搜索结果：是否存在分页，分页是否正常，是否有序
注意：分页是否仍保存查询条件，检查后面的记录是否符合条件- 查询数据多样性：
输入不存在的字段值测试，包括特殊字符查询测试，例如：'or'1'='1;
输入类似程序语句的条件时是否执行查询，如：xxx"xxxand;- 操作类型：
1.不输入的查询
2.输入全部空格的查询
3.模糊查询（输入部分字段，或者说，输入英文字母，查询到相关文中数据）
4.输入不存在的查询
5.输入存在的查询
6.单个查询和多个条件复合查询11.搜索-下拉框
- 检查点：
1.搜索结果是否有序
2.下拉框值是否齐全（下拉框值本身也是一个动态查询的结果）
3.下拉框值是否自动消失，再次点击“查询”可查看所有记录（是否要回填条件值）
4.分页时，是否保存搜索条件（从UI、开发、业务逻辑、用户使用等角度测试）以上总结的， 是比较纯粹的从页面控件角度测试点出发， 对于完整测试一个整体页面，需要各类测试有机结合起来：
1）UI测试： 页面布局； 页面样式检查；控件长度是否够长；显示时，是否会被截断；支持的快捷键，Tab键切换焦点顺序正确性等。
2）功能测试：页面上各类控件的测试范围，测试点，可参考上方 结合控件的实际作用来补充检查点： 比如， 密码框是否*显示， 输入是否做trim处理等
3）安全测试：输入特殊字符，sql注入，脚本注入测试 后台验证测试，对于较重要的表单 ，绕过js检验后台是否验证 数据传输是否加密处理，比如， 直接请求转发，地址栏直接显示发送字符串？ 数据库存储，特别密码等，是否加密形式存储
4）兼容性测试
5）性能测试12.常见功能点测试思路
- 新增 或 创建（Add or Create）
.1 操作后的页面指向
.2 操作后所有绑定此数据源的控件数据更新，常见的排列顺序为栈Stack类型，后进先出
.3 取消操作是否成功- 编辑 或 更新 (Edit or Update)
.1 操作后的页面指向
.2 操作后所有绑定此数据源的控件数据更新
.3 取消操作是否成功
.4 编辑界面是否读取出正确、全部的数据源
.5 记录在工作流中的编辑功能可用性
.6 操作成功的生效时刻及生效范围- 删除 或 移除 (Delete or Remove)
.1 操作后的页面指向
.2 操作后所有绑定此数据源的控件数据更新 (如下就是删除后，Tab数据没有立即刷新的bug)
.3 取消操作是否成功
.4 记录在工作流中的编辑功能可用性
.5 操作成功的生效时刻及生效范围（比如：购物网站，店家商品下架后，并没有同时删除买家的购买记录）- 选中 或 全选 (Check or Check all)
.1 多页面中，全选对所有页面是否有效
.2 支持多页面的个别选中，且返回查看时保留选中状态
.3 界面上的按钮的操作范围是否均受选中功能控制
.4 前一页选中状态，在翻页后，应保留原来状态
.5 先全选-》移除某个单选-》全选按钮是否移除选中状态