四、客户端兼容性测试
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、测试用例的粒度如何界定?碰到功能复杂的测试,应该如何书写测试用例?
专家分析:根据需求来定。较复杂的,可以先画出流程图,再进行编写测试用例。
文章来源:网络 版权归原作者所有
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系小编,我们将立即处理