web测试包括
界面测试、功能测试、性能测试、可用性、客户端兼容性、安全性
一套完整的测试应该由五个阶段组成：
1．测试计划
首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
2．测试设计 将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。
3．测试开发 建立可重复使用的自动测试过程。
4．测试执行 执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、
系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。
5．测试评估 结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。 显然，黑盒测试只有严格按照步骤进行，才可能对应用程序的质量进行把关。然而，如果没有一种优秀的测试工具的帮助，单纯凭借手工测试，不但将耗费大量的人力、物力和财力，而且有很多测试工作是难以实现甚至是无法实现的。
测试用例应该写得比较详尽，步骤一定要标明清楚（应该包括：编号，测试描述，前置条件，测试步骤以及测试希望结果）；
O 测试报告与测试用例分开，测试报告标明测试用例序号以及是否通过Y/N；
应提供的测试文件
O 测试计划书 O 测试用例 O 测试报告 O 测试总结
常用模块测试用例
登录 添加 查询 删除
登录
用户名和密码都符合要求（格式上的要求）
用户名和密码都不符合要求（格式上的要求）
用户名符合要求，密码不符合要求（格式上的要求）
密码符合要求，用户名不符合要求（格式上的要求）
用户名或密码为空
数据库中不存在的用户名，不存在的密码
数据库中存在的用户名，错误的密码
数据库中不存在的用户名，存在的密码
输入的数据前存在空格
输入正确的用户名密码
以后按[enter]是否能登陆
添加
要添加的数据项均合理，在界面保存成功后，检查数据库中是否添加了相应的数据：select查询
留出一个必填数据为空
按照边界值等价类设计测试用例的原则设计其他输入项的测试用例：数据组合测试
不符合要求的地方要有错误提示
是否支持table键
按enter是否能保存
若提示不能保存，也要察看数据库里是否多了一条数据
删除
删除一个数据库中存在的数据，然后查看数据库中是否删除（界面删除一条数据，查看数据库中是否删除）
删除一个数据库中并不存在的数据，看是否有错误提示，并且数据库中没有数据被删除
输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除。
输入的正确数据前加空格，看是否能正确删除数据
什么也不输入
是否支持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错误。
易用性测试
易用性测试方法有：静态测试；动态测试；动态和静态结合测试。
由于易用性缺陷的主观性，因此测试人员和UI设计人员经常产生不同意见。UI通常被当作创造者的作品，而测试人员说某处是错误，就可能挫伤“艺术家”。易用性是软件缺陷中的敏感问题。
人体工程学(ergonomics)是一门将日常使用的东西设计为易于使用和实用性强的学科。人体工程学的主要目标是达到易用性。
1、用户界面测试
用于与软件交互的方式称为用户界面或UI。
2、优秀UI的构成
软件测试员要负责测试软件的易用性，包括其用户界面。
记住，软件测试员不需要去设计UI，只需要把自己当作用户，然后去找出UI中的问题。
优秀UI具备的七个要素
(1) 符合标准和规范
重要的用户界面要符合现行标准和规范，这些标准和规范由软件易用性专家开发。它们是由大量正式测试、经验、技巧和错误得出的方便用户的规则。如果软件严格遵守这些规则，优秀UI的其他要素就自然具备。
(2) 直观性
* 用户界面是否洁净、不唐突、不拥挤？
* UI的组织和布局合理吗？
* 是否允许用户轻松地从一个功能转移到另一个功能？
* 下一步做什么明显吗？
* 任何时候都可以决定放弃或者退回、退出吗？
* 菜单或者窗口是否深藏不露？
* 有多余功能吗？软件整体抑或局部是否做得太深？
* 帮助系统有效吗？
(3) 一致性
* 用户的使用习惯性强，希望一个程序的操作方式能够带到另一个程序中。在审查软件一致性时要考虑一下术语：
* 快捷键和菜单选项
* 术语和命名
* 听众
* 诸如OK和Cancel按钮的位置
(4) 灵活性
* 灵活性表现在：用户喜欢选择不要太多，但是足以允许他们选择做什么和怎么做。
* 状态跳转
* 状态终止和跳过
* 数据输入和输出
(5) 舒适性
* 软件使用起来应该舒适，不能给用户工作制造障碍和困难。如何鉴别软件舒适性的一些好想法：
* 恰当。软件外观和感觉应该与所做的工作和使用者相符。
* 错误处理。程序应该在用户执行严重错误的操作之前提出警告，并且允许用户恢复由于错误操作导致丢失的数据。
* 性能。快不见得是好事。不少程序的错误提示信息一闪而过，无法看清。如果操作缓慢，应该让用户得到相应的信息。
(6) 正确性
* 要测试正确性，就是测试UI是否做了该做的事。
* 市场定位偏差：有没有多余的或者遗漏的功能，或者某些功能执行了与市场宣传材料不符的操作？
* 语言和拼写：程序员常常能制造出非常有趣的用户信息。
* 不良媒体：图标是否同样大小？是否具有相同的调色板？声音是否应该有相同的格式和采样率？
* 所见即所得：保证UI所说的就是实际得到的。
(7) 实用性
* 是否实用是优秀用户界面的最后一个要素。
* 不是指软件本身是否实用，而是指具体特性是否实用。
* 在审查产品说明书、准备测试或者实际测试时，想一想看到的特性对软件是否有实际价值。它们有助于用户执行软件设计的功能吗？如果认为它们没必要，就要研究一下找出它们存在于软件中的原因。
总之，不要让易用性测试的模糊性和主观性阻碍测试工作。易用性测试的模糊和主观是固然的，即使设计用户界面的专家也会承认有的地方是这样的
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测试之信息处理类篇
在这篇文章中，我将文本框（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和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..."对话框）是一种例外情况。
对于耗时的操作都应给出类似等待光标、进度表或其他的可视反馈。用户可以取消长时间的操作。如果可以取消未完成的操作，那么将按钮标记为"取消"，否则将按钮标记为"停止"。
shift+down可以多选，Ctrl实现多选；
网站测试的主要方面
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自带的测试数据库性能的工具，能够测试多种数据库的性能
IP卡
狗仔卡
发表于 2013-5-17 16:37:27
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
发表于 2013-5-18 08:58:50
楼主
