WEB系统测试分为6个部分：
●功能测试
●性能测试（包括负载/压力测试）
●用户界面测试
●兼容性测试
●安全测试
●接口测试
1功能测试
1.1链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。
链接测试可分为三个方面：
一、是否所有链接按指示的那样链接到了该链接的页面；
二、所链接的页面是否存在；
三、保证Web应用系统上没有孤立的页面（孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。）
采取措施：采用自动检测网站链接的软件来进行。
推荐软件：Xenu Link Sleuth免费绿色免安装软件
HTML Link Validator共享
(备注：动态生成的链接无法测试)
1.2表单测试
用户通过表单提交信息时，都是希望表单能正常工作。
一、依据表单填写内容的格式，字符与特殊字符等具体的要求结合数据校验对其进行测试。
二、对表单提交的完整性，以验正服务器信息的正确性。如所属省份与所在城市是还匹配的完整性需求。
1.3数据校验
根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。是对表单的输入内容进行校验，确认系统能够接受。
该项测试和表单测试可能会有一些重复。
1.2和1.3的采取措施：WinRunner（QTP）工具
1.4 cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在cookies中保存了注册信息，请确认该cookie能够正常工作而且已对这些信息已经加密。如果使用cookie来统计次数，需要验证次数累计正确。
采取措施：采用查看cookies的软件进行
可以选择采用的软件：IECookiesView v1.50
Cookies Manager v1.1
1.5数据库测试
使用了数据库的Web应用系统,可能发生的两种错误：
一、数据一致性错误：主要是由于用户提交的表单信息不正确而造成的
二、输出错误：主要是由于网络速度或程序设计问题等引起的问题。
针对这两种情况，可分别进行测试。
采取措施：考虑结合到1.2和1.3的测试中
1.6应用程序特定的功能需求
应用程序特定的功能需求的验证。
采取措施：根据需求说明文档需求进行测试
1.7设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，如HTML的版本，不同的脚本语言，例如Java、JavaScript、ActiveX、VBScript或Perl等。在分布式环境中开发时，开发人员不在一起工作，很容易出现这个问题。
采取措施：（比较笨的方法）在开发前，对开发人员的开发脚本语言、版本进行统一化要求。
2性能测试
2.1连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2.2负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。在Internet上，接受负载测试，其结果才是正确可信的
2.3压力测试
压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，即Web应用系统在什么情况下会崩溃，崩溃后，系统出现的反应。压力测试的区域包括表单、登陆和其他信息传输页面等。
采取措施：采用测试工具WAS、ACT协助进行测试
测试工具测试负载/压力测试关注问题：
瞬间访问高峰：负载测试工具能够模拟X个用户同时访问测试站点。
每个用户传送大量数据：系统能够处理单个用户的大量数据。
长时间的使用
3用户界面测试
3.1导航测试
导航描述了用户在一个页面内操作的方式。是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。
Web应用系统的层次一旦决定，即可着手测试用户导航功能。
3.2图形测试
一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起。图片尺寸要尽量地小，要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。（4）图片的大小和质量也很重要，一般采用JPG或GIF压缩，最好能使图片的大小减小到30k以下。
（5）需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。
采取措施：使用少许或尽量不使用背景。即使用背景，最好使用单色的，和导航条一起放在页面的左边。
3.3内容测试
内容测试即检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。可使用Microsoft Word的"拼音与语法检查"功能；
信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表入口，也就是一般Web站点中的所谓"相关文章列表"。需要确定是否列出了相关站点的链接。
3.4表格测试
需要验证表格是否设置正确。尽可能在不滚动条的情况下可以看到表格内的所有有效内容。
3.5整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。
采取措施：手动测试，参与人员最好有外部人员
4兼容性测试
4.1平台测试
采取措施：在Web系统发布之前，需要在操作系统下对Web系统进行兼容性测试。
4.2浏览器测试
浏览器是Web客户端最核心的构件。不同厂商的浏览器对Java、JavaScript、ActiveX或不同的HTML规格有不同的支持。框架和层次结构风格在不同的浏览器中也有不同的显示，或不显示。不同的浏览器对安全性设置也不一样。
采取措施：创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
4.3分辨率测试
页面版式在640x400、600x800或1024x768的分辨率模式下是否显示正常?字体是否太小以至于无法浏览?或者是太大?文本和图片是否对齐?
4.4 Modem/连接速率
是否有这种情况，用户使用28.8 modem下载一个页面需要10分钟，但测试人员在测试的时候使用的是T1专线?用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，需要确认图片不会太大。
4.5打印机
用户可能会将网页打印下来。测试人员需确认在屏幕上显示的图片和文本的对齐方式与打印出来的东西的一致性，以及一些特别功能表单打印的正确性。
4.6组合测试
结合4.1和4.2测试，对web应用系统进行测试。
采取措施：根据实际情况，采取等价划分的方法，列出兼容性矩阵。开发部门在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。
5安全测试
安全问题是对Web站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露用户就不会对网络有安全感。
5.1目录设置
Web安全的第一步就是正确设置目录。每个目录下应该有index.html或main.html页面，这样就不会显示该目录下的所有内容。
5.2 SSL安全套接字层(SSL)
很多站点使用SSL进行安全传送。你知道你进入一个SSL站点是因为浏览器出现了警告消息，而且在地址栏中的HTTP变成HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？
5.3登录
有些站点需要用户进行登录，以验证他们的身份。
主要考虑以下几个方面：
一、验证系统是否阻止非法的用户名/口令能够通过有效登录。
二、用户登录是否有次数限制?如有限制，那么超出限制后会出现什么情况？
三、口令选择是否有规则限制?
四、是否可以不登陆而直接浏览某个页面?
五、Web应用系统是否有超时的限制。即用户登陆后在一定时间内（例如15分钟）没有对页面进行任何操作，是否需要重新登陆才能正常使用？
5.4日志文件
在后台，需要验证服务器日志工作正常。日志对所有的事务处理的记录情况?是否在事务完成的时候都进行保存?
5.5脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。有些只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。
6接口测试
在很多情况下，web站点不是孤立。Web站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。
6.1服务器接口
浏览器与服务器的接口的测试。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。（这种测试可以归到功能测试中的表单测试和数据校验测试中）
6.2错误处理
接口错误处理。事务处理中断问题的处理。
采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况
