31道软件测试面试题12361字整理,快来看看你都会吗?面试技巧的哪些小心机

面试讲了你还了解这个东西,不讲就是你不会,代表这个东西你连听都没通过,工资就给你低开。谁会跟工资过不去呢?面试不要抱着我不知道,我就不讲的误区。要知道,了胜于无。30分总归大于0分,尽管30分比100差的远。面试套路还是要有的。

测试基础:简单问题---说亮点、工具问题---说实操

问题一:你是如何梳理复杂的业务流程的?

核心思路:用户角度 – 哪些人做哪些事,以及人和事、人和人、事和事之间的联系
基于了解项目需求,看了需求文档之后,从测试角度进行流程梳理

梳理系统的三个组成元素 :系统用户与角色、系统核心业务、系统核心功能
工具 :xmind
具体梳理方式 


问题二:前端操作时遇到的问题如何去后台定位问题

1.找到前端操作触发的接口/网络请求

   抓包---浏览器开发者工具和Fiddler
    记录请求信息和时间

2.登录linux服务器后台查看应用日志
3.检查后台是否有对应的日志信息以及错误日志是否与前端操作相关联

时间

关键字:error、exception

 问题三:A调B,B调C这种全链路的服务,如何去定位问题

如:订单系统、仓储系统、支付系统

用意:检查你是否具备复杂分布式系统测试的能力

问题定位方式1:   

     挨个系统去查看对应的数据库应用日志信息
     分布式系统--日志--分散在各个服务器/应用服务器里面

问题定位方式2:大厂通常有链路追踪系统,可以通过在线日志去查看

典型:ELK日志管理平台    -----》 kibana    web系统
可视化日志查看工具
输入关键字去查询日志、通过各种筛选条件去查看

问题四:给你一个业务场景,比如登录功能,请你设计一下测试用例?

考察你测试用例的设计思路是否清晰,展现技术的广度和深度

1、功能角度

方法论:边界值、等价类划分、错误推测方法

示例:

       a、 输入已注册的用户名和正确的密码,验证是否登录成功;
        b、输入已注册的用户名和不正确的密码,验证是否登录失败,并且提示信息正确;
        c、输入未注册的用户名和任意密码,验证是否登录失败,并且提示信息正确;
        d、用户名和密码两者都为空,验证是否登录失败,并且提示信息正确;
        e、用户名和密码两者之一为空,验证是否登录失败,并且提示信息正确;

        f、 如果登录功能启用了验证码功能,在用户名和密码正确的前提下,输入正确的验证码,验证是否登录失败,并且提示信息正确;

        g、如果登录功能启用了验证码功能,在用户名和密码正确的前提下,输入错误的验证码,验证是否登录失败,并且提示信息正确;
        h、前端页面是否根据设计要求限制用户名和密码长度;

      


2、用户体验角度

后台系统创建的用户第一次登录成功时,是否提示修改密码;
前端页面是否根据设计要求限制用户名和密码长度;
快捷键Tab 和Enter等,是否可以正常使用。
页面默认焦点是否定位在用户名的输入框中;

忘记用户名和忘记密码的功能是否可用;



3、兼容性角度
不同浏览器下,验证登录页面的显示以及功能正确性;
相同浏览器的不同版本下,验证登录页面正确的显示以及功能性;
不同移动设备终端的不同浏览器下,验证登录页面的显示以及功能正确性;
不同分辨率的界面下,验证登录页面的显示以及功能正确性。

4、安全性角度

页面上的密码框是否加密显示;
用户名和密码是否大小写敏感;
刷新页面是否会刷新验证码;
如果登录功能需要验证码,点击验证码图片是否可以更换验证码,更换后的验证码是否可用
不同级别的用户,比如管理员用户和普通用户,登录系统后的权限是否正确;
如果验证码具有时效性,需要分别验证时效内和时效外验证码的有效性;
用户登录成功但是会话超时后,继续操作是否会重定向到用户登录界面;
用户密码后台存储是否加密

用户密码在网络传输过程中是否加密

密码是否具有有效期,密码有效期到期后,是否提示需要修改密码;
不登录的情况下,在浏览器中直接输入登录后的URL地址,验证是否会重新定向到用户登录界面:

密码输入框是否不支持复制和粘贴

密码输入框内输入的密码是否都可以在页面源码模式下被查看

多次登录之后,是否锁定账户

SQL注入

5、性能角度

单用户登录的响应时间是否小于3秒;
单用户登录时,后台请求数量是否过多;
高并发场景下用户登录的响应时间是否小于5秒;
高并发场景下服务端的监控指标是否符合预期;
高集合点并发场景下,是否存在资源死锁和不合理的资源等待;
长时间大量用户连续登录和登出,服务器端是否存在内存泄漏。

问题五:说说你们公司的测试工作流程?

重点是结合项目说明

需求分析与评审

编写测试计划

任务分配

编写测试用例

评审测试用例

执行测试用例: 

       手工测试: 直接执行用例

      自动化测试: 分析测试用例--梳理出要转换为自动化测试脚本的用例,编写测试脚本  筛选

整理测试报告

总结

问题六:平时工作中用过哪些Linux命令?

top   类似Windows的资源管理器,可以查看cpu、内存的占用情况

ps -ef | grep 进程ID    查看进程的使用情况(非常高频)
                         ps:查询进程信息
                         | 管道符
                         grep  查找 过滤

netstat -ntpl | grep 端口号  查看端口占用情况

    启动系统的时候,提示端口被占用
    tomcat的端口冲突、被占用

tail -f 日志文件地址   用于动态查看log
   

问题7:你知道shell脚本知道怎么写吗?

Shell是一个用C语言编写的程序,它是用户使用Linux的桥梁
业界所说的shell通常都是指shell脚本
扩展名为sh (sh代表shell),扩展名并不影响脚本执行
#!/bin/bash   

       #!是一个约定的标记,它告诉系统这个脚本需要什么解释器来执行,即使用哪一种Shell
关键内容:变量、参数、运算符、流程控制、函数

类apython语言
    举出一个shell的编写经历

    学习自动化  --运行的时候,pytest ..... 
我写的不多,就是以前把pytest运行脚本的那一段命令,做成一个shell脚本

vi  test.sh

内容:
pytest ......


./test.sh   执行

问题8:你们是什么数据库,用什么工具去操作

navicat :Mysql 、Oracle
Redis  亮点
MongoDB  亮点

面试是一个细节活,每一个细节加起来就很厉害了,用小技术让自己变得更专业,更厉害

树立形象:技术范围广、实操性强、面设计是为了把别人比下去(别人不会,你会就把别人比下去了)

问题9:数据库查询语句里面怎么排除掉重复的数据?

SQL 里面的关键字
select  distinct 字段名 from  表名;

问题10:当你测试出来的BUG,开发确不认为是个BUG,你怎么处理这个问题?

沟通亮点:

可能开发只是任务太重,发发牢骚,沟通一下就好了
平时多沟通,多交流,别把自己当成找茬的

举证:

1.接口测试记录请求内容和响应内容
2.UI测试记得截图和描述清楚重现步骤

问题11:一个BUG你如何去区分,是前端还是后端的问题?

接口抓包分析  Fiddler等工具

分析思路  :

      请求参数或者请求方式不对,问题在前端
      响应内容不符合要求,后端问题
      接口请求和响应符合要求,前端问题

问题12:平常你是怎么测试接口的

接口测试的流程和普通的功能测试一样:根据需求和接口文档,设计用例

1.根据接口文档梳理接口测试的四个要素:请求地址、请求方式、请求参数、响应内容(判定接口测试结果)

2.使用postman录入接口信息,执行接口请求/测试:接口测试工具(postman、jmeter、apifox)

3.运行测试集/执行测试:不会一个个运行,都是批量运行

4.newman工具导出测试报告:升华、面试题--亮点


newman生成报告执行命令:

newman run  测试集报告.json   -e 环境文件  -g 全局变量.   -d 参数化文件  -r html --repoter-html-export

或者

newman run  测试集报告.json   -e 环境文件  -g 全局变量.   -d 参数化文件  -r htmlextra --repoter-htmlextra-export  (新版报告生成命令,生成的报告更直观、有图表)

问题13:没有接口文档的情况下,如何测试

没有接口文档的情况下,我主要有两种实现方式。

第一种方式,就是有时候我们公司要让我去整理一个结果文档出来

1、抓包手动分析,自己整理接口文档,分析给其他同事也可以去测试:

        charles:和filddler功能一样,不过要收钱,用破解版有法律风险,charles我也看过,所以没有单独去做了。

        fiddler:适应面广,app
        浏览器开发者工具:打开浏览器开发者工具,在工具里面,有一个网络选项,在网络里面点击一个具体的请求,可以看到请求的标头、响应的标头、请求参数、根据这些信息就可以组织一个接口文档的请求。

如果说有些接口我只是测试一下,没有文档的要求,我可能直接用脚本录制的技术来去做测试

2、脚本录制:直接生成接口测试所需要的脚本
①Fiddler脚本录制:Fiddler抓包之后,导出jmeter测试脚本,插件:把抓到的网络请求包变成jmeter脚本

② badboy录制

③jmeter脚本:jmeter自带的脚本录制功能,我是用的jmeter的脚本录制

   jemter录制原理:通过代理模式,

 jemter里面有一个HTTP代理服务器的功能,他这里面可以指定一个对应的,启动一个代理服务器,然后启动完毕之后,我只需要把浏览器对应的网络请求交给jemter,在操作完成之后,点击停止,它会自动生成对应的测试脚本,在我们指定的线程组里边都可以。

Jmeter脚本录制 :http代理功能、https需要安装jmeter生成的证书(方便,jmeter自带,不需要额外去安装插件,这个叫技术选型
 

简单问题-说亮点

工具问题-说实操

jmeter录制脚本案例

第一步:新建一个线程组

第二步:测试计划------非测试原件----HTTP代理服务器

问题14:session和token的区别

1. cookies数据存放在客户的浏览器上,session数据放在服务器上

2. cookies不是很安全,别人可以分析存放在本地的cookies并进行cookies欺骗考虑到安全应当使用session

3. session会在一定时间内保存在服务器上,当访问增多,会比较占用,你服务器的性能考虑到减轻服务器性能方面,应当使用cookie。


问题15:http和https请求的区别

。。。


问题16:HTTPS怎么保障其安全性的

。。。


 问题17:什么是接口幂等性

第一次请求和多次请求,产生的结果是否一样,如果一样就是幂等,如果不一样就是非幂等

例如:会员信息录入表单,录入身份证是唯一的,多次提交--生成多个会员信息。

正常情况下面,如果该会员已经录入到我们系统,第一次提交,第二次提交,第三次提交,他都只会产生一条会员信息,看到没幂等,就这么个意思,反复操作,重复处理,如果多次操作产生的结果是一样的,这叫幂等。

问题18:知道HTTP协议报文的内容有哪些吗?

HTTP请求报文:

HTTP请求报文由3部分组成(请求行+请求头+请求体)
第一部分:请求行,请求类型,资源路径以及HTTP 版本。
第二部分:请求头部,紧接着请求行(即第一行)之后的部分,用来说明服务器要使用的附加信息
第三部分:空行,请求头部后面的空行是必须的,请求头部和数据主体之间必须有换行
第四部分:请求数据也叫主体,可以添加任意的数据。


HTTP响应报文:

HTTP响应报文由3部分组成(响应行+响应头+响应体)
第一部分:,状态行。HTTP版本、状态码、状态消息。
第二部分:响应报头部,紧接着请求行(即第一行)之后的部分,用来说明服务器要使用的附加信息
第三部分:空行,头部后面的空行是必须的,头部和数据主体之间必须有换行
第四部分:响应正文。可以添加任意的数据。

问题19:postman和jmeter哪个更好?

从功能上Jmeter最为强大,可以测试各种类型的接口,不支持的也可以通过网上或自己编写的插件进行扩展


Postman更是轻量级,定位也不同,可用来测试http接口。界面更好看一些,更简单,更简洁。

问题20:接口中常见的返回状态码有哪些?你见过比较多的有哪些?

考点:http状态码
1开头:的信息,服务器收到请求,需要请求者继续执行操作 

       101:切换协议(例如websocket建立连接的时候)

2开头:成功,操作被成功接收并处理   

        200:确定,表示客户端请求已成功

3开头:重定向,需要进一步的操作以完成请求  

       302-对象已移动:服务器响应的时候,携带新的访问地址给你
       304-未修改,数据被客户端缓存

4开头:客户端错误,请求包含语法错误或无法完成请求

        404        找不到资源
        401        访问被拒绝
        403        服务器拒绝请求。可以理解为没有权限访问
        405        方法不被允许   如:用get访问post请求,提示:请求方法不允许

5开头:服务器错误,服务器在处理请求的过程中发生了错误

       500:内部服务器错误
       503:目前服务器无法使用,一般是因为服务器超载或停止维护   或者正在服务器正在启动,有时候也会报错

误区:服务器有错误不代表说服务端的开发人员有错误,服务器有错误或者说客户端错误,不代表说就一定是测试人员自己请求错了,比如说正确的情况下面就应该有个API/user/101,正确的话,我访问这个地址就应该有效果,那我去访问的时候返回404,那你说这个是我测试员自己请求错误了吗,不是的,只是说这个请求没有找到,可能是服务端没有提供,所以这个状态码,他的划分不代表说bug的定位,这个一定要搞清楚,很多面试官会给你挖坑,他说404这个问题是服务端问题还是客户端问题呢,从状态码的上面来说呢,我们叫客户端请求错了,就服务器没有这个东西你还去请求,那不是你的错误,是谁的错误,这只是状态码划分,所以千万不能把它划分到Bug的定位上面去

提示:这个是状态码一定要记住,不能简单的说404、402、503、505、501,这不行,把它404的具体含义展开来讲。

问题21:对于加密接口,如何进行测试?

   第一种是叫自己测试人员自己加密测试,就是你自己需要去写,还有另外一种方法就是生成加密后的数据,然后你可以直接让开发人员协助,生成的数据直接就是加密之后的数据

一、自己测试人员自己加密测试

 在调用接口的时候,要搞清楚接口的加密方式是什么。


   1、如果是对称加密,要先从开发那里获取对称密钥,基于对称密钥可以加密请求数据,以及解密响应报文。

  2、 如果是非对称加密,先从开发获取服务器公钥和私钥,也要知道当前用户的公钥和私钥信息。以便完成接口的数据加密和解密

   具体的实现需要通过工具来实现。
   常用的jmeter 和postman都支持编写脚本进行加密

加密通常还会配套有解密需求:服务器端返回的是密文,测试的时候要解密才能看
更多的情况---用代码比较方便

问题22:在你的接口测试工作中,你主要通过哪些标准判定接口测试的结果是否通过?

1}验证接口响应状志码是否是200。

         这是接口测试的最基本要求。 响应状态码200代表了该接口能接收请求,能返回响应。但这个地方要注意,有些结果它本身就是一些错误的情况下面,我们要返回404,或者说我们异常流程

2)验证响应的完整内容是否等于预期。

          当接口响应正文比较短,响应正文内容固定时,可以验证响应内容是否精确地等于预期的内容     如  delete   OK 

3)验证响应报文是否包含关键信息。

     当响应内容较长时,可以判断响应内容中是否包含一些关键信息,以此作为验证接口功能的验证

      一个商品的数据接口会返回这么多东西,那作为一个测试人员,我们不会说去把这里面所有的内容去全值匹配,我们会看关键字,比如说code是不是等于0,Message是不是success, ID号、title是不是符合我们的预期,看一些关键的信息就好了,不是说每一个细节,图片的东西我都看一下。


4)验证响应报文关键字段是否存在。

      当响应正文为XML格式或JSON格式时,可以通过XPATH或JSONPATH表达式,指定其中的
 


5验证响应报文关键字段,值是否正确。

        除了可以验证字段是否存在,如果值

6)杳询数据库或调用其余接口查询

     

面试时:有条理的去讲,比如说,第一种,第二种,第三种,第三种,第五种

问题23:知道怎么测试websocket接口嘛?

证明面试官想看你对这个web有没有对应的了解,因为面试官这么问你,一定是想知道你是否具备有httpwebsocket的两种接口或者说多种接口的测试能力

1、websocket在建立长连接后,websocket服务端和客户端都能主动向对方发送或者接收数据 (websocket是什么)


2、而在http协议中,一个request只能有一个response,而且这个response也是被动的,服务器端不能主动发起响应。(简单的说一下http和websocket的常见区别)


3、jmeter 有插件可以用于websocket接口测试

4、接口自动化的切入,引导,我自己之前也用python代码做过websocket的接口测试


你回答了一个websocket,回答上面这些东西,可能就是感觉,你这个经验比较丰富,那如果说你能够在这个过程中去主动做一些引导,我以前做过一些什么样的东西,

好,那面试官呢,有些面试可能就会觉得,你还用Python代码做过,请问你说一下,你说一下你用Python怎么做的,

这个时候你看原本他问你的东西没有自动化的东西,你就引到自动化这一块儿了,原本他可能问的是HTTP的一些接口自动化,这个时候引到了websocket,额外的引导过去,这个就是我们的套路,在这里面继续讲讲,比如说......,然后细致的说说,对吧,你的这个websocket或者自动化,怎么用的,代码怎么写的,用的什么包,对吧,代码怎么写的,当时是什么场景,这个时候你噼里啪啦又讲一堆,这个过程就是让面试官知道,你这个人还有很多技能,知道吧,不是说一个,简简单单的,我就是做一个小工具,我还会一些实际的什么代码编写能力的,所以这个时候亮点它是不一样的,你的技术能力你会发现,当你真正有技术之后,你能够和面试官做到真正的说有沟通,很多人面试,如果你没有技术的话,你没有去提前准备些技术,你和面试官只是说一个问答的过程,面试官问什么你就答什么,你谈不上沟通。

问题24:当一个接口出现异常的时候,你是如何分析这个异常的?

1、异常   

      查看后端日志,如Linux系统通过ssh方式连上服务器
      查看接口日志,查看是否有报错信息(命令: tail -f日志文件)

    如果说这个日志非常多的话,我还会结合这个的grep这个命令去进行数据的日志的筛选,每  一个细节都体现出你这个人有实操能力,结合你的以往情况进行讲解

2、一直无响应

      看后台资源(服务器+mysql)
     看后台日志

问题25:GET和POST请求区别是什么

1、场景

        get    常用于获取资源的请求       浏览器地址-- get请求
        post  常用语表单提交、创建数据、上传数据等

2、参数

     get参数:

        请求字符串是拼接在url后面
        请求url长度有限制(2048个字符),所以请求字符串也是有长度限制的
        安全性相对较差(因为能在url后边看到请求参数)
        只能进行url编码
        参数的数据类型,GET只支持ASCll字符

    post参数:

        请求参数放在请求体里
        请求参数没有长度限制
        安全性相对较好
        支持多种编码方式   
BASE64    MD5
        参数的数据类型,没有限制
 

问题26:多接口测试相互依赖的情况下如何测试

面试官,考察这个东西,无非就是考察你的实战能力,对吧,看你有没有碰到这种问题,不论你碰到过还是没碰到过,都要这么回答

正常回答:

利用postman或者jmeter,通过全局变量或环境变量来进行接口间的数据传递     接口关联


1、在前置接口中保存并提取要传递的数据
2、.将数据保存在变量
3、在后续接口,直接使用保存在全局变量或环境变量中的参数值    值引用

自动化的回答   引导切入自动化

有时候不仅是不会这个知识,而是说你就算换了知识之后,你不知道怎么去讲这个东西

问题27:你之前做接口测试的过程中发现过哪些bug? / 接口测试会有哪些小bug

常规错误,接口没实现,没按约定返回结果,边界值处理出错等。
输入异常值(空值、特殊字符、超过约定长度等),接口抛错,没做封装处理;
输入错误的参数、多输入、少输入参数,接口可能出现的错误;
安全性问题,如明文传输、返回结果含有敏感信息,没对用户身份信息做校验,没做恶意请求拦截等;
性能问题,如接口并发插入多条相同操作,响应时间过长,接口压测出现瓶颈等;

 

你要做两个专项,跟用例设计答题思路有点类似。

你具体发现了哪些bug,鬼知道,面试官,他也不知道你到底发现哪些bug,你直接说一说,发现哪些bug就好,知道吧,套在你的项目里面,因为这个bug谁也不知道是在哪里出现的,你怎么讲,面试官他不知道,反正他无法查证,理解我意思吧,这个你懂得,我只能提示到这里了,这些东西都是你说什么它就是什么,不在于你有没有做过这个事情,就是这么回事儿。


问题28:什么是TCP的握手机制?/ 为什么需要三次握手? / 为什么需要四次挥手?

变种问题:为什么需要三次把手?为什么需要四次挥手?

传输控制协议(TCP)是 Internet一个重要的传输层协议。

TCP提供面向连接、可靠、有序、字节流传输服务。应用程序在使用TCP之前,必须先建立TCP连接。


三次握手过程
四次挥手过程

三次握手就是三次数据传输,比如说,客户端提交数据到服务器端,如果网络不好,传输了一半的数据怎么办?是不是会出现这种情况,网络不好,这种情况下是不是经常会碰到,那怎么样尽量规避这种问题,这个时候就有了我们说的传输层协议,

那传输协议里面这个三次握手是什么概念呢,可以说是一个网络检查的过程,客户端、服务器之间的网络是否通畅,在传递数据之前,比如HTTP请求数据之前,我在页面提交一个JSON数据,JSON数据提交之前,先做了这么一件事情,这个客户端会说浏览器,我接下来要来传数据啦,好,先跟服务器打个招呼,我接下来要传数据到服务器端,但是为了保证网络还算好,保证传输数据没有问题,我们做一个网络连接的检查,我要向你传输数据,首先问你一下,我要传数据了行不行,服务器说好的,你向我传数据吧,没问题,你传过来吧,好给你一个回应,然后的话,客户端说行,那就这么定了,我接下来就向你传数据了,所以这里面就会三次握手,123这三个过程叫三次握手,然后接下来传数据,传什么Json数据,XML数据吧。

那为什么要这么做呢?

场景:打电话的时候

对方:喂,能听到声音吗?

你:能听到能听到,你能听到我的声音吗?

对方:能听到,接下来,正式进入这个讲解

你看你打电话是不是都这样,这个过程就是检查一下网络的一个数据是不是通顺,这其实也就是我们说的一个TCP连接的过程,TCP连接过程。

那为什么需要有三次?两次行不行?不行,为什么不行?你看,客户端传数据到服务器端,服务器端返回一下,这个过程证明由客户端到服务器端的这个网络传输没有问题,但是不能证明服务器端到客户端的过程没有问题,一来一回只能证明单向传递没有问题,那么最后客户端又传一个数据到服务器端,证明服务器端到后端的过程也没有问题,所以必须要有三次,不能说两次可以不,四次太多余,两次不够用,所以这就是三次握手,为什么要三次握手,就这个原因,对吧,你看这么一来一回之后,代表网络基本上没问题,这时候开始传数据,传JSON,传图片,传什么,删除这些请求就这个过程,这个过程叫三次握手。

四次挥手,是指在我们关闭网络连接之前,先来做一个结束连接的过程。怎么结束连接就是,前面我们讲客户端请求数据给了对不对,好,那服务端返回数据,这时候客户端说,我们请求完毕,Game over ,我们要拜拜了,这时候客户端说:我们两个接下来就不要有什么网络连接了,我要断开了,客户再问服务器我能不能断开,服务器说,我已经收到你的请求了,请注意,服务器说我已经收到你的请求了,但是我还不能关闭,请注意,我还不能关闭,为什么还不能关闭呢,因为我的数据还没传输给你的,所以在这个半关闭状态,服务器要做一些收尾的工作,服务器说你刚刚要我这么多数据,我还没给你呢,我还没来得及给你,赶紧给你给你xxxx资源,给你之后,最后服务器告诉你说:我全部传送完毕,可以关闭了,客户端说:行,那我就关闭了,就这么个过程。

那为什么需要有四次挥手?你可以看到,服务端能不能够直接关闭,不能。还有数据没关闭。

这个东西也很好理解,在过年的时候有没有碰到这种情况,就是过春节的时候,你们有没有碰到这种情况,

场景:拜完年了

姑妈:我要走了,拜年结束了

你:怎么这么快就走了,等一下再走,注意为什么要等一下,这是我们这里的什么特产,给你的礼物,拿完土特产,姑妈你再走吧,

你:装土特产给姑妈,并招呼 姑妈 以后常来,那就不远送了

姑妈:拿完土特产,走了,真的拜拜了

你说能不能少一个流程,少不了,是不是,所以你看为什么需要有四次挥手,也是这个原因,因为有数据传递的过程中,你不能够说,突然一下就中断了,理解了吧,所以这个就是我们说的TCP的握手机制,挺有意思的,那么他对于这个变种的问题,其实你看往往变种就会是为什么需要三次握手, 

为什么需要四次握手,理解吧,所以这三个过程的话,你要记住,它的目的是为了去建立一个可靠、有序的连接,所以在连接之前,在传递数据之前,先进行网络通畅的一个检查,而这个检查需要有三次的原因,就是第一次请求过去,告诉服务器端要建立请求了,服务器端返回数据告诉我们的客户端代表,请求的链路通畅的,第一步、第二步代表请求没问题,第二步第三步代表响应没问题,这个网络都是通畅的,对吧,代表网络状态正常,那就这个过程才算可靠。

问题29:你有没有测试过RESTFUL接口测试? ---》restful和http接口有什么区别

restful 接口本质就是http接口,restful指的是一种接口设计风格

http 协议---客户端浏览器和服务器按照约定传数据


普通的接口URL对应是某种操作,对数据的操作,切换URL地址,不同的参数
Restful风格的接口-- url对应一条数据,对数据的操作,切换http请求方法实现的


http://192.168.1.110:9991/user/get?uid=2

RESTFUL两大核心特点︰

1、每一个URI代表1种资源;
2、客户端使用GET、POST、PUT、DELETE4个表示操作方式的动词对服务端资源进行操作
GET用来获取资源,
POST用来新建资源(也可以用于更新资源)

PUT用来更新资源
DELETE用来删除资源
 

#新增用户数据
http://192.168.1.110:9991/users


#普通的http接口 -- uid 作为参数
http://192.168.1.110:9991/user/get?uid=1

http://192.168.1.110:9991/user/get?uid=2

Restful ---一个url代表一个资源   资源就是数据
http://192.168.1.110:9991/users/1      ---post请求,会新增一条数据
http://192.168.1.110:9991/users/2     ---get方式,会返回这条数据的内容

http://192.168.1.110:9991/users/3    ---delete 请求,删除这条数据

http://192.168.1.110:9991/users/4    ---put请求,更新这条数据


为什么服务器收到浏览器请求后,知道浏览器要什么数据?

        按照http协议要求,组装一些数据→发送给后妳代码程序【后面就是开发人员的事情】

为什么浏览器能根据服务端返回的不同的内容,做不同的展现

问题30:接口需要登录才能调用,怎么办?  / 如何解决登录问题?

POSTMAN调用一个接口,没有返回东西?

1、检查http响应状态码---
有些接口不是所有人都能够访问
有些接口需要登录:
        1.浏览器访问目标地址
        2.服务器 判断 没有效录   ----》告诉浏览器,你要先登录----》返回302状态码,告诉浏览器,跳转到登录页面【重定向】

cookie ---> cookie如何实现登录?cookie登录原理是什么?
 

1.登录原理

        服务器如何知道一个请求是否已登录

            服务器会去记录一个请求是否登录

                session机制:
                  1.浏览器访问网站的时候---->后台服务器会生成一个sessionld[唯一的字符串】---类似身份证

                  2.服务器 返回给 浏览器---》cookie的形式携带sessionld ---》浏览器自动保存

                 3.登录---》sessionld---》对应到后台系统【记录sessionld】

Cookie是什么?

1.Cookie对象是先由服务器端产生,再发送给客户端(浏览器)的。
2.浏览器会将该Cookie保存在客户端的某个文件中。
        也就是说,Cookie技术能将服务器端的一些数据保存在用户使用的客户端计算机中。
3.后续浏览器发送请求到服务器的时候,会自动携带cookie信息

QQ----两个手机同时登录,自动T下线?

服务器端生成一个通行证 【sessionld】---》通过cookie机制传递,---前端浏览器  ---自动保存起来

接口测试【jmeter、postman、python】调用工具---》一般来说,没有session-cookie自动处理,需要手动处理【编码、修改】

session和cookie协作流程

问题31:高级测试VS初级测试区别

 登录页面   ---  靠你   

功底:测试基本功【入门、进阶、高级、资深】
15k:软件质量

入门--->保障软件基本功能正常使用【有手就行。测试理论+项目实战】

中高级--->高效率的保障软件基本功能正常使用 【自动化技术】
测试开发  ---》功能、性能

美团25k+其他面试题:

1.已知一个ip地址为10.5.136.5。子网掩码为255.255.6%.0他的网络号和主机号分别是?
2.软作则试的目的是什么
3.session 和cookie的区别
4.一个完繁的http清求主要有六个步骤
5.性能测试的方法是什么?
6.代码白盒测试方法

7.软作性统测试的指标
8说了一个场景。让给出sql语句思路
9.问我含用的python第三方的库有哪些
10 根据你的工作经历。说说你对质量保证的理解?
11.在自动化方面有什么成熟的方案。有没有做过二次开发?
12.然,悉Linnx?知道哪些linux命令?
15怎么理解测试开发?为什么选抒测试开发?
16.hr说:你还有什么问题要问我吗?

 

面试套路总结:

1、面试要有亮点

2、引导面试官去了解你,这这是和亮点有点差不多的概念,但是有一点不同的地方叫引导,引导面试官了解一些新的东西,了解你一些新的东西

3、面试题的目的,不是说这东西你不懂,通过面试题把它学懂,不这样子,刷面试题,讲解面试题的目的,是把这个知识以面试表达的形式把它整理出来,让你讲一遍,完了之后,你自己根据实际的面试情况去进行描述表达,这才是我们面试的一个目的

4、面试题最重要的,是向面试官展示---表达技巧、描述方式、把你会的东西用更美好的方式讲出来,把你不会的东西用不会犯错的方式讲出来

5.了解大厂面试流程
6.学会揣摩面试官的问题
7.学会组织思维--应对面试官

8.! !!!面试造火箭,工作拧螺丝!! ! !!

9.传达信号:
        1.我有实战经验,马上能上手;

        2.我自己会写脚本,不会挖坑;

        3.有问题我可以自己解决;

面试官角度看项目经验


1、粗看
简历内容很多、项目也多

2、找亮点
        
1.经验丰富:多是小微系统功能系统,没有体现价值

         2.技术挑战性:只体现了简单的测试,基本没提及高级应用

        3.总结思考:点工“实锤”
3、推敲

        1.有较多重复内容
        2.某些案例太过基础,降低评价

        3.没有突出项目价值,个人价值



准备要点
重点要突出:重点内容要举例描述
信息不冗余:不要全篇反复都在讲几个点,看似内容多、实际无价值
层次要分明:不能简单盘点式的平铺直叙,亮点作为重点表述、低级的内容会起副作用
经得住推敲简历的目的要明确,所有版块整合在一起要经得起推敲
 

  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值