2018-08-22 10:04:09
故障模型---缺陷查找攻击的二十一招大法
3．输入特殊字符集
根据被测软件的具体情况输入非法字符。
多了解ASCII 字符集、程序设计语言和OS中的保留字符串及其特定含义。
4．输入使缓冲区溢出的数据
在需要接受字符串的地方输入一个比最大字符串更长的字符串。
黑客常用此法来攻击系统。
14．计算结果溢出
一次又一次地执行计算或使用很大或很小的输入和数据进行计算，重点测试数据类型的初始值或边界值附近的值，强制数据产生上溢或下溢。
16．文件系统超载
当软件较大，运行时需要较大空间时，强制磁盘系统满容量或小于等于被测试软件运行时所需容量后，运行被测试软件或利用测试工具模拟磁盘状况。
21．文件内容受损
对于那些需要对文件格式和内容进行校验的应用程序，可通过手工损坏文件或利用测试工具模拟CRC错误。
界面设计的行业标准总结一
GUI的整体标准包括以下四个方面：
1.规范性
2.合理性
3.一致性
4.界面定制性
一、GUI设计的规范性
遵循一致的准则，确立标准并遵循，是软件界面设计中必不可必的环节。确立界面标准的好处：
1.便于用户操作：户使用起来能够建立起精确的心里模型，使用熟练了一个界面后，切换到另外一个界面能够很轻松的推测出各种功能
2.使用户感觉到统一、规范，在使用软件的过程中愉快轻松的完成操作，提高对软件的认知
3.降低培训、支持成本，不必花费较多的人力对客户进行逐个指导
二、GUI布局的合理性
界面的合理性是指界面是否与软件功能相融洽，界面的颜色和布局是否协调等。例如：
1.界面布局
a.屏幕不能拥挤
* Mayhew在1992年的试验结果表明屏幕总体覆盖度不应该超过40％，而分组覆盖度不应该超过62％。
* 整个项目，采用统一的控件间距，通过调整窗体大小达到一致，即使在窗体大小不变的情况下，宁可留空部分区域，也不要破坏控件间的行间距。
b.控件按区域排列
* 一行控件纵向中对齐, 控件间距基本保持一致，行与行之间间距相同，靠窗体的控件距窗体边缘的距离应大于行间距。
* 当屏幕有多个编辑区域，要以视觉效果和效率来组织这些区域
c.有效组合
逻辑上相关联的控件应当加以组合以表示其关联性，反之，任何不相关的项目应当分隔开。在项目集合间用间隔对其进行分组，或者使用方框划分各自区域
d.窗口缩放时，控件位置、布局
* 固定窗口大小，不允许改变尺寸
* 改变尺寸的窗口，在窗口尺寸发生变化时控件的位置、大小做出相应的改变
* 改变尺寸的窗口，在窗口改变尺寸时增加相应在的纵向、横向滚动条，以方便用户使用窗体上的控件
2.界面颜色搭配
使用恰当的颜色，可以使软件的界面看起来更加规范：
a.统一色调
针对软件类型以及用户工作环境选择恰当色调，如：安全软件，根据工业标准，可以选取黄色。绿色体现环保，蓝色表现时尚清新、紫色表现浪漫等等，淡色可以使人舒适，暗色做背景使人不觉得累等。
b.与操作系统统一，读取系统标准色表
c.遵循对比原则
在浅色背景上使用深色文字，深色背景上使用浅色文字，如蓝色文字以白色背景容易识别，而在红色背景则不易分辨。除非特殊场合，杜绝使用对比强烈，让人产生憎恶感的颜色
d.整个界面色彩尽量少的使用类别不同的颜色
e.颜色方案也许会因为显示器、显卡、操作系统等原因显示出不同的色彩
f.针对色盲、色弱用户，可以使用特殊指示符
e.颜色方案也许会因为显示器、显卡、操作系统等原因显示出不同的色彩
f.针对色盲、色弱用户，可以使用特殊指示符
三、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（见附件）列出了常用的快捷键及其功能。
四、GUI界面操作可定制性
界面的可定制性大致可分为以下几个特性：
1.界面元素可定制
允许用户定义工具栏、状态栏是否显示，工具栏显示在界面上的位置；允许用户定义菜单的位置等。
2.工具栏可定制
不同用户对常用工具的使用是不同的，因此允许用户建立新的工具栏，选择要显示的工具栏，定制工具栏上的按钮等功能在软件系统中经常被用到
3.统计检索可定制
对于某些特殊行业的软件可以提供统计检索的可定制性，在充分了解用户需求的基础上制定大量的安全供用户选择。
GUI所包含各类元素标准的定制
GUI的元素大致可分为以下几个方面：
1. 窗口
2. 菜单
3. 图标
4. 控件
5. 鼠标
6. 文字
7. 联机帮助
界面设计的行业标准总结二
一、GUI窗口的标准
窗口是显示设备中的一个区域，用于观看对象、对象相关信息以及应用与对象的动作进行交互。从外观上来说，通常窗口是由标题、边框、菜单、工作区、滚动条等组成。窗口的标题栏可以进行打开、关闭、创建、缩放、移动、删除、重叠等操作
好的GUI窗口应该具备以下标准：
1.窗口控件的大小、对齐方向、颜色、背景等属性的设置和程序设计规约相一致
2.显示相关的下拉菜单、工具条、滚动条、对话框、按钮、图标和其他控制，既能正确显示又能调用
3.若窗口无法显示，所有内容能够改变大小、移动和滚动
4.活动窗口能够反显加亮
5.窗口能够正确的关闭
6.多个窗口叠加时窗口的名称正确显示
7.窗口的数据能够利用鼠标、功能键、方向前头和键盘操作
8.当窗口被覆盖并重新调用后，窗口能够正确再生
9.如果使用多任务，所有的窗口能够被实时更新
10.窗口支持最小化和最大化或放大
11.窗口上的控件随着窗体的缩放而缩放
12.父窗体支持缩放时，子窗体也应该支持缩放
13. 一个窗口中按Tab键，移动聚焦按顺序移动。先从左至右，再从上到下
14.子窗口位置在父窗口的左上角或正中，正上方1/4处为易吸引用户注意力的位。父窗口或主窗口的中心位置应该在对角线焦点附近，如下图2-1-2所示
15.当多个子窗口弹出时依次向右下方偏移，并且显示出窗口标题，如下图2-1-3所示
16.重要的命令按钮与使用频繁的按钮放在了界面醒目的位置
17.与正在进行的操作无关的按钮应该加以屏蔽
18.按钮大小要与界面的大小和空间协调
19.窗口中所包含的标签左对齐排列
20.多窗口的切换响应时间不宜过长
二、GUI菜单的标准
菜单是否易用主要体现在它能否提供线索帮助用户识别，而不用强迫用户去记忆，一个好的菜单设置可以分为以下几个方面：
1.菜单设置符合软件的需求
2.菜单项的措词准确，能够表达出所要进行设置的功能
3.菜单项的顺序合理，具有逻辑关联的项目集中放置
4.图形布局一致
5.菜单设置在窗体标题栏的下方
三、GUI图标的标准
图标是表示实体信息简洁、抽象的符号，它还可以作为可视按钮项，当被选中激活时，可以完成指定的功能。那么图标的设计当中应该着重考虑哪些问题呢，以下提供几点可供参考：
1.图标的设置符合常规的表达习惯
2.不同的目标采用不同的图标
3.图标具有清晰的轮廓，轮廓清晰的图标可保证图像在不同背景色上都具有较好的效果
4.选择合适的尺寸来定义图标。Windows XP系统的图标有四种尺寸（以像素为单位）可作为参考： 48×48， 32×32，24×24以及16×16，图标大小的选取决定于工具栏所定义的宽度
5.图标的外形与实际功能相似，应尽量避免抽象。这样的图标可以使用户很轻松、容易地认识图标的作用
6.在图标上加以标注，用来说明图标所完成的功能
7.图标放置在菜单栏的下方
四、GUI中控件的标准
软件系统功能的实现与控件是密不可分的，各控件位置的摆放直接影响到软件的使用，及其美观程度。下面举例说明软件系统中最常用到的控件对其元素间距、摆放位置进行说明：
1.控件元素的间距
a.单个元素间距
* 输入框之间垂直间距为5px
* Label文本标签和输入元素之间水平间距为8-22px
* 复选框、单选按钮之间垂直间距为8px
* 多种元素混合垂直排列时，复选框和单选按钮边上的间距无论在什么情况下都为8px
b.元素分组间距
* 窗口边框和内容区域的四周边距为11px；
* 父组和子组之间的四周间距为10px；
* 分组框边框和内部内容区域的四周边距为5px；
* 复选框组、单选框组的组水平间距为15px
2.按钮的位置，如下表2-4-1对按钮摆放位置的规则做了总结
五、鼠标在GUI中的标准
用户会把鼠标移进、移出窗口，或当光标在窗口，或当光标在窗口中，用户按下、释放鼠标键，鼠标是否准确、灵活，对一个软件系统来说也很重要。以下几点标准可作为在软件系统中鼠标设计的参考：
1.在整个交互的过程中，可以识别鼠标操作
2.多次点击鼠标后，仍能够正确识别
3.鼠标有多个按钮的情况下，能够正确识别每个按钮所要完成的功能
4.光标、处理指示器和识别指针随操作恰当的改变
5.点击选中时，鼠标指针停留在选中内容上，而不会滑动
6.支持鼠标滑轮上下翻动操作
7.对于相同种类的元素采用相同的操作激活
8.采用动态图标形象的表示出当前的操作，如用水漏表示系统忙，用手型表示可以点击等
9.鼠标无规则点击时不会产生不良后果
10.单击鼠标右键弹出快捷菜单，取消右键后该菜单隐藏
11.鼠标光标样式统一，尽量使用系统标准，杜绝出现重复的情况
六、GUI文字的标准
文字在视觉上向用户传达各种信息，界面文字包括界面文字的字体和界面文字的用语两个方面，那这两方面都有哪些要求呢？以下分别阐述。
1.字体
a.使用统一字体，如规定软件系统的中文字体为“宋体”，英文及数据采用“Times New Roman”
b.所有控件、描述信息尽量使用大小统一的字体属性，除了特殊提示信息、加强显示等例外情况
2.文字表达
提示信息、帮助文档文字表达遵循以下准则：
a.口语化描述，用词客气多用您、请，不要用或少用专业术语，杜绝错别字
b.标点符号（断句、逗号、句号、顿号、分号）的用法要统一， 提示信息比较多的话要进行分段
c.警告、信息、错误 使用对应的表示方法
d.使用统一的语言描述，例如一个关闭功能按钮，可以描述为退出、返回、关闭，则应该统一规定
e.根据用户不同采用相应的词语语气语调
七、GUI联机帮助的标准
帮助文档适用于以下三种情况：
* 系统默认、行业标准的控件操作不需要逐一描述，只需要对特殊控件加以描述
* 特殊操作、特殊功能界面，在界面上加控件直接连接到对应的帮助文件中
* 特殊设置的详细信息，除了应该在界面上用简洁明了的语句说明外，还可以在界面上加控件直接连接到对应的帮助文件中
帮助文档的标准要求：
* 结构化，按功能模块划分
* 必须阐述功能通过什么方法可以在软件中实现
* 措词恰当、简捷、通俗易懂，明了的帮助用户解决问题
* 不在帮助文档中做广告宣传
浅谈易用性测试及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. 对于范围的查询采用全闭的形式。
网站测试清单
通用
◇ 所有测试是否运行在干净系统上？
◇ 系统是否正常运行？
◇ 是否显示正确输出？
◇ 系统是否能提供所需功能？
◇ 普通用户是否能轻松地操作该系统？
◇ 是否易学易用？
◇ 系统是否会为客户提供服务？如响应的、有帮助的、正确的服务？
◇ 是否可以简单辨别系统的正确性与可靠性？
◇ 是否能轻易地修复或修改系统？
◇ 新版本中未经修改的功能是否能与老版本保持一致？
◇是否可以有效验证系统的工作方式是适当的？
◇ 本系统内一些组成部分是否可以被其他的系统再利用？
◇ 不同用户不同平台上安装系统是否同样快捷便利？
◇ 系统是否设置有未来更新的路径？
◇ 是否可以方便地获取信息？
◇ 网站是否能被搜索
可用性、界面及导航
◇ 系统为一个用户、十个用户或一千个用户服务时，是否同样工作正常？
◇ 是否可以快速登陆主页？
◇ 网站的操作方法是否清晰地展示给用户？
◇ 如果按操作方法进行操作是否可以得到预期结果？
◇ 是否所有新用户都理解网站内的所有术语？
◇ 是否所有窗体都有导航栏？
◇ 导航栏的位置是否始终保持一致？
◇ 是否导航栏仅作用于使用中的文本？
◇ 用户是否可以在不用鼠标的情况下使用导航栏功能？
◇ 视力障碍者是否可以使用网站？红绿色盲，少于 20/20
◇ 网站标志是否风格一致？
◇ 每个单独页面内是否包含主页链接？
◇ 每个页面的排版是否统一？
◇ 每个页面的管理风格是否一致？
◇ 网站内图表的使用是否协调？
◇ 快速下载的图表是否质量优化？
◇所有图片是为页面添彩，还是浪费网速？
◇ 是否使用了图表的最佳尺寸？
◇ 图表/图片周围的文字布局是否合理？
◇ 是否对所有的参考网站或电子邮件地址都设置了超链接？
◇ 超链接颜色设置是否标准？
◇ 网站在 1024x 768、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及 等
测试文件选择框的正确性。使用空文件，只有空格的文件，不同类型的文件，同名文件，内容相同名称不同的文件，大文件等。
测试强制性字段的正确性（即必输项测试），强制性字段必须用红色的星号*标识。强制性字段两种处理方式：最好是必填项没有输入时，在光标移走时在相应的文本框后显示需要用户输入的红色信息。一般也可以在提交时用弹出消息框提示未填的必填项，关闭消息框后必须停留在第一个待输入的文本框中。
每一个新窗口/屏幕中，光标默认停留在第一个待输入的文本框中。
一般下拉框中应显示一个默认值，列表框中高亮度显示一个默认值。如果不需要默认值时，一般默认值未“请选择。。。”。
一般来说系统应记忆以前输入或选择的信息，但是当涉及安全时，最好不要保留用户的信息。有些地方可以使用复选框让用户决定是否要保留信息。如登录界面。
对输入信息类型有限制的文本框应在输入非法值后给予提示，对于日期型的输入框，最好在标签上就给予提示
当输入的内容达到了字段的长度限制时，一般应控制不允许再输入，或者在提交后提示具体的允许输入的长度或者在光标转移时提示‘***允许输入的最大长度是***’等，而不是自动截断。（农信社资金业务管理系统目前采取右截断的处理方式，因此有问题）
系统中不允许的非法字符，最好是在输入时不允许输入，或在提交时给予具体系统不允许的非法字符列表提示。（如’、”、<、<>）
正确使用复选框或单选框。如果结果只有一个的，则使用单选框，如性别。验证单选按钮不能同时选中只能选中一个，而可以选择多个复选框。
一组单选按钮在初始状态时必须有一个被默认选中，不能同时为空。
分别测试多个复选框可以被逐一选中；同时选中，部分选中；都不被选中。
通过输入数字或用点击上下箭头来测试旋转按钮,测试其自动循环性，如范围为（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（查询）：查询记录。每次查询应显示返回的结果数。每次查询应定位到首页（当查询结果有多页时，应定位到首页）。保留前一次的查询条件。当查询条件较多时，需配以重置按钮。当未查询到任何记录时，需给予未查找到相关记录的提示信息。除用户明确要求不需要外，需提供模糊查询及组合查询功能。当查询返回的结果大于默认的一页大小时，最好采用分页或者根据系统默认或用户定义的一页显示的记录数量来分页。如有多页，需要提供首页，下一页，上一页，尾页和跳至功能。每页的记录不能重复，但也可以根据用户需要显示上一页的最后一条数据。
Reset（重置）：重置。应回到打开窗口时的最初状态。多次点击是否还能正常显示。
Return（返回）：返回。如果一个窗口或页面不能通过菜单，工具栏到达，而是必须通过前一个窗口完成才到达，应提供返回按钮或导航条让用户可以返回。
如果点击按钮后还需要用户的进一步的操作，按钮的名称应加上省略号。如Browse。。。
OK/Cancel/Apply/Help键的排放最好遵从Windows的标准排放。
按钮最好都给予浮动提示（什么是浮动提示），特别是图片按钮，可以避免由于网络太慢而导致的太长时间不能往下操作。
GUI测试之对话框、消息框篇
对话框/消息框的缺省<Enter>键应该设置在OK按钮上；对话框/消息框的缺省<Esc>键应该设置在Cancel按钮上。
一般来说重要的或复杂操作成功后应该给予提示，根据系统的特性选择弹出信息框或文字显示。需要后续操作的操作在成功后应给予提示。
非法的输入或操作应给出足够的提示说明。
对可能造成数据无法恢复的操作应该给予确认信息，给用户放弃选择的机会。如删除操作。
提示信息不宜太长，宽度不能超过当前窗口的1/2；当超过此比例时，请视具体情况进行换行。有多行提示信息的，请选择对齐方式（一般为左对齐）。
静态文本标签一般采用左对齐，这样显得更有条理且易于浏览。 静态文本标签一般置于相关控件的左边，有时选项过多过长时放在上面。
复杂或带有专业性的操作或输入最好在输入项下面给予提示。
通用对话框控件，如Open…，Save As…，Color…，Fonts…，Print…，Page SetUp…等调用系统的对话框只需要是否调用正确，能否实现正常功能就可以了，里面的具体功能可以不用测试。
消息框中的图标必须根据需要选择正确的使用，一般来说 X 表示有很重要的问题需要提醒用户；? 增亮没有危险的问题； ! 强调警告用户必须知道的事情； i 一般信息，可以使乏味的信息变得有趣。
正在进行的操作提示框应使用省略号，如“删除中。。。”。
对话框标题文本中不要出现省略号。如选择"打印选项..."命令结果而显示的对话框的标题应该为"打印"，而不是“打印。。。”。但是，表示命令正在执行过程中菜单对话框（如"连接到Internet..."对话框）是一种例外情况。
对于耗时的操作都应给出类似等待光标、进度表或其他的可视反馈。用户可以取消长时间的操作。如果可以取消未完成的操作，那么将按钮标记为"取消"，否则将按钮标记为"停止"。
网站测试的主要方面
1功能测试
对于网站的测试而言，每一个独立的功能模块需要单独的测试用例的设计导出，主要依据为《需求规格说明书》及《详细设计说明书》，对于应用程序模块需要设计者提供基本路径测试法的测试用例。
● 链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面：
1）测试所有链接是否按指示的那样确实链接到了该链接的页面；
2）测试所链接的页面是否存在；
3）保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
Xenu------主要测试链接的正确性的工具
可惜的是对于动态生成的页面的测试会出现一些错误。
●表单测试
当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。
B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量。
●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 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。
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
此工具能够测出网站系统的相应的安全问题，并且能够给出安全漏洞的解决方案，不过是一些较为常见的漏洞解决方案。