第一部分 应用程序测试
第一章 界面测试
界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
1.1 易用性测试
按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
1) 常用的按钮要有键盘快捷方式。
2) 界面应按功能划分出区域，要有功能说明或标题。
3) 界面及按钮的风格应尽量统一。
4) 界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
5) 界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
6) 有输入的界面进入时焦点应停留在第一个EDIT上。
7) 界面上的控件摆放的数目是否过多。一般最好不要超过10个，多于10个应建议使用分页界面显示。
8) 同一界面的功能数量是否过多。一般最好不要多于10个，过多导致使用不便。
9) 分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
10) 默认按钮要支持Enter及选择操作，即按Enter后自动执行默认按钮对应操作。
11) 可写控件检测到非法输入后应给出说明并能自动获得焦点。
12) Tab键的顺序与控件排列顺序要一致，目前流行总体从上到下，同时行间从左到右的方式。
13) 复选框和选项框中的内容应尽量按选择几率的高低而先后排列。
14) 复选框和选项框通常要有默认选项。
15) 选项数相同时多用选项框而不用下拉列表框。
16) 界面空间较小时使用下拉框而不用选项框。
17) 选项数较少时使用选项框，相反使用下拉列表框。
18) 专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
1.2 规范性
通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具箱、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具箱。
1) 常用菜单要有命令快捷方式。
2) 完成相同或相近功能的菜单用横线隔开放在同一位置。
3) 菜单前的图标能直观的代表要完成的操作。
4) 菜单深度一般要求最多控制在三层以内。
5) 菜单的说明要跟弹出的窗体一致。
6) 大型软件一般工具栏要求可以根据用户的要求自己选择定制。
7) 相同或相近功能的工具按钮放在一起。
8) 工具栏中的每一个按钮要有及时提示信息。
9) 一条工具栏的长度最长不能超出屏幕宽度。
10) 工具栏太多时可以考虑使用工具箱。
11) 工具箱要具有可增减性，由用户自己根据需求定制。
12) 工具箱的默认总宽度不要超过屏幕宽度的1/5。
13) 状态条要能显示用户切实需要的信息，常用的有：
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的 时间较长，还应该显示进度条和进程提示。
14) 状态条的高度以放置五号字为宜，滚动条的宽度比状态条的略窄。
15) 菜单和工具条要有清楚的界限；菜单要求凸出显示，这样在移走工具条时仍有立体感。
16) 右键快捷菜单采用与菜单相同的准则，且右键快捷菜单在对话框中不应出现。
1.3 帮助设施
系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。
1) 操作时要提供及时调用系统帮助的功能。常用F1。
2) 在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
3) 最好提供目前流行的联机帮助格式或HTML帮助格式。
4) 用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
5) 打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
6) 在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。
1.4 合理性
屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。
1) 父窗体或主窗体的中心位置应该在对角线焦点附近。即采取屏幕居中。
2) 子窗体位置应该在主窗体的左上角或正中。
3) 多个子窗体弹出时应该依次向右下方偏移，以显示出窗体标题为宜。
4) 重要的命令按钮与使用较频繁的按钮要放在界面上较注目的位置。
5) 与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
6) 对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。并且将按钮的缺省焦点置在“取消”按钮上。
7) 非法的输入或操作应有足够的提示说明。
8) 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
9) 提示、警告、或错误说明应该清楚、明了、恰当。
10) 对于需要执行长时间的操作，必须使用状态条，让用户了解进展情况，避免使用户误解为死机。
11) 大多数下拉框（ComboBox），应该不允许用户输入，如果需要输入，应在设计文档中指出。
12) 当下拉框（ComboBox）允许用户不选择任何选项时，不应显示一个空的选项，应使用文字描述，如“请选择…”等。
13) 对于文本框（TextBox）一般需要根据其对应的数据库字段的类型以及长度来限制用户允许输入的字符和长度，测试时要注意输入框中的数值的最大数和最小数，以及默认值、空白值或空格时的情况。
14) 对于ListView以Report形式（ViewStyle属性=vsReport）显示数据，一般要求实现列排序，如果由于特殊原因不能实现列排序，应该禁止用户点击列。
15) 对于日期输入框是否接受正确的日期输入；是否拒绝错误的日期输入；日期输入框在日期输入后是否按既定的日期格式显示日期。
16) 对于单选组内是否有且只有一个单选钮可选；如果单选组内无单选钮可选，这种情况是否允许存在。
17) 复选框组内是否允许多个复选框（包括全部可选）可选；如果复选框组内无复选框可选，这种情况是否允许存在；文本框及某些控件拒绝输入和选择时显示区域是否变灰或按既定规约处理。
18) 密码输入框是否按掩码的方式显示。
19) 对于有增加、修改或删除等有变动操作的页面，要随操作及时刷新。
20) 对于数据录入界面，重点考虑如何提高用户的录入速度。例如界面中有“身份证号”和“出生日期”，当用户输入了一个合法的身份证号后，系统应该自动根据身份证号将出生日期提取出来并填入“出生日期”控件中。
21) 系统的提示框样式应统一，即使用标准的Windows提示框，其中包括标题、图标、提示语和功能按钮。图标使用要规范，要根据提示信息的性质选择不同的图标，而且除非严重的错误，一般不使用“X”图标，以免使用户产生畏惧心理。
22) 如果系统中需要经常录入一些重复数据，应考虑将其提取出来，让用户进行一次配置，然后系统自动根据配置完成该信息的录入。例如：系统有登记企业信息的功能，其中企业信息包括该企业所在的省、市、区，由于该系统安装到某个市级单位后，所登记企业的所在省、市都是确定的，让用户每次登记时都重复选择省、市将给用户带来很大的不便。应该由用户在系统初始化时设置好缺省的省、市，在企业登记时只要选择该企业所在的区即可，这样就提高了用户的登记效率。
23) 对于输入型控件禁止为其指定输入法。
24) 窗体显示后，缺省的焦点应该设在最合理的控件上，方便用户操作。
25) 输入型控件一般不允许只输入空格或可存入输入值两端的空格。
1.5 美观与协调性
界面大小应该适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。
1) 长宽接近黄金点比例（宽高比为4:3），切忌长宽比例失调。
2) 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
3) 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置，要与界面的大小和空间要协调。
4) 避免空旷的界面上放置很大的按钮。
5) 放置完控件后界面不应有很大的空缺位置。
6) 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。建议使用宋体9号字。
7) 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。
8) 如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
9) 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
10) 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
11) 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。对于窗体中包含ListView、TreeView、DBGrid、StringGrid等控件，必须支持最大化，使用户能够尽量多的获得信息。当处于“往下还原”状态时，默认窗体应居中。
12) 如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。
13) 除主窗体外，其他窗体大部分都要支持敲“Esc”键退出的功能，除非设计文档中特殊指明。
1.6 菜单位置
菜单是界面上最重要的元素，菜单位置按照按功能来组织。
1) 菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
2) 常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍。
3) 下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。
4) 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
5) 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边。
6) 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
7) 对常用的菜单要有快捷命令方式。
8) 对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
9) 菜单前的图标不宜太大，与字高保持一致最好。
10) 主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
11) 主菜单数目不应太多，最好为单排布置。
1.7 独特性
如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的潜移默化的广告效用。
1) 安装界面上应有单位介绍或产品介绍，并有自己的图标。
2) 主界面，最好是大多数界面上要有公司图标。
3) 登录界面上要有本产品的标志，同时包含公司图标。
4) 帮助菜单的“关于”中应有版权和产品信息。
5) 公司的系列产品要保持一致的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。
1.8 快捷方式的组合
在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些，在西文Windows及其应用软件中快捷键的使用大多是一致的。
菜单中：
1) 面向事务的组合有:
组合键 Ctrl-D Ctrl-F Ctrl –H Ctrl-I Ctrl-N Ctrl-S Ctrl-O
功能 删除 寻找 替换 插入 新记录 保存 打开
2) 编辑:
组合键 Ctrl-A Ctrl-C Ctrl-V Ctrl-X Ctrl-Z Ctrl-Y
功能 全选 拷贝 粘贴 剪切 撤消操作 恢复操作
3) 文件操作:
组合键 Ctrl-P Ctrl-W
功能 打印 关闭
4) 系统菜单
组合键 Alt-F Alt-E Alt-T Alt－W Alt－H
功能 文件 编辑 工具 窗口 帮助
5) MS Windows保留键:
组合键 Ctrl-Esc Ctrl-F4 Alt-F4 Alt-Tab Enter Esc Shift-F1
功能 任务列表 关闭窗口 结束应用 下一应用 缺省按钮/确认操作 取消按钮/取消操作 上下文相关帮助
6) 按钮中：(可以根据系统需要而调节，以下只是常用的组合。)
组合键 Alt-Y Alt-C Alt-N Alt-D Alt-Q Alt-A Alt-E Alt-B Alt-R Alt-W
功能 确定 取消 否 删除 退出 添加 编辑 浏览 读 写
这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。
第二章 功能测试
在测试前，首先要根据《需求分析报告》全面了解用户需求并透彻理解。测试时要注意以下几点：
A、测试时要分清主次，即先测试主要功能，后测试次要功能。要选找出系统的功能主干，让数据依次流经功能主干，测试功能实现的是否正确。只要功能主干有问题，这个系统就是失败的。
B、 功能主干用正常正确后，我们还要考虑测试其异常处理功能。
C、 功能主干测试正确后，再进行分支功能的测试。
E、要对程序的功能进行方便性测试，将不够满意的地方，都应当成系统缺陷向项目负责人或系统开发者指出。
F、检查系统需求和设计说明书中要求的功能是否在系统中都被实现、性能是否达到指标。
G、数据之间的逻辑关系是否正确。
H、要有预览和打印功能。对于企业端软件，打印不能只针对一种打印机，要用多种打印机进行测试。
第三章 环境测试
配置测试环境是测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。在实际测试中，软件环境又可分为主测试环境和辅测试环境。主测试环境是测试软件功能、安全可靠性、性能、易用性等大多数指标的主要环境。一般来说，配置主测试环境可遵循下列原则：
1.符合软件运行的最低要求。测试环境首先要保证能支撑软件正常运行。
2.选用比较普及的操作系统和软件平台。一般都要在win98、win2000、2000server、windows xp下进行测试，除非软件的设计文档上有特殊要求。
3.要保证系统至少在时下流行的两种以上的浏览器上测试通过。如IE5、IE5.5、IE6、NS7等。
4.营造相对简单、独立的测试环境。除了操作系统，测试机上只安装软件运行和测试必需的软件，以避免不相关的软件影响测试实施。
5.无毒的环境。利用有效的正版杀毒软件检测软件环境，保证测试环境中没有病毒。并检测软件与时下流行的两种杀毒软件没有充突。
6．分辨率环境。要在不同的分辨率下进行测试，保证软件的每个页面的显示都正常。对于在Win2000下编制的程序，应在Win9X环境下检查界面上的字体和控件是否失真。
7．网络环境。要看网络连接是否正常；是否需要局域网和互联网等。
辅测试环境常常用来满足不同的测试需求或特殊测试项目：
(1)兼容性测试：在满足软件运行要求的范围内，可选择一些典型的操作系统和常用应用软件对其安装卸载和主要功能进行验证。
(2)模拟真实环境测试：有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。
(3) 横向对比测试：利用辅测试环境“克隆”出完全一致的测试环境，从而保证各个被测软件平等对比。
第四章 压力测试
压力测试用来检查程序对异常情况的抵抗能力。当关于容量的信息不确定的时候，需要确定是否分配了足够的磁盘空间，通讯的容量是否足够，测试系统过载的情况。压力测试总是迫使系统在异常的资源配置下运行。例如，
①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；
②定量地增长数据输入率，检查输入子功能的反映能力；
③运行需要最大存储空间（或其他资源）的测试用例；
④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例；
⑤多用户、超过系统设定的用户同时使用系统；
⑥以比预期更快的速度与系统进行交互；
⑦让系统长时间运行等等。
第五章 恢复测试
恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。
第六章 性能测试
性能测试主要是对响应时间、事务处理速率、数据显示速度、计算速度、网络传输速度、数据库查询响应时间、扫描时间、扫描识别率等和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足。实施和执行性能评测的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行评测和微调。
对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。
另外，还需要注意程序对系统消耗资源的测试，如CPU负载、内存、显存、硬盘资源消耗情况。
第七章 安全测试
安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，
①想方设法截取或破译口令；
②专门定做软件破坏系统的保护机制；
③故意导致系统失败，企图趁恢复之机非法进入；
④试图通过浏览非保密数据，推导所需信；
⑤权限控制是否合理、正确等等。
理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。
第八章 安装测试
A、在一台与用户的运行环境基本一致，没有安装过开发工具（如BCB、DELPHI、VB或VC）和没有安装过特殊字体的计算机上，依据产品《使用手册》/《安装手册》中的安装说明部分进行安装，要求无论是自动安装和手工配置都能够依据向导正确实施安装，安装退出后，软件能正确启运、运行。
B、产品安装界面上的提示要正确，对安装起指导作用，版权说明文件与该程序相符。
C、安装时，对默安装路径、用户自己指定的路径都要求能进行正确安装。
D、用户自已指定路径时，如为已存在路径能够进行安装，如为不存在的路径，应能创建该路径并进行安装。
E、程序安装完成后，在开始－程序菜单中要生成中文的快捷方式或程序组，本公司的软件产品，要生成“伍陆柒捌＊＊软件”程序组，在其下生成中文的快捷方式。
F、卸载测试，如果系统提供自动卸载工具，那卸载后，检查是否把所有文件都全部删除，注册表中的有关注册信息是否也被删除。
G、安装完成在简单的使用后在执行卸载操作，看是否能执行成功。
H、先安装客户端，在安装服务端，看是否会出现问题。
I、考察安装该系统是否对其他的应用程序造成影响。
第九章 文档测试
将文档同程序相比较，看是否有不相符的情况。检查文档的截图是否跟程序一致，检查文档是否有错字或不符合语法规范的地方。
A、程序的帮助文档要说明准确、通俗易懂，不用专业术语，且操作步骤要符合程序的要求。
B、要图文并茂，易于理解。
C、从程序抓取的图片中，数据要有代表意义，而不是一些乱七八糟的字母、数字的组合。有意义的数据也能对用户的操作起着指导作用。
总之，对文档要进行完整性校验、正确性校验、一致性校验、易理解性校验、易浏览性校验、版本统一性校验。
第十章 回归测试
当程序修改后，为了确保功能的正确性，需要重新测试应用程序中没有改变的部分。
在时间和条件允许的情况下，要测试修改相关的整个模块甚至整个程序。
第二部分 WEB程序的测试
一、按测试类型分类
字段编辑测试。字段编辑检查要查看格式编排、边界以及计算错误。如果日期需要限制在特定的时间范围内，该软件是否允许输入该时间范围外的日期？是否要求数字字段只包含数字？如果输入了字母会出现什么情况？如果包含计算，计算执行是否正确？字段输入框对请求的输入来说，是否足够大？如果有下拉框，其值否正确？
流控制和状态测试。在用户填写完表单中的字段并按下按钮后，逻辑是否会到达期望的进程？下一次显示同一页面时，其中的值是否正确？有时页面第一次显示了正确的值，而以后不再显示；或者情况相反。
配置测试。在可行的情况下，会用尽可能多的“受支持服务器”和客户程序配置对应用程序进行测试。
负载测试。在将页面或 Web 应用程序作为整体进行测试之前，应首先在组件级别进行负载和性能测试，以确保应用程序的每一部分能够在适当的指标下运行。这种隔离测试使测试小组能够更迅速地发现使用特定技术的问题。如果一个执行数据库查询功能的小脚本太慢，进行组件级别的测试比进行整个页面或应用程序测试更容易发现它。
回归测试。开发部门修复了代码中的错误后，我们会重新进行测试，以检查错误是否被修复并确保所做的修复不会引起其它问题。
二、按窗体位置分类：
左侧导航窗格：
是否能够在左侧的导航窗格中来回移动，该窗格显示是否正确？
是否能够在大于屏幕的区域内滚动？
是否能够选择不同的新闻组，文章列表是否显示在右上窗格中？
是否能够调整左侧导航窗格以及右上和右下窗格的大小？
右上窗格：
右上窗格是否正确地显示文章，是否保持了每篇文章的连载状况？
是否可以遍历连载文章？
读过一篇文章后，它是否被标记为红色？
如果文章列表大于一个页面，是否能够遍历右上窗格中的各个页面？
右下窗格：
是否可以选择一篇文章并显示在该页面的右下窗格中？
是否能够发布新消息，回复组，回复个人或转发文章？
在回复个人或转发消息时，默认的邮件客户程序是否启动并显示新消息？
是否能够伴随文章发送附件？
是否可以查看附件？
工具栏：
验证工具栏适合其所在的页面并能够根据浏览器窗口调整大小。
验证本地菜单能够正常运行。
验证本地菜单中的链接。
验证全局菜单能够正常运行。
验证全局菜单中的链接。
验证工具栏上的所有图形。
验证工具栏框架大小不可调整。
界面测试
站点地图和导航条
确认你测试的站点是否有地图。有些网络高手可以直接去自己要去的地方，而不必点击一大堆页面。另外新用户在网站中可能会迷失方向。站点地图和/或导航条可以引导用户进行浏览。需要验证站点地图是否正确。确认地图上的链接是否确实存。地图有没有包括站点上的所有链接。是否每个页面都有导航条? 导航条是否一致? 每个页面的链接是否正常? 导航条是否直观?
内容
测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望自己的站点能更专业一些。 最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户无法点击这些地址，他们可能会觉得很迷惑。
颜色/背景
由于 web 日益流行，很多人把它看作图形设计作品。不幸的是，有些开发人员对新的背景颜色更感兴趣，以至于忽略了这种背景颜色是否易于浏览。典型的站点是在紫色图片的背景上显示黄色的文本(如果你没有见过这样的站点，请浏览一下 GeoCities 或 AOL 上的个人主页，有不少这样的)。这种页面显得"非常高贵"，但是看起来很费劲。通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。
图片
无论作为屏幕的聚焦点或作为指引的小图标，一张图片都胜过千言万语。有时，告诉用户一个东西的最好办法就是将它展示给用户。但是，带宽对客户端或服务器来说都是非常宝贵的，所以要注意节约使用内存。是否所有的图片对所在的页面都是有价值的，或者它们只是浪费带宽? 使用其它的文件格式(.GIF, .JPG) 是否能使图片的大小减小到 30k 以下? 通常来说，不要将大图片放在首页上，因为这样可能会使用户放弃下载首页。如果用户可以很快看到首页，他可能会浏览站点，否则可能放弃。
表格
需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格？把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有因为某一格的内容太多，而将整行的内容拉长?
回绕
最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
功能测试
链接
链接是使用户从一个页面浏览到另一个页面的重要手段。对于每个链接，需要验证两件事情： 一是该链接将用户带到它所说明的地方，另外就是被链接页面是存在的。这句话听起来有些问题，但是有很多多站点的内部链接都是空的。这实在是无法忍受。
表单
当用户通过表单提交信息的时候，都希望表单能正常工作。如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。
数据校验
如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。
Cookies
很多用户喜欢甜食，但是开发人员喜欢 web cookie (小甜饼)。如果系统使用了cookie，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。
应用程序特定的功能需求
最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。
接口测试
在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。
服务器接口
第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。
外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
错误处理
最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。
兼容性测试
需要验证应用程序可以在用户使用的机器上运行。如果您用户是全球范围的，需要测试各种操作系统、浏览器、视频设置和 modem 速度。最后，还要尝试各种设置的组合。
操作系统
你的站点能否在 MAC 和IBM 兼容系统上浏览? 有些字体在某个系统上可能不存在，因此需要确认选择了备用字体。如果用户使用两种操作系统，请确认站点未使用只能在其中一种操作系统上运行的插件。
浏览器
站点能否使用 Netscape、Internet Explorer 或Lynx 进行浏览? 有些 HTML 命令或脚本只能在某些特定的浏览器上运行。请确认有图片的替代文字，因为可能会有用户使用文本浏览器。如果您使用 SSL 安全特性，则只需对 3.0 以上版本的浏览器进行验证，但是对于老版本的用户应该有相关的消息提示。
视频设置
页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?
Modem/连接速率
是否有这种情况，用户使用 28.8 modem下载一个页面需要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，需要确认图片不会太大。
打印机
用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。
组合测试
最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线，可能不需要测试下载施加。(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。
负载/压力测试
测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。
瞬间访问高峰
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。
每个用户传送大量数据
网上书店的多数用户可能只订购 1-5 书，但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?
长时间的使用
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。
安全性测试
即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。
目录设置
Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。
SSL
很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？
登录
有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗?
日志文件
在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?
脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。
结论
无论你在测试 internet、intranet 或者是 extranet 应用程序，web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下，就像业务功能一样，页面用于维护和发展公共关系，所以第一印象非常重要。
第三部分 数据库程序的测试
1. 如果要向SQL数据库中保存时间，时间的年份必须大于等于1753年，如果小于1753年，修改数据库时会出错。
2. 测试数据库程序时，除了要测试每个数据库操作是否正确外，要着重测试数据库共享问题，即多人同时执行同一功能，这样就会同时对同一数据表进行操作，测试程序是否正常。
3. 测试数据库程序时，还要测试数据库操作的速度，如果数据库操作缓慢，应通知程序员进行优化。
（引自葛宏宾）
作者Blog：http://blog.csdn.net/hiyaolee/
