一些经常使用模块的测试用例html
1、登陆 2、添加 三、查询 四、删除程序员
1、登陆web
①用户名和密码都符合要求（格式上的要求）sql
②用户名和密码都不符合要求（格式上的要求）数据库
③用户名符合要求，密码不符合要求（格式上的要求）编程
④密码符合要求，用户名不符合要求（格式上的要求）浏览器
⑤用户名或密码为空缓存
⑥数据库中不存在的用户名，不存在的密码安全
⑦数据库中存在的用户名，错误的密码服务器
⑧数据库中不存在的用户名，存在的密码
⑨输入的数据前存在空格
⑩输入正确的用户名密码
之后按[enter]是否能登录
2、添加
①要添加的数据项均合理，在界面保存成功后，检查数据库中是否添加了相应的数据：select查询
②留出一个必填数据为空
③按照边界值等价类设计测试用例的原则设计其余输入项的测试用例：数据组合测试
④不符合要求的地方要有错误提示
⑤是否支持table键
⑥按enter是否能保存
⑦若提示不能保存，也要察看数据库里是否多了一条数据
3、删除
①删除一个数据库中存在的数据，而后查看数据库中是否删除（界面删除一条数据，查看数据库中是否删除）
②删除一个数据库中并不存在的数据，看是否有错误提示，而且数据库中没有数据被删除[A1]
③输入一个格式错误的数据，看是否有错误提示，而且数据库中没有数据被删除。
④输入的正确数据前加空格，看是否能正确删除数据
⑤什么也不输入
⑥是否支持table键：tab键
⑦是否支持enter键
4、查询
精确查询：
①输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据
②输入正确的查询条件之前加上空格，看是否能正确地查出相应的数据
③输入格式或范围不符合要求的数据，看是否有错误提示：如日期格式：YYYY-MM-DD；范围：月份中输入13等，通常这些数据都是枚举型数据，如下拉框的形式出现
④输入数据库中不存在的数据
⑤不输入任何数据：查询结果应该为全部记录
⑥是否支持table键
⑦是否支持enter键
模糊查询：
在精确查询的基础上加上如下一点：
① 输入一些字符，看是否能查出数据库中全部的相关信息
故障模型---缺陷查找攻击的二十一招大法
1．输入非法数据
输入数据的类型、长度、边界值；还要留意错误信息自己。
基本数据类型的边界值
2．输入默认值
从选项按钮、配置面板等处去考察。
3．输入特殊字符集
根据被测软件的具体状况输入非法字符。
多了解ASCII 字符集、程序设计语言和OS中的保留字符串及其特定含义。
4．输入使缓冲区溢出的数据
在须要接受字符串的地方输入一个比最大字符串更长的字符串。
黑客经常使用此法来攻击系统。
5．输入产生错误的合法数据组合
在输入值之间存在依赖关系时，输入可能会出现问题的组合值。
6．产生同一个输入的各类可能输出
在同一输入对应多个输出时可用此法测试。
7．输出不符合业务规则的无效输出
列出全部的无效输出，而后逐一测试，重点查看输出结果的正确性。
8．输出属性修改后的结果
强制每一个输出产生，并编辑其属性，而后再次强制产生输出。
9．屏幕刷新显示
增长、删除、移动屏幕上的对象。
10．数据结构溢出
尝试将过多的值输入数据结构，测试上溢；尝试多删除一个数据，测试下溢。
11．数据结构不符合约束
任什么时候候都要对数据属性的约束进行检查，特别注意修改数据时也要进行。
可经过破坏内部数据的约束来进行测试。
12．操做数与操做符不符合
对于数值计算考虑操做数和操做符之间的限定关系；对于图形计算还要考虑各类输入数据之间的组合关系。
13．递归调用自身
考虑对象的自我交互或复制。
14．计算结果溢出
一次又一次地执行计算或使用很大或很小的输入和数据进行计算，重点测试数据类型的初始值或边界值附近的值，强制数据产生上溢或下溢。
15．数据共享或关联功能计算出错
当一个以上的功能在同一时间处于运行状态，能够考虑以点带面，重点测试某一功能，对可能与这个功能相连的其余功能附带测试。
16．文件系统超载
当软件较大，运行时须要较大空间时，强制磁盘系统满容量或小于等于被测试软件运行时所需容量后，运行被测试软件或利用测试工具模拟磁盘情况。
17．介质忙或不可用
软件运行须要消耗大量内存或须要其余相关软件同时运行，可经过启动大量程序或利用测试工具模拟磁盘情况。
18．介质损坏
用实际损坏介质的方法来测试应用程序。
19．文件名不合法
输入OS不容许的文件名和应用程序不容许的文件名。
20．更改文件访问权限
修改文件访问权限或用低权限的用户访问文件。
21．文件内容受损
对于那些须要对文件格式和内容进行校验的应用程序，可经过手工损坏文件或利用测试工具模拟CRC错误。
界面设计的行业标准总结一
GUI的总体标准包括如下四个方面：
1.规范性
2.合理性
3.一致性
4.界面定制性
1、GUI设计的规范
遵循一致的准则，确立标准并遵循，是软件界面设计中必不可必的环节。确立界面标准的好处：
1.便于用户操做：户使用起来可以创建起精确的内心模型，使用熟练了一个界面后，切换到另一个界面可以很轻松的推测出各类功能
2.使用户感受到统1、规范，在使用软件的过程当中愉快轻松的完成操做，提升对软件的认知
3.下降培训、支持成本，没必要花费较多的人力对客户进行逐个指导
2、GUI布局的合理性
界面的合理性是指界面是否与软件功能相融洽，界面的颜色和布局是否协调等。例如：
1.界面布局
a.屏幕不能拥挤
* Mayhew在1992年的试验结果代表屏幕整体覆盖度不该该超过40％，而分组覆盖度不该该超过62％。
* 整个项目，采用统一的控件间距，经过调整窗体大小达到一致，即便在窗体大小不变的状况下，宁肯留空部分区域，也不要破坏控件间的行间距。
b.控件按区域排列
* 一行控件纵向中对齐, 控件间距基本保持一致，行与行之间间距相同，靠窗体的控件距窗体边缘的距离应大于行间距。
* 当屏幕有多个编辑区域，要以视觉效果和效率来组织这些区域
c.有效组合
逻辑上相关联的控件应当加以组合以表示其关联性，反之，任何不相关的项目应当分隔开。在项目集合间用间隔对其进行分组，或者使用方框划分各自区域
d.窗口缩放时，控件位置、布局
* 固定窗口大小，不容许改变尺寸
* 改变尺寸的窗口，在窗口尺寸发生变化时控件的位置、大小作出相应的改变
* 改变尺寸的窗口，在窗口改变尺寸时增长相应在的纵向、横向滚动条，以方便用户使用窗体上的控件
2.界面颜色搭配
使用恰当的颜色，能够使软件的界面看起来更加规范：
a.统一色调
针对软件类型以及用户工做环境选择恰当色调，如：安全软件，根据工业标准，能够选取黄色。绿色体现环保，蓝色表现时尚清新、紫色表现浪漫等等，淡色能够令人温馨，暗色作背景令人不以为累等。
b.与操做系统统一，读取系统标准色表
c.遵循对比原则
在浅色背景上使用深色文字，深色背景上使用浅色文字，如蓝色文字以白色背景容易识别，而在红色背景则不易分辨。除非特殊场合，杜绝使用对比强烈，让人产生憎恶感的颜色
d.整个界面色彩尽可能少的使用类别不一样的颜色
e.颜色方案也许会由于显示器、显卡、操做系统等缘由显示出不一样的色彩
f.针对色盲、色弱用户，能够使用特殊指示符
e.颜色方案也许会由于显示器、显卡、操做系统等缘由显示出不一样的色彩
f.针对色盲、色弱用户，能够使用特殊指示符
3、GUI风格的一致性
界面的一致性既包括使用标准的控件，也指相同的信息表现方法，如在字体、标签风格、颜色、术语、显示错误信息等方面确保一致。
1.在不一样分辨率下的美观程度
软件界面要有一个默认的分辨率，而在其余分辨率下也能够运行，分别在800×600，1024×768，1280×768，1280×1024，1200×1600分辨率下的大字体、小字体下的界面表现。
2.界面布局要一致
如全部窗口按钮的位置和对齐方式要保持一致。
3.界面的外观要一致
如控件的大小、颜色、背景和显示信息等属性要一致，一些须要特殊处理或有特殊要求的地方除外。
4.界面所用颜色要一致
颜色的先后一致会使整个应用软件有一样的观感，反之会让用户以为所操做的软件杂乱无章，没有规则或言。
5.操做方法要一致
如双击其中的项，触发某事件，那么双击任何其余列表框中的项，都应该有一样的事件发生。
6.控件风格、控件功能要专注
a.不错误的使用控件
例如使用Button样式作Table的功能，拿主菜单条显示版权信息等
b.一个控件只作单一功能，不复用
若是在特殊状况下出现复用的时候，可采用如下两种方法解决：
* 分组，使用双份控件
* 使用Table页，给用户很明显的视觉变化
7.标签和讯息的措词要一致
如在提示、菜单和帮助中产生相同的术语。
8.标签中文字信息的对齐方式要一致
如某类描述信息的标题行定为居中，那么其余相似的功能也应该与此一致。
9.快捷键在各个配置项上语义保持一致
如Tab键的习惯用法是阅读顺序从从左到右，从上到下。在定义软件快捷键时也能够将现有一些快捷键的属性做为参考，如表1-3-1（见附件）列出了经常使用的快捷键及其功能。
4、GUI界面操做可定制性
界面的可定制性大体可分为如下几个特性：
1.界面元素可定制
容许用户定义工具栏、状态栏是否显示，工具栏显示在界面上的位置；容许用户定义菜单的位置等。
2.工具栏可定制
不一样用户对经常使用工具的使用是不一样的，所以容许用户创建新的工具栏，选择要显示的工具栏，定制工具栏上的按钮等功能在软件系统中常常被用到
3.统计检索可定制
对于某些特殊行业的软件能够提供统计检索的可定制性，在充分了解用户需求的基础上制定大量的安全供用户选择。
GUI所包含各种元素标准的定制
GUI的元素大体可分为如下几个方面：
1. 窗口
2. 菜单
3. 图标
4. 控件
5. 鼠标
6. 文字
7. 联机帮助
界面设计的行业标准总结二
1、GUI窗口的标准
窗口是显示设备中的一个区域，用于观看对象、对象相关信息以及应用与对象的动做进行交互。从外观上来讲，一般窗口是由标题、边框、菜单、工做区、滚动条等组成。窗口的标题栏能够进行打开、关闭、建立、缩放、移动、删除、重叠等操做
好的GUI窗口应该具有如下标准：
1.窗口控件的大小、对齐方向、颜色、背景等属性的设置和程序设计规约相一致
2.显示相关的下拉菜单、工具条、滚动条、对话框、按钮、图标和其余控制，既能正确显示又能调用
3.若窗口没法显示，全部内容可以改变大小、移动和滚动
4.活动窗口可以反显加亮
5.窗口可以正确的关闭
6.多个窗口叠加时窗口的名称正确显示
8.当窗口被覆盖并从新调用后，窗口可以正确再生
9.若是使用多任务，全部的窗口可以被实时更新
10.窗口支持最小化和最大化或放大
11.窗口上的控件随着窗体的缩放而缩放
12.父窗体支持缩放时，子窗体也应该支持缩放
13. 一个窗口中按Tab键，移动聚焦按顺序移动。先从左至右，再从上到下
14.子窗口位置在父窗口的左上角或正中，正上方1/4处为易吸引用户注意力的位。父窗口或主窗口的中心位置应该在对角线焦点附近，以下图2-1-2所示
15.当多个子窗口弹出时依次向右下方偏移，而且显示出窗口标题，以下图2-1-3所示
16.重要的命令按钮与使用频繁的按钮放在了界面醒目的位置
17.与正在进行的操做无关的按钮应该加以屏蔽
18.按钮大小要与界面的大小和空间协调
19.窗口中所包含的标签左对齐排列
20.多窗口的切换响应时间不宜过长
2、GUI菜单的标准
菜单是否易用主要体如今它可否提供线索帮助用户识别，而不用强迫用户去记忆，一个好的菜单设置能够分为如下几个方面：
1.菜单设置符合软件的需求
2.菜单项的措词准确，可以表达出所要进行设置的功能
3.菜单项的顺序合理，具备逻辑关联的项目集中放置
4.图形布局一致
5.菜单设置在窗体标题栏的下方
3、GUI图标的标准
图标是表示实体信息简洁、抽象的符号，它还能够做为可视按钮项，当被选中激活时，能够完成指定的功能。那么图标的设计当中应该着重考虑哪些问题呢，如下提供几点可供参考：
1.图标的设置符合常规的表达习惯
2.不一样的目标采用不一样的图标
3.图标具备清晰的轮廓，轮廓清晰的图标可保证图像在不一样背景色上都具备较好的效果
4.选择合适的尺寸来定义图标。Windows XP系统的图标有四种尺寸（以像素为单位）可做为参考： 48×48， 32×32，24×24以及16×16，图标大小的选取决定于工具栏所定义的宽度
5.图标的外形与实际功能类似，应尽可能避免抽象。这样的图标能够使用户很轻松、容易地认识图标的做用
6.在图标上加以标注，用来讲明图标所完成的功能
7.图标放置在菜单栏的下方
4、GUI中控件的标准
软件系统功能的实现与控件是密不可分的，各控件位置的摆放直接影响到软件的使用，及其美观程度。下面举例说明软件系统中最经常使用到的控件对其元素间距、摆放位置进行说明：
1.控件元素的间距
a.单个元素间距
* 输入框之间垂直间距为5px
* Label文本标签和输入元素之间水平间距为8-22px
* 复选框、单选按钮之间垂直间距为8px
* 多种元素混合垂直排列时，复选框和单选按钮边上的间距不管在什么状况下都为8px
b.元素分组间距
* 窗口边框和内容区域的四周边距为11px；
* 父组和子组之间的四周间距为10px；
* 分组框边框和内部内容区域的四周边距为5px；
* 复选框组、单选框组的组水平间距为15px
2.按钮的位置，以下表2-4-1对按钮摆放位置的规则作了总结
5、鼠标在GUI中的标准
用户会把鼠标移进、移出窗口，或当光标在窗口，或当光标在窗口中，用户按下、释放鼠标键，鼠标是否准确、灵活，对一个软件系统来讲也很重要。如下几点标准可做为在软件系统中鼠标设计的参考：
1.在整个交互的过程当中，能够识别鼠标操做
2.屡次点击鼠标后，仍可以正确识别
3.鼠标有多个按钮的状况下，可以正确识别每一个按钮所要完成的功能
4.光标、处理指示器和识别指针随操做恰当的改变
5.点击选中时，鼠标指针停留在选中内容上，而不会滑动
6.支持鼠标滑轮上下翻动操做
7.对于相同种类的元素采用相同的操做激活
8.采用动态图标形象的表示出当前的操做，如用水漏表示系统忙，用手型表示能够点击等
9.鼠标无规则点击时不会产生不良后果
10.单击鼠标右键弹出快捷菜单，取消右键后该菜单隐藏
11.鼠标光标样式统一，尽可能使用系统标准，杜绝出现重复的状况
6、GUI文字的标准
文字在视觉上向用户传达各类信息，界面文字包括界面文字的字体和界面文字的用语两个方面，那这两方面都有哪些要求呢？如下分别阐述。
1.字体
a.使用统一字体，如规定软件系统的中文字体为“宋体”，英文及数据采用“Times New Roman”
b.全部控件、描述信息尽可能使用大小统一的字体属性，除了特殊提示信息、增强显示等例外状况
2.文字表达
提示信息、帮助文档文字表达遵循如下准则：
a.口语化描述，用词客气多用您、请，不要用或少用专业术语，杜绝错别字
b.标点符号（断句、逗号、句号、顿号、分号）的用法要统一， 提示信息比较多的话要进行分段
c.警告、信息、错误 使用对应的表示方法
d.使用统一的语言描述，例如一个关闭功能按钮，能够描述为退出、返回、关闭，则应该统一规定
e.根据用户不一样采用相应的词语语气语调
7、GUI联机帮助的标准
帮助文档适用于如下三种状况：
* 系统默认、行业标准的控件操做不须要逐一描述，只须要对特殊控件加以描述
* 特殊操做、特殊功能界面，在界面上加控件直接链接到对应的帮助文件中
* 特殊设置的详细信息，除了应该在界面上用简洁明了的语句说明外，还能够在界面上加控件直接链接到对应的帮助文件中
帮助文档的标准要求：
* 结构化，按功能模块划分
* 必须阐述功能经过什么方法能够在软件中实现
* 措词恰当、简捷、通俗易懂，明了的帮助用户解决问题
* 不在帮助文档中作广告宣传
浅谈易用性测试及GUI常见的测试要求
对于一个须要面对用户的软件产品来讲，最直观的UI和使用感觉也是产品可否得到用户承认的关键一环。我的认为，在毒霸的产品传统中，从设计到开发再到测试，对产品的易用性和GUI的规范每每给予的关注较少。我在测试过程当中就遇到了不少影响使用心情的非关功能方面的 BUG。但愿此文能够在毒霸的易用性和GUI方面的测试中给同窗们提供一些参考。
易用性测试
易用性(Useability)是交互的适应性、功能性和有效性的集中体现。
在《软件工程产品质量》质量模型中，提出易用性包含易理解性、易学习性和易操做性；即易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。易用性测试包括针对应用程序的测试，同时还包括对用户手册系统文档的测试。一般采用质量外部模型来评价易用性。包括以下方面的测试：
(1) 易理解性测试
(2) 易学性测试
(3) 易操做性测试
(4) 吸引性测试
(5) 易用的依从性测试
易用性测试方法有：静态测试；动态测试；动态和静态结合测试。
因为易用性缺陷的主观性，所以测试人员和UI设计人员常常产生不一样意见。UI一般被看成创造者的做品，而测试人员说某处是错误，就可能挫伤“艺术家”。易用性是软件缺陷中的敏感问题。
人体工程学(ergonomics)是一门将平常使用的东西设计为易于使用和实用性强的学科。人体工程学的主要目标是达到易用性。
一、用户界面测试
用于与软件交互的方式称为用户界面或UI。
二、优秀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)其余辅助说明
从以上几点，咱们能够看到输入测试数据只是设计测试用例的一个步骤，而不是所有。
测试用例的设计是一项复杂的测试工做，测试用例的设计方法须要考虑测试的目标，被测试软件的特性，测试者人力资源的技术和能力，测试组织形式，测试进度、测试成本等多个方面。
网站测试清单
通用
◇ 全部测试是否运行在干净系统上？
◇ 系统是否正常运行？
◇ 是否显示正确输出？
◇ 系统是否能提供所需功能？
◇ 普通用户是否能轻松地操做该系统？
◇ 是否易学易用？
◇ 系统是否会为客户提供服务？如响应的、有帮助的、正确的服务？
◇ 是否能够简单辨别系统的正确性与可靠性？
◇ 是否能轻易地修复或修改系统？
◇ 当系统须要提交或修复时，开发人员是否能够在限期内完成？
◇ 新版本中未经修改的功能是否能与老版本保持一致？
◇ 系统是否能使硬件、网络及人力资源获得有效利用？
◇ 系统是否能匹配相关的技术水平？
◇ 系统是否能匹配适当调整的需求？
◇是否能够有效验证系统的工做方式是适当的？
◇ 本系统内一些组成部分是否能够被其余的系统再利用？
◇ 不一样用户不一样平台上安装系统是否一样快捷便利？
◇ 系统是否设置有将来更新的路径？
◇ 是否能够方便地获取信息？
◇ 网站是否能被搜索？
可用性、界面及导航
◇ 系统为一个用户、十个用户或一千个用户服务时，是否一样工做正常？
◇ 是否能够快速登录主页？
◇ 网站的操做方法是否清晰地展现给用户？
◇ 若是按操做方法进行操做是否能够获得预期结果？
◇ 是否全部新用户都理解网站内的全部术语？
◇ 是否全部窗体都有导航栏？
◇ 导航栏的位置是否始终保持一致？
◇ 是否导航栏仅做用于使用中的文本？
◇ 用户是否能够在不用鼠标的状况下使用导航栏功能？
◇ 视力障碍者是否能够使用网站？红绿色盲，少于 20/20
◇ 网站标志是否风格一致？
◇ 每一个单独页面内是否包含主页连接？
◇ 每一个页面的排版是否统一？
◇ 每一个页面的管理风格是否一致？
◇ 网站内图表的使用是否协调？
◇ 快速下载的图表是否质量优化？
◇全部图片是为页面添彩，仍是浪费网速？
◇ 是否使用了图表的最佳尺寸？
◇ 图表/图片周围的文字布局是否合理？
◇ 是否对全部的参考网站或电子邮件地址都设置了超连接？
◇ 超连接颜色设置是否标准？
◇ 网站在 1024x 76八、600x800 等像素下是否显示正常？
◇ 字体是否过小（切忌并不是每一个人都能得到相同的视图效果）？
◇ 字体是否太大？
◇ 全部文本是否排列适当？
◇ 全部图标是否排列适当？
◇ 图片是否能被完整打印？
◇ 网站内是否有站内地图？
◇ 站内地图的每一个超连接是否有对应的目标连接页？
◇ 站内地图是否包含了网站内全部的超连接？
◇ 每一个页面的超连接是否正常工做？
◇ 内容是合法正确的（非单元测试期间开发者设置的填充内容）
◇ 页面背景（颜色）是否会分散注意力？
◇ 返回按钮是否正常工做？不会打开一个新的浏览器窗口，或重定向其余站点。
◇ 返回上页或转至新页面时，是否会致使本页面内容丢失？
◇ 从主页开始是否能够经过 3 次或更少的点击数到达目标页面？
◇ 图表或表格中的内容是否完整？是否正确列出？是否能肯定所选文本处于图表或表格的正确区域内？
◇ 页面上的连接是否和先前一致？有没有新出来的或消失的连接？
有没有连接失败的状况？
◇ 点击连接是否能到达正确的目标页面？
◇ 目标页面是否存在？
◇ 站主的联系信息是否能从网站中得到（姓名、电话、电子邮件地址、邮寄地址、传真号）？
◇ 若是用户须要为某个页面做标签，该页面的名称是否易懂？
◇ 若是用户有获取历史页面纪录的权限，那网站地址是否会出如今 History 列表中？
◇ 网站页面的状态栏是否真实反映出页面登录的进度、信息等？
表格
◇ 表格是否过长，常常须要经过拖动滚动条才能看到表格右边的栏目？
◇ 表格是否能正确打印？
◇ 表格内的列宽和行高是否合适？
◇ 会不会由于某个输入而使行高变化异常？
框架
◇ 是否会出现浏览器不支持的框架？
◇ 框架是否能自动准确地调整大小？用户是否能够操控框架的尺寸？
◇ 滚动条是否会适时出现？
◇ 框架页面上是否有明确的数据供书签或收藏夹识别？
◇ 搜索引擎是否能够找到框架中的内容？
◇ 框架边框是否美观？
◇ 框架内更新是否会出现问题？
数据认证
◇ 网站内面向用户的数据描述是否清楚？
◇ 隐私制度是否制定清楚？用户可否看到该制度？
◇ 保存的数据是否准确？
◇ 工做站是否对数据进行认证？
◇ 服务器是否对数据进行认证？
◇ 是否能够确保用户在工做站录入的信息能够被服务器正确接收？
◇ 在不一样的时间段是否能够避免录入相同的信息（订单表等）？
◇ 是否为每一个用户分配有惟一标识符，用于录入表格数据，保证表格对象的惟一性？
◇ 要求用户录入的信息是不是进程所必需的？例如：要求用户录入生日信息是用于其订单编号？或是仅仅为了多得到一些用户信息？
◇ 数字录入区域是否能够录入文字？
◇ 搜索中可否使用通配符？
◇ 是否能够在域内录入空格和空值？
◇ 是否能够录入长串？
◇ 域内是否能够录入文本最大的数量？
◇ 复选框和控件按钮的初值是否设置正确？
◇ 一个组内的控件按钮是每次只能选中一个？
◇ 复选框是否会触发预期事件？
◇在表格域内用户是否不能输入 HTML 代码？
◇智能错误处理是否会引起数据认证？ IE.如生日域的需求格式为 MM/DD/YYYY，则用户输入出声年份为 1857 是不匹配的。
外部界面
◇ 系统界面是否与相关的外部系统相匹配？
◇ 界面是否经过验证？
◇ 是否全部的支持的浏览器都通过测试？
◇ 一旦外部应用程序不可用或服务器链接失败，是否全部与外部界面相关的错误环境都通过测试？
◇ 代理缓存是否通过测试？
◇ 是否全部可能从网站内部安装的应用程序都通过测试？
内部界面
◇ 网站是否支持无下载功能的用户使用？
◇ 网站是否设置有防火墙？
◇ 网站是否能够灵活使用卸载插件？
◇ 网站处于不一样模式或运行速度的状况下可能须要使用插件，网站是否支持？
◇ 是否全部的插件能够协同工做？
◇ 是否全部平台都支持，且能打开连接文件（如 Solaris 操做系统是否能够打开 Microsoft Word 文件）？
◇ 是否全部浏览器都支持这些插件？
◇ 一旦 Java 不可用，是否网站就不可用？
◇ 是否全部的插件都能正常启动？
◇ 若是下载时遇到错误，是否会有错误处理？
◇ 网站功能中是否有使用"非标准"硬件（如话筒、线缆调制解调器等）的功能存在？
◇ 是否能够下载注册的 ActiveX 控件？
◇ 是否能够下载未注册的 ActiveX 控件？
◇ 是否能够初始化并编译未被认定为安全的 ActiveX 控件？
◇ 是否能够运行 ActiveX 控件和插件？
◇ 是否能够编译被认定为安全可编译的 ActiveX 控件？
◇ 反馈结果是否须要 cookie？
◇ 若是用户不支持 cookie，反馈结果是否正常？
◇ 反馈结果是否容许使用每一个对话 cookie？
◇ 反馈结果是否须要文件下载？
◇ 若是用户不要下载文件，网站是否仍能够使用？
◇ 反馈结果是否须要使用特定字体？
◇ 反馈结果是否须要用户跨越多个站点/域连接数据源？
◇ 用户是否能够使用拖拉和点击功能？
◇ 用户是否能够使用复制/粘贴功能？
◇ 反馈结果是否须要下载任何桌面项？
◇ 反馈结果是否须要登录或安装任何带框架的文件？
◇ 是否容许提交未加密数据？
◇ 网站是否容许经过脚本复制操做？
浏览器 - IE、Netscape、AOL、Mac 等
◇ HTML 版本是否与相应的浏览器版本相匹配？
◇ 测试时，JAVA 源码/脚本是否被浏览器支持？
◇ 测试时，浏览器是否能够正确显示图片？
◇ 是否能够肯定在任何浏览器上，字型都是可用的？
◇ 与每一个浏览器相关的安全性设置/风险是否通过检验？
◇ 是否在多个浏览器上验证过数字证书？
◇ 与浏览器配套的插件是否和网站一块儿通过测试？
◇ 是否设置了源码不可见？
◇ 不一样浏览器上的网站内容是否均可打印？
◇ 是否影响总体的内容大小（可靠性、一致性）？
◇ 是否验证过应用程序与框架是否兼容？
◇ 鼠标和键盘是否经测试适用于不一样的浏览器？
◇ 是否执行过智能错误处理（如：cookie 不可用）？
◇ 128 位编码是否经验证可用？
◇ 在不一样浏览器上 GIF 是否经测试可用？
Cookies
◇ cookie 储存的信息是否通过验证？
◇ cookie 信息是否通过加密？
◇ cookie 信息是否适量增长？
◇ 是否阻止用户编辑 cookie？
◇ 是否检查过若是用户浏览网站期间删除 cookie，会发生什么？
◇ 是否检查过若是用户关闭网站后删除 cookie，会发生什么？
◇ cookie 储存的路径是否正确？
◇ cookie 的信息是否正确有效，用户是否能够使用该信息链接网站？
登录/并发使用
◇ 系统是否达到预期的响应时间、流量以及实用价值？
◇ 系统是否能够承受极限用户量的访问？
◇ 系统是否能够长期无端障地正确运行？
◇ 是否监视过 CPU 的使用、响应时间、硬盘空间、内存用量及泄露？
◇ 是否认义标准响应时间（如：全部的页面的显示时间应小于 10 秒）？
◇ 是否验证防火墙、证书、服务提供商以及能够网络的影响？
◇ 不一样速度的调制解调器上网页的登录性能是否可接受？
◇ 同一用户是否能够长时间连续使用网站？
◇ 多个用户是否能够长时间连续使用网站？
◇ 在高流量的状况下，网站是否能支持短期的使用？
◇ 网站是否能够维持大量数据的处理，而不崩溃？
◇ 若是事务是无效的，网站是否仍容许大订单，而不会死锁目录？
错误处理
◇ 是否创建自动错误监察恢复机制，以保持系统运行？
◇ 若是系统崩溃，重启和恢复机制是否有效可靠？
◇ 若是半途断开网站，事务是否随之取消？
◇ 若是网络突然中断，事务是否随之取消？
◇ 反馈结果是否处理文件传输的中断？
◇ 反馈结果是否处理浏览器崩溃？
◇ 当网站和应用服务器链接中断时，反馈结果是否处理？
◇ 反馈结果是否处理数据库服务器中断连接的状况？
◇ 应用程序是否通报用户事务的状态？
◇ 网站是否包含 24 x 7 性能监控？
◇ 监控软件 MAPI 的电子邮件协议/限制
◇ 网站是否能够连接到页面系统？
◇ 时间 - 连续、每时、天天、每周
◇ 硬件限制 - 监视软件是否必须运行在专用机器上？
◇ 内存 - 泄露、隐藏、持续运行致使的问题
网络影响
◇ 是否考虑过 32 位和 64 位版本的 IP 问题？
◇ 是否测试过安全代理服务器的影响？
安全
◇ 是否足够安全？
◇ 是否机密/用户私密保护？
◇ 是否只有使用 128 位浏览器才能成功连接？
◇ 网站是否提示用户姓名和密码？
◇ 网站是否须要孩童输入我的信息？若是须要，是否在安全页面进行，且警示其家长？
◇ 服务器和客户端是否都有数字证书？
◇ 是否验证密码开始和结束的地方？
◇ 是否容许同时注销？
◇ 应用程序是否支持因静止而致使超时？
◇ 安全页面内书签是否不能使用？
◇ 在非安全/安全页面的状态栏上是否有显示钥匙/锁？
◇ 右击、查看、源文件是否不可用？
◇ 是否不能在 URL 上经过编辑内容而进行直接搜索？
◇ 若是使用数字证书，请经过注册证书、按规定填写安全信息测试浏览器缓存。安装证书后，试着使用回车键，看安全信息是否仍保存在缓存中。若是仍旧存在，那任何使用者均可能有机会获取这些高敏感的数字证书中的安全信息。
◇ 因为 SSL 和低于 3.0 版本的浏览器不兼容，是否有第二种方法能够链接到安全页面？
◇ 用户是否清楚什么时候进入、什么时候离开网站的安所有分？
◇ 当用户屡次使用无效登录名/密码信息登录失败时，服务器是否会拒绝该用户再次尝试连接？
GUI测试之窗口篇
窗口是Windows自己以及Windows 环境下的应用程序的基本界面单位，就是显示在屏幕上的一个矩形区域。通常来讲窗口是具备标题栏、菜单/菜单栏、工具栏、工做区、状态栏、最大化、最小化按钮和滚动条的标准方框，应用程序经过它和用户进行交互。可是若是没有标题栏、状态栏、最大化、最小化按钮是否是就不叫窗口呢。其实否则，窗口的概念很广，例如按钮和对话框等也是窗口，只不过是一种特殊的窗口罢了。这里我主要将的仍是标准意义上的窗口。
窗口主要有进入、移动、改变窗口大小；最大化、最小化和还原；使用滚动条和关闭窗口等操做。
所以能够经过以下来测试窗口：
大多数的窗口、屏幕/对话框应该有最小化，恢复和关闭按钮。
全部的窗口、屏幕/对话框应该有和内容相一致对应的标题。
只有主窗口才有标题栏图标、菜单栏、工具栏和状态栏。二级窗口不要使用菜单栏、工具栏或状态栏。
每个窗口/屏幕都应有功能匹配的OK和Cancel按钮。窗口/对话框的缺省<Enter>键应该设置在OK按钮上；窗口/对话框的缺省<Esc>键应该设置在Cancel按钮上。
a.Escape键取消对话框，焦点从新定位回到父窗口先前的焦点上，
b.Alt＋F4关闭窗口，和Escape键类似，但它能够在即便没有Cancel按钮的对话框中工做
c.Alt＋Space打开窗口的菜单Restore, Move, Size, Minimize, Maximize, Close
d.Shift＋F10和右击效果同样。
e.能够用键盘上的箭头按钮实现Move和Size功能
一个窗口每一个组件的访问键必须是惟一的。
父窗体或主窗体的中心位置应该在对角线焦点附近;子窗体位置应该在主窗体的左上角或正中;多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
二级窗口最好不要显示在任务栏中，由于单击主窗口的任务栏按钮也会激活二级窗口。
若是子窗体的任何操做会影响了父窗体的数据时，关闭子窗体同时必须刷新父窗体的数据。
关闭父窗体时必须关闭全部打开的子窗体。若是因为子窗口没有关闭而没法关闭父窗口，必须给予提示信息框。在关闭提示信息框后显示必须关闭的子窗口。
子窗体的大小最好不要超过父窗体，且最好不要遮住父窗体的主要信息。若是存在多层嵌套窗口，每层窗口弹出时都自动往右下移动一点点，以保证不遮盖上层窗口标题为准。
窗口嵌套层次最好不超过3层。
点击窗口中的帮助按钮或F1必须带出和窗口内容相一致的帮助。
窗口能够被屡次打开和关闭。但窗口未关闭或被其余窗口覆盖时，再次点击菜单或按钮，测试窗口是否能够被激活。
若是窗体能够最小化，最大化或可调整大小时，窗体上的控件也要随着窗体而缩放；对于含有按钮的界面通常不该该支持缩放，即右上角只有关闭功能。
工具栏按钮应该有浮动的提示，能够根据用户的要求本身选择定制；:相同或相近功能的工具栏放在一块儿；:一条工具栏的长度最长不能超出屏幕宽度；工具栏的图标能直观的表明要完成的操做；系统经常使用的工具栏设置默认放置位置；:工具栏太多时能够考虑使用工具厢；:工具厢要具备可增减性，由用户本身根据需求定制。:工具厢的默认总宽度不要超过屏幕宽度的1/5
状态条要能显示用户切实须要的信息，经常使用的有： 目前的操做、系统状态、用户位置、用户信息、提示信息、错误信息等，若是某一操做须要的时间较长，还应该显示进度条和进程提示。状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
菜单和工具条应有清楚的界限，菜单和状态栏中使用统一大小的字体（一般使用5号字体）
菜单应采用“经常使用--主要--次要--工具--帮助”的位置排列。提供经常使用的菜单项，如“文件”、“编辑”，“查找”，“打印”等。对经常使用的菜单项提供快捷命令方式。快捷方式惟一。
主菜单数目不太多时最好为单排布置。若是菜单选项较多，应该采用加长菜单的长度而减小深度的原则排列。菜单深度通常要求最多控制在三层之内。
下拉菜单要根据菜单选项的含义进行分组，並且按照必定的规则进行排列，用横线隔开。一组菜单的使用有前后要求或有向导做用时，应该按前后次序排列。没有顺序要求的菜单项按使用频率和重要性排列，经常使用的放在开头，不经常使用的靠后放置；重要的放在开头，次要的放在后边。对与进行的操做无关的菜单要用屏蔽的方式加以处理，若是采用动态加载方式——即只有须要的菜单才显示——最好。
菜单前的图标不宜太大，与字高保持一直最好。主菜单的宽度要接近，字数不该多于四个，每一个菜单的字数能相同最好。
状态栏中的信息应该根据窗口的内容的变化而变化，如在初始状态时，系统有多少条数据，通过查询后状态栏的数据应该发生变化。
滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比；拖动滚动条，检查屏幕刷新状况，并查看是否有乱码；单击滚动条和滚动条的上下按钮；用滚轮控制滚动条；
若是系统的模块较多，较深，常常会多级菜单，最好在窗口上加上导航条，以方便用户能够快速返回
GUI测试之信息处理类篇
在这篇文章中，我将文本框（Text Box），列表框（List Box），组合框（Combo Box）、下拉列表框（Drop-down List Box），复选框（Check Box），单选框（Radio box）/（option box），选项框（Option box）、滑动条（Slider）、旋转按钮（Spin Button）等都做为信息处理类来统一总结。
窗口/屏幕上的每个字段都应有相应的标签。
根据文本框能够接受的类型测试文本框：
1）输入正常的字母或数字
2）输入已存在的信息
（当某个字段不能重复的时候，输入已存在的信息，看保存是否会提示，好比注册用户的时候，要求用户名不可重复：先注册一个用户，保存成功（肯定数据库中已保存该条数据），再注册一个用户，输入一样的用户名，保存是否会提示：该用户名已被使用等。）
3）输入超过容许长度的字符或边界数字
4）输入空白，空格，（输入其余特殊字符如：#@￥%&*等）
5）输入不一样类型或不一样日期格式的数据，
6）复制/粘贴等操做强制输入程序不容许的输入数据
7）输入数据库或特殊字符集，例如NULL及\n等
测试文件选择框的正确性。使用空文件，只有空格的文件，不一样类型的文件，同名文件，内容相同名称不一样的文件，大文件等。
测试强制性字段的正确性（即必输项测试），强制性字段必须用红色的星号*标识。强制性字段两种处理方式：最好是必填项没有输入时，在光标移走时在相应的文本框后显示须要用户输入的红色信息。通常也能够在提交时用弹出消息框提示未填的必填项，关闭消息框后必须停留在第一个待输入的文本框中。
每个新窗口/屏幕中，光标默认停留在第一个待输入的文本框中。
通常下拉框中应显示一个默认值，列表框中高亮度显示一个默认值。若是不须要默认值时，通常默认值未“请选择。。。”。
通常来讲系统应记忆之前输入或选择的信息，可是当涉及安全时，最好不要保留用户的信息。有些地方能够使用复选框让用户决定是否要保留信息。如登陆界面。
对输入信息类型有限制的文本框应在输入非法值后给予提示，对于日期型的输入框，最好在标签上就给予提示
当输入的内容达到了字段的长度限制时，通常应控制不容许再输入，或者在提交后提示具体的容许输入的长度或者在光标转移时提示‘***容许输入的最大长度是***’等，而不是自动截断。（农信社资金业务管理系统目前采起右截断的处理方式，所以有问题）
系统中不容许的非法字符，最好是在输入时不容许输入，或在提交时给予具体系统不容许的非法字符列表提示。（如’、”、<、<>）
正确使用复选框或单选框。若是结果只有一个的，则使用单选框，如性别。验证单选按钮不能同时选中只能选中一个，而能够选择多个复选框。
一组单选按钮在初始状态时必须有一个被默认选中，不能同时为空。
分别测试多个复选框能够被逐一选中；同时选中，部分选中；都不被选中。
经过输入数字或用点击上下箭头来测试旋转按钮,测试其自动循环性，如范围为（0～999）先输入为999，在点击向下键，看是否会跳到0。输入字符或超过边界的数值，系统应该提示错误且从新输入；
验证列表框中的条目内容显示正确；容许多选的列表框，要分别检查shift和ctrl选中条目状况
避免使用水平滚动条，由于它会使项目阅读起来比较困难。解决的办法有：尽可能使用垂直滚动条、加宽窗口、减少文本的宽度，或者使文本自动换行等。固然，若是确实须要，还能够使用水平滚动条。
全选框勾中时应该选中当页全部记录，去掉当页某个记录的勾选，则全选也不选中。翻页后，自动去掉已勾选的记录及全选的勾选。
复选框能够经过Space能够控制选中/不选中
F4, Alt+down或alt+up控制combobox打开和关闭
对于combobox，Escape键等同于Cancel，Up/down箭头按钮控制向上或向下，Shift+up和shift+down能够多选，Ctrl实现多选；
GUI测试之按钮篇
在同一窗口中实现某一功能的按钮是惟一的。
按钮位置：OK按钮老是在上方或者左方,而Cancel按钮老是在下方或右方。
等价键：Cancel按钮的等价按键一般是Esc,而选中按钮的等价按钮一般是Enter保持一致。
测试按钮可否正常的实现功能，经常使用按钮的功能为：
OK（肯定）接受输入的数据或显示的响应信息，关掉窗口
Cancel（取消）不接受输入的信息，关掉窗口。取消时最好给予提示，尤为时有大量输入的窗口。
Close（关闭）：结束当前的任务，让程序继续进行；关掉数据窗口
Help（帮助）：调出程序的帮助信息
Save（保存）：保存数据，停留在当前窗口。如过保存耗时长的话，最好显示相似沙漏，进度条之类的提示。注意验证可否重复保存。如在IE中因为网速慢而致使的重复保存。
Add（新增）：新增记录。新增的记录必须排在首页首行。提交失败后必须保留用户已输入的内容，以便再次提交。提交时需对主要标识字段进行重复值、空值（空格）判断。
Update/Edit（编辑）：修改/编辑记录。如界面存在复选按钮，勾选多条记录进行修改时，需给予只能对一条记录进行修改，默认为第一条的提示信息。修改时加载的内容都为该记录的实际内容，而再也不为默认值。修改完成后必须回到原记录所在位置，且刷新显示修改后的值。提交失败后必须保留用户已修改的内容，以便再次提交。在查询条件下修改返回后如不知足查询条件则不显示，反之知足当前的查询条件则需显示新增的记录。需对主要标识字段进行重复值、空值（空格）判断。
Delete（删除）：删除记录。在删除以前必须有确认删除的提示信息。删除成功后刷新不显示被删除的记录。删除成功后返回到原记录所在页面；而当原记录所在页不存在时，则返回上一页。当被删除的记录与其它记录存在关联时，应给予不容许删除及更明细提示等信息。针对大批量的删除应提供全选复选框，方便用户删除。
Search（查询）：查询记录。每次查询应显示返回的结果数。每次查询应定位到首页[A2] 。保留前一次的查询条件。当查询条件较多时，需配以重置按钮。当未查询到任何记录时，需给予未查找到相关记录的提示信息。除用户明确要求不须要外，需提供模糊查询及组合查询功能。当查询返回的结果大于默认的一页大小时，最好采用分页或者根据系统默认或用户定义的一页显示的记录数量来分页。若有多页，须要提供首页，下一页，上一页，尾页和跳至功能。每页的记录不能重复，但也能够根据用户须要显示上一页的最后一条数据。
Reset（重置）：重置。应回到打开窗口时的最初状态。屡次点击是否还能正常显示。
Return（返回）：返回。若是一个窗口或页面不能经过菜单，工具栏到达，而是必须经过前一个窗口完成才到达，应提供返回按钮或导航条让用户能够返回。
若是点击按钮后还须要用户的进一步的操做，按钮的名称应加上省略号。如Browse。。。
OK/Cancel/Apply/Help键的排放最好听从Windows的标准排放。
按钮最好都给予浮动提示[A3] ，特别是图片按钮，能够避免因为网络太慢而致使的太长时间不能往下操做。
GUI测试之对话框、消息框篇
对话框/消息框的缺省<Enter>键应该设置在OK按钮上；对话框/消息框的缺省<Esc>键应该设置在Cancel按钮上。
通常来讲重要的或复杂操做成功后应该给予提示，根据系统的特性选择弹出信息框或文字显示。须要后续操做的操做在成功后应给予提示。
非法的输入或操做应给出足够的提示说明。
对可能形成数据没法恢复的操做应该给予确认信息，给用户放弃选择的机会。如删除操做。
提示信息不宜太长，宽度不能超过当前窗口的1/2；当超过此比例时，请视具体状况进行换行。有多行提示信息的，请选择对齐方式（通常为左对齐）。
静态文本标签通常采用左对齐，这样显得更有条理且易于浏览。 静态文本标签通常置于相关控件的左边，有时选项过多过长时放在上面。
复杂或带有专业性的操做或输入最好在输入项下面给予提示。
通用对话框控件，如Open…，Save As…，Color…，Fonts…，Print…，Page SetUp…等调用系统的对话框只须要是否调用正确，可否实现正常功能就能够了，里面的具体功能能够不用测试。
消息框中的图标必须根据须要选择正确的使用，通常来讲 X 表示有很重要的问题须要提醒用户；? 增亮没有危险的问题； ! 强调警告用户必须知道的事情； i 通常信息，能够使乏味的信息变得有趣。
正在进行的操做提示框应使用省略号，如“删除中。。。”。
对话框标题文本中不要出现省略号。如选择"打印选项..."命令结果而显示的对话框的标题应该为"打印"，而不是“打印。。。”。可是，表示命令正在执行过程当中菜单对话框（如"链接到Internet..."对话框）是一种例外状况。
对于耗时的操做都应给出相似等待光标、进度表或其余的可视反馈。用户能够取消长时间的操做。若是能够取消未完成的操做，那么将按钮标记为"取消"，不然将按钮标记为"中止"。
测试用例设计--因果图方法
一. 方法简介
1.定义：是一种利用图解法分析输入的各类组合状况，从而设计测试用例的方法，它适合于检查程序输入条件的各类组合状况。
2.因果图法产生的背景：
等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各类组合、输入条件之间的相互制约关系。这样虽然各类输入条件可能出错的状况已经测试到了，但多个输入条件组合起来可能出错的状况却被忽视了。
若是在测试时必须考虑输入条件的各类组合，则可能的组合数目将是天文数字，所以必须考虑采用一种适合于描述多种条件的组合、相应产生多个动做的形式来进行测试用例的设计，这就须要利用因果图（逻辑模型）。
3.因果图介绍
1) 4种符号分别表示了规格说明中向4种因果关系。
2) 因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称缘由），右结点表示输出状态（或称结果）。
3) Ci表示缘由，一般置于图的左部；ei表示结果，一般在图的右部。Ci和ei都可取值0或1，0表示某状态不出现，1表示某状态出现。
4. 因果图概念
1) 关系
① 恒等：若ci是1，则ei也是1；不然ei为0。
② 非：若ci是1，则ei是0；不然ei是1。
③ 或：若c1或c2或c3是1，则ei是1；不然ei为0。“或”可有任意个输入。
④ 与：若c1和c2都是1，则ei为1；不然ei为0。“与”也可有任意个输入。
2) 约束
输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件自己不可能同时出现。输出状态之间也每每存在约束。在因果图中,用特定的符号标明这些约束。
A.输入条件的约束有如下4类：
① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。
② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。
③ O约束（惟一）；a和b必须有一个，且仅有1个为1。
④ R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。
B.输出条件约束类型
输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。
5. 采用因果图法设计测试用例的步骤：
1) 分析软件规格说明描述中, 那些是缘由(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每一个缘由和结果赋予一个标识符。
2) 分析软件规格说明描述中的语义，找出缘由与结果之间, 缘由与缘由之间对应的关系，根据这些关系,画出因果图。
3) 因为语法或环境限制, 有些缘由与缘由之间,缘由与结果之间的组合状况不可能出现，为代表这些特殊状况, 在因果图上用一些记号代表约束或限制条件。
4) 把因果图转换为断定表。
5) 把断定表的每一列拿出来做为依据,设计测试用例。
网站测试的主要方面
1功能测试
对于网站的测试而言，每个独立的功能模块须要单独的测试用例的设计导出，主要依据为《需求规格说明书》及《详细设计说明书》，对于应用程序模块须要设计者提供基本路径测试法的测试用例。
● 连接测试
连接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。连接测试可分为三个方面：
1）测试全部连接是否按指示的那样确实连接到了该连接的页面；
2）测试所连接的页面是否存在；
3）保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有连接指向该页面，只有知道正确的URL地址才能访问。
连接测试能够自动进行，如今已经有许多工具能够采用。连接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的全部页面开发完成以后进行连接测试。
Xenu------主要测试连接的正确性的工具
惋惜的是对于动态生成的页面的测试会出现一些错误。
●表单测试
当用户给Web应用系统管理员提交信息时，就须要使用表单操做，例如用户注册、登录、信息提交等。在这种状况下，咱们必须测试提交操做的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。若是使用了默认值，还要检验默认值的正确性。若是表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时能够跳过这些字符，看系统是否会报错。
要测试这些程序，须要验证服务器能正确保存这些数据，并且后台运行的程序能正确解释和使用这些信息。
B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等若是有固定的操做流程能够考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，能够在测试、回归测试时运行以便减轻测试人员工做量。
咱们对UM子系统中各个功能模块中的各项功能进行逐一的测试，主要测试方法为：边界值测试、等价类测试，以及异常类测试。测试中要保证每种类型都有2个以上的典型数值的输入，以确保测试输入的全面性。
●Cookies测试
Cookies一般用来存储用户信息和用户在某应用系统的操做，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来建立动态和自定义页面或者存储登录等信息。
若是Web应用系统使用了Cookies，就必须检查Cookies是否能正常工做并且对这些信息已经加密。测试的内容可包括Cookies是否起做用，是否按预约的时间进行保存，刷新对Cookies有什么影响等。
●设计语言测试
Web设计语言版本的差别能够引发客户端或服务器端严重的问题，例如使用哪一种版本的HTML等。当在分布式环境中开发时，开发人员都不在一块儿，这个问题就显得尤其重要。除了HTML的版本问题外，不一样的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
●数据库测试
在Web应用技术中，数据库起着重要的做用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最经常使用的数据库类型是关系型数据库，能够使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，通常状况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是因为用户提交的表单信息不正确而形成的，而输出错误主要是因为网络速度或程序设计问题等引发的，针对这两种状况，可分别进行测试。
2性能测试
网站的性能测试对于网站的运行而言异常重要，可是目前对于网站的性能测试作的不够，咱们在进行系统设计时也没有一个很好的基准能够参考，于是创建网站的性能测试的一整套的测试方案将是相当重要的。
网站的性能测试主要从三个方面进行：链接速度测试、负荷测试（Load）和压力测试（Stress）.链接速度测试指的是打开网页的响应速度测试。负荷测试指的是进行一些边界数据的测试，压力测试更像是恶意测试，压力测试倾向应该是导致整个系统崩溃。
●链接速度测试
用户链接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户能够等较长的时间，但若是仅仅访问一个页面就不会这样。若是Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，若是响应速度太慢，用户可能还没来得及浏览内容，就须要从新登录了。并且，链接速度太慢，还可能引发数据丢失，使用户得不到真实的页面。
●负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工做。负载级别能够是某个时刻同时访问Web系统的用户数量，也能够是在线数据处理的数量。例如：Web应用系统能容许多少个用户同时在线？若是超过了这个数量，会出现什么现象？Web应用系统可否处理大量用户对同一个页面的请求？
●压力测试
负载测试应该安排在Web系统发布之后，在实际的网络环境中进行测试。由于一个企业内部员工，特别是项目组人员老是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，因此，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么状况下会崩溃。黑客经常提供错误的数据负载，直到Web应用系统崩溃，接着当系统从新启动时得到存取权。
压力测试的区域包括表单、登录和其余信息传输页面等。
采用的测试工具：
性能测试能够采用相应的工具进行自动化测试，咱们目前采用以下工具
ab -----Apache 的测试工具
OpenSTA—开发系统测试架构
3 接口测试
在不少状况下，web 站点不是孤立。Web 站点可能会与外部服务器通信，请求数据、验证数据或提交订单。
●服务器接口
第一个须要测试的接口是浏览器与服务器的接口。测试人员提交事务，而后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还能够查询数据库，确认事务数据已正确保存。
●外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减小欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。若是商店只使用 Visa 卡和 Mastercard 卡， 能够尝试使用 Discover 卡的数据。（简单的客户端脚本可以在提交事务以前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 表明Discover。）一般，测试人员须要确认软件可以处理外部服务器返回的全部可能的消息。
●错误处理
最容易被测试人员忽略的地方是接口错误处理。一般咱们试图确认系统可以处理全部错误，但却没法预期系统全部可能的错误。尝试在处理过程当中中断事务，看看会发生什么状况？订单是否完成？尝试中断用户到服务器的网络链接。尝试中断 web 服务器到信用卡验证服务器的链接。在这些状况下，系统可否正确处理这些错误？是否已对信用卡进行收费？若是用户本身中断事务处理，在订单已保存而用户没有返回网站确认的时候，须要由客户表明致电用户进行订单确认。
4 可用性测试
可用性/易用性方面目前咱们只能采用手工测试的方法进行评判，并且缺少一个很好的评判基准进行，此一方面须要你们共同讨论。
●导航测试
导航描述了用户在一个页面内操做的方式，在不一样的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不一样的链接页面之间。经过考虑下列问题，能够决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可经过主页存取？Web系统是否须要站点地图、搜索引擎或其余的导航帮助？
在一个页面上放太多的信息每每起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有知足本身须要的信息，若是没有，就会很快地离开。不多有用户愿意花时间去熟悉Web应用系统的结构，所以，Web应用系统导航帮助要尽量地准确。
导航的另外一个重要方面是Web应用系统的页面结构、导航、菜单、链接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
●图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的做用，又能起到美化页面的功能。一个Web应用系统的图形能够包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一块儿，以避免浪费传输时间。Web应用系统的图片尺寸要尽可能地小，而且要能清楚地说明某件事情，通常都连接到某个具体的页面。
（2）验证全部页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，通常采用JPG或GIF压缩。
●内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的仍是误传的。例如，在商品价格列表中，错误的价格可能引发财政问题甚至致使法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试一般使用一些文字处理软件来进行，例如使用Microsoft Word的“拼音与语法检查”功能；信息的相关性是指是否在当前页面能够找到与当前浏览信息相关的信息列表或入口，也就是通常Web站点中的所谓“相关文章列表”。
●总体界面测试
总体界面是指整个Web应用系统的页面结构设计，是给用户的一个总体感。例如：当用户浏览Web应用系统时是否感到温馨，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对总体界面的测试过程，实际上是一个对最终用户进行调查的过程。通常Web应用系统采起在主页上作一个调查问卷的形式，来获得最终用户的反馈信息。
对全部的可用性测试来讲，都须要有外部人员（与Web应用系统开发没有联系或联系不多的人员）的参与，最好是最终用户的参与。
5 兼容性测试
须要验证应用程序能够在用户使用的机器上运行。若是您用户是全球范围的，须要测试各类操做系统、浏览器、视频设置和 modem 速度。最后，还要尝试各类设置的组合。
●平台测试
市场上有不少不一样的操做系统类型，最多见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪种操做系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操做系统下能正常运行，但在另外的操做系统下可能会运行失败。
所以，在Web系统发布以前，须要在各类操做系统下对Web系统进行兼容性测试。
●浏览器测试
浏览器是Web客户端最核心的构件，来自不一样厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不一样的HTML规格有不一样的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不一样的浏览器中也有不一样的显示，甚至根本不显示。不一样的浏览器对安全性和Java的设置也不同。
测试浏览器兼容性的一个方法是建立一个兼容性矩阵。在这个矩阵中，测试不一样厂商、不一样版本的浏览器对某些构件和设置的适应性。
采用测试工具：
经过白盒测试或者黑盒测试导出的测试用例，采用相应的工具进行测试，能够采用OpenSTA进行测试，此测试工具能够采用不一样的浏览器进行测试。
●视频测试
页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否过小以致于没法浏览? 或者是太大? 文本和图片是否对齐?
●Modem/链接速率测试
是否有这种状况，用户使用 28.8 modem下载一个页面须要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，须要确认图片不会太大。
●打印机测试
用户可能会将网页打印下来。所以网页在设计的时候要考虑到打印问题，注意节约纸张和油墨。有很多用户喜欢阅读而不是盯着屏幕，所以须要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不同。测试人员至少须要验证订单确认页面打印是正常的。
●组合测试
最后须要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，可是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却没法使用 Lynx 来浏览。若是是内部使用的 web 站点，测试可能会轻松一些。若是公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。若是全部的人都使用 T1 专线，可能不须要测试下载施加。（但须要注意的是，可能会有员工从家里拨号进入系统） 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。可是，理想的状况是，系统能在全部机器上运行，这样就不会限制未来的发展和变更。
6 安全测试
Web应用系统的安全性测试区域主要有：
●目录设置
Web 安全的第一步就是正确设置目录。每一个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的全部内容。若是没有执行这条规则。那么选中一幅图片，单击鼠标右键，找到该图片所在的路径“…com/objects/images”。而后在浏览器地址栏中手工输入该路径，发现该站点全部图片的列表。这可能没什么关系。可是进入下一级目录 “…com/objects” ，点击 jackpot。在该目录下有不少资料，其中有些都是已过时页面。若是该公司每月都要更改产品价格信息，而且保存过时页面。那么只要翻看了一下这些记录，就能够估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。若是某个客户在谈判以前查看了这些信息，他们在谈判桌上确定处于上风。
●登陆
如今的Web应用系统基本采用先注册，后登录的方式。所以，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，能够试多少次的限制，是否能够不登录而直接浏览某个页面等。
●Session
Web应用系统是否有超时的限制，也就是说，用户登录后在必定时间内（例如15分钟）没有点击任何页面，是否须要从新登录才能正常使用。
●日志文件
为了保证Web应用系统的安全性，日志文件是相当重要的。须要测试相关信息是否写进了日志文件、是否可追踪。
●加密
当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
●安全漏洞
服务器端的脚本经常构成安全漏洞，这些漏洞又经常被黑客利用。因此，还要测试没有通过受权，就不能在服务器端放置和编辑脚本的问题。
目前网络安全问题日益重要，特别对于有交互信息的网站及进行电子商务活动的网站尤为重要。目前咱们的测试没有涵盖网站的安全性的测试，咱们拟定采用工具来测定。
工具以下
SAINT------- Security Administrator’s Integrated Network Tool
此工具可以测出网站系统的相应的安全问题，而且可以给出安全漏洞的解决方案，不过是一些较为常见的漏洞解决方案。
7 代码合法性测试
代码合法性测试主要包括2个部分：程序代码合法性检查与显示代码合法性检查。
●程序代码合法性检查
程序代码合法性检查主要标准为《intergrp小组编程规范》，目前采用由SCM管理员进行规范的检查，将来指望可以有相应的工具进行测试。
●显示代码合法性检查
显示代码的合法性检查，主要分为Html、JavaScript、Css代码检查，目前采用HTML代码检查------采用CSE HTML Validator进行测试JavaScript、Css也能够在网上下载相应的测试工具。
8 文档测试
●产品说明书属性检查清单
1）完整.是否有遗漏和丢失，彻底吗？单独使用是否包含所有内容
2）准确.既定解决方案正确吗？目标明确吗？ 有没有错误？
3）精确、不含糊、清晰.描述是否一清二楚？ 仍是自说自话？容易看懂和理解吗？
4）一致.产品功能能描述是否自相矛盾，与其余功能有没有冲突
5）贴切.描述功能的陈述是否必要？有没有多余信息？功能是否原来的客户要求？
6）合理.在特定的预算和进度下，以现有人力，物力和资源可否实现？
7）代码无关.是否坚持定义产品，而不是定义其所信赖的软件设计，架构和代码
8）可测试性.特性可否测试？测试员创建验证操做的测试程序是否提供足够的信息？
●产品说明书用语检查清单
1）说明。 对问题的描述一般表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语，仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱，也可能含糊其词----不管是哪种状况均可视为软件缺陷.
2）老是，每一种，全部，没有，从不.若是看到此类绝对或确定的，切实认定的叙述，软件测试员就能够着手设计针锋相对的案例.
3）固然，所以，明显，显然，必然.这些话意图诱使接受假定状况.不要中了圈套.
4）某些，有时，经常，一般，惯常，常常，大多，几乎.这些话太过模糊.“有时”发生做用的功能没法测试.
5）等等，诸如此类，依此类推.以这样的词结束的功能清单没法测试.功能清单要绝对或者解释明确，以避免让人迷惑，不知如何推论.
6）良好，迅速，廉价，高效，小，稳定.这些是不肯定的说法，不可测试.若是在产品说明书中出现，就必须进一步指明含义.
7）已处理，已拒绝，已忽略，已消除.这些廉洁可能会隐藏大量须要说明的功能.
8）若是...那么...（没有不然）.找出有“若是...那么...”而缺乏配套的“不然”结构的陈述.想想“若是”没有发生会怎样.
相关的测试工具
· OpenSTA
主要作性能测试的负荷及压力测试，使用比较方便，能够编写测试脚本，也能够先行自动生成测试脚本，然后对于应用测试脚本进行测试。
· SAINT
网站安全性测试，可以对于指定网站进行安全性测试，并能够提供安全问题的解决方案。
· CSE HTML Validator
一个有用的对于HTML代码进行合法性检查的工具
· Ab（Apache Bench）
Apache自带的对于性能测试方面的工具，功能不是不少，可是很是实用。
· Crash-me
Mysql自带的测试数据库性能的工具，可以测试多种数据库的性能
黑盒测试用例设计
黑盒测试（Black-box Testing，又称为功能测试或数据驱动测试）是把测试对象看做一个黑盒子。利用黑盒测试法进行动态测试时，须要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。
采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序全部功能需求的输入条件。黑盒测试并非白盒测试的替代品，而是用于辅助白盒测试发现其余类型的错误。
黑盒测试试图发现如下类型的错误：
1）功能错误或遗漏；
2）界面错误；
3）数据结构或外部数据库访问错误；
4）性能错误；
5）初始化和终止错误。
1、黑盒测试的测试用例设计方法
· 等价类划分方法
· 边界值分析方法
· 错误推测方法
· 因果图方法
· 断定表驱动分析方法
· 正交实验设计方法
· 功能图分析方法
等价类划分：
是把全部可能的输入数据，即程序的输入域划分红若干部分（子集），而后从每个子集中选取少数具备表明性的数据做为测试用例。该方法是一种重要的，经常使用的黑盒测试用例设计方法。
1） 划分等价类： 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的表明值就等于对这一类其它值的测试。所以，能够把所有输入数据合理划分为若干等价类，在每个等价类中取一个数据做为测试的输入条件，就能够用少许表明性的测试数据。取得较好的测试结果。等价类划分可有两种不一样的状况：有效等价类和无效等价类。
有效等价类：是指对于程序的规格说明来讲是合理的，有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
无效等价类：与有效等价类的定义恰巧相反。
设计测试用例时，要同时考虑这两种等价类。由于，软件不只要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具备更高的可靠性。
2）划分等价类的方法：下面给出六条肯定等价类的原则。
① 在输入条件规定了取值范围或值的个数的状况下，则能够确立一个有效等价类和两个无效等价类。
② 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的状况下，可确立一个有效等价类和一个无效等价类。
③ 在输入条件是一个布尔量的状况下，可肯定一个有效等价类和一个无效等价类。
④ 在规定了输入数据的一组值（假定n个），而且程序要对每个输入值分别处理的状况下，可确立n个有效等价类和一个无效等价类。
⑤ 在规定了输入数据必须遵照的规则的状况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不一样角度违反规则）。
⑥ 在确知已划分的等价类中各元素在程序处理中的方式不一样的状况下，则应再将该等价类进一步的划分为更小的等价类。
3）设计测试用例：在确立了等价类后，可创建等价类表，列出全部划分出的等价类：
输入条件 有效等价类 无效等价类
而后从划分出的等价类中按如下三个原则设计测试用例：
① 为每个等价类规定一个惟一的编号。
② 设计一个新的测试用例，使其尽量多地覆盖还没有被覆盖地有效等价类，重复这一步。直到全部的有效等价类都被覆盖为止。
③ 设计一个新的测试用例，使其仅覆盖一个还没有被覆盖的无效等价类，重复这一步。直到全部的无效等价类都被覆盖为止。
边界值分析法
边界值分析方法是对等价类划分方法的补充。
（1）边界值分析方法的考虑：
长期的测试工做经验告诉咱们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。所以针对各类边界状况设计测试用例，能够查出更多的错误。
使用边界值分析方法设计测试用例，首先应肯定边界状况。一般输入和输出等价类的边界，就是应着重测试的边界状况。应当选取正好等于，刚刚大于或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。
（2）基于边界值分析方法选择测试用例的原则：
1）若是输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值做为测试输入数据。
2）若是输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数做为测试数据。
3）根据规格说明的每一个输出条件，使用前面的原则1）。
4）根据规格说明的每一个输出条件，应用前面的原则2）。
5）若是程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素做为测试用例。
6）若是程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值做为测试用例。
7）分析规格说明，找出其它可能的边界条件。
错误推测法
错误推测法： 基于经验和直觉推测程序中全部可能存在的各类错误， 从而有针对性的设计测试用例的方法。
错误推测方法的基本思想： 列举出程序中全部可能有的错误和容易发生错误的特殊状况，根据他们选择测试用例。例如， 在单元测试时曾列出的许多在模块中常见的错误。 之前产品测试中曾经发现的错误等， 这些就是经验的总结。 还有， 输入数据和输出数据为0的状况。 输入表格为空格或输入表格只有一行。 这些都是容易发生错误的状况。 可选择这些状况下的例子做为测试用例。
因果图方法
前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系， 相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的状况。 但要检查输入条件的组合不是一件容易的事情， 即便把全部输入条件划分红等价类，他们之间的组合状况也至关多。所以必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动做的形式来考虑设计测试用例。 这就须要利用因果图（逻辑模型）。
因果图方法最终生成的就是断定表。 它适合于检查程序输入条件的各类组合状况。
利用因果图生成测试用例的基本步骤：
（1） 分析软件规格说明描述中， 那些是缘由（即输入条件或输入条件的等价类），那些是结果（即输出条件），并给每一个缘由和结果赋予一个标识符。
（2） 分析软件规格说明描述中的语义。找出缘由与结果之间，缘由与缘由之间对应的关系。 根据这些关系，画出因果图。
（3） 因为语法或环境限制， 有些缘由与缘由之间，缘由与结果之间的组合状况不不可能出现。为代表这些特殊状况， 在因果图上用一些记号代表约束或限制条件。
（4） 把因果图转换为断定表。
（5） 把断定表的每一列拿出来做为依据，设计测试用例。
从因果图生成的测试用例（局部，组合关系下的）包括了全部输入数据的取TRUE与取FALSE的状况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增长而线性地增长。
前面因果图方法中已经用到了断定表。断定表（DECision Table）是分析和表达多逻辑条件下执行不一样操做的状况下的工具。在程序设计发展的初期，断定表就已被看成编写程序的辅助工具了。因为它能够把复杂的逻辑关系和多种条件组合的状况表达得既具体又明确。
断定表驱动分析方法
断定表一般由四个部分组成。
条件桩（ConDItion STub）：列出了问题得全部条件。一般认为列出得条件的次序可有可无。
动做桩（Action Stub）：列出了问题规定可能采起的操做。这些操做的排列顺序没有约束。
条件项（Condition Entry）：列出针对它左列条件的取值。在全部可能状况下的真假值。
动做项（Action Entry）：列出在条件项的各类取值状况下应该采起的动做。
规则：任何一个条件组合的特定取值及其相应要执行的操做。在断定表中贯穿条件项和动做项的一列就是一条规则。显然，断定表中列出多少组条件取值，也就有多少条规则，既条件项和动做项有多少列。
断定表的创建步骤：（根据软件规格说明）
① 肯定规则的个数。假若有n个条件。每一个条件有两个取值（0，1），故有种规则。
② 列出全部的条件桩和动做桩。
③ 填入条件项。
④ 填入动做项。等到初始断定表。
⑤ 简化、合并类似规则（相同动做）。
B.Beizer 指出了适合使用断定表设计测试用例的条件：
① 规格说明以断定表形式给出，或很容易转换成断定表。
② 条件的排列顺序不会也不影响执行哪些操做。
③ 规则的排列顺序不会也不影响执行哪些操做。
④ 每当某一规则的条件已经知足，并肯定要执行的操做后，没必要检验别的规则。
⑤ 若是某一规则获得知足要执行多个操做，这些操做的执行顺序可有可无。
黑盒测试的优势
一、基本上不用人管着，若是程序中止运行了通常就是被测试程序CRASh了
二、设计完测试例以后，下来的工做就是爽了，固然更苦闷的是肯定crash缘由
黑盒测试的缺点
一、结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴
二、没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来作的，还作不到针对被测试程序的状态转换来做
三、就没有状态概念的测试来讲，寻找和肯定形成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来讲，就更麻烦了，尤为不是一个单独的tEStcase形成的问题。这些在堆的问题中表现的更为突出。
黑盒测试（功能测试）工具的选择
那么，如何高效地完成功能测试？选择一款合适的功能测试工具并培训一支高素质的工具使用队伍无疑是相当重要的。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短时间来看，这类企业盈利情况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。
目前，用于功能测试的工具软件有不少，针对不一样架构软件的工具也不断推陈出新。这里重点介绍的是其中一个较为典型自动化测试工具，即Mercury公司的WinRunner。
WinRunner是一种用于检验应用程序可否如期运行的企业级软件功能测试工具。经过自动捕获、检测和模拟用户交互操做，WinRunner能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽可能不出现功能性故障。
WinRunner的特色在于： 与传统的手工测试相比，它能快速、批量地完成功能点测试；能针对相同测试脚本，执行相同的动做，从而消除人工测试所带来的理解上的偏差； 此外，它还能重复执行相同动做，测试工做中最枯燥的部分可交由机器完成； 它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，经过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用；它针对于大多数编程语言和Windows技术，提供了较好的集成、支持环境，这对基于Windows平台的应用程序实施功能测试而言带来了极大的便利。
WinRunner的工做流程大体能够分为如下六个步骤：
1．识别应用程序的GUI
在WinRunner中，咱们能够使用GUI Spy来识别各类GUI对象，识别后，WinRunner会将其存储到GUI Map File中。它提供两种GUI Map File模式： Global GUI Map File和GUI Map File per Test。其最大区别是后者对每一个测试脚本产生一个GUI文件，它能自动创建、存储、加载，推荐初学者选用这种模式。可是，这种模式不易于描述对象的改变，其效率比较低，所以对于一个有经验的测试人员来讲前者不失为一种更好的选择，它只产生一个共享的GUI文件，这使得测试脚本更容易维护，且效率更高。
2．创建测试脚本
在创建测试脚本时，通常先进行录制，而后在录制造成的脚本中手工加入须要的TSL（与C语言相似的测试脚本语言）。录制脚本有两种模式： Context Sensitive和Analog，选择依据主要在因而否对鼠标轨迹进行模拟，在须要回放时通常选用Analog。在录制过程当中这两种模式能够经过F2键相互切换。
只要看看现代软件的规模和功能点数就能够明白，功能测试早已跨越了单靠手工敲敲键盘、点点鼠标就能够完成的阶段。而性能测试则是控制系统性能的有效手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要做用。
3．对测试脚本除错（debug）
在WinRunner中有专门一个Debug TOOlbar用于测试脚本除错。能够使用step、pause、breakpoint等来控制和跟踪测试脚本和查看各类变量值。
4．在新版应用程序执行测试脚本
当应用程序有新版本发布时，咱们会对应用程序的各类功能包括新增功能进行测试，这时固然不可能再来从新录制和编写全部的测试脚本。咱们能够使用已有的脚本，批量运行这些测试脚本测试旧的功能点是否正常工做。能够使用一个call命令来加载各测试脚本。还可在call命令中加各类TSL脚原本增长批量能力。
5．分析测试结果
分析测试结果在整个测试过程当中最重要，经过分析能够发现应用程序的各类功能性缺陷。当运行完某个测试脚本后，会产生一个测试报告，从这个测试报告中咱们能发现应用程序的功能性缺陷，能看到实际结果和指望结果之间的差别，以及在测试过程当中产生的各种对话框等。
6．回报缺陷（defect）
在分析完测试报告后，按照测试流程要回报应用程序的各类缺陷，而后将这些缺陷发给指定人，以便进行修改和维护。
经常使用的功能测试方法
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。经常使用的测试方法以下：
一、页面连接检查：每个连接是否都有对应的页面，而且页面之间切换正确。
二、相关性检查：删除/增长一项会不会对其余项产生影响，若是产生影响，这些影响是否都正确。
三、检查按钮的功能是否正确：如update， cancel， delete， SAve等功能是否正确。
四、字符串长度检查： 输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错。
五、字符类型检查： 在应该输入指定类型的内容的地方输入其余类型的内容（如在应该输入整型的地方输入其余字符类型），看系统是否检查字符类型，会否报错。
六、标点符号检查： 输入内容包括各类标点符号，特别是空格，各类引号，回车键。看系统处理是否正确。
七、中文字符处理： 在能够输入中文的系统输入中文，看会否出现乱码或出错。
八、检查带出信息的完整性： 在查看信息和update信息时，查看所填写的信息是否是所有带出。，带出信息和添加的是否一致
九、信息重复： 在一些须要命名，且名字应该惟一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的先后输入空格，系统是否做出正确处理。
十、检查删除功能：在一些能够一次删除多个信息的地方，不选择任何信息，按”delete”，看系统如何处理，会否出错；而后选择一个和多个信息，进行删除，看是否正确处理。
十一、检查添加和修改是否一致： 检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型。
十二、检查修改重名：修改时把不能重名的项改成已存在的内容，看会否处理，报错。同时，也要注意，会不会报和本身重名的错。
1三、重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否作了处理。
1四、检查屡次使用back键的状况： 在有back的地方，back，回到原来页面，再back，重复屡次，看会否出错。
1五、search检查：在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确。若是能够输入多个search条件，能够同时添加合理和不合理的条件，看系统处理是否正确。
1六、输入信息位置： 注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。
1七、上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否可以作到。
1八、必填项检查：应该填写的项没有填写时系统是否都作了处理，对必填项是否有提示信息，如在必填项前加*
1九、快捷键检查：是否支持经常使用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不容许输入信息的字段，如选人，选日期对快捷方式是否也作了限制。
20、回车键检查： 在输入结束后直接按回车键，看系统处理如何，会否报错。
Web测试中的界面测试用例设计
1、文本框、按钮等控件测试
一、文本框的测试
如何对文本框进行测试：
a、输入正常的字母或数字;
b、输入已存在的文件的名称;
c、输入超长字符。例如在“名称”框中输入超过容许边界个数的字符，假设最多255个字符，尝试输入256个字符，检查程序可否正确处理;
d、输入默认值，空白，空格;
e、若只容许输入字母，尝试输入数字;反之，尝试输入字母;
f、利用复制，粘贴等操做强制输入程序不容许的输入数据;
g、输入特殊字符集，例如，NUL及\n等;
h、输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示;
i、输入不符合格式的数据，检查程序是否正常校验，如程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示。
在测试过程当中所用到的测试方法：
a、输入非法数据;
b、输入默认值;
c、输入特殊字符集;
d、输入使缓冲区溢出的数据;
e、输入相同的文件名;
二、命令按钮控件的测试
测试方法：
a、点击按钮正确响应操做。如单击肯定，正确执行操做;单击取消，退出窗口;
b、对非法的输入或操做给出足够的提示说明，如输入月工做天数为32时，单击“肯定”后系统应提示：天数不能大于31;
c、对可能形成数据没法恢复的操做必须给出确认信息，给用户放弃选择的机会;
三、单选按钮控件的测试
测试方法：
a、一组单选按钮不能同时选中，只能选中一个;
b、逐一执行每一个单选按钮的功能。分别选择了“男”、“女”后，保存到数据库的数据应该相应的分别为“男”、“女”;
c、一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空。
四、up-down控件文本框的测试
测试方法：
a、直接输入数字或用上下箭头控制，如在“数目”中直接输入10，或者单击向上的箭头，使数目变为10;
b、利用上下箭头控制数字的自动循环，如当最多数字为253时，单击向上箭头，数目自动变为1;反之亦适用;
c、直接输入超边界值，系统应该提示从新输入;
d、输入默认值，空白。如“插入”数目为默认值，点击“肯定”;或删除默认值，使内容为空，单击“肯定”进行测试;
e、输入字符。此时系统应提示输入有误。
五、组合列表框的测试
测试方法：
a、条目内容正确，其详细条目内容能够根据需求说明肯定;
b、逐一执行列表框中每一个条目的功能;
c、检查可否向组合列表框输入数据。
六、复选框的测试
测试方法：
a、多个复选框能够被同时选中;
b、多个复选框能够被部分选中;
c、多个复选框能够都不被选中;
d、逐一执行每一个复选框的功能。
七、列表框控件的测试
测试方法：
a、条目内容正确：同组合列表框相似，根据需求说明书肯定列表的各项内容正确，没有丢失或错误;
b、列表框的内容较多时要使用滚动条;
c、列表框容许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的状况;
八、滚动条控件的测试
要注意一下几点：
a、滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如word中浏览100页文档，浏览到50页时，滚动条位置应处于中间;
b、拖动滚动条，检查屏幕刷新状况，并查看是否有乱码;
c、单击滚动条;
d、用滚轮控制滚动条;
e、滚动条的上下按钮。
九、各类控件在窗体中混和使用时的测试
a、控件间的相互做用;
b、tab键的顺序，通常是从上到下，从左到右;
c、热键的使用，逐一测试;
d、enter键和esc键的使用。
在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。
ps：密码输入框测试时要特别注意进行字母大写输入的测试。
2、查找替换操做
案例演示：打开word中的“替换”对话框。
测试本功能有经过测试和失败测试两种状况：
经过测试：
a、输入内容直接查找、或查找所有;
b、在组合框中寻找已经查找过的内容、再次查找并确认文档的内容正确，如已经查找过“测试用例”、再次进入不用从新输入查找内容、直接在文档中搜寻就能够。
失败测试：
a、输入过长或太短的查询字符串。如假设查询的字符串长度为1到255，那么，输入0、一、二、25六、255和254进行测试;
b、输入特殊字符集。如在word中^g表明图片、^表明分栏符、能够输入这类特殊字符测试;替换测试大致相同。
关于编辑操做窗口的功能测试的用例：
a、关闭查找替换窗口。不执行任何操做、直接退出;
b、附件和选项测试。假如设定“精确搜寻”、“向后”搜索等附件选项等等来测试;
c、控件间的相互做用。如搜寻内容为空时、按钮“搜寻所有”、“搜寻”、“所有替换”、“替换”都为灰色。
d、热键、Tab键。回车键的使用。
插入操做
一、插入文件
测试的状况：
a、插入文件;
b、插入图像;
c、在文档中插入文档自己;
d、移除插入的源文件;
e、更换插入的源文件的内容。
二、连接文件
测试方法：
a、插入连接文件;
b、在文档中连接文档自己;
c、移除插入的源文件：
d、更换插入的源文件的内容。
三、插入对象
要测试的内容：
a、插入程序容许的对象、如在word中插入excel工做表;
b、修改所插入对象的内容。插入的对象仍能正确显示;
c、卸载生成插入对象的程序、如在word中插入excel工做表后卸载excel、工做表仍正常使用。
编辑操做
编辑操做包括剪切、复制、粘贴操做。
测试剪切操做的方法
a、对文本、文本框、图文框进行剪切;
b、剪切图像;
c、文本图像混合剪切。
复制操做方法与剪切相似。
测试时，主要是对粘贴操做的测试方法是：
a、粘贴剪切的文本、文本框及图文框;
b、粘贴所剪切的图像;
c、剪切后，在不一样的程序中粘贴;
d、屡次粘贴同一内容，如剪切后，在程序中连续粘贴3次;
e、利用粘贴操做强制输入程序所不容许输入的数据。
3、界面测试用例的设计方法
一、窗体
测试窗体的方法：
a、窗体大小，大小要合适，控件布局合理;
b、移动窗体。快速或慢速移动窗体，背景及窗体自己刷新必须正确;
c、缩放窗体，窗体上的控件应随窗体的大小变化而变化;
d、显示分辨率。必须在不一样的分辨率的状况下测试程序的显示是否正常。
进行测试时还要注意状态栏是否显示正确，工具栏的图标执行操做是否有效，是否与菜单懒中图标显示一致;错误信息内容是否正确、无错别字且明确等等。
二、控件
测试方法：
a、窗体或控件的字体和大小要一致;
b、注意全角、半角混合;
c、无中英文混合。
4、菜单
进行测试时要注意：
a、选择菜单是否能够正常工做、并与实际执行内容一致;
b、是否有错别字;
c、快捷键是否重复;
d、热键是否重复;
e、快捷键与热键操做是否有效;
f、是否存在中英文混合;
g、菜单要与语境相关、如、不一样权限的用户登录一个应用程序、不一样级别的用户能够看到不一样级别的菜单并使用不一样级别的功能;
h、鼠标右键快捷菜单。
特殊属性
a、安装界面应有公司介绍或产品介绍、有公司的图标;
b、主界面及大多数界面最好有公司图标;
c、选择“帮助”->“关于”命令、应看见相关版权和产品信息。
代替测试用例的检查表
2004年末在大连出差的时候，帮一个项目作测试，顺便写下这个检查表，这个检查表对测试的初学者积累经验比较有用，实际对于有经验的测试人员尤为对于测试业务管理信息系统，基本上大量的测试不须要再编写测试用例，固然对业务流程、复杂逻辑仍是要设计详细的测试用例的。若是你测试的系统是有大量人机交互的业务管理信息系统，并且你又比较懒惰，那就能够使用这个检查表检查了。
所以我总结了这类系统中经常使用的测试的检查项，供当时项目组的测试人员使用，如今再次整理出来发于博客。
1 针对测试组长或测试经理
1.1测试管理工做检查表：
1. 检查每轮测试开始时测试环境是否准备好（包括软件硬件、测试基本数据等）；
2. 确保测试环境（数据和程序）与开发分离，除了测试组以外其余人不能更新测试环境的数据和程序；
3. 每轮测试根据上一轮的状况和整体测试计划作分工调整；
4. 检查case库的填报状况，抽查执行过的case；
5. 检查BUG提交状况，抽查提交的BUG是否规范；
6. 天天晚上统计BUG状况，填写天天的BUG报告；
7. 根据天天的测试状况，决定是否开发组要发布新的BUILD；
8. 每轮测试结束后填写测试总结。
2 下面是针对测试执行人员的：
2.1输入、编辑功能的验证检查点：
1. 必输项是否有红星标记，若是不输入提示是否跟相应的Label对应，提示的顺序是否跟Form输入域的排列次序一致；
2. 输入的特殊字符是否能正确处理：`~!@#$%^&*()_+-={}[]|\:;”’<>,./?；