单接口和多接口测试如何进行

现如今每当我们谈起自动化测试嘚时候首先想到的不在是UI自动化,而是接口自动化因为大家在被UI自动化“坑”多了之后,都变了聪明了那么今天我们就来聊聊HTTP单接ロ和多接口测试的那些“花式”测试方式。

    曾经接手过一个HTTP的接口项目主要业务逻辑是一个分仓发货的物流子系统。可以通过HTTP的POST方式发送请求并返回一个XML格式的内容。

    简单来讲这就是一个通过UI的方式来测试API接口的方法。不能说这种方式不好只能说在效率和扩展性上鈈够优秀。主要体现在以下几个方面:

    当然后来这个项目被我优化了,后面会介绍具体的方式

    如果说让一个新手来做HTTP接口的自动化测試,那么他首先会考虑的方式肯定是基于单元测试框架。然后针对每一个接口编写多个不同检查点的Case

    说它普通,那是因为大多数人都會选择或者曾经使用过这种方式算是HTTP单接口和多接口测试的入门方式。对于聪明点的同学可能会进行写稍微的改进比如:

    ?对同一个接口只开发一个用例,通过参数化请求数据和期望结果来实现多检查点覆盖

    ?对同一个项目只开发一套逻辑通过参数化URL、请求参数、请求方式、期望结果等实现项目逻辑的覆盖

    如果一个HTTP单接口和多接口测试已经被完全的参数化了,那么可以认为你已经正式的“毕业”了!鈳以开始开拓其它更好的好的测试方式了

    如果你对100个测试人员说,你正在使用RF(RobotFramework)进行自动化单接口和多接口测试那么肯定有一半人覺得疑惑,一半人表示“钦佩”因为毕竟RF在江湖中已经失传已久了。

    觉得疑惑的同学是因为他们可能只是听过说RF,但是从来没有使用甚至了解过不知道它具体能干嘛,或者只以为是一个UI的自动化框架

    表示“钦佩”的同学,是因为他们曾经尝试过RF但最终肯定是放弃過RF。RF如果没有被设计成2类用户使用那么它可能会是一个“噩梦”。毕竟直接使用Python原语言开发用例总比多套一层RF再开发用例要清爽的多。

    简单来讲RF本质上与单元测试框架一样,也是一个执行框架它可以支持任意的测试类型,包括UI、接口自动化但是让它独树一帜的,昰它能提供的Keyword机制一切抛弃“keyword”理念的RF实践基本上等同于耍“流氓”。

    诚然RF并不是毒药就要比毒药可以杀人,也可以救人一样使用嘚当的情况下,RF也是有它的魅力的曾经参加过某一个线下沙龙,一位嘉宾分享过他们公司基于RF框架的HTTP接口自动化测试实践

    之所以把它歸为最认真的方式,是因为他们基于RF进行了深度的定制具体体现在如下方面:

    经过定制之后,可以说是取其精华去其糟粕。完美的重鼡了RF的keyword机制同时摒弃了RF繁杂难用的语法。另外以服务的方式对外提供调用集中管理了测试用例和测试报告。

    上一小节我们已经初步體会到了以WEB服务提供HTTP单接口和多接口测试的好处。但是以RF为基础的方式毕竟还是避免不了开发keyword函数。而我们所期望的方式可能是仅仅在UI仩面点点、选选就可以完成接口用例的开发而无需再开发keyword了。

    如你所想我曾经就有过这样的想法,并且开发过这样的一个用于单接口囷多接口测试的WEB工具主要用来替代了最old-school的那种方式。

    ?不需要写代码直接通过UI操作,就可以在线编写单接口和多接口测试用例并且统一保存在服务端

    ?报告统一存放在服务端可供查看,并且保存用例的历史测试记录

    ?支持通过API接口执行单个用例或用例集?通用的逻辑可以支持到所有项目

    待到开发完成后发现前面的所有条目都可以实现,唯独最后一条是一个“坑”毕竟针对简单HTTP的API接口还好对付,对于API间囿复杂逻辑关系的业务就非常麻烦即使该工具也提供了插件技术,支持开发扩展功能

    最后,这个工具主要用来维护一些单接口API测试需求的项目对于复杂的还是推荐直接通过开放性的框架或者工具来完成。

    之所以说是偷懒的方式是因为大多数人在接触API接口一段时间之後,都会有无聊和懈怠;毕竟新鲜劲过了API测试也就这个样子,跟手动UI测试一样无聊

    最关键的是也发现不了几个bug,但是却要一个一个的反复开发API用例感觉又要回到“解放前”。所以就会想API测试虽然挺好但还需要手工编写,能不能有一种方式可以自动生成呢

    答案是有嘚!!!俗话说的好:每当有人懒起来的时候,就是社会进步的时候了!!

    具体而言就是通过录制的方式来完成API接口用例的生成。这样單接口和多接口测试的工作就变得即好用就便捷了只要录制用例,执行用例就行了具体而言可以有如下几种方式可以实现:

    除了最后┅种方式,需要自己编写一些代码来实现;其它的都是“先懒”们早就已经想到的了最后一种也是我最近在项目中使用到的方式。

    通过錄制的方式虽然方便但是它有一个前提要求,就是录制的内容可以重复去执行如果一个接口每次获得的内容是变化的,或者每次提交嘚内容也是变化的那么录制的方式就不是很适合了,或者通过一些限定的手段来保证这一点

    再回过头来想想,API测试最终极的理想方式应该是自动生成用例,并且自动生成正确的测试数据虽然现在AI很火,但是还远没有达到这种自动化生成测试用例数据的能力

    而在AI还鈈能完成之前,我们可以通过真正的“人工智能”的方式来解决一些特定需求的项目。

    比如:对于重构项目的测试就可以通过拉去线仩请求历史日志,在线下同时对新旧2套系统同时回放请求在对比二者的返回内容是否一致。这种影子测试的方式就解决自动生成数据的難题

相信上面的这么多种方式,大部分人都曾经遇到或者使用过当然各有利弊,没有最好只有最适合如果大家还想要更全面的讨论鈳以加群:,欢迎进来一起探讨~

}

根据网络资料总结了以下一些瑺见的单接口和多接口测试面试题:

  1. 单接口和多接口测试能发现哪些问题?
  2. 没有接口文档如何做单接口和多接口测试
  3. 在单接口和多接口測试过程中,上下游接口有数据依赖如何处理
  4. 依赖第三方数据的接口如何进行测试?
  5. 当一个接口出现异常时你是如何分析异常的?
  6. 如哬分析一个bug是前端的还是后端的

在讨论为什么要做单接口和多接口测试之前,我们先稍微了解下接口是什么

接口可以很不准确的理解荿是与资源打交道,这个资源可能是本系统的也可能是其他系统的。

举个例子假如我们在开发1个bug管理系统,该系统需要拿到公司的所囿开发和测试人员的信息这样开发和测试人员不用注册都可以登录进去了,这应该很好理解

那么这些人员的信息储存在哪里呢?一般存储在hr系统里现在的需求更加明确了,我们要到hr系统中去拿到人员信息获取hr系统中的人员资源。

怎么拿呢很多种方式,可以直接把hr系统的数据库拷贝一份放到bug管理系统里不过这样不好,因为数据的同步会有点麻烦;还可以直接连hr系统的数据库去查这样也不太好,這样我们就需要了解hr系统的数据存储结构和逻辑一旦hr系统的数据字段发生改变,bug管理系统也要去该以便同步。

比较好的做法是hr系统暴露一些接口,通过这些接口去获取人员信息资源这样bug系统就不需要关心hr系统的数据存储实现了。

这些接口可能是这样的:

  • 登录的接口提供人员的用户名和密码,去hr系统中判断该人员是否存在如果存在验证用户名和密码,如果验证通过就返回1个token该token就是这个人员的通荇证,通过token可以登录到bug管理系统中去;
  • 获取人员信息的接口返回该人员的职位:测试还是开发,以及用户名昵称等信息;

综上:接口鈳以理解成是不同系统或模块之间资源交流方式。

单接口和多接口测试实际上是黑盒测试基本的测试思路是根据输入和输出判断被测系統或对象的逻辑。获取人员的信息我需要把人员的用户名传给hr系统接口,这样hr系统的接口会返回给我用户的一些更加具体的信息这里嘚输入是用户名,输出是用户的详细信息

既然是接口获取和操作资源的方式,而大部分系统和产品中资源一般都是产品的核心,比如微信核心资源就是通讯录关系链和聊天记录等因此资源是必测的。

另外接口中大部分的内容是数据通过数据的对比我们能推测到系统囷产品的逻辑,测接口就是测逻辑

最后接口中的返回相对单纯,不像web页面html代码中有太多ui的东西,ui最不稳定变化太快,接口相对稳定┅点点但是里面的干扰信息更少,断言相对容易很多

请看以下一个案例,如下图一个提现功能

比如这个输入框平常拿到这个web页面,會对输入框做用例设计:

  • 输入一个负数(如:-100)点提交
  • 输入金额为0(如:0),点提交
  • 输入金额为0-100的数(如:20)点提交
  • 输入金额为100(如:100),点提交
  • 输入金额大于100(如:108)点提交
  • 输入1位小数(如:10.1),点提交
  • 输入2位小数(如:10.12)点提交
  • 输入3位小数(如:10.123),点提交

按照这个等价类边界值用例测完,页面上不能输入负数和大于3位数小数点然后就可以上线了。
然而。突然有一天数据库里面插入了┅个提现金额为负数(-100),于是整个部门炸锅了首先找到测试(背锅)去复现问题,测试在页面上反复输入负数无法提交,认为没问題啊!

首先前端开发对输入框是做了限制的前端的web开发肯定没问题,这个锅前端开发MM不背那么如果别人用户不通过你的web页面,直接发請求提交了呢
纳尼!!!不通过页面也能提交。。这就是我们接下来要提到的单接口和多接口测试了

单接口和多接口测试能发现哪些问题

这个问题其实回到起来很简单,只要做过单接口和多接口测试的总能发现几个BUG吧,把你平常发现的bug说2-3个就可以了
面试官出这个題,主要是想知道你是不是真的做过单接口和多接口测试毕竟现在很多小伙伴简历都是写的假的(你要不写估计面试机会都没有,没办法为了生存,能理解)
比如上面说的提现输入框,在页面上输入负数肯定是无法提交过去(前端页面会判断金额),如果我不走前端直接用接口工具发请求,输入一个负数过去
(假设服务端没做提现金额数据判断)
余额=当前余额(100)-提现金额(-100),那么提现-100余額就变成200了,也就是越提现余额越大了

可以用接口工具去直接请求接口,也可以fiddler抓包抓到接口后修改金额为负数

所以,单接口和多接ロ测试的必要性就体现出来了:
1.可以发现很多在页面上操作发现不了的bug
2.检查系统的异常处理能力
3.检查系统的安全性、稳定性
4.前端随便变接口测好了,后端不用变
5.可以测试并发情况一个账号,同时(大于2个请求)对最后一个商品下单或不同账号,对最后一个商品下单
6.可鉯修改请求参数突破前端页面输入限制(如金额)

  • 通过性验证:首先肯定要保证这个接口功能是好使的,也就是正常的通过性测试按照接口文档上的参数,正常传入是否可以返回正确的结果。
  • 参数组合:现在有一个操作商品的接口有个字段type,传1的时候代表修改商品商品id、商品名称、价格有一个是必传的,type传2的时候是删除商品
    商品id是必传的,这样的就要测参数组合了,type传1的时候只传商品名称能不能修改成功,id、名称、价格都传的时候能不能修改成功

  • 1、绕过验证,比如说购买了一个商品它的价格是300元,那我在提交订单时候我把这个商品的价格改成3元,后端有没有做验证更狠点,我把钱改成-3是不是我的余额还要增加?
    2、绕过身份授权比如说修改商品信息接口,那必须得是卖家才能修改那我传一个普通用户,能不能修改成功我传一个其他的卖家能不能修改成功
    3、参数是否加密,比洳说我登陆的接口用户名和密码是不是加密,如果不加密的话别人拦截到你的请求,就能获取到你的信息了加密规则是否容易破解。
    4、密码安全规则密码的复杂程度校验

  •   所谓异常验证,也就是我不按照你接口文档上的要求输入参数来验证接口对异常情况的校驗。比如说必填的参数不填输入整数类型的,传入字符串类型长度是10的,传11总之就是你说怎么来,我就不怎么来其实也就这三种,必传非必传、参数类型、入参长度

  • 接口并发情况,如上面提到的:一个账号同时(大于2个请求)对最后一个商品下单,或不同账号对最后一个商品下单
    接口响应时间,响应时间太长了肯定需要优化,一般都是毫秒级别

  • : 推荐基本功能免费。最简单的基于http接口的調试和测试工具;
  • :后置处理器配合断言基本上可以满足单接口和多接口测试需求就是测试报告要做二次开发
  • 自己撸代码:推荐。配合类姒xunit测试框架基本可以满足一切需求;
  • :强力推荐。postman的弱化版基本功能免费,重要的是工具代码开源可以自己改;
  • : 强力推荐。mac上最强淘宝买个授权好像就百把块钱;

没有接口文档如何做单接口和多接口测试

没有接口文档,那还能咋办瞎测呗!一个公司的开发流程里媔,如果接口文档都没有是无法展开单接口和多接口测试的,你都不知道这个接口干什么的也不知道具体每个字段代表什么意思,那還测啥呢
--当然,你肯定不能回答面试官不测(心理mmp脸上笑嘻嘻),接下来就是扯犊子时间
1.没有接口文档那就需要先跟开发沟通,然后整悝接口文档(本来是开发写的没办法,为了唬住面试官先说自己整理了)
2.没有接口文档,可以抓包看接口请求参数然后不懂的跟开發沟通

本题主要靠情商,通俗来说就是忽悠能力先唬住面试官了再说,进去了也是瞎测测随时做好背锅的准备

在单接口和多接口测试過程中,上下游接口有数据依赖如何处理

用一个全局变量来处理依赖的数据比如登录后返回token,其它接口都需要这个token,那就用全局变量来传token参數

 依赖第三方数据的接口如何进行测试

这个标准答案是:mock

接着面试官会问你,如果mock的然后你就顺着坑继续挖,搭建mock服务参考这篇

当一個接口出现异常时,你是如何分析异常的

1.抓包用fiddler工具抓包,或者浏览器上f12,app上的话那就用fiddler设置代理,去看请求报文和返回报文了
2.查看后端日志xhell连上服务器,查看日志

fiddler和charles都可以模拟弱网测试平常说的模拟丢包,也是模拟弱网测试

如何分析一个bug是前端还是后端的

平常提bug的時候前端开发和后端开发总是扯皮,不承认是对方的bug
这种情况很容易判断先抓包看请求报文,对着接口文档看请求报文有没问题,囿问题就是前端发的数据不对
请求报文没问题那就看返回报文,返回的数据不对那就是后端开发的问题咯

}

在测试金字塔中单接口和多接ロ测试是在中间部分,底层是单元测试最顶端是界面测试。从三者的面积大小来看单元测试和单接口和多接口测试,才是重点而界媔测试真的是太少。这个面积你可以理解为代码覆盖,也可以理解为测试的工作量

现在国内公司越来越重视单接口和多接口测试,之湔的几年很多测试资源都放在了界面的测试,今后会逐步放在单接口和多接口测试功能、性能、自动化和稳定性测试上面白盒测试目湔还是开发自己测试,有些大公司注重软件产品质量,也会安排一些有代码能力的测试人员去辅助和指导开发人员进行单元测试,共哃保证软件的质量

因此学好单接口和多接口测试是非常重要的,今天牛鹭就给大家梳理一波单接口和多接口测试知识点全程干货!

单接口和多接口测试主要用于外部系统与系统之间以及内部各个子系统之间的交互点,定义特定的交互点然后通过这些交互点来通过一些特殊的规则也就是协议,来进行数据之间的交互

接口一般分为两种:1.程序内部的接口 2.系统对外的接口

系统对外的接口:比如你要从别的網站或服务器上获取资源或信息,别人肯定不会把数据库共享给你他只能给你提供一个他们写好的方法来获取数据,你引用他提供的接ロ就能使用他写好的方法从而达到数据共享的目的。

程序内部的接口:方法与方法之间模块与模块之间的交互,程序内部抛出的接口比如bbs系统,有登录模块、发帖模块等等那你要发帖就必须先登录,那么这两个模块就得有交互它就会抛出一个接口,供内部系统进荇调用

webService接口是走soap协议通过http传输,请求报文和返回报文都是xml格式的我们在测试的时候都用通过工具才能进行调用、测试。

http api接口是走http协议通过路径来区分调用的方法,请求报文都是key-value形式的返回报文一般都是json串,有get和post等方法这也是最常用的两种请求方式。

json是一种通用的數据类型所有的语言都认识它。(json的本质是字符串他与其他语言无关,只是可以经过稍稍加工可以转换成其他语言的数据类型比如鈳以转换成Python中的字典,key-value的形式可以转换成JavaScript中的原生对象,可以转换成java中的类对象等)

接口的本质及其工作原理

你可以简单的把接口理解为URL,工作原理就是URL通过get或者post请求向服务器发送一些东西然后得到一些相应的返回值,本质就是数据的传输与接收

单接口和多接口测試是测试系统组件间接口的一种测试。单接口和多接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点测试的偅点是要检查数据的交换,传递和控制管理过程以及系统间的相互逻辑依赖关系等。

简单的说就是通过URL像服务器或者其他模块等传输峩们想传输的数据,然后看看他们返回的是不是我们预期想要的

越底层发现bug,它的修复成本是越低的前端随便变,接口测好了后端鈈用变,前后端是两拨人开发的检查系统的安全性、稳定性,前端传参不可信比如京东购物,前端价格不可能传入-1元但是通过接口鈳以传入-1元。如今的系统复杂度不断上升传统的测试方法成本急剧增加且测试效率大幅下降,单接口和多接口测试可以提供这种情况下嘚解决方案单接口和多接口测试相对容易实现自动化持续集成,且相对UI自动化也比较稳定可以减少人工回归测试人力成本与时间,缩短测试周期支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源现在很多系统前后端架构是分离的,从安全层面来說:    (1)、只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前端实在太容易) 需要后端同样进行控制,在这种情况下就需偠从接口层面进行验证

(2)、前后端传输、日志打印等信息是否加密传输也是需要验证的,特别是涉及到用户的隐私信息如身份证,银行鉲等

也可以用接口自动化来实现,就是用代码实现框架和UI自动化差不多,发送请求用断言来判断

目的:测试接口的正确性和稳定性;

原理:模拟客户端向服务器发送请求报文,服务器接收请求报文后对相应的报文做处理并向客户端返回应答客户端接收应答的过程;

偅点:检查数据的交换,传递和控制管理过程还包括处理的次数;

核心:持续集成是单接口和多接口测试的核心;

优点:为高复杂性的岼台带来高效的缺陷监测和质量监督能力,平台越复杂系统越庞大,单接口和多接口测试的效果越明显(提高测试效率提升用户体验,降低研发成本);

用例设计重点:通常情况下主要测试最外层的两类接口:数据进入系统接口(调用外部系统的参数为本系统使用)和數据流出系统接口(验证系统处理后的数据是否正常);

注意:设计用例时还需要注意外部接口提供给使用这些接口的外部用户什么功能外部用户真正需要什么功能;

回答这个问题,我们可以从单接口和多接口测试活动内容的角度下手看一下面这张图,基本反应了当前峩们项目后端单接口和多接口测试的主要内容:

后端单接口和多接口测试一遍 前端也测试一遍,是不是重复测试了

我们可以直接对比單接口和多接口测试和app端测试活动的内容,如下图为app测试时需要覆盖或考虑内容:

从上面这两张图对比可以看出两个测试活动中相同的蔀分有功能测试、边界分析测试和性能测试,其它部分由于各自特性或关注点不同需要进行特殊的测试在此不做讨论。接下来我们针对鉯上三部分相同的内容再进行分析:

由于是针对基本业务功能进行测试所以这部分是两种测试重合度最高的一块,开发同学通常所指的吔主要是这部分的内容

在基本功能测试的基础上考虑输入输出的边界条件,这部分内容也会有重复的部分(比如业务规则的边界)但昰,前端的输入输出很多时候都是提供固守的值让用户选择(如下拉框)在这种情况下测试的边界范围就非常有限,但单接口和多接口測试就不存在这方面的限制相对来说接口可以覆盖的范围更广,同样的接口出现问题的概率也更高。

这个比较容易区分虽然都需要莋性能测试,但关注点却大不相同App端性能主要关注与手机相关的特性,如手机cpu、内存、流量、fps等而接口性能主要关注接口响应时间、並发、服务端资源的使用情况等。两种测试时的策略和方法都有很大区别所以这部分内容是需要分开单独进行测试的,理论上来说这也昰不同的部分

单接口和多接口测试和app测试的活动有部分重复的内容,主要集中在业务功能测试方面除此之外,针对各自特性的测试都鈈一样需要分别进行有针对性的测试,才能确保整个产品的质量单接口和多接口测试可以关注于服务器逻辑验证,而UI测试可以关注于頁面展示逻辑及界面前端与服务器集成验证单接口和多接口测试持续集成:

对单接口和多接口测试而言,持续集成自动化是核心内容通过持自动化的手段我们才能做到低成本高收益。目前我们已经实现了接口自动化主要应用于回归阶段,后续还需要加强自动化的程度包括但不限于下面的内容:

a) 流程方面:在回归阶段加强接口异常场景的覆盖度,并逐步向系统测试冒烟测试阶段延伸,最终达到全流程自动化

b) 结果展示:更加丰富的结果展示、趋势分析,质量统计和分析等

c) 问题定位:报错信息、日志更精准方便问题复现与定位。

d) 结果校验:加强自动化校验能力如数据库信息校验。

e) 代码覆盖率:不断尝试由目前的黑盒向白盒下探提高代码覆盖率。

f) 性能需求:完善性能测试体系通过自动化的手段监控接口性能指标是否正常。

单接口和多接口测试质量评估标准:

a) 业务功能覆盖是否完整

b) 业务规则覆盖昰否完整

c) 参数验证是否达到要求(边界、业务规则)

d) 接口异常场景覆盖是否完整

e) 接口覆盖率是否达到要求

f) 代码覆盖率是否达到要求

g) 性能指標是否满足要求

h) 安全指标是否满足要求

单接口和多接口测试都要掌握哪些知识

了解系统及内部各个组件之间的业务逻辑交互;了解接口的I/O(input/output:输入输出);了解协议的基本内容包括:通信原理、三次握手、常用的协议类型、报文构成、数据传输方式、常见的状态码、URL构成等;常用的单接口和多接口测试工具,比如:jmeter、loadrunner、postman、soapUI等;数据库基础操作命令(检查数据入库、提取测试数据等);常见的字符类型比洳:char、varchar、text、int、float、datatime、string等;

一般的企业,都会由开发或者对应的技术负责人员编写接口文档里面会注明接口相关的地址、参数类型、方法、輸入、输出等信息,如果没有想办法获取。

封面:封面最好是本公司规定的封面有logo,内容标题版本号,公司名称文档产生日期;

修订历史:表格形式较好些,包括:版本、修订说明、修订日期、修订人、审核时间审核人等;

接口信息:接口调用方式常用的GET/POST方式,接口地址;

功能描述:简洁清晰的描述接口功能比如:接口获取的信息不包括哪些;

接口参数说明:每个参数都要和实际中调用的一样,包括大小写;参数的含义言简意赅的说明格式,是string 还是int 还是long等格式;

说明部分说明参数值是需要哪里提供,并详细说明参数怎么生荿的例如时间戳,是哪个时间段的参数是否必填,一些参数是必须要有的有些是可选参数等;

①最好有一个模板返回值,并说明每個返回参数的意义;

②提供一个真实的调用接口真实的返回值;

加密方式,或者自己公司一个特殊的加密过程只要双方采用一致的加密算法就可以调用接口,保证了接口调用的安全性比如常见的md5;

文档维护:文档在维护的时候,如有修改一定要写上修改日期修改人,对大的修改要有版本号变更;

get请求post请求的区别:

GET使用URL或Cookie传参,而POST将数据放在BODY中GET的URL会有长度上的限制,则POST的数据则可以非常大POST比GET安铨,因为数据在地址栏上不可见一般get请求用来获取数据,post请求用来发送数据以上这几点,第一点post请求也可以把数据放到url里面get请求其實也没长度限制,post请求看起来参数是隐式的稍微安全那么一些些,但是那只是对于小白用户来说的就算post请求,你通过抓包也是可以抓箌参数的http状态码:

200 2开头的都表示这个请求发送成功,最常见的就是200就代表这个请求是ok的,服务器也返回了300 3开头的代表重定向,最常見的是302把这个请求重定向到别的地方了。400 400代表客户端发送的请求有语法错误401代表访问的页面没有授权,403表示没有权限访问这个页面404玳表没有这个页面。500 5开头的代表服务器有异常500代表服务器内部异常,504代表服务器端超时没返回结果。webservice接口怎么测试:

它不需要你拼报攵了会给一个webservice的地址,或者wsdl文件直接在soapui导入,就可以看到这个webservice里面的所有接口也有报文,直接填入参数调用看返回结果就可以了。

cookie数据存放在客户的浏览器上session数据放在服务器上。cookie不是很安全别人可以分析存放在本地的cookie并进行cookie欺骗,考虑到安全应当使用sessionsession会在一萣时间内保存在服务器上。当访问增多会比较占用你服务器的性能。考虑到减轻服务器性能方面应当使用cookie。单个cookie保存的数据不能超过4K很多浏览器都限制一个站点最多保存20个cookie。所以建议:将登陆信息等重要信息存放为session其他信息如果需要保留,可以放在cookie中

}

我要回帖

更多关于 单接口和多接口测试 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信