51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: lsekfe
打印 上一主题 下一主题

【你问我来答第17期】:如何做好接口测试?(已结束)

[复制链接]

该用户从未签到

21#
发表于 2011-12-1 18:48:05 | 只看该作者
对接口测试也有兴趣,路过顶一下
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2011-12-1 19:16:29 | 只看该作者
回复 6# tjy688

      接口测试的流程其实和功能测试的流程类似,因为接口测试依赖的主要对象也是需求说明书,所以,最初的流程就是参与需求讨论,评审需求,
     
    需求确定以后,开发会根据需求进行接口设计,会产出接口定义,在开发设计过程中,有能力的话,可以给出一些针对设计的建议,提高可测性,针对需求及设计,进行测试计划,测试设计,然后还需要和配管确定测试环境相关的事情。

    在开发完成接口定义之后,就根据需求文档及接口定义进行测试用例设计,测试用例设计主要从业务场景,功能,以及异常测试几个方面考虑。

    测试用例设计完成后,针对测试用例进行评审,然后,如果开发代码部分可测时,即可进入测试了,因为是部分可测,可能会使用到mock方法。

     已有测试代码时,就要进行测试代码的持续集成了,我们是使用hudson来进行持续集成的

      在项目结束后,会对每个项目进行总结。

      如果有问题,请指出,我们一起讨论。
回复 支持 反对

使用道具 举报

该用户从未签到

23#
发表于 2011-12-1 19:26:59 | 只看该作者
回复 11# iTest99


          你好,我所做的接口测试指的是,针对J2ee中,负责业务处理的逻辑层的接口测试,因为该层主要是提供给web层调用或者是向其他组件提供服务。
回复 支持 反对

使用道具 举报

该用户从未签到

24#
发表于 2011-12-1 20:47:53 | 只看该作者
接口测试的难点是不是在宇外部接口测试用例的编写?
  对于接口这个概念,我在学JAVA时接触过。所谓的外部接口是不是数据输出的端口?
如果是,请问怎样编写它的用例(讲下概要就行,还没学用例编写~~) 。  我是新手啊 以前时学开发的 求教 谢谢
回复 支持 反对

使用道具 举报

该用户从未签到

25#
发表于 2011-12-1 21:06:51 | 只看该作者
回复 19# 德尔惠

    后台数据的测试,有专门的方法去校验的,在测试脚本编写的时候,调用后台数据校验方法校验就可以了,其实这个框架是将每个部分都单独组装,然后在写测试脚本的时候分别调用的,比如,页面操作的有专门页面操作的方法,页面元素定位的有专门的定位方法,测试结果固化的,有专门测试结果固化方法,这样的好处是,可以分别维护,方便增删功能。
回复 支持 反对

使用道具 举报

该用户从未签到

26#
发表于 2011-12-1 21:17:28 | 只看该作者
回复 14# xinhuayw


    对于接口测试来说,项目测试用例的重复运行首先是表现在单个测试用例的独立性方面的,也就是说,每一个测试用例的运行除了依赖被测对象和对应的数据库环境外,是不依赖于其他任何测试用例的,并且这个测试用例执行完毕后,对系统来说,也是没有任何痕迹的,这样就保证了每个测试用例运行时,都在一个干净的环境中运行。要实现测试用例的独立性,就必须对被测系统的设计有详细的了解,这样,不会出现测试用例执行后遗漏数据,环境未改变,另外,还需要对测试用例进行详细的设计。另外,要保证测试用例的重复使用,还需要做到测试用例的及时更新,在这个方面,我们是做接口测试的人会维护对应的系统的接口测试用例,要保证,代码每次更新,测试用例都必须全部执行通过。
回复 支持 反对

使用道具 举报

该用户从未签到

27#
发表于 2011-12-2 11:15:56 | 只看该作者
小刀,你好,我想问一下:接口测试怎么设计测试用例呢?
回复 支持 反对

使用道具 举报

该用户从未签到

28#
发表于 2011-12-2 11:24:28 | 只看该作者
小刀,你好,我想了解下,接口测试的用例如何设计呢?跟其他测试的有什么不同吗?因为我是做测试类职位招聘的,可能对这块也不是很懂,所以有时候也跟求职者解释不清楚
回复 支持 反对

使用道具 举报

该用户从未签到

29#
发表于 2011-12-2 12:50:22 | 只看该作者
只是学过基本的java,没有项目实战经验,想要学习selenium, 如何入手啊?有什么好的建议,谢谢!!!!
回复 支持 反对

使用道具 举报

该用户从未签到

30#
发表于 2011-12-2 14:21:16 | 只看该作者
hi,刀兄。。我现在做的是web测试,可上面要我想想怎样实现自动化,我也没有什么语言基础,帮忙啊。。。
回复 支持 反对

使用道具 举报

该用户从未签到

31#
发表于 2011-12-2 17:31:25 | 只看该作者
感谢刀哥
回复 支持 反对

使用道具 举报

  • TA的每日心情

    2019-12-27 13:32
  • 签到天数: 15 天

    连续签到: 1 天

    [LV.4]测试营长

    32#
    发表于 2011-12-2 17:52:15 | 只看该作者
    支持一下:)~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    33#
    发表于 2011-12-2 22:46:28 | 只看该作者
    才开始测试,对接口测试感兴趣,可是,当前的能力又无法进行接口测试,怎么样才能进入接口测试呢?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    34#
    发表于 2011-12-3 15:58:13 | 只看该作者
    回复 10# csun888

        你好,接口可以分下面几种
    1. 系统与系统之间的调用,比如银行会提供接口供电子商务网站调用,或者说,支付宝会提供接口给淘宝调用
    2. 上层服务对下层服务的调用,比如service层会调用DAO层的接口,而应用层又会调用服务层提供的接口,一般会通过
    3. 服务之间的调用,比如注册用户时,会先调用用户查询的服务,查看该用户是否已经注册。

       而我们所要做的接口测试,先要了解是基于哪一种类型的接口测试,不同类型的接口测试方法可能是不一致的,总体来说,不管是那种类型,我们只要把被测接口当做是服务方,而把我们的测试手段当做是客户方,我们的目的就是,通过我们的测试手段,去验证服务端满足了他声明提供的功能。

        至于说到具体的测试方法,http协议的接口测试,一般会用jmeter去测试,jmeter的好处是不用写测试代码,直接使用jmeter提供的http请求去测试,也可以使用HTTPClient去测试,好处是可以方便集成和自动化。java接口的测试,则需要编写测试代码去测试,有点类似于单元测试,但是需要更多的考虑业务场景。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    35#
    发表于 2011-12-3 16:09:00 | 只看该作者
    回复 13# gulun


        接口测试的数据准备,可以从下面几个方面去考虑:

    1. 如果是只测试一次的接口,可以使用硬编码的方式准备测试数据,在写测试代码的时候,使用到什么数据就写什么数据,为了避免数据重复,可能比较多的会用到随机字符或随机数
    2. 可以直接通过调用其他API的方式准备测试数据,这种情况在测试最上层服务的时候比较有用,比如测试团购购买服务,就需要准备要购买的团购数据,购买团购的用户数据,这个时候,可以直接调用生产团购的api和生成用户的api直接生成测试数据
    3. 使用excel或xml准备测试数据,这种准备测试数据的方式,主要针对对象数据的准备,比如可以将一条团购数据对应excel中的一条数据,因为一般开发都会使用pojo映射,而在准备测试数据的时候,这些pojo对象属性的设置往往是重复和大工作量的,用excel或XML方式准备,则可以减少在代码当中重复去准备这些数据。
    4. 也可以使用工具方法的形式去准备测试数据,通过在代码中写工具方法去实现数据生成,而在测试代码中调用工具方法去得到所需数据。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    36#
    发表于 2011-12-3 16:16:15 | 只看该作者
    回复 29# yaojinyf


        你好,selenium入门其实不难的,难的是后面的熟悉运用,以及对自动化过程的了解,对于你所说的如何入手,我建议你百度一下  《Selenium私房菜(新手入门教程)》,按照这个上面描述的,一步一步写完了,我觉得,应该就算是入门了,然后就是如何熟悉及提高了,我觉得,如果有空的话,可以将selenium的每个方法都实践一下,也就是说,了解它每个方法具体是做什么的,然后在自己的脚本中去用这个方法,这样,对selenium的方法就基本掌握了,那么剩下的,就是如何去改善,提高脚本的可执行性,可重用性,这个时候,就需要自己去写一些公共的方法来在测试脚本中使用。

       当然,会使用selenium并不是说就会自动化了,自动化是一个很广泛的概念,掌握了selenium,只是说,有了做自动化的一个工具,如何把这个工具和自己的实际项目结合才是重要的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    37#
    发表于 2011-12-3 16:21:58 | 只看该作者
    回复 27# 水生哥哥


        你好,我觉得接口测试用例的设计方法其实和功能测试用例的设计方法是类似的,因为接口是需要满足需求的,而接口测试所依赖的也是需求说明书,但是,因为接口测试毕竟是通过代码去测试代码,所以,为了保证覆盖率,可能会使用到单元测试的方法,具体的测试用例设计,我考虑的如下,请参考,如果有错误,一起讨论。

    输入参数测试:针对输入的参数进行测试,也可以说是假定接口参数的不正确性进行的测试,确保接口对任意类型的输入都做了相应的处理:输入参数合法,输入参数不合法,输入参数为空,输入参数为null,输入参数超长;

    功能测试:接口是否满足了所提供的功能,相当于是正常情况测试,如果一个接口功能复杂时推荐对接口用例进行结构划分,这样子用例具有更好的可读性和维护性。

    逻辑测试:逻辑测试严格讲应为单元测试,单元测试应保持内部逻辑的正确性,可单元测试和接口测试界限并不是那么清楚,所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常;

    异常情况测试:接口实现是否对异常情况都进行了处理,接口输入参数虽然合法,但是在接口实现中,也会出现异常,因为内部的异常不一定是输入的数据造成的,而有可能是其他逻辑造成的,程序需要对任何的异常都进行处理
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    38#
    发表于 2011-12-3 16:25:45 | 只看该作者
    回复 30# GKF53373


          如果没有任何语言基础,就做自动化,会有一点点困难,但是并不是说不能做,重要的是,你对自动化有没有兴趣,并且,上面对自动化的支持如何,如果说要入门,你可以先看看QTP,QTP有详细的指南,指导你如何做一个web机票预订的例子,通过这个例子,你会了解自动化是怎么样去做的,只有了解了自动化是怎么一回事,才可以去做自动化。

         如果是比较简单的web自动化测试,推荐你使用jmeter,jmeter虽然是一个性能测试工具,但是它可以用来做功能测试,虽然对web页面上的验证少点,但是,可以保证主要的流程是正确的,好的一点是,jmeter对语言的要求基本没有,主要是对jmeter这个工具的使用,你可以参考下。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    39#
    发表于 2011-12-3 16:36:51 | 只看该作者
    回复 28# irisatcareer


          你好,关于接口测试用例如何设计,我在回复水生哥哥的帖子里已经说了,你可以看那个回复,至于你说的,接口测试和其他测试有什么区别,我想说的是,测试按照阶段分,会分为单元测试,集成测试,系统测试,验收测试,回归测试,Alpah测试,Beta测试,而按照测试方法分,又分为黑盒测试,白盒测试,灰盒测试。从测试阶段来说,接口测试属于集成测试,从测试方法上来说,接口测试属于灰盒测试。所以,在不同开发组完成各自开发模块的时候,就可以开始接口测试,通过接口测试,来验证系统各个部件集成起来没有问题,但是还需要通过细致的系统测试来保证整个系统的正确性,因为接口测试属于灰盒测试,从设计测试用例来说,它更偏向黑盒测试,但是从测试手段来说,它又属于白盒测试,因为在测试过程中,需要了解代码结构。

         有点点乱,其实,了解下测试的不同分类,可能就能够了解接口测试和其他测试的区别了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    40#
    发表于 2011-12-3 16:39:40 | 只看该作者
    关于接口测试,其实是最近才比较兴起的,一起讨论,学习,做好接口测试,如果我的回复有错误,或者你不认可我的回复,请你一定要指出,以免对大家造成误导。[/
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-23 02:53 , Processed in 0.079467 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表