Java web測试分为6个部分

1、功能測试 2、性能測试（包含负载/压力測试）3、用户界面測试 4、 兼容性測试 5、  安全測试  6、接口測试

 

1 功能測试

1.1 链接測试

链接測试可分为三个方面。

首先，測试全部链接是否按链接项描写叙述的那样确实链接到了该链接的页面。

其次，測试所链接的页面是否存在、是否正确；

最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面。仅仅有知道正确的URL地址才干訪问。

链接測试能够自己主动进行。通过软件測试对全部链接进行检測。

採取措施：採用自己主动检測站点链接的软件来进行。

採用软件：

Xenu Link Sleuth 免费 绿色免安装软件

1.2 表单測试

測试表单是否能正常工作。

1、使用表单来进行在线注冊时，提交button是否能正常工作，检查当注冊完毕后应返回注冊成功的消息！。使用表单收集信息，測试程序是否能正确处理这些数据。须要验证server是否能正确保存这些数据。同一时候測试后台执行的程序是否能正确解释和使用这些信息。

当用户使用表单进行用户注冊、登陆、信息提交等操作时，測试提交操作的完整性，以校验提交给server的信息的正确性。即：在当前填写项目中出现不应有的内容。

比如：用户填写的出生日期与职业是否恰当。填写的所属省份与所在城市是否匹配等。

假设使用默认值，要检验默认值的正确性。当表单仅仅能接受指定的某些值，測试不依照要求进行填写或选择时，能否自己主动报错！提示改动。比如：仅仅能接受某些字符，測试时能够跳过这些字符，看系统是否会报错。

字符串长度检查：输入超出字符串长度的内容，看系统是否检查字符串长度，会不会出错。

1.3 数据校验

系统依据业务规则须要对用户输入进行校验。測试这些校验功能正常工作。

比如，标点符号检查：输入内容包含各种标点符号。特别是空格、各种引號、回车键。看系统处理是否正确。

信息反复：在一些须要命名，且名字应该唯一的信息输入反复的名字或ID，看系统有没有处理。会否报错。重名包含是否区分大写和小写。以及在输入内容的前后输入空格。系统是否作出正确处理。

检查删除功能：在一些能够一次删除多个信息的地方，不选择不论什么信息，按“delete”，看系统怎样处理，会否出错;然后选择一个和多个信息，进行删除，看是否正确处理。

检查加入和改动是否一致：检查加入和改动信息的要求是否一致。比如加入要求必填的项，改动也应该必填;加入规定为整型的项，改动也必须为整型。检查改动重名：改动时把不能重名的项改为已存在的内容，看会否处理，报错。同一时候。也要注意，会不会报和自己重名的错。

反复提交表单：一条已经成功提交的纪录。back后再提交。看看系统是否做了处理。检查多次使用back键的情况：在有back的地方，back，回到原来页面。再back，反复多次。看会否出错。

search检查：在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确。假设能够输入多个search条件，能够同一时候加入合理和不合理的条件，看系统处理是否正确。

输入信息位置：注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。

上传下载文件检查：上传下载文件的功能是否实现。上传文件能否打开。对上传文件的格式有何规定。系统是否有解释信息，并检查系统是否可以做到。

必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息。如在必填项前加*，

快捷键检查：是否支持经常使用快捷键。如Ctrl+C Ctrl+VBackspace等，对一些不同意输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

回车键检查：在输入结束后直接按回车键，看系统处理怎样，会否报错。

在測试表单时，该项測试和表单測试可能会有一些反复。

1.4 cookies測试

什么事Cookies:Cookies通经常使用来存储用户信息和用户在某应用系统的操作。当一个用户使用Cookies訪问了某一个应用系统时，Webserver将发送关于用户的信息，把该信息以Cookies的形式存储在client计算机上，这可用来创建动态和自己定义页面或者存储登陆等信息。

測试的内容可包含Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。假设在 cookies 中保存了注冊信息。请确认该 cookie可以正常工作并且已对这些信息已经加密。假设使用 cookie 来统计次数，须要验证次数累计正确。须要与广东部分进行沟通。

1.5 数据库測试

測试数据库时主要測试两个方面：各自是数据一致性错误和输出错误。数据一致性错误主要是因为用户提交的表单信息不对而造成的，而输出错误主要是因为网络速度或程序设计问题等引起的。

1.6 应用程序特定的功能需求

尝试用户可能进行的全部操作。尝试全部须要文档中提出的功能是否实现。

1.7 相关性检查：删除/添加一项会不会对其它项产生影响，假设产生影响。这些影响是否都正确。

2 性能測试

2.1 连接速度測试

有些页面有超时的限制，假设响应速度太慢，用户可能还没来得及浏览内容。就须要又一次登陆了。并且。连接速度太慢。还可能引起数据丢失。使用户得不到真实的页面。

測试有超市限制的页面，将超时时间发布。

观察因为超时引起的登录失败是否造成不可恢复的错误。

2.2 负载測试 2.3 压力測试

瞬间訪问高峰

每一个用户传送大量数据

长时间的使用

2.2 2.3这两种測试临时无法开展。

3 用户界面測试

3.1 UI測试 看页面是否美观(包含页面的布局是否合理,页面长度是否合理,前景色与背景色是否搭配,页面风格是否统一,色调是否适合人眼,会不会太刺眼,字体大小是否合适,字体的颜色是否与背景色搭配,字体链接时是否会出现设置怪异的背景色,字体颜色有没有与背景色太接近或差距太大导致没办法看清字体或刺激视觉,点击链接时图片和字体会不会产生移位)

表格和DIV測试：是否网页设计师在表格或DIV里放置了过多的东西导致表格或DIV拉长,表格或DIV之间是否对齐,中间是否有空隙,是否产生了错位,假设在表格或DIV中设置了溢位,表格或DIV中的内容能否够所有看到,有没有出现一半字的情况,假设使用了框架结构.框架结构是否合理,表格每行的宽度是否足够,是否有折行

3.2 图形測试

图形測试的内容有：

　　（1）要确保图形有明白的用途，图片或动画不能够存在交叉、折腾、重叠等问题。以免浪费传输时间。

检查页面上图片的像素。像素不超过72

　　（2）验证全部页面字体的风格是否一致。

　　（3）背景颜色应该与字体颜色和前景颜色相搭配。

（4）測试文字回绕是否正确。假设说明文字指向右边的图片，应该确保该图片出如今右边。

3.3内容測试

内容測试用来检验站点提供信息的正确性、准确性和相关性。

信息的正确性是指信息是可靠的还是误传的。

比如，站点的报价，电话

信息的准确性是指是否有语法或拼写错误。

信息的相关性是指是否在当前页面能够找到与当前浏览信息相关的信息列表或入口。

应确保网站只是分地使用粗体字、大字体和下划线。

3.4 表格測试

须要验证表格是否设置正确。能否正常显示表格中的所有内容，是否须要改变网页位置。是否须要溢出。

3.5 总体界面測试

长期測试须要用户參与！

4 兼容性測试

4.1 浏览器測试

測试不同IE版本号，測试不同内核的浏览器是否兼容。

測试工具已经准备好：IETESTER。

4.3 分辨率測试

页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?

4.4 打印机

測试网页打印时能否正常显示整个页面。

5 安全測试

站点接下来即将开展网银的功能，因此须要对站点总体安全性进行測试。可考虑后期进行。

5.1 文件夹设置

Web 安全的第一步就是正确设置文件夹。每一个文件夹下应该有 index.html 或 main.html 页面，这样就不会显示该文件夹下的全部内容。

5.2 SSL

假设使用了SSL。应測试当用户进入或离开安全网站的时候。请确认有对应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？

5.3 登录

须要验证系统阻止非法的username/口令登录，而可以通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 假设同意登录失败的次数为3，在第三次登录的时候输入正确的username和口令。是否能通过验证，口令选择是否有规则限制  是否可以不登陆而直接浏览某个页面？

Web应用系统是否有超时的限制。，用户登陆后在一定时间内（比如15分钟）没有点击不论什么页面，是否须要又一次登陆才干正常使用。

5.4 日志文件

在后台。要注意验证server日志工作正常。日志是否记全部的事务处理?

是否记录失败的注冊企图?是否在每次事务完毕的时候都进行保存? 记录IP 地址吗?

记录username吗?

6 接口測试

在非常多情况下，web 网站不是孤立。Web 网站可能会与外部server通讯。请求数据、验证数据或提交订单。



 6.1server接口

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

        这样的測试能够归到功能測试中的表单測试和数据校验測试中



6.2 外部接口

        有些 web 系统有外部接口。

比如，网上商店可能要实时验证信用卡数据以降低欺诈行为的发生。測试的时候。要使用 web 接口发送一些事务数据。分别对有效信用卡、无效信用卡和被盗信用卡进行验证。假设商店仅仅使用 Visa 卡和 Mastercard 卡。 可以尝试使用 Discover 卡的数据。

(简单的client脚本可以在提交事务之前对代码进行识别。比如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。

)通常，測试人员须要确认软件可以处理外部server返回的全部可能的消息。

        这样的情况在远程抄表中可能会体现到



6.3 错误处理

        最easy被測试人员忽略的地方是接口错误处理。

通常我们试图确认系统可以处理全部错误，但却无法预期系统全部可能的错误。

尝试在处理过程中中断事务。看看会发生什么情况？订单是否完毕？尝试中断用户到server的网络连接。尝试中断 web server到信用卡验证server的连接。

在这些情况下，系统是否能正确处理这些错误？是否已对信用卡进行收费？假设用户自己中断事务处理。在订单已保存而用户没有返回站点确认的时候，须要由客户代表致电用户进行订单确认。

採取措施：在理解需求的基础上。充分发挥想象力。尽量比較全面的列出各种异常情况。

7 结论

        不管你在測试 internet、intranet 或者是 extranet 应用程序，web 測试相对于非 web 測试来说都是更具挑战性的工作。用户对 web 页面质量有非常高的期望。在非常多情况下，就像业务功能一样。页面用于维护和发展公共关系，所以第一印象非常重要。



着是非常重要的一点  业务知识与流程是最重要的..