网站测试流程、要求及测试报告.docx

上传人:b****9 文档编号:75338 上传时间:2022-10-02 格式:DOCX 页数:24 大小:24.24KB
下载 相关 举报
网站测试流程、要求及测试报告.docx_第1页
第1页 / 共24页
网站测试流程、要求及测试报告.docx_第2页
第2页 / 共24页
网站测试流程、要求及测试报告.docx_第3页
第3页 / 共24页
网站测试流程、要求及测试报告.docx_第4页
第4页 / 共24页
网站测试流程、要求及测试报告.docx_第5页
第5页 / 共24页
点击查看更多>>
下载资源
资源描述

网站测试流程、要求及测试报告.docx

《网站测试流程、要求及测试报告.docx》由会员分享,可在线阅读,更多相关《网站测试流程、要求及测试报告.docx(24页珍藏版)》请在冰豆网上搜索。

网站测试流程、要求及测试报告.docx

网站测试流程、要求及测试报告

基于Web的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。

基于Web的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。

重要的是,还要从最终用户的角度进行安全性和可用性测试。

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

  随着Internet和Intranet/Extranet的快速增长,Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。

许多传统的信息和数据库系统正在被移植到互联网上,电子商务迅速增长,早已超过了国界。

范围广泛的、复杂的分布式应用正在Web环境中出现。

Web的流行和无所不在,是因为它能提供支持所有类型内容连接的信息发布,容易为最终用户存取。

  YogeshDeshpande和SteveHansen在1998年就提出了Web工程的概念。

Web工程作为一门新兴的学科,提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。

它"使用合理的、科学的工程和管理原则,用严密的和系统的方法来开发、发布和维护基于Web的系统"。

目前,对于web工程的研究主要是在国外开展的,国内还刚刚起步。

  在基于Web的系统开发中,如果缺乏严格的过程,我们在开发、发布、实施和维护Web的过程中,可能就会碰到一些严重的问题,失败的可能性很大。

而且,随着基于Web的系统变得越来越复杂,一个项目的失败将可能导致很多问题。

当这种情况发生时,我们对Web和Internet的信心可能会无法挽救地动摇,从而引起Web危机。

并且,Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。

  在Web工程过程中,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。

基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的浏览器端的显示是否合适。

重要的是,还要从最终用户的角度进行安全性和可用性测试。

然而,Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。

因此,我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

  一般软件的发布周期以月或以年计算,而Web应用的发布周期以天计算甚至以小时计算。

Web测试人员必须处理更短的发布周期,测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

  网站测试流程、要求及测试报告

一个网站基本完工后,需要通过下面三步测试才可以交活。

一、制作者测试,包括美工测试页面、程序员测试功能。

在做完后第一时间内有制作者本人进行测试。

a)页面包括首页、二级页面、三级页面的页面在各种常用分辨率下有无错位;图片上有没有错别字;各连接是否是死连接;各栏目图片与内容是否对应等

b)功能达到客户要求;数据库连接正确;各个动态生成连接正确;传递参数格式、内容正确;试填测试内容没有报错;页面显示正确

二、全面测试根据交工标准和客户要求,由专人进行全面测试

也是包括页面和程序两方面,而且要结合起来测,保证填充足够的内容后不会导致页面变形。

另外要检查是否有错别字,文字内容是否有常识错误。

三、发布测试网站发布到主服务器之后的测试,主要是防止环境不同导致的错误

软件缺陷的原则

软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等

软件未达到产品说明书标明的功能。

软件出现了产品说明书指明不会出现的错误。

软件功能超出产品说明书指明范围。

软件未达到产品说明书虽未指出但应达到的目标。

软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好。

测试的主要方面:

一、功能测试

对于网站的测试而言,每一个独立的功能模块需要单独的测试用例的设计导出,主要依据为《需求规格说明书》及《详细设计说明书》,对于应用程序模块需要设计者提供基本路径测试法的测试用例。

1、链接测试

  链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。

链接测试可分为三个方面:

1)测试所有链接是否按指示的那样确实链接到了该链接的页面;

2)测试所链接的页面是否存在;

3)保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。

链接测试可以自动进行,现在已经有许多工具可以采用。

链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。

Xenu------主要测试链接的正确性的工具

可惜的是对于动态生成的页面的测试会出现一些错误。

2、表单测试

当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。

在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。

例如:

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

如果使用了默认值,还要检验默认值的正确性。

如果表单只能接受指定的某些值,则也要进行测试。

例如:

只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。

要测试这些程序,需要验证服务器能正确保存这些数据,而且后台运行的程序能正确解释和使用这些信息。

B/S结构实现的功能可能主要的就在这里,提交数据,处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能,编写可重复使用的脚本代码,可以在测试、回归测试时运行以便减轻测试人员工作量。

我们对UM子系统中各个功能模块中的各项功能进行逐一的测试,主要测试方法为:

边界值测试、等价类测试,以及异常类测试。

测试中要保证每种类型都有2个以上的典型数值的输入,以确保测试输入的全面性。

3、Cookies测试

  Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。

如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作而且对这些信息已经加密。

测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。

4、设计语言测试

Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。

当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。

除了HTML的版本问题外,不同的脚本语言,例如Java、JavaScript、ActiveX、VBScript或Perl等也要进行验证。

5、数据库测试

  在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。

在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。

在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。

数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。

二、性能测试

网站的性能测试对于网站的运行而言异常重要,但是目前对于网站的性能测试做的不够,我们在进行系统设计时也没有一个很好的基准可以参考,因而建立网站的性能测试的一整套的测试方案将是至关重要的。

网站的性能测试主要从三个方面进行:

连接速度测试、负荷测试(Load)和压力测试(Stress),

连接速度测试指的是打开网页的响应速度测试。

负荷测试指的是进行一些边界数据的测试,压力测试更像是恶意测试,压力测试倾向应该是致使整个系统崩溃。

1、连接速度测试

  用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。

当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。

如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。

  另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。

而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

2、负载测试

  负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。

负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。

例如:

Web应用系统能允许多少个用户同时在线?

如果超过了这个数量,会出现什么现象?

Web应用系统能否处理大量用户对同一个页面的请求?

3、压力测试

  负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。

因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。

  进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。

压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。

黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。

压力测试的区域包括表单、登陆和其他信息传输页面等。

采用的测试工具:

性能测试可以采用相应的工具进行自动化测试,我们目前采用如下工具

ab-----Apache的测试工具

OpenSTA—开发系统测试架构

三、接口测试

在很多情况下,web站点不是孤立。

Web站点可能会与外部服务器通讯,请求数据、

验证数据或提交订单。

1、服务器接口

第一个需要测试的接口是浏览器与服务器的接口。

测试人员提交事务,然后查看服务器

记录,并验证在浏览器上看到的正好是服务器上发生的。

测试人员还可以查询数据库,确认事务数据已正确保存。

2、外部接口

有些web系统有外部接口。

例如,网上商店可能要实时验证信用卡数据以减少欺诈行

为的发生。

测试的时候,要使用web接口发送一些事务数据,分别对有效信用卡、无效信用卡和被盗信用卡进行验证。

如果商店只使用Visa卡和Mastercard卡,可以尝试使用Discover卡的数据。

(简单的客户端脚本能够在提交事务之前对代码进行识别,例如3表示AmericanExpress,4表示Visa,5表示Mastercard,6代表Discover。

)通常,测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。

3、错误处理

最容易被测试人员忽略的地方是接口错误处理。

通常我们试图确认系统能够处理所有错

误,但却无法预期系统所有可能的错误。

尝试在处理过程中中断事务,看看会发生什么情况?

订单是否完成?

尝试中断用户到服务器的网络连接。

尝试中断web服务器到信用卡验证服

务器的连接。

在这些情况下,系统能否正确处理这些错误?

是否已对信用卡进行收费?

如果

用户自己中断事务处理,在订单已保存而用户没有返回网站确认的时候,需要由客户代表致

电用户进行订单确认。

四、可用性测试

可用性

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 考试认证 > 财会金融考试

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1