WEB测试要点及基本方法(三)

5.安全测试

　　即使站点不接受信用卡支付，安全问题也是非常重要的。Web站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。

目录设置

　　Web安全的第一步就是正确设置目录。每个目录下应该有index.html或main.html页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录"…com/objects"，点击jackpot。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。

SSL

　　很多站点使用SSL进行安全传送。你知道你进入一个SSL站点是因为浏览器出现了警告消息，而且在地址栏中的HTTP变成HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？

登录

　　有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制?是否限制从某些IP地址登录?如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗?口令选择有规则限制吗? 是否可以不登陆而直接浏览某个页面？

　　Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。

日志文件

　　在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理?是否记录失败的注册企图?是否记录被盗信用卡的使用?是否在每次事务完成的时候都进行保存?记录IP地址吗?记录用户名吗?

脚本语言

　　脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。　

6.接口测试

　　在很多情况下，web站点不是孤立。Web站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。

服务器接口

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

这种测试可以归到功能测试中的表单测试和数据校验测试中

外部接口

　　有些web系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用web接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用Visa卡和Mastercard卡，可以尝试使用Discover卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如3表示American Express，4表示Visa，5表示Mastercard，6代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。

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

错误处理

　　最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断web服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。

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