随着移动互联网的发展,越来越多的应用基于前后端分离构建,后端提供数据接口,前端调用接口返回数据渲染到UI,这个时候保证后端接口数据正确性变的愈来愈重要,接口自动化测试逐渐成为各大公司投入产出比最高的测试技术。介入时间早,执行效率高,稳定性高的优点,让越来越多的公司引入接口自动化测试。很多团队,接口测试就是手动运行接口,肉眼比对接口返回的数据,这样的操作流程效率低下,容易出错,如何实现对接口的自动化测试,提升接口测试的效率呢?本次我们有幸邀请到一位接口自动化资深大佬,帮助大家且深入的熟练掌握接口自动化测试,让你工作得心应手!
15年

15年以上软件测试、开发及管理经验
参与过美国大型收缴费系统的开发及测试工作

项目

熟悉大型应用软件的开发和测试流程
有丰富的测试技术项目管理经验

管理

对单元测试、系统测试的方法和管理流程有深刻认识

51Testing:商老师您好,有很多测试人员对接口测试不是很了解,您能和我们说说为什么要做接口测试?接口测试的意义是什么?编写接口测试用例时应该考虑哪些测试点?
        当今的互联网时代,需要越来越开放,也更需要越来越“兼容”。所谓的开放,是一些通用的平台(比如银联、微信或支付宝等),开放出来可以供其他的运营平台进行调用,同时要提供一些标准的使用规则,可以供各种不同的系统和平台进行相互的数据传输及处理,这就是所谓的“兼容”。

        接口技术刚好满足了这两个特点要求,它不仅能够有效的保护自身系统的安全性和完整性不受到危害的同时,可以把接口的规则和要求以及处理的结果“公诸于众”,让其他的产品及平台能够和这些通用平台进行数据的通讯,既保证了安全性,又扩展了平台的应用范围。而对于公司产品内部而言,用接口进行设计实现,也可以很大程度上的提升产品实现的灵活性,适应各种不同情况的处理逻辑变更问题。所以接口测试不光是我们系统内部之间的相互调用,可能还有系统之间,平台和平台之间的,这些都是有可能的。所以基于以上这样的IT产品的技术应用背景,接口测试工作势在必行,但这方面的测试人才储备和培养是远远不够的,因为企业需求大,而且薪资待遇高,所以就成为现在最炙手可热的测试岗位之一。

        从技术层面上而言,接口测试的意义主要是检查接口的实现和接口测设计是否相一致。接口测试的用例设计主要是考虑到接口的请求地址、请求类型、请求参数等等。

        在具体设计接口测试用例时,先要对接口测试需求进行挖掘和分析,很多人认为接口测试用例很简单,就是按照要求构造正常的参数,异常的参数就可以了。这些只能达到一个接口是否可用的最低测试标准。如果我们希望设计完备的接口测试用例,那就不能只是简单的考虑参数的正确和错误,而应该从接口测试的整体进行全面的分析。

        接口测试包括独立接口的测试、联调接口的测试、接口性能测试、接口安全性测试等多个方面。最近我们正在给企业做的一个项目就是接口性能测试。

        所以不能简单的把接口测试用例只定位在独立接口功能测试层面上,这个是不充分的。要考虑是否存在大规模的接口并发调用问题。还有就是接口的安全性,因为现在有很多抓包工具,如果我们在发送接口请求时没有对敏感或重要数据进行安全性处理的话,经过抓包可以获取相关的账号或密码信息,那就是很恐怖了。

        而且每一个接口的设计细节还有很多的不同,比如有些接口参数是放在header中而不是body体中,有些是https协议,不是http协议,有些接口还需要有cookie或session的认证才能发送成功,有些认证参数是静态的,有些却是动态生成的,有些接口在执行时,需要用到其他接口的返回结果,等等。诸如各种各样的接口设计分析问题,都是要在接口测试需求分析和用例设计工作中去解决的。
点击展开
点击收起
51Testing:在学习接口测试的过程中,经常会提到API接口测试和普通的接口测试,两者之间有何区别?
        API(Application Programming Interface)顾名思义,叫应用程序编程接口。它属于接口,但是接口的概念更宽泛一些,可以说API只是接口的一种类型。比较流行的API接口有RPC(Remote Procedure Call)、RESTful、web Service、Socket。

        对于接口测试工程师而言,这些接口的具体内部实现方式以及它们的区别对于接口测试工作本身的影响并不大。

        可以借用“以不变应万变”的工作思路,即无论是哪种接口实现技术,我们都要有能力分析出以下内容,就可以有效的开展后续的接口测试工作了。
  • 接口的请求地址或接口程序访问地址
  • 接口所需要传递的参数(参数个数,参数名称,参数的规则及要求等,注意是否存在隐性参数)
  • 接口的请求方式
  • 接口的响应结果(格式,内容,正常响应,异常响应)
点击展开
点击收起
51Testing:用JMeter做接口测试和用Python做接口测试有什么区别呢?
        Jmeter是一个测试工具,而Python是一个脚本语言,这是两个范畴的概念,无法进行区别比对。简单来说可以这样理解,使用Jmeter可以通过人工的操作来进行接口测试的执行工作,我们暂且称为接口手工测试。这样的工作方式非常简单,在接口测试工作量比较小的情况下,还是可行的,但是需要测试接口的数量非常多,一般来说超过20个以上,就不太适合再用工具进行测试了。

        建议可以在接口基本已经稳定的情况下,使用python来编写自动化接口测试脚本来进行,可以大大提高测试工作的整体效能。
点击展开
点击收起
51Testing:在进行接口测试之前,一般开发会提供接口文档,给出一些接口参数和必要熟悉,便于我们编写接口脚本。但如果没有提供接口开发文档的请求下,我们该如何编写接口测试脚本呢?在编写测试脚本前要做哪些必要的准备呢?
        其实现在很多公司都存在文档不完备,文档不全,或者是有变更,没有进行及时更新的情况,更严重的就是压根没有文档,各种可能性都有可能存在。那么作为测试工程师,我们要学会在最恶劣的环境下生存,所谓最恶劣的环境就是文档不规范,甚至没有文档的情况。如果在这种情况下都不妨碍测试工作的进行,那您可以说在接口测试需求分析方面具备了很强的理解、沟通和分析能力。

        那么在接口文档支持不足的情况下,到底如何开展编写接口测试脚本呢?个人建议首先要解决的不是脚本编写的问题,必须先解决测试需求分析的问题。具体过程如下:

        1、明确接口测试范围


        2、进行接口测试需求分析


        3、使用postman等工具进行接口的冒烟测试

        4、接口基本上测试通过或bug已经修复完成

        5、编写自动化接口测试脚本
点击展开
点击收起
51Testing:接口测试数据用什么方式构造和存储比较合理,有利于后期维护?
        接口测试数据有很多种存储方式,如果从便于脚本的编写和维护的角度而言,我们可以在研发接口测试脚本的时候,以不同的方式分版本来实现接口测试数据的存储,一方面可以由简到繁,逐步提升测试数据的覆盖面,同时也更有利于脚本研发工作的开展和后期的维护工作。具体过程如下:

        1、V1.0版本,以一组固定的常量方式来存储接口测试数据。这个版本所研发的脚本主要目的是调通接口的正常请求发送。

        2、V2.0版本:把常量的测试数据变成变量形式存储,一般在python种采用字典格式。这个版本是一个过渡版本,为后续的脚本参数化打一个基础。


        3、V3.0版本:以文件的方式进行测试数据的存储,可以现在文件中写入一组测试i数据进行读取,调试通过后,再多增加两组数据,再进行调试,直到没有任何问题了,就可以放心大胆的构造任意的批量数据了。

        4、V4.0版本:有些接口测试数据必须从数据库中实时读取,那就需要写脚本连接数据库,通过执行SQL命令取出相应的测试数据。

        很多测试工程师都怀疑自己的编程能力,其实是因为我们缺乏循序渐进的提升方法。像以上这样我们逐步的分版本,由简到繁慢慢增加脚本的难点,那么不仅大家了解了各种数据存储的方式,而且每一个版本都能实现我们预期的目标,这样的工作也会让我们越来越有成就感,越来越有竞争力!
点击展开
点击收起
51Testing:那中小企业的测试人员要如何从零开始搭建企业级的接口自动化框架?能否举例说明一下呢?
        那么所谓的接口自动化框架,它有两种不同的类型,一种类型的就是完全用现在成熟的一个框架技术,只是把我们相关的这个接口的脚本移植到框架里面能使用框架进行运行就可以了。这种方式的优点的就实现起来比较方便一些,也不需要投入额外的太多的开发去进行,只要把用例的脚本移植到框架里面,以框架的风格来编写和运行就可以了。但灵活性是比较弱,很难应对频繁的、大规模的不同版本的回归测试。

        举个例子:假如我们有一千多个脚本文件,此次回归测试里面需要从中提取34个脚本执行.首先怎么找到这34个脚本,执行顺序怎么重新调整,这些脚本对应哪些测试数据文件,又生成哪些测试报告......这些工作没有复杂度,但是非常繁琐,也考验我们的记忆力!

        但如果我们有自己研发的接口自动化框架,那就不一样了。可以通过读取自己设计的配置文件,来确定要运行哪些脚本文件,只要把运行的状态改一下就行,接口之间的执行顺序也只需要改配置文件就可以了。修改好配置文件后,启动框架驱动程序,一键就可以搞定了。如果我们自主研发的框架灵活性足够强的话,不仅支持一个项目,任意项目都是可以支撑的,只要去维护框架的配置层文件就可以了,代码是丝毫不用做任何的调整的,所以是非常值得我们去研究和探讨的。
点击展开
点击收起
51Testing:有会员反映在接口测试中,经常会遇到cookie和session,二者有什么区别和联系呢?
        cookie和session不一定是接口测试才能遇到的,这是程序在设计的时候本身存在的。它们都是为了进行页面访问验证而使用的技术。简单来说就是在打开一个页面时,后台服务器如何判断你是哪个用户,是非法的还是已登录的合法用户,它都要通过cookie或session来进行判断。

        cookie和session最大区别的就是一般而言cookie会保存在用户本地的浏览器端,只要不删除或账号信息不变更,可以一直使用,而session是服务器发给我们的一个动态验证码,在我们关闭浏览器或退出访问或超过一定时间时,就会失效,如果想继续访问,就必须重新登录后,服务器端会重新发一个session。

        比如说我们拿一个网站来说,我们登录一次后,发现下次登录时,界面上自动存有上次登录的用户名,一般来说都是采用了cookie技术,把信息保存在本地了。但是有的网站访问时我们发现,如果有一会没有操作页面(比如超过了一个多小时),再进行操作时,它自动跳转到登录页面,让我们重新登录,说明可能使用的是session技术,这时候说明session超时了,已经失效了。

        在进行接口测试时,如果遇到cookie和session,就需要进行这些参数的构造了,否则无法访问成功。如果大家想具体了解如何进行cookie和session的验证,可以看一下python全栈测试开发课程关于接口测试部分的内容。
点击展开
点击收起
51Testing:随着手机支付的普及,越来越多的人已习惯出门不带现金,直接用手机支付购买商品。作为测试人员要怎么调用微信和支付宝第三方接口进行测试呢?(例如:程序支持微信支付,支付宝支付,怎么对交互接口测试?)
        其实对于我们测试人员来言,我们所谓的内部接口和外部接口跟我们来说没有什么太大关系,我们所有的测试都是要解决我刚讲的就是接口的请求地址、请求方式、传入参数,包括验证,你要不要给我一个数字证书啊,反正我要去安装呀?把这些问题搞清楚了,他其实接口的实现过程基本上是类似的,没有什么太大区别,只是说一个是系统内部一个是系统外部。
51Testing:现在跟多公司的接口都进行了这样或者那样的加密处理,以前测试人员测试的接口都是没有加密的,现在的接口加密了,那如何去对这些加密过的接口进行测试呢?
        加密有几种加密方式,一种是协议上的加密,比如用HTTPS那这种这时候需要可能有一个协议的证书去把他导入到我们的这个接口的代码里面,或者说如果我们用工具进行接口测试的话,需要将其导入到我们的工具中,这是一种所谓的加密方式,和数据加密不太一样。

        那关于接口的数据加密,那就是我们在测的时候发送出去之后我们要通过抓包工具,或者通过脚本,帮我们发送的数据的截取下来看看我们的数据有没有进行加密的一个处理,判断是否十分正确,比如说我们把加密后的数据取出来之后呢,在要去问开发要一个解密的一个算法,然后呢去执行这段算法之后,看你加密之后通过解密这个程序解密之后和你刚才输入的参数是否一致就可以了,主要就这么两个过程。
点击展开
点击收起
51Testing:如何在初创自动化团队引入并推广自动化测试?有什么注意事项吗?自动化从零到有怎么样才能少走弯路?
        基本上所有的自动化测试工作都需要一些共有的前提条件,和是否初创的关系并不是特别大,主要和以下几个条件相关:

        1、这个项目或产品是要长期运营还是提交之后就没有太多的维护工作了

        2、目前我们的需求或设计是否已经基本稳定或局部稳定

        3、团队中是否有具备自动化测试能力的工程师

        如果这个产品或项目需要长期运营,意味着后续有越来越多的回归测试要进行,那就非常有必要进行自动化测试了。但如果这个产品提交后,不需要太多的升级维护工作,那么可以有自动化测试,但辛苦开发的脚本使用的次数如果在10次以下,就工作的投入产出比而言就是不划算的。

        可以给大家举个例子,比如我们天天顿顿吃面包,那么买个面包机(加入花500元,带原材料),比起外面买面包而言,每一个面包便宜至少5元,也就意味着如果我们吃了200个面包,节约了1000元,减去投入成本500,我们还有500的利润,这个就是面包机创造的价值。但如果我们不是每天每顿都吃面包,非常偶尔吃一下,那么大家算算,吃够了100个面包,才是刚刚持平,如果只吃了10个面包,就不再吃了,那就太亏本了。

        而自动化测试就像面包机一样,虽然后续的工作成本越来越低,但是初期写脚本的工作量比手工测试要高很多,可以说差不多1:10的关系,那么投入这么大的工作成本做出来的成果,使用次数太少,其价值就无法体现了。所以第一个条件是决定有没有必要进行自动化测试的首要条件。

        其次为什么需要需求设计较为稳定或局部稳定呢?因为需求设计的变更很有可能会带来脚本的变更,这都需要投入不少的工作量,也是一样的道理,如果反复的修改脚本,其所投入的时间远远大于手工测试的时间,所以一般都是针对需求、设计比较稳定或者是使用频率比较高,比较重要的内容做自动化测试,其性价比是较高的。

        最后一个条件:团队中是否有具备自动化测试能力的工程师,不言而喻是需要具备的。如果非常有必要开展自动化但是没有自动化人才,那么就需要创造条件去满足了。要么招聘要么培训,主要是这两种方案。

        至于自动化从零到有怎么样才能少走弯路的问题,可以有三个方面的思路来考虑:

        首先:分析自动化前提条件是否已经具备,哪一项不具备,就不要急于开展,否则得不偿失;其次如果前两个条件基本已经满足,最后一个人的问题就是招聘和培训来解决,先不要大面积招聘,可以先找一个技术优秀又愿意分享的人才,让他先针对重要常用的功能实施自动化,等有了成果后,也通过了审核,确认技术是过关的没有太大问题的时候,可以陆续再招聘1-2名较为熟练的自动化测试工程师,由这名优秀的工程师带领,逐步推行自动化测试,等基本成熟后,可以把团队中业务能力优秀的手工测试工程师培养转化为自动化工程师,或招聘新的人才,这样团队就慢慢建立起来了。

        自动化测试的成果也不要一下子要求太高,先从独立的测试脚本慢慢积累,在到业务场景脚本的实现,最后才是到测试框架这个维度。逐步积累经验,不容易半途而废,而且保证产出的成果物都能用于目前的测试工作,就基本上没有太大的风险了。
点击展开
点击收起
51Testing:您认为是否任何项目都适合使用自动化?如果遇到您判断来看用不上自动化,但是领导希望做这个东西来显示部门的含金量,这个时候有有必要据理力争吗?
        关于自动化的前提条件前面也已经提到过了。如果领导希望使用自动化,在条件不完全具备的情况下也是可以考虑的。首先,先要给领导说明为什么现在有些条件不具备,这样做可能的风险是什么,要有实际的数据来进行说明。其次,领导能承担这个风险的前提下,我们可以针对一些稳定的业务或模块,开展部分的自动化测试试验,这是可以的。最后,如果没有这方面的人才,可以邀请一些外部的技术专家进行培训指导,还有其他的方式也可以和领导探讨。结合领导可接受的投入,来规划我们的自动化测试工作。自动化测试确实是一个势在必行的事情,但是需要多沟通,多交流,多积累,多储备人才,可以逐步分阶段进行就可以了。
点击展开
点击收起
51Testing:作为部门领导,在团队初创时,您是否有遇到过人力投入安排的问题,在团队人力进展的情况下,要如何合理安排,高效地开展测试工作呢?
        所谓的人员投入安排是一个比较大的一个问题,可以给大家一些参考。首先,要判断一下目前团队成员的技能水平,如果有些工程师脚本能力不太强的,可以使用工具进行手工的接口测试。脚本能力比较强的,要再细化是能写独立的脚本,还是说测试框架也能实现?把人员的技术分成不同的层次,可以做一个团队成员能力分析表。

        依据每个成员的技术能力进行分工,这样更容易完成预定的计划。而不要简单的只按照工作量进行平均分配,做到人尽其能,才是最有效的分工方式。

        在这个前提下,如果资源还是不足,那就必须要和项目经理或更高的管理层进行沟通了。沟通的目的就是如何能提升开发提交代码的质量问题,也就是说如果开发提交的代码质量能有很大程度的改善的话,那么测试资源其实就可以很大程度的减少投入了。

        如果还是不足,可以考虑临时找一些实习的测试工程师,但是前提是我们的测试用例需要特别完备,特别详细才可以。

        以上这些方法供大家参考使用,如果都无法做到,那就是有很大的测试风险,需要提前和管理层进行充分的沟通,让大家了解到这个问题。
点击展开
点击收起
51Testing:如果遇到团队没有接口测试相关的技术领头人,大家都只有边学边试着做,从无到有,应该按照怎样的步骤来走?您能否提供一个系统的学习线路图?
        如果测试团队中没有技术负责人,那么建议先开展接口手工测试。等到基本的测试任务都完成了,接口相关的bug也修复了,需求设计也基本稳定了,可以边学边试着做自动化测试。否则工作风险太高,不建议大家在正常工作没有保障的情况下做“试验”。

        如何进行系统的学习,基于python的全栈课程的设计思路给给大家一些建议参考:

        1、一定要依托于项目,不能单纯的只是为了学习而学习

        2、学习也好,试验也罢,必须在开展之前,明确我们要提交的测试成果物是什么,要有目的的学习和试验,要有成果对应。一般而言,自动化接口测试的成果有:接口测试需求分析、接口自动化测试用例、接口测试脚本、接口测试中遇到的问题分析等等。

        3、完成一个任务后,要对该任务进行不断的优化升级(比如最开始的脚本只支持一组数据的测试,如何能支持任意多组测试数据的测试覆盖呢?原来的脚本没有测试报告内容,无法脱离人的跟踪检查,那如何加入测试报告的内容呢?......)

        4、从一个单一的任务逐步过渡到复杂的、有关联的场景测试任务,最后到自动化测试框架的设计及研发。

        按照以上这样的思路开展学习、试验以及工作的推演,不仅能很快的上手,而且目标也是十分清楚明确的,成果也是可见可评估的。不是简单的技术或语法的堆砌,我们最终要解决的是工作的具体问题,这点非常重要!
点击展开
点击收起
51Testing:随着互联网市场竞争愈发激烈,在企业招聘软件测试中高级岗位时,很多女性会因为已婚未孕、生育问题,收到用人单位的各种刁难!同时在女性带领团队的时候,往往不知所措,作为一个成功的女领导,您之前是否有遇到这样的问题?您是如何解决的?
        自己也是一个女性,不敢称为成功。和大家就是交流分享,希望能对大家有帮助就好!关于女性做测试岗位其实有很多的优势,而面临婚育问题,其实大家不用过于恐惧。因为无论是什么岗位的女性,都会面临这个阶段。只是有几点需要注意的地方,大家提前规划好就没有问题了。

        首先,重中之重是不要把生育和换工作甚至是技术提升这三件事放在一个时间点上去完成。也就是说不要到了快生育或打算生育的时候同时又要换工作,还想提升岗位或薪资。这是非常糟糕的规划。

        合理的规划应该是,在一家公司任职超过2年以上(至少一年以上),各方面的工作做的还比较不错,领导也比较认可,这时候就可以考虑生育问题。因为我们为公司已经创造了工作价值,生育的问题公司领导是可以接纳和认可的。但是如果我们在婚育年龄(结婚问题倒不大,主要是考虑生孩子的风险),这时我们又想换个工作,甚至想换个更好的工作,那基本上就比较纠结了。除非您能力特别强,或者公司愿意承担您生育对工作进度影响的风险,或者您本人承诺几年之内不生孩子......总之,这时很难成为公司的首选人才,只能是备选项了。

        如果大家没有完全规划好,刚好已经准备生育但同时也面临找工作,那么就只能退而求其次了,但是仍然可以改善。策略一:找一个不是特别繁忙的工作,薪水不要要求太高,那就一边工作一边安心待产。策略二:辞职在家生产。但这两个策略大家都要注意,在这一段不算短的时间内,大家一定不能松懈,不要认为只生宝宝就行,对未来而言仍然有很大的风险。因为我们生产后再去找工作,公司仍然会担心我们的工作强度能否胜任,所以没有过硬的技术,可能在一段时间内,还是没有太多的竞争优势。

        所以大家一定要利用好每一段较为闲暇的时间,一定要不提升自己的技能。我们网校的python全栈测试大家可以参与进来,是以项目的形式带领大家一步步完成自动化的测试任务,有了项目和技术的成果,那么等可以上班或者再找更好的工作,我们才有了过硬的砝码。千万不能懈怠,否则生完宝宝再找工作,我们技术上没有什么优势,又有一段时间可能没有参与工作,仍然是难以继续发展的。即使要做全职的妈妈,也需要不断的学习如何教育孩子,所以任何时候,我们都不能忘记学习和提升自己。

        其实讲到最后,女性也好,生宝宝也好,其实都不是问题,只要我们规划好,有了过硬的技术实力,永远都是公司炙手可热的测试人才,并不会因为这些正常的事情而影响到我们的提升和发展!

        特别喜欢老师(索达吉堪布上师)说过的一句话:终身学习、终身修行、终身利他。也把这句话送给大家,祝愿我们每一个人都能通过自己的不断努力,给自己的未来插上腾飞的翅膀!!
点击展开
点击收起