软件测试界面测试规范.docx
《软件测试界面测试规范.docx》由会员分享，可在线阅读，更多相关《软件测试界面测试规范.docx（28页珍藏版）》请在冰点文库上搜索。
软件测试界面测试规范
软件界面测试规范
1概述
未来的软件设计将是以用户为中心的时代，用户的需求将引导软件的设计与研发过程。
腾讯QQ和盛大公司之所以淘汰了无数同行而成为行业楚翘，并非是广大用户青睐他们，而是他们的产品始终关注了最终用户的真实需求，通过庞大的用户量战胜了竞争对手。
一直以来，很多人对行业软件的印象始终是“功能基本实现，界面可以忍受”，同样是软件，为什么行业软件的界面就不能像通用软件那样做好一些呢？
对我们公司来说，用户使用了我们的软件后，就和我们公司产生了相应的联系，我们公司的形象，就通过他们正在使用的软件体现出来。
良好的界面对于宣扬我们的企业文化和业务理念都会产生积极的影响。
因此无论是出于公司规模越来越大的形象考虑，还是从市场竞争的角度出发，都需要我们在软件界面上下功夫。
长期以来，我们在测试的过程中，对于界面测试也一直在进行，但由于缺乏统一的标准，各个产品线，各个项目之间都有所差异。
本规范是在对以前开发和测试中的经验进行总结后，对软件界面测试的一份指导性文件，对软件界面测试过程中所涉及到的测试理论和测试标准进行总体规范，以有效保证软件产品的质量。
在此基础上，进行了一些扩展，从易用性、规范性、健壮性等方面建立一些界面测试检查条目（界面测试检查单），用来对我们的产品界面进行指导性的测试。
2界面设计与测试理论
在激烈的市场竞争中，仅仅有强大的功能是远远不够的，界面一直是相当重要的一个评判标准。
我们在软件研发过程中，必须时刻记得这一点。
2.1界面设计理论
软件只是一种工具，而软件与人的信息交换是通过界面来进行的，我们一直使用的软件图形用户界面有时也被称为WIMP，表现了它的四种特有属性，即窗口（Window）、图标（Icon）、菜单（Menu）、鼠标指针（PointingDevice）。
它的特点是操作直观、提供指针支持及界面图形化。
一般来说，软件人机界面设计需考虑以下问题：
1）界面总体布局设计：
即如何使界面的布局变得更加合理。
例如，我们应该把功能相近的按钮放在一起，并在样式上与其他功能的按钮相区别，这样用户使用起来将会更加方便。
2）操作流程设计：
即通过设计工作流程，而使用户的工作量减小，工作效率提高。
例如：
我们如何才能让用户用最少的步骤，完成一项操作。
使用别的软件，鼠标要点击50下，在屏幕上移动20000个像素的距离才能完成，而使用您的软件只需要点击鼠标25下，在屏幕上移动5000个像素就能完成。
那么用户在使用您的软件时就要比使用其他软件工作效率提高四倍，那么用户自然会选用您的软件了。
3）工作界面舒适性设计：
即使用户更加舒适的工作。
例如：
我们用什么样的界面主色调，才能够让用户在心情愉快的情况下，工作最长的时间而不感觉疲倦呢？
红色：
热烈，刺眼，易产生焦虑心情。
蓝色：
平静，科技，舒适。
明色：
干净，明亮，但对眼睛较多刺激，长时间工作易引起疲劳。
暗色：
安静，大气，对眼睛较少刺激。
微软公司公司浅灰色的系统主色调及ICON协调的成功运用，已经促使目前国际所有的软件产品形成一种的规范，这也是微软成功的重要因素之一。
4）正规的理解及调查需求：
MAC的外壳色彩创新带动了现在所有机器的个性化，但早在以前ACER也出过墨绿色的机箱，但却很失败。
原因有两个，一个是设计的还是不够，另外就是时机不好，因为当时大众的品位还不够。
我们需要对合作伙伴的需求进行正规的分析规划，人机界面设计才可以得到正确实施。
由上可见，人机界面设计是一门综合性非常强的学科，它不仅借助计算机技术，还要依托于心理学，认知科学，语言学、通信技术及戏剧、音乐、美术多方面的理论和方法。
如果要制作出用户满意的界面，软件的界面设计一定要引起足够重视。
2.2界面测试理论
在界面测试的过程中，除了对设计的合理性和正确性进行检验外，更要从用户的角度来检验软件界面是否合格。
通常的，对于C/S应用程序的界面，测试范围包括以下内容：
1、易用性：
界面元素应该直观易懂，用词准确，没有模棱两可的字眼，要与同一界面上的其他元素易于区分，能望文知意最好。
理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
2、健壮性：
当输入数据非法时，软件能够做出反应、给出提示或直接进行处理，不会产生莫名其妙的结果，不会出现“死机”现象，用户的误操作不会引起程序的崩溃。
3、规范性：
通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：
界面遵循规范化的程度越高，则易用性相应的就越好。
对于WEB界面，由于界面有一定的主题，因此主要从一致性考虑，无论是控件使用，提示信息措辞，还是颜色、窗口布局风格，遵循统一的标准，做到真正的一致。
3界面测试检查单
3.1C/S应用程序：
1、安装检查单
序号
检查内容
强制
建议
说明
1
安装时显示的许可协议信息是否正确？
√
2
安装时是否可自定义目录？
√
3
当目录不存在时，是否可以建立目录？
√
4
选择目录后点“确定”或回车是否都可用？
√
5
是否安装到正确的目录？
√
6
安装时是否有next、back、cancel按钮来让用户控制安装过程？
√
7
每个界面的焦点按钮应该引导安装程序进入下一个合理操作？
√
8
安装过程的每个界面是否都支持键盘操作？
√
9
是否在正确的路径建立了正确格式的快捷方式（启动程序和卸载程序）？
√
10
安装过程中主动取消是否有提示确认信息？
√
11
安装过程中取消是否能回退之前的全部操作所产生的结果？
√
临时文件可有部分遗留，但安装目标位置不能有文件残留
12
安装过程中异常终止是否会影响下次安装？
√
13
安装后是否确实需要重新启动系统？
√
14
安装后需要的DLL是否全部安装？
√
15
帮助文件是否在指定目录下？
√
16
注册表的注册信息是否正确？
√
17
是否有日志文件，如有，是否记录正确？
√
18
安装过程是否需要连接服务端，如服务端未启动是否会发生错误？
√
19
程序安装后是否对其他应用程序产生影响？
√
20
安装时产生的临时文件是否全部删除？
√
21
程序运行所有必须的设置是否都可以通过界面进行配置？
√
22
使用后是否可以通过Uninstall程序或控制面板卸载应用程序？
√
23
卸载后，安装的文件、文件夹、注册表信息是否被删除？
√
24
覆盖安装是否可以将旧的目标文件全部覆盖？
√
25
在笔记本上安装运行是否有问题？
√
程序的安装和执行功能都要检查。
2、程序界面检查单
序号
检查内容
强制
建议
说明
1
应用程序的启动时间是否少于10秒？
√
通常情况下，程序启动应在10秒内完成
2
启动程序的时间超过3秒，是否有进度条或动画显示？
√
3
程序在非系统默认分辨率下显示是否正常？
√
4
每个界面是否都可以从标题栏等信息得知当前用户所处的位置及可进行哪些操作，操作界面应该正确引导用户进行操作直到最后保存结果或提交命令。
√
对于弹出式界面和嵌套界面可不作要求
5
每个界面的风格是否和界面规范指定的一致？
√
按照实际项目的UI规范执行检查
6
是否立即响应用户的操作，如操作所需时间超过2秒，是否提示用户正在处理进行之中，并且鼠标形状改变为等待状态？
√
7
若操作时间超过5秒，是否有进度条或动画显示，并且操作可以取消？
√
8
鼠标的箭头形状要根据软件执行的任务发生变化，使用户能够明白当前软件处于什么运行状态。
√
9
菜单和界面功能键都对应有效操作，无效的功能需要屏蔽。
√
10
某一系列操作分为开始、中间和结尾，每一步操作需要给出相应的反馈。
√
11
快捷键需要和其他通用Windows软件及Windows系统保持一致，其他自定义的快捷键要方便键盘操作。
√
12
程序对快捷键的响应速度要快。
√
按照普通PC的配置进行衡量
13
界面导航菜单简洁方便，菜单深度不超过三层。
√
根据业务场景进行判断是否有必要使用多层菜单
14
界面信息和提示信息使用用户熟悉的业务术语，不使用技术术语。
√
15
关键业务操作需要记录日志，日志记录的信息是否能正确回推出原有的操作。
√
16
涉及配置变化的，都有保存提示，未保存前关闭程序也需要给出提示。
√
17
多窗口的界面，子窗口最小化时排列整齐，窗口间切换正确。
√
18
业务术语不要截短、简写，使用户误解。
√
19
用户操作需要请求数据输入时，需要提供合理的默认值。
√
20
自身程序已经加载的数据，在没有需要更新的情况下，不要再次请求数据。
√
21
翻译得体，没有拼写错误。
√
22
功能键的误操作不会引起应用程序崩溃。
√
23
表示程序关闭、与服务器建立连接、登陆、退出等术语之间含义明确、不混淆。
√
24
操作成功或失败，需要给出反馈，尽量在反馈中给出失败原因，错误提示应具有指示性，比较清晰，不包含技术术语，界面统一，出现错误的日志记录要详细。
√
25
界面操作应全程支持键盘操作，界面的TABORDER与输入习惯保持一致，回车进入下一个输入控件，全部输入完毕则执行默认操作，控件的排列顺序按照从上到下，同时行间从左到右的方式。
√
26
关于（About）界面包括应用程序名称和版本、厂商名称以及支持联系信息。
√
27
版本编号和命名保持最新且与文件名、帮助、关于界面以及配置文件中的信息一致。
√
28
操作使用说明和实际界面上的图片和描述要保持一致。
√
29
界面显示的信息对用户是必要的且尽量是全面的。
√
30
程序的配置可以备份，重新安装后导入配置文件即可使用。
√
31
功能图标贴切易懂。
√
32
同样的功能前后命名一致。
√
33
进入某个界面，焦点自动停留在用户常用功能的控件或用户大多数情况下第一个会输入的控件。
√
34
界面字体统一，在不同系统表现相同。
√
35
菜单栏上完成相同或相近功能的功能要放在一起，如果有菜单栏，则常用功能需要在工具栏建立快捷方式。
√
36
界面上完成同一功能或任务的元素要集中放置，减少鼠标移动的距离。
√
37
复选框和选项框按选择几率的高低顺序或业务上的要求进行排列，复选框和选项框要有默认选项，并支持Tab选择。
√
38
界面空间较小时使用下拉框而不用选项框，选项数较少时使用选项框，相反使用下拉列表框。
√
39
对于某些影响系统执行结果的改变需要给予提示或建议。
√
40
对话框、提示信息的大小写和对齐方式要统一并符合用户习惯，某些国家习惯从右往左读写而国内往往是从左往右。
√
41
状态条要能显示用户切实需要的信息，常用的有：
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息、当前功能的提示等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。
√
42
右键菜单要真实的体现当前所能操作的所有功能，不能进行的操作应灰化或屏蔽，避免无效功能。
√
43
多个单词组成的一个命令或者功能，一般每个单词首字母要大写，整个系统的命名规则要统一，对于整体表达一个含义的短语，在断行时不要分开。
√
44
对某些功能有浮动提示的，如果该元素位于界面左边或左上位置，当鼠标移动到该位置时，提示内容应该在右方或右下方显示，如果在右边或右下位置，提示内容则显示在左或左上的位置，提示内容不能和功能名称（caption或text）相同，必须是对其简单明确的描述。
√
45
输入文字中间或前后有空格、输入系统保留的或需要特殊处理的字符及语句时，程序应能处理（限制某些类型的输入或对其进行处理）。
√
46
ESC是否能退出当前界面或取消当前操作？
对于正在处理的任务或发生了修改的界面，退出前是否有提示。
√
47
界面上的查询结果，一般情况下应支持对字段名称单击进行排序的操作。
√
48
界面输入的完整性和约束在输入提交时需要校验，数据项完整性校验时光标焦点要能自动定位到错误处。
√
49
用户看到界面就能清楚相关功能，表单要尽量自我解释，不要设计过多的隐含在界面里面的功能。
√
50
能够自动获取数据不要让用户再去录入，能够选择录入数据不要让用户手工录入。
√
51
DBGRID类的数据显示控件应该在第一时间提供给用户检索数据，因此SQL存在性能问题时候要考虑分页并尽快显示第一页同时将后续的数据进行缓存。
√
作为选项使用的下拉框等控件内容需要一次性显示出来
52
同一界面不要出现超过3个的GRID控件。
√
53
对于提供的各种功能能够让用户方便的转到对应的帮助文件条目上。
√
54
C/S界面最外层不允许出现左右和上下滚屏，如果放不下，可使用多个页面显示。
√
页面内部的控件可酌情使用滚动条，一般情况下尽量避免
55
减少不必要的各种操作，能够点一次鼠标或敲一次键盘完成的绝不作出两次或多次。
√
56
一个完整的功能最好不要在多个窗口中切换才能完成。
√
57
不重新加载页面的界面之间切换时，切换后要保持原来界面的数据。
√
以满足方便操作和符合需要为准
58
一个菜单栏下，菜单项较多时，不同类别的菜单项之间要加分隔线。
√
59
同一组单选框的内容需要框起来。
√
3.2B/S应用程序
1.统一性检查
序号
检查内容
强制
建议
说明
1
数据操作区4个角为是否为圆角（例外：
页面空间不够大的情况下，可以不使用圆角）。
√
按照实际项目UI规范执行检查
2
插入列表和树结构时是否无嵌套边框（例外：
并排显示两个单元数据或类似情况时，可以使用嵌套边框）。
√
统一、美观
3
严格按照项目的界面CSS规范生成页面，各个元素的界面位置要求一致。
√
4
界面中表单标签、控件元素是否均横向向左、纵向对齐。
√
按照具体项目UI规范执行检查
5
CheckBox和文字标签是否紧靠（不宜相隔太宽）。
√
按照具体项目UI规范执行检查
6
功能上牵涉到增删改操作的输入框，是否为白底四周有边框的默认风格输入框，只作显示数据的输入框是否为灰显。
√
按照具体项目UI规范执行检查
7
可输入的界面元素处于只读状态时是否使用了只读样式。
√
具体样式按照项目UI规范执行检查
8
Textarea是否使用标准样式。
按照具体项目UI规范执行检查
9
Select是否使用标准样式。
按照具体项目UI规范执行检查
10
同一页面上的控件的行距、列距是否统一。
11
同一页面上的控件的长宽是否统一。
12
按钮是否使用标准样式，可用时文字是否为黑色，不可用时是否为灰色。
√
按照具体项目UI规范执行检查
13
当按钮的操作局限于某个区域内时，按钮是否置于该区域之内。
√
14
当按钮所作用的操作包括几个区域，按钮是否置于最外层的区域。
√
15
在设计多表格切换时，是否采用页签形式表现，选中页签背景与未中的标签背景要区分出来。
√
具体色调按照UI规范执行
16
NEW是否在操作区域的左部；文字前添加
。
√
按照具体项目UI规范执行检查
17
CLOSE按钮是否在操作区域右下部；文字前不添加
；Close前TR添加分隔线
。
√
按照具体项目UI规范执行检查
18
标准情况：
“Query”、“Reset”、“Search”，是否都放在操作区域内部，居右对齐，并且另起一行，不与其它控件并列一行。
√
19
特殊情况：
当查询条件较少，足够将查询条件以及Query、Reset或Search同一行显示，Query等操作是否放在同一行。
√
20
链接文字是否置于所操作的区域之内，是否根据界面安排情况，适当的居左或居右对齐。
但无论居左、居右都不可以紧靠在区域的边框。
√
21
树控件的链接列表，是否采用公用的样式，并且没有显示表头。
√
按照具体项目UI规范执行
22
表单的必填项是否在输入框后使用红色*来表示，并在二者之间存在一个空格。
√
23
树控件作为树时，不使用标题行，树控件作为列表使用时，必须使用标题行。
√
24
树控件标题栏是否留有纵向滚动条的宽度18px，即树控件的width和各列的宽度之和差18px，或使用百分比表示宽度时留有4％，树控件中尽量不要出现左右滚动条。
√
按照具体项目UI规范执行
25
分页显示是否采用标准风格显示。
√
按照具体项目UI规范执行
26
分页是否缺省显示3页，每次翻下3页。
√
按照具体项目UI规范执行
27
分页是否每页记录数可修改。
√
28
情态动词:
肯定句用should，否定句用cannot，避免语气过于强制。
29
输入时提示的信息格式统一。
√
按照项目UI规范执行（内容、格式、语法格式、语态）
30
操作成功或失败的提示信息格式统一。
√
按照项目UI规范执行（内容、语法格式、语态）
31
提示信息大于显示区域，或精简，或使用more按钮。
√
32
英文提示中的标点符号：
使用英文标点，如果不在句末，后面要空一格，
不要用逗号“,”连接两个完整的句子，用句号“.”连接，句号后面空一格。
英文提示的标点符号必须是英文字符，中文提示的标点符号必须是中文字符。
√
33
提示信息中是否没有拼写和语法错误。
√
34
查询提交较多时，界面中的“查询”与“重置”成对出现，另外，“确定”与“取消”成对出现。
√
35
界面是否整体向上、向左对齐靠拢。
√
36
B/S界面最外层尽量不要出现左右滚动条。
√
2.易用性检查
序号
检查内容
强制
建议
说明
1
初始进入页面，光标是否停留在第一个常用输入控件上。
√
2
因输入错误，在提交时进行提示后，光标是否定位到对应的输入控件，或者明确告知操作者错误位置。
√
3
界面数据更改后是否及时刷新。
√
4
是否杜绝了拼写错误。
√
5
提示信息是否能避免使用专业技术用语，使用直白、用户能理解的语言。
√
6
是否能避免使用太多的注释信息;如果实在需要，另外列出（如光标移动到目标上才显示全部信息）。
√
7
注释信息和提示信息中是否不显示叹号和带有激烈意味的词语。
√
8
当输入框中数据发生变化后，用户没有提交，点击关闭，是否提示用户是否保存数据。
√
9
光标位置和提示信息所表达的位置是否一致。
√
10
显示信息的时间是否过长或过短。
√
11
是否能避免显示用户无法看懂的错误，将错误信息翻译成用户能理解的词语。
√
12
常用按钮是否支持快捷方式。
√
13
完成同一功能或任务的元素是否能放在集中位置，减少鼠标移动的距离。
√
14
界面是否支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
√
15
界面是否支持键盘自动浏览按钮功能，即按回车鍵的自动切换功能。
√
16
Tab键的顺序与控件排列顺序是否一致，TAB顺序是否符合输入顺序。
√
升级会员 