四、客户端兼容性测试

1、平台测试

市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。

因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

2、浏览器测试

浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、ActiveX、plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为InternetExplorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

五、安全性测试

Web应用系统的安全性测试区域主要有：

（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。

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

（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。

（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

六、总结

以上从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。

基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。

web页面测试注意事项：

Web测试往往不被测试人员重视，认为是没有技术含量的体力活，本人结合自己的工作经验谈谈Web测试中的一些注意事项，或许会对大家有所帮助。测试过程中主要考虑HTML页面、TCP/IP通讯、Internet链接、防火墙和运行在web页面上的一些程序（例如，applet、javascript、应用程序插件），以及运行在服务器端的应用程序（例如，CGI脚本、数据库接口、日志程序、动态页面产生器）。另外，因为服务器和浏览器类型很多，不同版本差别很小，但是表现出现的结果却不同，连接速度以及日益迅速的技术和多种标准、协议。当然还可以借助Web测试工具对其进行自动化测试。其它要考虑的如下：

1、服务器上期望的负载是多少（例如，每单位时间内的点击量），在这些负载下应该具有什么样的性能（例如，服务器反应时间，数据库查询时间）。性能测试需要什么样的测试工具呢（例如，web负载测试工具，其它已经被采用的测试工具，web自动下载工具，等等）？

2、系统用户是谁？他们使用什么样的浏览器？使用什么类型的连接速度？他们是在公司内部还是外部？

3、在客户端希望有什么样的性能（例如，页面显示速度？动画、applets的速度等？如何引导和运行）？

4、允许网站维护或升级吗？

5、需要考虑安全方面（防火墙，加密、密码等）是否需要，如何做？怎么能被测试？需要连接的Internet网站可靠性有多高？对备份系统或冗余链接请求如何处理和测试？web网站管理、升级时需要考虑哪些步骤？需求、跟踪、控制页面内容、图形、链接等有什么需求？

6、需要考虑哪种HTML规范？多么严格？允许终端用户浏览器有哪些变化？

7、页面显示和/或图片占据整个页面或页面一部分有标准或需求吗？

8、内部和外部的链接能够被验证和升级吗？多久一次？

9、产品系统上能被测试吗？或者需要一个单独的测试系统？浏览器的缓存、浏览器操作设置改变、拨号上网连接以及Internet中产生的“交通堵塞”问题在测试中是否解决，这些考虑了吗？

10、服务器日志和报告内容能定制吗？它们是否被认为是系统测试的主要部分并需要测试吗？

11、CGI程序、applets、javascripts、ActiveX组件等能被维护、跟踪、控制和测试吗？

18、测试用的评审需要注意一些什么？主要是针对哪些人群？

专家分析：在国内这个评审这个概念很淡薄，但是却是无处不在的。比如经常做的代码走查、立项会议、需求讨论等等其实都是一种简化的评审，有的公司把这叫做“头脑风暴”（往往是遇到难题的时候集中大家的智慧来冲关）

1、可以评审的东东很多，需求、策略、计划、用例、代码…基本上项目中你能想到的东西，都可以拿出来评审。

2、组织评审需要有清晰的目的（这个是整个环节中重要的部分），很简单，你首先要知道，你需要从这个评审中得到什么？也许是希望被评审东东更加完善，也许是希望增加大家交流的机会，甚至可能是为了应付上面的检查等等。

3、不同目的评审，参与人员自然也随之变化：比如，希望需求更加完善的评审，理论一切与产品有关的人员，大到项目经理，小到一线销售人员都需要来参加。但是，往往评审的人员越多，时间上就越难安排，所以需要结合实际情况来删减。当然，也不是说必须要XX人参加的评审才叫评审，比如一个BA与一个客户或开发人员私下的一次交流，只要做了详细的记录，也可以算作是一个评审。

所以，有内容的评审其实是不拘形式的，假如非得搞个内审或外审来规范，我只能说那是走过场而已。

4、在组织评审的细节上，有一点很重要：不要在评审过程中“照本宣书”。

很多公司在评审前不做准备，评审时拉个主持人上去就对着文档、PPT一阵读，半天下来，问大家有没问题，结果只能是只言片语。

所以，在评审前最好先做预审，也就是在评审前，给予评审人员一定的时间，也许是三、两天，也许是一星期，让评审人员熟悉评审目标，并提出自己的意见，由一个统一的程序收集起来，在评审中逐一解决。这样的效果会好很多。

5、最后说说比较规范的评审流程

确定评审目标——确定参与人员（包括主持人、记录员、评审员等）——安排评审时间——预审——整理预审报告——评审——整理评审报告——作者修改评审目标——复审（复审可以走简单流程，由各个提建议的评审人员查看自己的建议是否得到合理的修改）——存档

19、测试用例的粒度如何界定？碰到功能复杂的测试，应该如何书写测试用例？

专家分析：根据需求来定。较复杂的，可以先画出流程图，再进行编写测试用例。

文章来源：网络 版权归原作者所有

上文内容不用于商业目的，如涉及知识产权问题，请权利人联系小编，我们将立即处理