Web自动化测试中接口测试.docx

  1. 1、本文档共5页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
Web自动化测试中接口测试

Web自动化测试中的接口测试  1、背景   1.1?Web程序中的接口   1.1.1 典型的Web设计架构   web是实现了基于网络通信的浏览器客户端与远程服务器进行交互的应用,通常包括两部分:web服务器和web客户端。web客户端的应用有html,JavaScript,ajax,flash等;服务器端的应用非常丰富,比如java的servlet,jsp,ssh框架,.net的aspx,还包括其他脚本如php,python。   web服务器端的设计架构近年来一直比较流行的是三层架构(3-tier application),通常意义上的三层架构就将业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。分层的目的在于降低代码见耦合,提高代码架构的可维护性。   总的来说,这三层架构的意义如下:   1)表现层(UI):用户界面,即用户可见的操作界面或者入口。   2)业务逻辑层(BLL):封装具有业务含义的操作函数。   3)数据访问层(DAL):封装对数据库或者其他存储介质的原子性操作。   1.1.2 Web接口的概念   web接口是服务器与客户端交互的方式,即浏览器或者其他客户端工具与web服务UI层交互的协议.常见的有两大类,一是浏览器与服务器交互的HTTP协议的接口,另一类web?service接口如soap,rmi,rpc等协议。   HTTP接口请求方法常用的有GET、POST两种请求类型。具有无连接无状态的特征。HTTP请求例如GET?/images/logo.gif?HTTP/1.1,表示从/images目录下请求logo.gif这个文件。   1.2 WEB接口自动化   1.2.1 Web接口测试   web接口测试即站在web服务程序UI层之上自动化测试的一种手段,是站在用户的角度上测试web服务程序业务逻辑的正确性。测试的重点是围绕web服务暴露的接口检查接口数据的正确性,这个过程是将web服务程序当做黑盒,通过自动化测试技术提高测试执行效率降低人工回归的成本。   1.2.2 什么要做接口测试   下图说明了基于HTTP接口的web应用的整体架构特征,按照这种架构设计开发项目,引发两个问题:   第一、系统级测试一定要等到web服务器程序和浏览器端的程序都开发完毕后才能进行吗?参考以下传统的RD与QA合作进行的项目流程,可以看到,QA在RD提测程序后才能真正进入到测试阶段,那么项目的发布周期自然受到这种串行下来的工作安排影响,是1+1的时间周期。    第二、为了提高效率,公司的团队引入了系统级自动化测试的工具或方案,既然是从用户角度去测试,当然要寄希望于从模拟用户行为代替手工操作来进行测试。 比如从浏览器操作的方式去测试,能很直接的覆盖用户的一手操作,但是需要思考的是,浏览器各个版本如ie6,7,8,chrome,firefox等,各 自有各自特性,JavaScript在浏览器内表现效果又不尽相同,浏览器在不同windows环境下、不同网络条件下运行的状况又不一样,给QA带来一 个难题:如何保证浏览器上的自动化case稳定、高效执行?   我们先分析第一个问题,项目团队需要提高产品发布效率,提前QA测试介入的时间点,我们可以想到有几种方案:   1)QA跟随RD进度,加入到各个层级代码参与单元测试:   假设我们没有引入TDD模式没有引入敏捷, 那么常规的解决方式是一批被测函数代码由RD写完之后提交svn,然后QA update代码后先花十几分钟阅读代码再加上对业务需求的理解然后再花费十几分钟写Xunit case,与QA预期结果一致则好,不一致则需要再花时间与RD沟通原因等等。其一QA花费更多时间,要深入到RD的代码逻辑深处;其二对 QA?coding能力要求也很高,这取决于公司QA人员的定位,是要求QA更熟悉测试设计而代码能力次之呢,还是QA的整体技术能力都要很高,一般来讲 大多数的QA强项在于业务需求的熟悉和测试设计能力,所以这种方式对团队整体人员素质的要求非常高。 2)QA不参与单测,RD依据需求纵向拆分功能点然后迭代提测,QA能提前一定时间介入测试:   对照如下的流程示意图说明这个过程,实际上是传统瀑布模型做了拆分,变为了多个短期的“小瀑布模型”,这样的效果能使得项目周期长的产品,可提前介入测试以提前发现问题。    在这样的迭代流程中,如何合理利用自动化手段来提高测试效率呢?一般来讲迭代周期不会很长,常规性的为3~5天一个周期,做太复杂的自动化投入成本较 高。对于web系统来讲,为避免过多的自动化投入得不偿失,需要谨慎的判断web系统的特征适合哪种自动化模式。所以这里特别要关注的就是分层自动化测 试:    如上图所述,web系统可以做几种功能测试:单元

文档评论(0)

whemm + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档