程序不同模块之间传输数据并作处理的类或函数
答: https 协议需要到 CA(Certificate Authority,证书颁发机构)申请证书,一般免费证书 较少,因而需要一定费用; http 是超文本传输协议,信息是明文传输,Https 协议是由 SSL+Http 协议构建的可进行加 密传输、身份认证的网络协议,比 http 协议安全; http 和 https 使用的是完全不同的连接方式,用的端口也不一样,前者是 80,后者是 443;
答:POST 和 GET 都是向服务器提交数据,并且都会从服务器获取数据。 区别:
1)传送方式:get 通过地址栏传输,post 通过报文传输
2)传送长度:get 参数有长度限制(受限于 url 长度),而 post 无限制
3)GET 产生一个 TCP 数据包(对于 GET 方式的请求,浏览器会把 http header 和 data 一并 发送出去,服务器响应 200 返回数据),POST 产生两个 TCP 数据包(对于 POST,浏览器先 发送 header,服务器响应 100 continue,浏览器再发送 data,服务器响应 200 ok 返回数 据)
4)get 请求参数会被完整保留在浏览历史记录里,而 post 中的参数不会被保留
5)在做数据查询时,建议用 GET 方式;而在做数据添加、修改或删除时,建议用 post 方式
答: 主要有四种方式:application/x-www-form-urlencoded、multipart/form-data、 application/json、text/xml 等。
答: 无状态是指协议对于事务处理没有记忆能力,服务器不知道客户端是什么状态。即我们给服 务器发送 HTTP 请求之后,服务器根据请求,会给我们发送数据过来,但是,发送完,不会 记录任何信息。HTTP 是一个无状态协议,这意味着每个请求都是独立的,Keep-Alive 没能 改变这个结果。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导 致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。HTTP 协议这种特性有优点也有缺点,优点在于解放了服务器,每一次请求“点到为止”不会造成 不必要连接占用,缺点在于每次请求会传输大量重复的内容信息。客户端与服务器进行动态 交互的 Web 应用程序出现之后,HTTP 无状态的特性严重阻碍了这些应用程序的实现,毕竟 交互是需要承前启后的,简单的购物车程序也要知道用户到底在之前选择了什么商品。于是, 两种用于保持 HTTP 连接状态的技术就应运而生了,一个是 Cookie,而另一个则是 Session。
答: cookie 数据存放在客户的浏览器上,session 数据放在服务器上 cookie 不是很安全,别人可以分析存放在本地的 cookie 并进行 cookie 欺骗,考虑到安全 应当使用 session session 会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能,考虑 到减轻服务器性能方面应当使用 cookie 单个 cookie 保存的数据不能超过 4K,很多浏览器都限制一个站点最多保存 20 个 cookie 可以将登陆信息等重要信息存放为 session;其他信息需要保存,可以放在 cookie
答:
1xx – 信息提示(表示临时的响应。客户端在收到常规响应之前,准备接收一个或多个 1xx 响应)
2xx – 成功(表明服务器成功地接受了客户端请求)
3xx – 重定向(客户端浏览器必须采取更多操作来实现请求。例如,浏览器可能不得不请 求服务器上的不同的页面,或通过代理服务器重复该请求)
4xx – 客户端错误(发送错误,客户端有问题。例如,客户端请求不存在的页面,客户端 未提供有效的身份证验证信息)
5xx – 服务器错误(服务器由于遇到错误而不能完成该请求)
常见的返回码有:
答:DNS 是域名系统 (Domain Name System),DNS 是用来做域名解析的,它会在你上网输入 网址后,把它转换成 IP,然后去访问对方服务器;没有它,你想上百度就要记住百度的 IP, 但有了 DNS 的处理,你只需要记住对应网站的域名,即网址就可以了。
答:
功能测试:
接口的功能是否正常实现
接口是否按照接口文档实现(比如username参数写为了user,那么这就不符合,因为接口文档在整个开发中都需要使用,所以接口实际的设计要与接口设计文档中保持一致)
兼容性测试: 比如说今天接口进行了调整,但是前端没有进行变更,这时候需要验证新的接口是否满足旧的调用方式
错误码测试:用的错误码与业务错误码是否能够清晰的说明调用问题,错误码是否能够尽可能的全的覆盖所有的情况
返回值测试:返回值除了内容需要是正确的,还需要类型也是正确的,保证调用方拿到这些参数能够正确的解析
业务逻辑测试
是否有依赖业务,比如查看订单,是需要用户首先登录的,所以肯定要保证登录了或有相应的cookie
业务逻辑测试: 传递正确的参数,接口对数据库进行查询的操作,需要去验证数据库查询是否正确,接口对数据库进行 增删改的 操作,也需要看数据库是否同步进行了这些操作
异常测试:
异常分为两类,参数异常和数据异常
参数异常:
关键字参数:将参数写为开发语言中的关键字
参数为空:比如去掉了username参数
多或少参数:多或者少参数的验证,现在还不确定如果一个接口多了参数如果没有报错是否是合理的,或者是否需要优化,因为就目前开发给予的答案是,一般不对接口多了参数的处理
错误参数:比如将username参数写为了user等看是否能返回相应的error?code
数据异常:
关键字数据:将参数的值填为开发语言中的关键字
数据为空:将参数的额值填为空
长度不一致:因为数据库中每个字段都设置有字段长度,填写不符合的长度进行验证
错误数据:就是将参数的值任意填写,或填写不存在的数值
异常类型测试: 比如count参数,这个参数的类型一定是可以转换为int类型的,这时候我们需要测试如果传的一些不可以 转换为int类型值来测试代码是否加入判断
性能测试:
响应时间
吞吐量
并发用户数
占用内存,CPU等
答: 通常,设计接口测试用例需要考虑以下几个方面:
①是否满足前提条件 有些接口需要满足前提,才可成功获取数据。常见的,需要登录 Token 逆向用例:针对是否满足前置条件(假设为 n 个条件),设计 0~n 条用例
②是否携带默认值参数 正向用例:带默认值的参数都不填写、不传参,必填参数都填写正确且存在的“常规”值, 其他不填写,设计 1 条用例
③业务规则、功能需求 这里根据时间情况,结合接口参数说明,可能需要设计 N 条正向用例和逆向用例
④参数是否必填 逆向用例:针对每个必填参数,都设计 1 条参数值为空的逆向用例
⑤参数之间是否存在关联 有些参数彼此之间存在相互制约的关系
⑥参数数据类型限制 逆向用例:针对每个参数都设计 1 条参数值类型不符的逆向用例
答:
可用性测试 根据约定的协议、方法、格式内容,传输数据到接口经处理后返回期望的结果:
答:常用 http 协议接口测试工具,如:postman、fiddler、jmeter;webService 接口用 SoapUI、 jmeter 等。
本题主要考情商,通俗来说就是忽悠能力,先唬住面试官了再说,进去了也是瞎测测,随时 做好背锅的准备,当然,你肯定不能回答面试官不测(心理 mmp,脸上笑嘻嘻),接下来就是 扯犊子时间
答:用抓包工具把接口抓取处理,然后针对性进行测试;接口中字段信息不清楚的,找时间
集中寻求开发解答。(常用抓包工具 Fiddler、Charles 等)
答:用一个全局变量来处理依赖的数据,比如登录后返回 token,其它接口都需要这个 token, 那就用全局变量来传 token 参数。
答:mock 接着面试官会问你,如果 mock 的,然后你就顺着坑继续挖,搭建 mock 服务,参考这篇 http://www.51ste.com/share/det-485.html
答:依赖登录状态的接口的本质上是在每次发送请求时需要带上 session 或者 cookie 才能 发送成功,在构建 POST 请求时添加必要的 session 或者 cookie
答:Fiddler 和 charles 都可以模拟弱网测试,平常说的模拟丢包,也是模拟弱网测试。具体可以看《几种弱网模拟方法,总有一种适合你》
面试官出这个题,主要是想知道你是不是真的做过接口测试,毕竟现在很多小伙伴简历经过 包装(不包装连面试机会都没有,没办法,为了生存,能理解)
答:
常规错误,接口没实现,没按约定返回结果,边界值处理出错等。 输入异常值(空值、特殊字符、超过约定长度等),接口抛错,没做封装处理; 输入错误的参数、多输入、少输入参数,
接口可能出现的错误; 安全性问题,如明文传输、返回结果含有敏感信息,没对用户身份信息做校验,没做恶意请 求拦截等;
性能问题,如接口并发插入多条相同操作,响应时间过长,接口压测出现瓶颈等;
答: 先抓包,用 fiddler(charles)工具抓包,或者浏览器上 F12 调试工具;APP 上的话,那就 用 Fiddler 做代理,通过手机设置代理去看请求和返回报文; 查看后端日志,如 Linux 系统通过 xhell 连上服务器,查看接口日志,查看是否有报错信息 (命令:tail -f 日志文件)
答: 平常提 bug 的时候,前端开发和后端开发总是扯皮,不承认是对方的 bug。 这种情况很容易判断,先抓包看请求报文,对着接口文档,看请求报文有没问题,有问题就 是前端发的数据不对; 请求报文没问题,那就看返回报文,返回的数据不对,那就是后端开发的问题咯。
在 unittest 中,没有自带的数据驱动,我们得借助 ddt 来实现,首先,我们得在 python 运行环境中安装 ddt,用下列命令安装 pip install ddt 另 外 一 个 测 试 框 架 pytest , 它 自 带 数 据 驱 动 实 现 , 是 通 过 @pytest.mark.parametrize(argnames,argvalues) 来实现参数化的。 也可以根据自己需求用 python 实现数据的读取和驱动。
把上一个请求返回的结果传入到下一个请求的参数中,将请求的结果反射到一个类属性(使 用 setattr()函数),下一个请求去调用这个类属性
断言 ,预期结果与实际结果对比
数据库校验,根据测试场景来查询数据库里的数据和请求之前的数据进行比对 测码学院
简述自动化框架的设计、维护
测试框架:python+unittest+requests+ddt+openpyxl+pymysql+logging
python:入门简单,语法简洁
unittest :定义一个测试用例类,具体的方法来维护测试用例的生命周期,测试场景行为, 测试用例 前置场景,行为,期望结果,实际结果,断言方法,Setup teardown 方法
requests:接口调用 ,支持 http 请求的库,API 简洁,提供不同的 http 请求方法,支持 session,cookies,
ddt :数据驱动,ddt 类装饰器,data 测试方法装饰器 unpack 解包可迭代的数据类型
普通用户,数据库,配置文件—(基础数据),一般进行接口测试时,每个接口的传参都不止一种情况,一般会考虑正向、逆向等多种组合。所以在测试一个接口时通常会编写多条case,而这些case除了传参不同外,其实并没什么区别。这个时候就可以利用ddt来管理测试数据,提高代码复用率。
openpyxl: 数据管理 excel 管理数据,使用 openpyxl 模块来进行 excel 数据的读和写 (excle,csv, json, yaml, txt 都可以管理测试数据)
pymysql:数据库交互,数据校验
eval,json:数据格式的转换 Eval 将 python 支持的格式转换成对应的格式
logging:日志处理, 统一日志输出格式,渠道,级别,执行结果的记录,便于定位问题
jenkins:持续集成
2/框架设计思路:数据驱动+结构分层(可读性,可维护性,可扩展性)
数据驱动:将维护数据与代码分离,接口调用行为一致,针对不同的参数组合驱动不同的测 试场景,减少代码冗余
结构分层:数据层+用例层+逻辑层
数据层:测试数据的支撑 data.xls
用例层:用例的执行 test_register.py test_recharge.py
逻辑层:公用的方法的封装与提取 doexcle.py do_mysql.py http_requests.py logger.py 等模块
3/框架设计步骤:
准备测试数据: EXCEL 表准备测试用例—excel 数据的读取—参数值的替换 测码学院
发起请求:请求方法(get/post 方法进行封装—URL 的拼接(不同—参数转化为字典
拿到请求的返回值:解析返回值 code,status,msg 信息
断言
好处:
1、自动化测试用例和手工测试用例的完美结合,减少重复工作
2、配置灵活,可以自主切换测试环境,执行测试用例
3、常用功能进行封装,逻辑清晰,易于维护
4、统一执行入口,管理测试用例集:
run.py 模块通过模糊查找来选择需要执行的测试用例
5、持续集成,定时构建,快速反馈
完成所有的自动化测试框架的设计和实现后,进行接口测试,然后集成到
jenkins,配置定时执行,生成 html 报表,查看测试通过率,查看接口的功能
每次发版时,进行回归测试,新功能开发未提测前
suite = unittest.TestSuite() #存储用例
suite.addTest(TestMathMethod(“test_add_two_positive”)) #只执行一条,通过函数名执行用例
#执行一个类里面的所有函数
loader = unittest.TestLoader() #创建一个加载器
suite.addTest(loader.loadTestsFromTestCase(TestMathMethod)) #根据测试类名加载(具体到类名)
suite.addTest(loader.loadTestsFromModule(class_01)) #根据模块名使用,如果某个模块里面有多个类名,就需要使用此方法
转载连接:https://blog.csdn.net/weixin_44602565/article/details/108704374?spm=1001.2014.3001.5501