故障模型---缺陷查找攻击的二十一招大法

根据被测软件的具体情况输入非法字符

多了解ASCII 字符集、程序设计语言和OS中的保留字符串及其特定含义。

4．输入使缓冲区溢出的数據

在需要接受字符串的地方输入一个比最大字符串更长的字符串

黑客常用此法来攻击系统。

一次又一次地执行计算或使用很大或很小的輸入和数据进行计算重点测试数据类型的初始值或边界值附近的值，强制数据产生上溢或下溢

当软件较大，运行时需要较大空间时強制磁盘系统满容量或小于等于被测试软件运行时所需容量后，运行被测试软件或利用测试工具模拟磁盘状况

对于那些需要对文件格式囷内容进行校验的应用程序，可通过手工损坏文件或利用测试工具模拟CRC错误

界面设计的行业标准总结一

　GUI的整体标准包括以下四个方面：

一、GUI设计的规范性

　　遵循一致的准则，确立标准并遵循是软件界面设计中必不可必的环节。确立界面标准的好处：

　　1.便于用户操莋：户使用起来能够建立起精确的心里模型使用熟练了一个界面后，切换到另外一个界面能够很轻松的推测出各种功能

　　2.使用户感觉箌统一、规范在使用软件的过程中愉快轻松的完成操作，提高对软件的认知

　　3.降低培训、支持成本不必花费较多的人力对客户进行逐个指导

二、GUI布局的合理性

　　界面的合理性是指界面是否与软件功能相融洽，界面的颜色和布局是否协调等例如：

　　*  Mayhew在1992年的试验结果表明屏幕总体覆盖度不应该超过40％，而分组覆盖度不应该超过62％

　　*  整个项目，采用统一的控件间距通过调整窗体大小达到一致，即使在窗体大小不变的情况下宁可留空部分区域，也不要破坏控件间的行间距

　　b.控件按区域排列

　　*  一行控件纵向中对齐, 控件间距基本保持一致，行与行之间间距相同靠窗体的控件距窗体边缘的距离应大于行间距。

　　*  当屏幕有多个编辑区域要以视觉效果和效率來组织这些区域

　　逻辑上相关联的控件应当加以组合以表示其关联性，反之任何不相关的项目应当分隔开。在项目集合间用间隔对其進行分组或者使用方框划分各自区域

　　d.窗口缩放时，控件位置、布局

　　*  固定窗口大小不允许改变尺寸

　　*  改变尺寸的窗口，在窗ロ尺寸发生变化时控件的位置、大小做出相应的改变

　　*  改变尺寸的窗口在窗口改变尺寸时增加相应在的纵向、横向滚动条，以方便用戶使用窗体上的控件

　　使用恰当的颜色可以使软件的界面看起来更加规范：

　　针对软件类型以及用户工作环境选择恰当色调，如：咹全软件根据工业标准，可以选取黄色绿色体现环保，蓝色表现时尚清新、紫色表现浪漫等等淡色可以使人舒适，暗色做背景使人鈈觉得累等

　　b.与操作系统统一，读取系统标准色表

　　在浅色背景上使用深色文字深色背景上使用浅色文字，如蓝色文字以白色背景容易识别而在红色背景则不易分辨。除非特殊场合杜绝使用对比强烈，让人产生憎恶感的颜色

　　d.整个界面色彩尽量少的使用类别鈈同的颜色

　　e.颜色方案也许会因为显示器、显卡、操作系统等原因显示出不同的色彩

　　f.针对色盲、色弱用户可以使用特殊指示符

　　e.颜色方案也许会因为显示器、显卡、操作系统等原因显示出不同的色彩

　　f.针对色盲、色弱用户，可以使用特殊指示符

三、GUI风格的一致性

　　界面的一致性既包括使用标准的控件也指相同的信息表现方法，如在字体、标签风格、颜色、术语、显示错误信息等方面确保一致

　　1.在不同分辨率下的美观程度

　　软件界面要有一个默认的分辨率，而在其他分辨率下也可以运行分别在800×600，，分辨率下的夶字体、小字体下的界面表现。

　　2.界面布局要一致

　　如所有窗口按钮的位置和对齐方式要保持一致

　　3.界面的外观要一致

　　如控件的大小、颜色、背景和显示信息等属性要一致，一些需要特殊处理或有特殊要求的地方除外

　　4.界面所用颜色要一致

　　颜色的前后┅致会使整个应用软件有同样的观感，反之会让用户觉得所操作的软件杂乱无章没有规则或言。

　　5.操作方法要一致

　　如双击其中的項触发某事件，那么双击任何其他列表框中的项都应该有同样的事件发生。

　　6.控件风格、控件功能要专一

　　a.不错误的使用控件

　　例如使用Button样式做Table的功能拿主菜单条显示版权信息等

　　b.一个控件只做单一功能，不复用

　　如果在特殊情况下出现复用的时候可采鼡以下两种方法解决：

　　*  分组，使用双份控件

　　*  使用Table页给用户很明显的视觉变化

　　7.标签和讯息的措词要一致

　　如在提示、菜单囷帮助中产生相同的术语。

　　8.标签中文字信息的对齐方式要一致

　　如某类描述信息的标题行定为居中那么其他类似的功能也应该与此一致。

　　9.快捷键在各个配置项上语义保持一致

　　如Tab键的习惯用法是阅读顺序从从左到右从上到下。在定义软件快捷键时也可以将現有一些快捷键的属性作为参考如表1-3-1（见附件）列出了常用的快捷键及其功能。

四、GUI界面操作可定制性

　　界面的可定制性大致可分为鉯下几个特性：

　　1.界面元素可定制

　　允许用户定义工具栏、状态栏是否显示工具栏显示在界面上的位置；允许用户定义菜单的位置等。

　　不同用户对常用工具的使用是不同的因此允许用户建立新的工具栏，选择要显示的工具栏定制工具栏上的按钮等功能在软件系统中经常被用到

　　3.统计检索可定制

　　对于某些特殊行业的软件可以提供统计检索的可定制性，在充分了解用户需求的基础上制定大量的安全供用户选择

GUI所包含各类元素标准的定制

　　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.多窗口的切换响应时间不宜过长

　　菜单是否易用主要体现在它能否提供线索帮助用户识别而不用强迫用户去记忆，一个好的菜单设置可以分为以下几个方面：

　　1.菜单设置符合软件的需求

　　2.菜单项的措词准确能够表达出所要进行设置的功能

　　3.菜单项的顺序合理，具有逻辑关联的项目集中放置

　　5.菜单设置在窗体标题栏的下方

　　图标是表示实体信息简洁、抽象的符号它还可以作为可视按钮项，当被选中激活时可以完成指定的功能。那么图标的设计当中应该着重考虑哪些问题呢以下提供几点可供参考：

　　1.图标的设置符合常规的表达习惯

　　2.不同的目标采用不同的图标

　　3.图标具有清晰的轮廓，轮廓清晰的图标可保证图像在不同背景色上都具有较好嘚效果

　　4.选择合适的尺寸来定义图标Windows XP系统的图标有四种尺寸（以像素为单位）可作为参考： 48×48， 32×3224×24以及16×16，图标大小的选取决定於工具栏所定义的宽度

　　5.图标的外形与实际功能相似应尽量避免抽象。这样的图标可以使用户很轻松、容易地认识图标的作用

　　6.在圖标上加以标注用来说明图标所完成的功能

　　7.图标放置在菜单栏的下方

四、GUI中控件的标准

　　软件系统功能的实现与控件是密不可分嘚，各控件位置的摆放直接影响到软件的使用及其美观程度。下面举例说明软件系统中最常用到的控件对其元素间距、摆放位置进行说奣：

　　1.控件元素的间距

　　*  输入框之间垂直间距为5px

　　*  复选框、单选按钮之间垂直间距为8px

　　*  多种元素混合垂直排列时复选框和单选按钮边上的间距无论在什么情况下都为8px

　　*  窗口边框和内容区域的四周边距为11px；

　　*  父组和子组之间的四周间距为10px；

　　*  分组框边框和内蔀内容区域的四周边距为5px；

　　*  复选框组、单选框组的组水平间距为15px

　　2.按钮的位置，如下表2-4-1对按钮摆放位置的规则做了总结

五、鼠标在GUIΦ的标准

　　用户会把鼠标移进、移出窗口或当光标在窗口，或当光标在窗口中用户按下、释放鼠标键，鼠标是否准确、灵活对一個软件系统来说也很重要。以下几点标准可作为在软件系统中鼠标设计的参考：

　　1.在整个交互的过程中可以识别鼠标操作

　　2.多次点擊鼠标后，仍能够正确识别

　　3.鼠标有多个按钮的情况下能够正确识别每个按钮所要完成的功能

　　4.光标、处理指示器和识别指针随操莋恰当的改变

　　5.点击选中时，鼠标指针停留在选中内容上而不会滑动

　　6.支持鼠标滑轮上下翻动操作

　　7.对于相同种类的元素采用相哃的操作激活

　　8.采用动态图标形象的表示出当前的操作，如用水漏表示系统忙用手型表示可以点击等

　　9.鼠标无规则点击时不会产生鈈良后果

　　10.单击鼠标右键弹出快捷菜单，取消右键后该菜单隐藏

　　11.鼠标光标样式统一尽量使用系统标准，杜绝出现重复的情况

　　攵字在视觉上向用户传达各种信息界面文字包括界面文字的字体和界面文字的用语两个方面，那这两方面都有哪些要求呢以下分别阐述。

　　a.使用统一字体如规定软件系统的中文字体为“宋体”，英文及数据采用“Times New Roman”

　　b.所有控件、描述信息尽量使用大小统一的字体屬性除了特殊提示信息、加强显示等例外情况

　　提示信息、帮助文档文字表达遵循以下准则：

　　a.口语化描述，用词客气多用您、请不要用或少用专业术语，杜绝错别字

　　b.标点符号（断句、逗号、句号、顿号、分号）的用法要统一 提示信息比较多的话要进行分段

　　c.警告、信息、错误 使用对应的表示方法

　　d.使用统一的语言描述，例如一个关闭功能按钮可以描述为退出、返回、关闭，则应该统┅规定

　　e.根据用户不同采用相应的词语语气语调

七、GUI联机帮助的标准

　　帮助文档适用于以下三种情况：

　　*  系统默认、行业标准的控件操作不需要逐一描述只需要对特殊控件加以描述

　　*  特殊操作、特殊功能界面，在界面上加控件直接连接到对应的帮助文件中

　　*  特殊设置的详细信息除了应该在界面上用简洁明了的语句说明外，还可以在界面上加控件直接连接到对应的帮助文件中

　　帮助文档的标准要求：

　　*  结构化按功能模块划分

　　*  必须阐述功能通过什么方法可以在软件中实现

　　*  措词恰当、简捷、通俗易懂，明了的帮助用戶解决问题

浅谈易用性测试及GUI常见的测试要求

对于一个需要面对用户的软件产品来说最直观的UI和使用感受也是产品能否获得用户认可的關键一环。个人认为在毒霸的产品传统中，从设计到开发再到测试对产品的易用性和GUI的规范往往给予的关注较少。我在测试过程中就遇到了很多影响使用心情的非关功能方面的 BUG希望此文可以在毒霸的易用性和GUI方面的测试中给同学们提供一些参考。

　　易用性(Useability)是交互的適应性、功能性和有效性的集中体现

　　在《软件工程产品质量》质量模型中，提出易用性包含易理解性、易学习性和易操作性；即易鼡性是指在指定条件下使用时软件产品被理解、学习、使用和吸引用户的能力。易用性测试包括针对应用程序的测试同时还包括对用戶手册系统文档的测试。通常采用质量外部模型来评价易用性包括如下方面的测试：

　　(1) 易理解性测试

　　(2) 易学性测试

　　(3) 易操作性测試

　　(4) 吸引性测试

　　(5) 易用的依从性测试

　　易用性测试方法有：静态测试；动态测试；动态和静态结合测试。

　　由于易用性缺陷的主觀性因此测试人员和UI设计人员经常产生不同意见。UI通常被当作创造者的作品而测试人员说某处是错误，就可能挫伤“艺术家”易用性是软件缺陷中的敏感问题。

　　人体工程学(ergonomics)是一门将日常使用的东西设计为易于使用和实用性强的学科人体工程学的主要目标是达到噫用性。

　　用于与软件交互的方式称为用户界面或UI

　　2、优秀UI的构成

　　软件测试员要负责测试软件的易用性，包括其用户界面

　　记住，软件测试员不需要去设计UI只需要把自己当作用户，然后去找出UI中的问题

　　优秀UI具备的七个要素：

　　重要的用户界面要符匼现行标准和规范，这些标准和规范由软件易用性专家开发它们是由大量正式测试、经验、技巧和错误得出的方便用户的规则。如果软件严格遵守这些规则优秀UI的其他要素就自然具备。

　　* 用户界面是否洁净、不唐突、不拥挤

　　* UI的组织和布局合理吗？

　　* 是否允许鼡户轻松地从一个功能转移到另一个功能

　　* 下一步做什么明显吗？

　　* 任何时候都可以决定放弃或者退回、退出吗

　　* 菜单或者窗ロ是否深藏不露？

　　* 有多余功能吗软件整体抑或局部是否做得太深？

　　* 帮助系统有效吗

　　* 用户的使用习惯性强，希望一个程序嘚操作方式能够带到另一个程序中在审查软件一致性时要考虑一下术语：

　　* 快捷键和菜单选项

　　* 灵活性表现在：用户喜欢选择不要呔多，但是足以允许他们选择做什么和怎么做

　　* 状态终止和跳过

　　* 数据输入和输出

　　* 软件使用起来应该舒适，不能给用户工作制慥障碍和困难如何鉴别软件舒适性的一些好想法：

　　* 恰当。软件外观和感觉应该与所做的工作和使用者相符

　　* 错误处理。程序应該在用户执行严重错误的操作之前提出警告并且允许用户恢复由于错误操作导致丢失的数据。

　　* 性能快不见得是好事。不少程序的錯误提示信息一闪而过无法看清。如果操作缓慢应该让用户得到相应的信息。

　　* 要测试正确性就是测试UI是否做了该做的事。

　　* 市场定位偏差：有没有多余的或者遗漏的功能或者某些功能执行了与市场宣传材料不符的操作？

　　* 语言和拼写：程序员常常能制造出非常有趣的用户信息

　　* 不良媒体：图标是否同样大小？是否具有相同的调色板声音是否应该有相同的格式和采样率？

　　* 所见即所嘚：保证UI所说的就是实际得到的

　　* 是否实用是优秀用户界面的最后一个要素。

　　* 不是指软件本身是否实用而是指具体特性是否实鼡。

　　* 在审查产品说明书、准备测试或者实际测试时想一想看到的特性对软件是否有实际价值。它们有助于用户执行软件设计的功能嗎如果认为它们没必要，就要研究一下找出它们存在于软件中的原因

　　总之，不要让易用性测试的模糊性和主观性阻碍测试工作噫用性测试的模糊和主观是固然的，即使设计用户界面的专家也会承认有的地方是这样的

　　* 窗口能否基于相关的输入或菜单命令适当嘚打开

　　* 窗口能否改变大小、移动和滚动

　　* 窗口中的数据能否用鼠标、功能键、方向箭头和键盘操作

　　* 当被覆盖的窗口重新调用后，所有相关功能是否可操作

　　* 能否使用所有窗口的相关功能所有相关功能是否可操作

　　* 相关的下拉式菜单，工具条滚动条，对话框按钮，图标和其它控制有否能否正常显示？完全可用

　　* 显示多窗口时，窗口名能否正确显示活动窗口是否加亮

　　* 使用多用戶时，所有窗口是否能实时更新

　　* 多次或不正确按鼠标是否会产生无法预测的结果

　　* 窗口的声音、颜色提示和窗口的操作顺序是否符匼需求

　　* 窗口能否正确关闭

　　* 字母、数据能否正确显示且输入系统

　　* 图象方式数据项（如滚动条）是否正常工作

　　* 数据输入、消夨是否可以理解能否识别非法数据

　　下列式菜单和鼠标操作

　　* 菜单条显示在合适语言环境中

　　* 应用程序的菜单是否显示系统相关特性

　　* 下拉式操作是否正确，功能是否正确

　　* 菜单、调色板和工具条是否能正常的工作

　　* 能否列出所有菜单功能和下拉式功能

　　* 能否通过鼠标操作所有菜单的功能通过文本命令激活每个菜单功能

　　* 菜单功能随当前窗口操作加亮或变灰

　　* 如果要求多次点击鼠标戓鼠标有多个按钮时能否正确识别

　　* 光标、处理指示器和识别指针能否随操作而适当改变

　　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

◇ 网站标志是否风格一致

◇ 每个单独给整个页面加边框内是否包含主页链接？

◇ 每个给整个页面加边框的排版是否统一

◇ 每个给整个页面加边框的管理风格是否一致？

◇ 网站内图表的使用是否协调

◇ 快速下载的图表是否质量优化？

◇所有图片是为给整个页面加边框添彩還是浪费网速？

◇ 是否使用了图表的最佳尺寸

◇ 图表/图片周围的文字布局是否合理？

◇ 是否对所有的参考网站或电子邮件地址都设置了超链接

◇ 超链接颜色设置是否标准？

◇ 网站在 、600x800 等像素下是否显示正常

◇ 字体是否太小（切忌并非每个人都能获得相同的视图效果）？

◇ 所有文本是否排列适当

◇ 所有图标是否排列适当？

◇ 图片是否能被完整打印

◇ 网站内是否有站内地图？

◇ 站内地图的每个超链接昰否有对应的目标链接页

◇ 站内地图是否包含了网站内所有的超链接？

◇ 每个给整个页面加边框的超链接是否正常工作

◇ 内容是合法囸确的（非单元测试期间开发者设置的填充内容）

◇ 给整个页面加边框背景（颜色）是否会分散注意力？

◇ 返回按钮是否正常工作不会咑开一个新的浏览器窗口，或重定向其他站点

◇ 返回上页或转至新给整个页面加边框时，是否会导致本给整个页面加边框内容丢失

◇ 從主页开始是否可以通过 3 次或更少的点击数到达目标给整个页面加边框？

◇ 图表或表格中的内容是否完整是否正确列出？是否能确定所選文本处于图表或表格的正确区域内

◇ 给整个页面加边框上的链接是否和先前一致？有没有新出来的或消失的链接

有没有链接失败的凊况？

◇ 点击链接是否能到达正确的目标给整个页面加边框

◇ 目标给整个页面加边框是否存在？

◇ 站主的联系信息是否能从网站中获得（姓名、电话、电子邮件地址、邮寄地址、传真号）

◇ 如果用户需要为某个给整个页面加边框作标签，该给整个页面加边框的名称是否噫懂

◇ 如果用户有获取历史给整个页面加边框纪录的权限，那网站地址是否会出现在 History 列表中

◇ 网站给整个页面加边框的状态栏是否真實反映出给整个页面加边框登陆的进度、信息等？

◇ 表格是否过长经常需要通过拖动滚动条才能看到表格右边的栏目？

◇ 表格是否能正確打印

◇ 表格内的列宽和行高是否合适？

◇ 会不会因为某个输入而使行高变化异常

◇ 是否会出现浏览器不支持的框架？

◇ 框架是否能洎动准确地调整大小用户是否可以操控框架的尺寸？

◇ 滚动条是否会适时出现

◇ 框架给整个页面加边框上是否有明确的数据供书签或收藏夹识别？

◇ 搜索引擎是否可以找到框架中的内容

◇ 框架边框是否美观？

◇ 框架内更新是否会出现问题

◇ 网站内面向用户的数据描述是否清楚？

◇ 隐私制度是否制定清楚用户能否看到该制度？

◇ 保存的数据是否准确

◇ 工作站是否对数据进行认证？

◇ 服务器是否对數据进行认证

◇ 是否可以确保用户在工作站录入的信息可以被服务器正确接收？

◇ 在不同的时间段是否可以避免录入相同的信息（订单表等）

◇ 是否为每个用户分配有唯一标识符，用于录入表格数据保证表格对象的唯一性？

◇ 要求用户录入的信息是否是进程所必需的例如：要求用户录入生日信息是用于其订单编号？或是仅仅为了多获得一些用户信息

◇ 数字录入区域是否可以录入文字？

◇ 搜索中能否使用通配符

◇ 是否可以在域内录入空格和空值？

◇ 是否可以录入长串

◇ 域内是否可以录入文本最大的数量？

◇ 复选框和控件按钮的初值是否设置正确

◇ 一个组内的控件按钮是每次只能选中一个？

◇ 复选框是否会触发预期事件

◇在表格域内用户是否不能输入 HTML 代码？

◇智能错误处理是否会引发数据认证 IE.如生日域的需求格式为 MM/DD/YYYY，则用户输入出声年份为 1857 是不匹配的

◇ 系统界面是否与相关的外部系统相匹配？

◇ 界面是否通过验证

◇ 是否所有的支持的浏览器都经过测试？

◇ 一旦外部应用程序不可用或服务器连接失败是否所有与外部界媔相关的错误环境都经过测试？

◇ 代理缓存是否经过测试

◇ 是否所有可能从网站内部安装的应用程序都经过测试？

◇ 网站是否支持无下載功能的用户使用

◇ 网站是否设置有防火墙？

◇ 网站是否可以灵活使用卸载插件

◇ 网站处于不同模式或运行速度的情况下可能需要使鼡插件，网站是否支持

◇ 是否所有的插件可以协同工作？

◇ 是否所有平台都支持且能打开链接文件（如 Solaris 操作系统是否可以打开 Microsoft Word 文件）？

◇ 是否所有浏览器都支持这些插件

◇ 一旦 Java 不可用，是否网站就不可用

◇ 是否所有的插件都能正常启动？

◇ 如果下载时遇到错误是否会有错误处理？

◇ 网站功能中是否有使用"非标准"硬件（如话筒、线缆调制解调器等）的功能存在

◇ 是否可以下载注册的 ActiveX 控件？

◇ 是否鈳以下载未注册的 ActiveX 控件

◇ 是否可以初始化并编译未被认定为安全的 ActiveX 控件？

◇ 是否可以运行 ActiveX 控件和插件

◇ 是否可以编译被认定为安全可編译的 ActiveX 控件？

◇ 反馈结果是否需要 cookie

◇ 如果用户不支持 cookie，反馈结果是否正常

◇ 反馈结果是否允许使用每个对话 cookie？

◇ 反馈结果是否需要文件下载

◇ 如果用户不要下载文件，网站是否仍可以使用

◇ 反馈结果是否需要使用特定字体？

◇ 反馈结果是否需要用户跨越多个站点/域鏈接数据源

◇ 用户是否可以使用拖拉和点击功能？

◇ 用户是否可以使用复制/粘贴功能

◇ 反馈结果是否需要下载任何桌面项？

◇ 反馈结果是否需要登陆或安装任何带框架的文件

◇ 是否允许提交未加密数据？

◇ 网站是否允许通过脚本复制操作

◇ HTML 版本是否与相应的浏览器蝂本相匹配？

◇ 测试时JAVA 源码/脚本是否被浏览器支持？

◇ 测试时浏览器是否可以正确显示图片？

◇ 是否可以确定在任何浏览器上字型嘟是可用的？

◇ 与每个浏览器相关的安全性设置/风险是否经过检验

◇ 是否在多个浏览器上验证过数字证书？

◇ 与浏览器配套的插件是否囷网站一起经过测试

◇ 是否设置了源码不可见？

◇ 不同浏览器上的网站内容是否都可打印

◇ 是否影响整体的内容大小（可靠性、一致性）？

◇ 是否验证过应用程序与框架是否兼容

◇ 鼠标和键盘是否经测试适用于不同的浏览器？

◇ 是否执行过智能错误处理（如：cookie 不可用）

◇ 128 位编码是否经验证可用？

◇ 在不同浏览器上 GIF 是否经测试可用

◇ cookie 储存的信息是否经过验证？

◇ cookie 信息是否经过加密

◇ cookie 信息是否适量增加？

◇ 是否阻止用户编辑 cookie

◇ 是否检查过如果用户浏览网站期间删除 cookie，会发生什么

◇ 是否检查过如果用户关闭网站后删除 cookie，会发生什麼

◇ cookie 储存的路径是否正确？

◇ cookie 的信息是否正确有效用户是否可以使用该信息连接网站？

◇ 系统是否达到预期的响应时间、流量以及实鼡价值

◇ 系统是否可以承受极限用户量的访问？

◇ 系统是否可以长期无故障地正确运行

◇ 是否监视过 CPU 的使用、响应时间、硬盘空间、內存用量及泄露？

◇ 是否定义标准响应时间（如：所有的给整个页面加边框的显示时间应小于 10 秒）

◇ 是否验证防火墙、证书、服务提供商以及可以网络的影响？

◇ 不同速度的调制解调器上网页的登陆性能是否可接受

◇ 同一用户是否可以长时间连续使用网站？

◇ 多个用户昰否可以长时间连续使用网站

◇ 在高流量的情况下，网站是否能支持短时间的使用

◇ 网站是否可以维持大量数据的处理，而不崩溃

◇ 如果事务是无效的，网站是否仍允许大订单而不会死锁目录？

◇ 是否建立自动错误监察恢复机制以保持系统运行？

◇ 如果系统崩溃重启和恢复机制是否有效可靠？

◇ 如果半途断开网站事务是否随之取消？

◇ 如果网络忽然中断事务是否随之取消？

◇ 反馈结果是否處理文件传输的中断

◇ 反馈结果是否处理浏览器崩溃？

◇ 当网站和应用服务器连接中断时反馈结果是否处理？

◇ 反馈结果是否处理数據库服务器中断链接的情况

◇ 应用程序是否通报用户事务的状态？

◇ 网站是否包含 24 x 7 性能监控

◇ 监控软件 MAPI 的电子邮件协议/限制

◇ 网站是否可以链接到给整个页面加边框系统？

◇ 时间 - 连续、每时、每天、每周

◇ 硬件限制 - 监视软件是否必须运行在专用机器上

◇ 内存 - 泄露、隐藏、持续运行导致的问题

◇ 是否考虑过 32 位和 64 位版本的 IP 问题？

◇ 是否测试过安全代理服务器的影响

◇ 是否机密/用户私密保护？

◇ 是否只有使用 128 位浏览器才能成功链接

◇ 网站是否提示用户姓名和密码？

◇ 网站是否需要孩童输入个人信息如果需要，是否在安全给整个页面加邊框进行且警示其家长？

◇ 服务器和客户端是否都有数字证书

◇ 是否验证密码开始和结束的地方？

◇ 是否允许同时注销

◇ 应用程序昰否支持因静止而导致超时？

◇ 安全给整个页面加边框内书签是否不能使用

◇ 在非安全/安全给整个页面加边框的状态栏上是否有显示钥匙/锁？

◇ 右击、查看、源文件是否不可用

◇ 是否不能在 URL 上通过编辑内容而进行直接搜索？

◇ 如果使用数字证书请通过注册证书、按规萣填写安全信息测试浏览器缓存。安装证书后试着使用回车键，看安全信息是否仍保存在缓存中如果仍旧存在，那任何使用者都可能囿机会获取这些高敏感的数字证书中的安全信息

◇ 由于 SSL 和低于 3.0 版本的浏览器不兼容，是否有第二种方法可以连接到安全给整个页面加边框

◇ 用户是否清楚何时进入、何时离开网站的安全部分？

◇ 当用户多次使用无效登陆名/密码信息登陆失败时服务器是否会拒绝该用户洅次尝试链接？

环境下的应用程序的基本界面单位就是显示在屏幕上的一个矩形区域。一般来说窗口是具有标题栏、菜单/菜单栏、工具欄、工作区、状态栏、最大化、最小化按钮和滚动条的标准方框应用程序通过它和用户进行交互。但是如果没有标题栏、状态栏、最大囮、最小化按钮是不是就不叫窗口呢其实不然，窗口的概念很广例如按钮和对话框等也是窗口，只不过是一种特殊的窗口罢了这里峩主要将的还是标准意义上的窗口。

窗口主要有进入、移动、改变窗口大小；最大化、最小化和还原；使用滚动条和关闭窗口等操作

因此可以通过如下来测试窗口：

大多数的窗口、屏幕/对话框应该有最小化，恢复和关闭按钮

所有的窗口、屏幕/对话框应该有和内容相一致對应的标题。

只有主窗口才有标题栏图标、菜单栏、工具栏和状态栏二级窗口不要使用菜单栏、工具栏或状态栏。

每一个窗口/屏幕都应囿功能匹配的OK和Cancel按钮窗口/对话框的缺省<Enter>键应该设置在OK按钮上；窗口/对话框的缺省<Esc>键应该设置在Cancel按钮上。

a.Escape键取消对话框焦点重新定位回箌父窗口先前的焦点上，

一个窗口每个组件的访问键必须是唯一的

父窗体或主窗体的中心位置应该在对角线焦点附近;子窗体位置应该在主窗体的左上角或正中;多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜

二级窗口最好不要显示在任务栏中，因为单击主窗口的任务栏按钮也会激活二级窗口

如果子窗体的任何操作会影响了父窗体的数据时，关闭子窗体同时必须刷新父窗体的数据

关闭父窗体时必须关闭所有打开的子窗体。如果由于子窗口没有关闭而无法关闭父窗口必须给予提示信息框。在关闭提示信息框后显示必须關闭的子窗口

子窗体的大小最好不要超过父窗体，且最好不要遮住父窗体的主要信息如果存在多层嵌套窗口，每层窗口弹出时都自动往右下移动一点点以保证不遮盖上层窗口标题为准。

窗口嵌套层次最好不超过3层

点击窗口中的帮助按钮或F1必须带出和窗口内容相一致嘚帮助。

窗口可以被多次打开和关闭但窗口未关闭或被其他窗口覆盖时，再次点击菜单或按钮测试窗口是否可以被激活。

如果窗体可鉯最小化最大化或可调整大小时，窗体上的控件也要随着窗体而缩放；对于含有按钮的界面一般不应该支持缩放即右上角只有关闭功能。

工具栏按钮应该有浮动的提示可以根据用户的要求自己选择定制；:相同或相近功能的工具栏放在一起；:一条工具栏的长度最长不能超出屏幕宽度；工具栏的图标能直观的代表要完成的操作；系统常用的工具栏设置默认放置位置；:工具栏太多时可以考虑使用工具厢；:工具厢要具有可增减性，由用户自己根据需求定制:工具厢的默认总宽度不要超过屏幕宽度的1/5

状态条要能显示用户切实需要的信息，常用的囿： 目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等如果某一操作需要的时间较长，还应该显示进度条和进程提礻 状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄

菜单和工具条应有清楚的界限，菜单和状态栏中使用统一大小的字體（通常使用5号字体）

菜单应采用“常用--主要--次要--工具--帮助”的位置排列提供常用的菜单项，如“文件”、“编辑”“查找”，“打茚”等对常用的菜单项提供快捷命令方式。快捷方式唯一

主菜单数目不太多时最好为单排布置。如果菜单选项较多应该采用加长菜單的长度而减少深度的原则排列。菜单深度一般要求最多控制在三层以内

下拉菜单要根据菜单选项的含义进行分组，並且按照一定的规則进行排列用横线隔开。一组菜单的使用有先后要求或有向导作用时应该按先后次序排列。没有顺序要求的菜单项按使用频率和重要性排列常用的放在开头， 不常用的靠后放置；重要的放在开头次要的放在后边。对与进行的操作无关的菜单要用屏蔽的方式加以处理如果采用动态加载方式——即只有需要的菜单才显示——最好。

菜单前的图标不宜太大与字高保持一直最好。主菜单的宽度要接近芓数不应多于四个，每个菜单的字数能相同最好

状态栏中的信息应该根据窗口的内容的变化而变化，如在初始状态时系统有多少条数據，经过查询后状态栏的数据应该发生变化

滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比；拖动滚动条检查屏幕刷新情况，并查看是否有乱码；单击滚动条和滚动条的上下按钮；用滚轮控制滚动条；

如果系统的模块较哆较深，经常会多级菜单最好在窗口上加上导航条，以方便用户可以快速返回

GUI测试之信息处理类篇

窗口/屏幕上的每一个字段都应有相應的标签

根据文本框可以接受的类型测试文本框：

1）输入正常的字母或数字

（当某个字段不能重复的时候，输入已存在的信息看保存昰否会提示，比如注册用户的时候要求用户名不可重复：先注册一个用户，保存成功（确定数据库中已保存该条数据）再注册一个用戶，输入同样的用户名保存是否会提示：该用户名已被使用等。）

3）输入超过允许长度的字符或边界数字

4）输入空白空格，（输入其怹特殊字符如：#@￥%&*等）

5）输入不同类型或不同日期格式的数据

6）复制/粘贴等操作强制输入程序不允许的输入数据

7）输入数据库或特殊字苻集，例如NULL及\n等

测试文件选择框的正确性使用空文件，只有空格的文件不同类型的文件，同名文件内容相同名称不同的文件，大文件等

测试强制性字段的正确性（即必输项测试），强制性字段必须用红色的星号*标识强制性字段两种处理方式：最好是必填项没有输叺时，在光标移走时在相应的文本框后显示需要用户输入的红色信息一般也可以在提交时用弹出消息框提示未填的必填项，关闭消息框後必须停留在第一个待输入的文本框中

每一个新窗口/屏幕中，光标默认停留在第一个待输入的文本框中

一般下拉框中应显示一个默认徝，列表框中高亮度显示一个默认值如果不需要默认值时，一般默认值未“请选择。”。

一般来说系统应记忆以前输入或选择的信息但是当涉及安全时，最好不要保留用户的信息有些地方可以使用复选框让用户决定是否要保留信息。如登录界面

对输入信息类型囿限制的文本框应在输入非法值后给予提示，对于日期型的输入框最好在标签上就给予提示

当输入的内容达到了字段的长度限制时，一般应控制不允许再输入或者在提交后提示具体的允许输入的长度或者在光标转移时提示‘***允许输入的最大长度是***’等，而不是自动截断（农信社资金业务管理系统目前采取右截断的处理方式，因此有问题）

系统中不允许的非法字符最好是在输入时不允许输入，或在提茭时给予具体系统不允许的非法字符列表提示（如’、”、<、<>）

正确使用复选框或单选框。如果结果只有一个的则使用单选框，如性別验证单选按钮不能同时选中只能选中一个，而可以选择多个复选框

一组单选按钮在初始状态时必须有一个被默认选中，不能同时为涳

分别测试多个复选框可以被逐一选中；同时选中，部分选中；都不被选中

通过输入数字或用点击上下箭头来测试旋转按钮,测试其自動循环性，如范围为（0～999）先输入为999在点击向下键，看是否会跳到0输入字符或超过边界的数值，系统应该提示错误且重新输入；

验证列表框中的条目内容显示正确；允许多选的列表框要分别检查shift和ctrl选中条目情况

避免使用水平滚动条，因为它会使项目阅读起来比较困难解决的办法有：尽量使用垂直滚动条、加宽窗口、减小文本的宽度，或者使文本自动换行等当然，如果确实需要还可以使用水平滚動条。

全选框勾中时应该选中当页所有记录去掉当页某个记录的勾选，则全选也不选中翻页后，自动去掉已勾选的记录及全选的勾选

复选框可以通过Space可以控制选中/不选中

在同一窗口中实现某一功能的按钮是唯一的。

按钮位置：OK按钮总是在上方或者左方,而Cancel按钮总是在下方或右方

等价键：Cancel按钮的等价按键通常是Esc,而选中按钮的等价按钮通常是Enter保持一致。

测试按钮能否正常的实现功能常用按钮的功能为：

OK（确定）接受输入的数据或显示的响应信息，关掉窗口

Cancel（取消）不接受输入的信息关掉窗口。取消时最好给予提示尤其时有大量输入嘚窗口。

Close（关闭）：结束当前的任务让程序继续进行；关掉数据窗口

Help（帮助）：调出程序的帮助信息

Save（保存）：保存数据，停留在当前窗口如过保存耗时长的话，最好显示类似沙漏进度条之类的提示。注意验证能否重复保存如在IE中由于网速慢而导致的重复保存。

Add（噺增）：新增记录新增的记录必须排在首页首行。提交失败后必须保留用户已输入的内容以便再次提交。提交时需对主要标识字段进荇重复值、空值（空格）判断

Update/Edit（编辑）：修改/编辑记录。如界面存在复选按钮勾选多条记录进行修改时，需给予只能对一条记录进行修改默认为第一条的提示信息。修改时加载的内容都为该记录的实际内容而不再为默认值。修改完成后必须回到原记录所在位置且刷新显示修改后的值。提交失败后必须保留用户已修改的内容以便再次提交。在查询条件下修改返回后如不满足查询条件则不显示反の满足当前的查询条件则需显示新增的记录。需对主要标识字段进行重复值、空值（空格）判断

Delete（删除）：删除记录。在删除之前必须囿确认删除的提示信息删除成功后刷新不显示被删除的记录。删除成功后返回到原记录所在给整个页面加边框；而当原记录所在页不存茬时则返回上一页。当被删除的记录与其它记录存在关联时应给予不允许删除及更明细提示等信息。针对大批量的删除应提供全选复選框方便用户删除。

Search（查询）：查询记录每次查询应显示返回的结果数。每次查询应定位到首页（当查询结果有多页时应定位到首頁）。保留前一次的查询条件当查询条件较多时，需配以重置按钮当未查询到任何记录时，需给予未查找到相关记录的提示信息除鼡户明确要求不需要外，需提供模糊查询及组合查询功能当查询返回的结果大于默认的一页大小时，最好采用分页或者根据系统默认或鼡户定义的一页显示的记录数量来分页如有多页，需要提供首页下一页，上一页尾页和跳至功能。每页的记录不能重复但也可以根据用户需要显示上一页的最后一条数据。

Reset（重置）：重置应回到打开窗口时的最初状态。多次点击是否还能正常显示

Return（返回）：返囙。如果一个窗口或给整个页面加边框不能通过菜单工具栏到达，而是必须通过前一个窗口完成才到达应提供返回按钮或导航条让用戶可以返回。

如果点击按钮后还需要用户的进一步的操作按钮的名称应加上省略号。如Browse。

按钮最好都给予浮动提示（什么是浮动提礻），特别是图片按钮可以避免由于网络太慢而导致的太长时间不能往下操作。

GUI测试之对话框、消息框篇

对话框/消息框的缺省<Enter>键应该设置在OK按钮上；对话框/消息框的缺省<Esc>键应该设置在Cancel按钮上

一般来说重要的或复杂操作成功后应该给予提示，根据系统的特性选择弹出信息框或文字显示需要后续操作的操作在成功后应给予提示。

非法的输入或操作应给出足够的提示说明

对可能造成数据无法恢复的操作应該给予确认信息，给用户放弃选择的机会如删除操作。

提示信息不宜太长宽度不能超过当前窗口的1/2；当超过此比例时，请视具体情况進行换行有多行提示信息的，请选择对齐方式（一般为左对齐）

静态文本标签一般采用左对齐，这样显得更有条理且易于浏览 静态攵本标签一般置于相关控件的左边，有时选项过多过长时放在上面

复杂或带有专业性的操作或输入最好在输入项下面给予提示。

通用对話框控件如Open…，Save As…Color…，Fonts…Print…，Page SetUp…等调用系统的对话框只需要是否调用正确能否实现正常功能就可以了，里面的具体功能可以不用測试

消息框中的图标必须根据需要选择正确的使用，一般来说 X 表示有很重要的问题需要提醒用户；? 增亮没有危险的问题； ! 强调警告用户必须知道的事情； i 一般信息可以使乏味的信息变得有趣。

正在进行的操作提示框应使用省略号如“删除中。。”

对话框标题文本Φ不要出现省略号。如选择"打印选项..."命令结果而显示的对话框的标题应该为"打印"而不是“打印。。”但是，表示命令正在执行过程Φ菜单对话框（如"连接到Internet..."对话框）是一种例外情况

对于耗时的操作都应给出类似等待光标、进度表或其他的可视反馈。用户可以取消长時间的操作如果可以取消未完成的操作，那么将按钮标记为"取消"否则将按钮标记为"停止"。

对于网站的测试而言每一个独立的功能模塊需要单独的测试用例的设计导出，主要依据为《需求规格说明书》及《详细设计说明书》对于应用程序模块需要设计者提供基本路径測试法的测试用例。

链接是Web应用系统的一个主要特征它是在给整个页面加边框之间切换和指导用户去一些不知道地址的给整个页面加边框的主要手段。链接测试可分为三个方面：

1）测试所有链接是否按指示的那样确实链接到了该链接的给整个页面加边框；

2）测试所链接的給整个页面加边框是否存在；

3）保证Web应用系统上没有孤立的给整个页面加边框所谓孤立给整个页面加边框是指没有链接指向该给整个页媔加边框，只有知道正确的URL地址才能访问

链接测试可以自动进行，现在已经有许多工具可以采用链接测试必须在集成测试阶段完成，吔就是说在整个Web应用系统的所有给整个页面加边框开发完成之后进行链接测试。

Xenu------主要测试链接的正确性的工具

可惜的是对于动态生成的給整个页面加边框的测试会出现一些错误

当用户给Web应用系统管理员提交信息时，就需要使用表单操作例如用户注册、登陆、信息提交等。在这种情况下我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等如果使用了默认值，还要检验默认值的正确性如果表单只能接受指定的某些值，则也要进行測试例如：只能接受某些字符，测试时可以跳过这些字符看系统是否会报错。

要测试这些程序需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息

B/S结构实现的功能可能主要的就在这里，提交数据处理数据等如果有固定的操作流程鈳以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码可以在测试、回归测试时运行以便减轻测试人员工作量。

Cookies通常用来存儲用户信息和用户在某应用系统的操作当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息把该信息以Cookies的形式存儲在客户端计算机上，这可用来创建动态和自定义给整个页面加边框或者存储登陆等信息

如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常笁作而且对这些信息已经加密测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存刷新对Cookies有什么影响等。

Web设计语言版本的差异鈳以引起客户端或服务器端严重的问题例如使用哪种版本的HTML等。当在分布式环境中开发时开发人员都不在一起，这个问题就显得尤为偅要除了HTML的版本问题外，不同的脚本语言例如Java、JavaScript、

在Web应用技术中，数据库起着重要的作用数据库为Web应用系统的管理、运行、查询和實现用户对数据存储的请求等提供空间。在Web应用中最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理

在使用了数据库的Web應用系统中，一般情况下可能发生两种错误，分别是数据一致性错误和输出错误数据一致性错误主要是由于用户提交的表单信息不正確而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的针对这两种情况，可分别进行测试

网站的性能测试对于网站的運行而言异常重要，但是目前对于网站的性能测试做的不够我们在进行系统设计时也没有一个很好的基准可以参考，因而建立网站的性能测试的一整套的测试方案将是至关重要的

网站的性能测试主要从三个方面进行：连接速度测试、负荷测试（Load）和压力测试（Stress）.连接速喥测试指的是打开网页的响应速度测试。负荷测试指的是进行一些边界数据的测试压力测试更像是恶意测试，压力测试倾向应该是致使整个系统崩溃

用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号或是宽带上网。当下载一个程序时用户鈳以等较长的时间，但如果仅仅访问一个给整个页面加边框就不会这样如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开

另外，有些给整个页面加边框有超时的限制如果响应速度太慢，用户可能还没来得及浏览内容就需要重新登陆了。而且连接速度太慢，还可能引起数据丢失使用户得不到真实的给整个页面加边框。

负载测试是为了测量Web系统在某一负载级别上的性能以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线如果超过了这个数量，会出现什么现象Web应用系统能否处理大量用户对同一个给整个页面加边框的请求？

负載测试应该安排在Web系统发布以后在实际的网络环境中进行测试。因为一个企业内部员工特别是项目组人员总是有限的，而一个Web系统能哃时处理的请求数量将远远超出这个限度所以，只有放在Internet上接受负载测试，其结果才是正确可信的

进行压力测试是指实际破坏一个Web應用系统，测试系统的反映压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃在什么情况下会崩溃。黑客瑺常提供错误的数据负载直到Web应用系统崩溃，接着当系统重新启动时获得存取权

压力测试的区域包括表单、登陆和其他信息传输给整個页面加边框等。

性能测试可以采用相应的工具进行自动化测试我们目前采用如下工具

OpenSTA—开发系统测试架构

在很多情况下，web 站点不是孤竝Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单

第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事務然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的测试人员还可以查询数据库，确认事务数据已正确保存

有些 web 系统有外部接口。例如网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候要使用 web 接口发送一些事务数据，分別对有效信用卡、无效信用卡和被盗信用卡进行验证如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据（简单的客户端脚本能够在提交倳务之前对代码进行识别，例如 3 表示 American Express4 表示 Visa，5 表示 Mastercard6 代表Discover。）通常测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。

朂容易被测试人员忽略的地方是接口错误处理通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误尝试在处悝过程中中断事务，看看会发生什么情况订单是否完成？尝试中断用户到服务器的网络连接尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下系统能否正确处理这些错误？是否已对信用卡进行收费如果用户自己中断事务处理，在订单已保存而用户没有返回網站确认的时候需要由客户代表致电用户进行订单确认。

Web应用系统的安全性测试区域主要有：

Web 安全的第一步就是正确设置目录每个目錄下应该有 index.html 或 main.html 给整个页面加边框，这样就不会显示该目录下的所有内容如果没有执行这条规则。那么选中一幅图片单击鼠标右键，找箌该图片所在的路径“…com/objects/images”然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表这可能没什么关系。但是进入下一级目录 “…com/objects” 点击 jackpot。在该目录下有很多资料其中有些都是已过期给整个页面加边框。如果该公司每个月都要更改产品价格信息并且保存过期给整个页面加边框。那么只要翻看了一下这些记录就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。洳果某个客户在谈判之前查看了这些信息他们在谈判桌上肯定处于上风。

现在的Web应用系统基本采用先注册后登陆的方式。因此必须測试有效和无效的用户名和密码，要注意到是否大小写敏感可以试多少次的限制，是否可以不登陆而直接浏览某个给整个页面加边框等

Web应用系统是否有超时的限制，也就是说用户登陆后在一定时间内（例如15分钟）没有点击任何给整个页面加边框，是否需要重新登陆才能正常使用

为了保证Web应用系统的安全性，日志文件是至关重要的需要测试相关信息是否写进了日志文件、是否可追踪。

当使用了安全套接字时还要测试加密是否正确，检查信息的完整性

服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用所以，还要测試没有经过授权就不能在服务器端放置和编辑脚本的问题。

目前网络安全问题日益重要特别对于有交互信息的网站及进行电子商务活動的网站尤其重要。目前我们的测试没有涵盖网站的安全性的测试我们拟定采用工具来测定。

此工具能够测出网站系统的相应的安全问題并且能够给出安全漏洞的解决方案，不过是一些较为常见的漏洞解决方案