|
4 兼容性测试
4.1 平台测试
市场上有很多不同的操作系统类型,最常见的有Windows、Unix、Macintosh、Linux等。Web应用系
统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同
一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。
因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。
4.2 浏览器测试
浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、JavaScript、 ActiveX、
plug-ins或不同的HTML规格有不同的支持。例如,ActiveX是Microsoft的产品,是为Internet Explorer
而设计的,JavaScript是Netscape的产品,Java是Sun的产品等等。另外,框架和层次结构风格在不同的
浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的
浏览器对某些构件和设置的适应性。
4.3 分辨率测试
页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于
无法浏览? 或者是太大? 文本和图片是否对齐?
4.4 Modem/连接速率
是否有这种情况,用户使用 28.8 modem下载一个页面需要 10 分钟,但测试人员在测试的时候使用
的是 T1 专线? 用户在下载文章或演示的时候,可能会等待比较长的时间,但却不会耐心等待首页的出
现。最后,需要确认图片不会太大。
4.5 打印机
用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题,注意节约纸张和油墨。有
不少用户喜欢阅读而不是盯着屏幕,因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本
的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。
4.6 组合测试
最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错,但是在 IBM 兼容机上却很难看
。在 IBM 机器上使用 Netscape 能正常显示,但却无法使用 Lynx 来浏览。如果是内部使用的 web 站
点,测试可能会轻松一些。如果公司指定使用某个类型的浏览器,那么只需在该浏览器上进行测试。如
果所有的人都使用 T1 专线,可能不需要测试下载施加。(但需要注意的是,可能会有员工从家里拨号进
入系统) 有些内部应用程序,开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置
的系统。但是,理想的情况是,系统能在所有机器上运行,这样就不会限制将来的发展和变动。
采取措施:根据实际情况,采取等价划分的方法,列出兼容性矩阵
5 安全测试
即使站点不接受信用卡支付,安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部
使用。如果用户信息被黑客泄露,客户在进行交易时,就不会有安全感。
5.1 目录设置
Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面,这样就
不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片,单击鼠标右键
,找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径,发现该站
点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ,点击 jackpot。在该目
录下有很多资料,其中引起我注意的是已过期页面。该公司每个月都要更改产品价格,并且保存过期页
面。我翻看了一下这些记录,就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空
间。如果某个客户在谈判之前查看了这些信息,他们在谈判桌上肯定处于上风。
5.2 SSL
很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息,而
且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL,测试人员需要确定是否有相应的替代页面
(适用于3.0 以下版本的浏览器,这些浏览器不支持SSL。当用户进入或离开安全站点的时候,请确认有
相应的提示信息。是否有连接时间限制?超过限制时间后出现什么情况?
5.3 登录
有些站点需要用户进行登录,以验证他们的身份。这样对用户是方便的,他们不需要每次都输入个
人资料。你需要验证系统阻止非法的用户名/口令登录,而能够通过有效登录。用户登录是否有次数限制
? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3,你在第三次登录的时候输入正确的用户
名和口令,能通过验证吗? 口令选择有规则限制吗? 是否可以不登陆而直接浏览某个页面?
Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何
页面,是否需要重新登陆才能正常使用。
5.4 日志文件
在后台,要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图?
是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?
5.5 脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访
问邮件服务器,但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些
脚本语言,并研究该语言的缺陷。还要需要测试没有经过授权,就不能在服务器端放置和编辑脚本的问
题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。 |
|