bigbiggirl

WEB端面试题

1、测试中你认为是bug,而开发并不认为是bug,你会如何解决?

开发人员说不是bug,有2种情况,一是需求没有确定,所以我可以这么做,这个时候可以找来产品经理进行确认,需不需要改动,3方商量确定好后再看要不要改。二是这种情况不可能发生,所以不需要修改,这个时候,我可以先尽可能的说出是BUG的依据是什么?如果被用户发现或出了问题,会有什么不良结果?程序员可能会给你很多理由,你可以对他的解释进行反驳。如果还是不行,那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug,我也只是建议的方式写进TD中,如果开发人员不修改也没有大问题。如果确定是bug的话,一定要坚持自己的立场,让问题得到最后的确认。

 

 

2、给你一个网站如何测试?

首先,查找需求说明、网站设计等相关文档,分析测试需求。

制定测试计划,确定测试范围和测试策略,一般包括以下几个部分:功能性测试;界面测试;性能测试;数据库测试;安全性测试;兼容性测试

设计测试用例:

功能性测试可以包括,但不限于以下几个方面:

链接测试。链接是否正确跳转,是否存在空页面和无效页面,是否有不正确的出错信息返回。

提交功能的测试。

多媒体元素是否可以正确加载和显示。

多语言支持是否能够正确显示选择的语言等。

界面测试可以包括但不限于一下几个方面:

页面是否风格统一,美观

页面布局是否合理,重点内容和热点内容是否突出

控件是否正常使用

对于必须但未安装的控件,是否提供自动下载并安装的功能

文字检查

性能测试一般从以下两个方面考虑:

压力测试;负载测试;强度测试

数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性,对数据的存取操作,数据内容的验证等方面。

安全性测试:

基本的登录功能的检查

是否存在溢出错误,导致系统崩溃或者权限泄露

相关开发语言的常见安全性问题检查,例如SQL注入等

如果需要高级的安全性测试,确定获得专业安全公司的帮助,外包测试,或者获取支持

兼容性测试,根据需求说明的内容,确定支持的平台组合:

浏览器的兼容性;

操作系统的兼容性;

软件平台的兼容性;

数据库的兼容性

开展测试,并记录缺陷。合理的安排调整测试进度,提前获取测试所需的资源,建立管理体系(例如,需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容)

定期评审,对测试进行评估和总结,调整测试的内

 

 

 

3、购物车功能如何测试?

. 验证购物车界面设计

界面设计验证点如下:

1.界面设计是否美观,显示是否正常

2.界面布局是否合理

3.购物车入口数量设计是否合理(购物车需要引导用户付款,入口设计需要有此体现)

4.购物车图标链接显示是否明显

5.鼠标悬停购物车图标,是否有迷你购物车界面,显示是否正常

. 购物车功能测试

功能测试可以分为两个部分,验证内容如下:

• 1.购物车基本功能

– 添加商品

1.是否能够添加商品

2.添加单个商品数量是否有上下限

3.添加商品种类是否有上下限

4.添加同类型商品的不同规格商品显示是否分条显示

5.加入购物车商品排序是否合理

• 删除商品

1.能否删除单类商品

2.是否有快速删除多种商品方式(全选,删除)

3.删除商品是否有确认提示

• 跳转商品详情

1.跳转商品图片显示是否正常

2.跳转商品链接显示内容是否完整,是否过长

3.点击图片或者链接是否能够跳转商品详情

•编辑商品数量

1.是否有通过+ -编辑商品数量方式

2.是否有通过输入直接编辑商品数量方式

3.编辑商品数量是否有上下限

4.编辑商品数量是否考虑库存情况

• 显示商品数量,金额,总额等

1.商品加入购物车内是否和原价格一致

2.商品数量显示是否正确

3.选择商品总数是否正确

4.选中商品价格总额是否正确

•进入商品购物或结算

1.购物车是否有进入购物链接

2.购物车是否有进入结算链接

• 2.购物车业务功能

– 购物车与用户模块关联

1.未登录用户是否可以添加商品到购物车

2.未登录用户添加商品到购物车,登录后是否将商品合并到用户购物车

3.若不允许未登录用户添加商品到购物车,点击加购物车后是否有登录提示

4.用户有会员折扣时,购物车内商品价格是否对应

• 购物车与商品订单模块关联

1.加入购物车商品有价格调整,购物车内商品价格是否跟随变化

2.加入购物车商品,库存变化时购物车是否有对应调整

3.购物车商品确认订单后是否会从购物车清除

4.订单价格是否与购物车内一致

• 购物车与优惠活动模块关联

1.商家发放用户优惠券购物车对应变化

2.商品满减活动,购物车价格对应变化

. 购物车非功能

界面显示设计

购物车功能

–购物车基本功能

–购物车业务关联

购物车非功能

– 性能

– 兼容性等

购物车非功能测试可以从多方面进行考虑,举出部分进行说明,验证内容如下:

• 1.性能

1.进入购物车页面 消耗时长

2.添加商品到购物车时长

3.进入购物车结算时长

4.对购物车页面内容变更,页面内容更新速度。(增加某个购买数量,页面对应显示更新速度)

• 2.兼容性

1.不同设备上显示和使用是否正常

2.不同浏览器显示和使用是否正常

  

4、美团的登录界面如何测试?

功能测试
  1. 什么都不输入,直接点击提交按钮,看提示信息
  2. 输入正确的用户名和密码,点击提交按钮,看是否能登录成功
  3. 输入错误的用户名或者错误的密码,点击提交按钮,看提示信息
  4. 登陆成功之后能否正确的跳转到正确的页面
  5. 用户名太短或者太长时,应该怎么处理
  6. 密码太短或者太长时,应该怎么处理
  7. 用户名若含有特殊字符,字母,数字等不同于汉字的,应该怎么处理
  8. 密码若含有特殊字符,字母,数字,或者混合类型时,密码强度的变化
  9. 用户名和密码中间出现空格时,会怎么处理
  10. 用户名和密码前后出现空格时,会怎么处理
  11. 记住用户名或者记住用户名和密码的功能(比如刚刚登陆成功之后退出,再次登陆时是否有记录
  12. 验证首次打开登录界面,鼠标的输入焦点是否在用户名的输入框以方便用户直接输入
  13. 密码的加密显示(如星号或者小黑点)
  14. 牵扯到验证码的登录时,要考虑图片上的数字是否扭曲过大导致看不清楚,数字的颜色(考虑色盲患者),验证码的刷新按钮是否有效
  15. 登录界面上的注册,忘记密码,退出登录点击后,链接是否有效
  16. 输入密码时,切换为大写时是否有提醒
  17. 布局是否合理,两个文本框的位置是否对齐,按钮的位置是否合理
  18. 文本框的长度宽度是否合理,按钮的大小是否易于点击
  19. 界面是否简介易懂,是否有错别字
  20. 打开该登录页面需要多久
  21. 登录成功跳转到正确的界面时需要多久
  22. 用户名和密码是否通过加密的方式发给web服务器
  23. 用户名和密码是否是在服务端完成验证的,不能只在客户端调用JavaScript来进行验证
  24. 两个文本框应禁止输入脚本语言,防止XSS攻击
  25. 限制错误登录的次数,防止暴力破解
  26. 考虑多用户在一台机器上登录
  27. 考虑一用户在多台机器上登录
  28. 输入用户名和密码时常用快捷键在输入文本框中能否使用(ctrl+c,ctrl+v,ctrl+a等)
  29. 输入正确的用户名和文本框之后按回车是否可以登录
  30. 输入用户名之后按Tab键是否可以转到密码输入框
  31. 在主流的浏览器上是否可以正常使用(如IE,谷歌等)
  32. 在不同的平台上是否可以正常使用
  33. 在移动设备上是否可以正常使用(iPhone,Android)
界面测试
性能测试
安全测试
可用性测试
兼容性测试
本地化测试

不同语言环境下能否正常运行

 

5、给你一个水杯、电梯如何测试?

功能度:用水杯装水看漏不漏;水能不能被喝到

安全性:杯子有没有毒或细菌

可靠性:杯子从不同高度落下的损坏程度

可移植性:杯子在不同的地方、温度等环境下是否都可以正常使用

兼容性:杯子是否能够容纳果汁、白水、酒精、汽油等

易用性:杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档:使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试:将杯子盛上水(案例一)24小时检查泄漏时间和情况;盛上汽油(案例二)24小时检查泄漏时间和情况等

压力测试:用根针并在针上面不断加重量,看压强多大时会穿透

 

电梯测试:

功能测试—单个功能:

1、电bai梯内分楼层键是否正常

2、电梯内开关门键是否正常

3、电梯内的报警键是否正常使用

4、电梯外的上下键是否正常

5、同时关注显示屏,电梯内外的显示屏显示的电梯层数、运行方向是否正常

6、有障碍物时,电梯门的感应系统是否有效

功能测试—逻辑业务/功能交互

1、功能与功能模块间的集成,可根据电梯当前状态是上行、下行还是停止来设计测试点,以保证覆盖率

电梯当前状态是上行时,有人在X楼按下上升/下降键,电梯是否会停止

电梯当前状态是下行时,有人在X楼按下上升/下降键,电梯是否会停止

在搭载满员的情况下,如有人在X楼按下上升/下降键,电梯是否会停止

2、功能设备与设备间的集成,关注功能接口,比如:

电梯和大楼层,电梯和摄像头,电梯与空调,电梯和对讲机(报警装置),电梯与显示屏,电梯与其他电梯的协作能力

例如:一栋楼有2部电梯,一部停在2楼,一部停在4楼,有人1楼按电梯,是否2楼的电梯下降到1楼开

界面测试

1、查看电梯的外观,按钮的图标显示,电梯内部张贴的说明(比如报警装置的说明、称重量等)

易用性测试

1、楼层按键高度(小孩和一些身高矮的用户会按键不方便)

2、电梯是否有地毯、夏天是否有空调、通风条件、照明条件、手机信号是否通畅

3、电梯是否有扶手,是否有专针对残疾人的扶手等等

兼容性测试

1、电梯的整体和其他设备的兼容性,与大楼的兼容,与海地隧道的兼容等等

2、不同类型的电压是否兼容

安全性测试

1、下坠时是否有制动装置

2、暴力破坏电梯时是否报警,超重是否报警

3、停电情况下电梯是否有应急电源装置

性能测试

1、测试电梯负载单人时的运行情况(基准测试)

2、多人时的运行情况(负载测试)

3、一定人数下较长时间的运作(稳定性测试)

4、更长时间运作时的运行情况(疲劳测试)

5、不断增加人数导致电梯报警(拐点压力测试)

 

6、测试策略的含义:黑盒测试、白盒测试、功能测试、接口测试、性能测试?

白盒测试:逻辑覆盖、循环覆盖、基本路径覆盖

黑盒测试:边界值分析法、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试、场景法

功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。

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

 

7、你们项目的测试流程是什么?

需求分析-》需求说明书/原型-》前后端编码-》两端联调-》测试-》用户验收测试-》申请上线,确认上线时间-》预发布测试-》上线

 

8、测试计划、测试用例、测试需求、测试报告、上线报告,分别包含什么内容?

测试计划包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。

测试用例包含用例编号、所属模块、测试标题、重要级别、前置条件、操作步骤、输入数据、预期结果

 

9、你们的测试方法是什么?如何保证覆盖率?

功能测试常用方法:等价类、边界值、错误推测法、因果图、判定表等;

测试用例覆盖率很难达到100%,越复杂的功能越难保证,只能说尽量提高测试覆盖率。
通过以下手段可以提高覆盖率:
1、编写测试用例前,检查相关需求需求、设计文档是否有问题(功能描述不清,设计逻辑缺陷),如有问题找相关设计或者开发问清楚。
2、然后整理成需要覆盖的功能列表或者思维导图,功能列表包含新增和修改功能点,性能需求也要列出来(因为要整理对应的性能测试用例),同时还需要对既有功能进行一个梳理,检查是否会与其他功能有交互,整理出影响点。
3、把功能列表发给组员,并找时间进行会议评审,主要对功能等进行查漏补缺。
4、最后才行进测试用例编写,注意编写规范。
5、编写完毕后,把测试用例发给组员,开会进行评审,主要对检查点、用例规范进行查漏补缺。
6、执行测试用例过程中,发现用例不完善或者错误,需对测试用例进行及时的修改与调优
7、测试完毕后对漏测的bug进行测试用例补充。

 

 

10、如何评判测试用例写的好不好?是否做测试用例评审?评审人员有哪些?

1、测试用例书写格式正确、描述清晰, 其他测试人员拿到测试用例可以在不询问写作人的情况下正常执行下去,(简单来说, 其他人能看懂,能执行) 

2、测试用例对测试点覆盖完全,也就是说测测过程中发现的问题基本都是通过测试用例发现的,发现的比例越高越好, 越高说明测试用力的防护能力越强,当然测试用例不可能特别完备,在我们执行测试用例的过程,如果bug不是通过用例发现,我们需要对用例进行增加,这样我们下一次就可以把这个问题给防护住。(但是不是所有的bug都需要增加测试用例)(简单说就是bug尽可能都是测试用例发现的) 

3、测试用例所属功能上线后,用户反馈好,说明测试用例关注的点都是用户care的点

有做测试用例评审;评审人员包括测试人员、开发人员、产品

 

11、什么是静态测试、动态测试、α测试、β测试、上线测试、回归测试?

静态测试是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。

动态测试是实际运行被测程序,输入相应的测试实例,检查运行结果与预期结果的差异,判定执行结果是否符合要求,从而检验程序的正确性、可靠性和有效性,并分析系统运行效率和健壮性等性能。

黑盒测试一般用来确认软件功能的正确性和可操作性,目的是检测软件的各个功能是否能得以实现,把被测试的程序当作一个黑盒,不考虑其内部结构,在知道该程序的输入和输出之间的关系或程序功能的情况下,依靠软件规格说明书来确定测试用例和推断测试结果的正确性。

白盒测试根据软件内部的逻辑结构分析来进行测试,是基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般盒测试由项目经理在程序员开发中来实现。

α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

 

12、研发部有多少测试、开发,你们的上线标准是什么?

3个测试25个开发(前端15、后台10)

上线标准:内部测试通过后会通知用户验收,验收通过后申请上线,通过申请后会在预发布环境继续进行一轮测试,然后才正式上线;

 

13、支付接口如何测试?具体每个阶段如何执行?

一:从功能方面考虑:
1)、正常完成支付的流程;

2)、支付中断后继续支付的流程;

3)、支付中断后结束支付的流程;

4)、单订单支付的流程;

5)、多订单合并支付的流程;

6)、余额不足;

7)、未绑定银行卡;

8)、密码错误;

9)、密码错误次数过多;

10)、找人代付;

11)、弱网状态下,连续点击支付功能功能,会不会支付多次;

12)、有优惠券、折扣、促销价进行结算是否正确;

13)、不同终端上支付:包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等;

14)、不同的支付方式:银行卡网银支付、支付宝支付、微信支付等;

15)、支付失败后,再次支付。

2、从性能方面考虑:
多个用户并发支付能否成功;

支付的响应时间;

3、从安全性方面考虑
使用Fiddler拦截订单信息,并修改订单金额,或者修改订单号,(下两个订单A,B,付款时拦截订单B,并把订单B的订单号改为A订单的订单号)无法完成支付;

4、从用户体验方面考虑
是否支持快捷键功能;

点击付款按钮,是否有提示;

取消付款,是否有提示;

UI界面是否整洁;

输入框是否对齐,大小是否适中等。

5、兼容性
BS架构:不同浏览器测试。

APP:不同类型,不同分辨率,不同操作系统的手机上测试

  

14、如何设计测试用例?

根据需求规格和菜单树得出基本功能测试用例;

边界值测试用例

容错测试用例

并行测试用例

交叉测试用例

兼容测试用例

极限测试用例

 

15、缺陷优先级?严重程度?上线前还有缺陷如何解决?公司用的缺陷管理工具是什么?

缺陷严重程度(优先级):致命(紧急)、严重(高)、一般(中)、轻微(低)、建议

缺陷严重程度由高到低:1.致命---->系统中断、死机、程序崩溃

                  2.严重错误---->主要功能实现或者所实现的功能与需求不一致

                  3.一般错误---->非主要功能实现错误...

                  4.轻微错误---->不会影响正常的软件使用

                  5.文字错误---->描述不清晰、文字对齐方式...

                  6.建议性------>非缺陷

缺陷优先级由高到低:1.非常高---->主要功能错误或引起系统崩溃、数据丢失的缺陷

                 2.---->严重影响系统功能和性能的缺陷

                 3.---->影响系统功能的一般缺陷

                 4.---->对软件质量影响非常轻微或者出现几率很低的一些缺陷

https://wenku.baidu.com/view/746d6ad6a5e9856a57126046.html

 

16、自动化测试是如何开展的?流程是怎样的?你们的自动化测试脚本是怎样维护的?

遵循软件开发的基本规则,按照软件开发生命周期来弄:

a. 需求概述   

制定自动化测试需求分析说明书

b. 制定自动化测试计划

c. 制定自动化测试方案

d. 自动化测试用例设计或从功能测试用例中挑选适合的用例

e. 自动化脚本的开发

f. 自动化测试执行,生成报告

根据自动化测试计划中指导,按照时间的要求执行所有自动化测试内容,并生成自动化测试结果,分析自动化测试需求覆盖率,自动化测试效果,生成报告。

https://blog.csdn.net/ricky_yangrui/article/details/89052372

 

17、如何进行断言?

断言 ,预期结果与实际结果对比

数据库校验,根据测试场景来查询数据库里的数据和请求之前的数据进行比对

 

18、json和字典有什么区别?

字典是python的基础数据类型

 json 本质上还是字符串,只是按 keyvalue 这种键值对的格式来的字符串

 

19、元组和列表有什么区别?

列表

方括号,可以添加,删除,或者是搜索列表中的项目。由于可以增加或删除项,可以说列表是可变的数据类型,即这种类型是可以被改变的。

元组

圆括号元祖和列表十分相似,不过元组是不可变的。不能修改元组。元组通过圆括号中用逗号分隔的项目定义。

 

20、自动化中如何使用多个浏览器测试?如何捕获错误信息?

当然可以,我写的用例可以在在IE,火狐和谷歌这三种浏览器上运行。实现的思路是封装一个方法,分别传入一个浏览器的字符串,如果传入IE就使用IE,如果传入FireFox就使用FireFox,如果传入Chrome就使用Chrome浏览器,并且使用什么浏览器可以在总的ini配置文件中进行配置。需要注意的是每个浏览器使用的驱动不一样。

 

21、日志级别有哪些?会发送邮件吗?如何通过测试报告定位具体的问题出在哪里?

日志等级从低到高:

DEBUG  程序调试运行时使用

INFO    程序正常运行时使用

WARNING程序未按预期运行时使用,但并不是错误,如用户登录密码错误

ERROR   程序出错误时使用,如:IO操作失败

CRITICAL 特别严重的错误,导致程序不能再继续运行时使用,如磁盘空间为空

 

22、如何保证系统稳定性?

保证测试用例覆盖率、不同环境保证代码运行正常、上线后也要测试

23、验收测试你们是如何做的?

 

APP端面试题

1、APP测试主要从哪些方面考虑的?

1UI测试

2、功能测试

3、健壮性测试

4、适配

5、稳定性测试

6、性能测试

7、回归测试

8、上线测试

 

2、APP测试中,iosAndroid有怎样的区别?

1Android长按home键呼出应用列表和切换应用,然后右滑则终止应用;

2、多分辨率测试,Android20多种,ios较少;

3、机操作系统,Android较多,ios较少且不能降级,只能单向升级;新的ios系统中的资源库不能完全兼容低版本中的ios系统中的应用,低版本ios系统中的应用调用了新的资源库,会直接导致闪退(Crash);

4、操作习惯:AndroidBack键是否被重写,测试点击Back键后的反馈是否正确;应用数据从内存移动到SD卡后能否正常运行等;

5push测试:Android:点击home键,程序后台运行时,此时接收到push,点击后唤醒应用,此时是否可以正确跳转;ios,点击home键关闭程序和屏幕锁屏的情况(红点的显示);

6、安装卸载测试:Android的下载和安装的平台和工具和渠道比较多,ios主要有app storeiTunestestflight下载;

7、升级测试:可以被升级的必要条件:新旧版本具有相同的签名;新旧版本具有相同的包名;有一个标示符区分新旧版本(如版本号),对于Android若有内置的应用需检查升级之后内置文件是否匹配(如内置的输入法)

另外:对于测试还需要注意一下几点:

1、 并发(中断)测试:闹铃弹出框提示,另一个应用的启动、视频音频的播放,来电、用户正在输入等,语音、录音等的播放时强制其他正在播放的要暂停;

2、 数据来源的测试:输入,选择、复制、语音输入,安装不同输入法输入等;

3push(推送)测试:在开关机、待机状态下执行推送,消息先死及其推送跳转的正确性;应用在开发、未打开状态、应用启动且在后台运行的情况下是push显示和跳转否正确;推送消息阅读前后数字的变化是否正确;多条推送的合集的显示和跳转是否正确;

4、分享跳转:分享后的文案是否正确;分享后跳转是否正确,显示的消息来源是否正确;

5、 触屏测试:同时触摸不同的位置或者同时进行不同操作,查看客户端的处理情况,是否会crash

 

3、APP兼容性如何测试?若无真机,如何测试?是否有使用过云测试?

我们公司就买了, 魅族, 华为, 小米, iphone7、 iphone8 、 iphone8plus 、 iphone x 测试兼容性,有些没有的机型,先借用同事的手机进行测试,同时申请公司购买,或者采用云真机。

  

4、APP兼容性和机型如何进行选取?

1android设备众多,怎么挑选(不同类型设备)

根据现有市场占有率数据,挑选出top n款手机,溶蚀挑选部分使用较少的手机进行验证

2、同一android设备,存在多种操作系统版本,如何保证测试覆盖全面(不同操作系统版本)

测试设计过程中考虑每个版本差异,并给出差异分析报告。优先满足每款手机主流操作系统

做一些调研,当前市场各版本和品牌的使用率

 

接口测试面试题

1、HTTPHTTPS有什么区别?

https协议需要到CA(Certificate Authority,证书颁发机构)申请证书,一般免费证书较少,因而需要一定费用;
http是超文本传输协议,信息是明文传输,Https协议是由SSL+Http协议构建的可进行加密传输、身份认证的网络协议,比http协议安全;
http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443;

 

2、Sessioncookie有什么区别?

cookie 数据保存在客户端,session 数据保存在服务器端;

cookie 可以减轻服务器压力,但是不安全,容易进行 cookie 欺骗;

session 较安全,但占用服务器资源

 

3、你们的接口测试有几套环境?不同环境如何进行处理?

两套  不同环境的接口和url等信息可直接放在yaml文件中,在不同文件直接更改配置文件即可

 

4、有关联的数据如何处理进行调用?

把上一个请求返回的结果传入到下一个请求的参数中,将请求的结果反射到一个类属性(使用setattr()函数),下一个请求去调用这个类属性

 

5、TCP/IP协议是什么?

HTTP协议:超文本传输协议,用于普通浏览

HTTPS协议:安全超文本传输协议,身披SSL外衣的HTTP协议

FTP协议:文件传输协议,用于文件传输

POP3协议:邮局协议,收邮件使用

SMTP协议:简单邮件传输协议,用来发送电子邮件

Telent协议:远程登陆协议,通过一个终端登陆到网络

SSH协议:安全外壳协议,用于加密安全登陆,替代安全性差的Telent协议

 

6、接口测试如何做?流程是怎样的?

1)发送接口请求
2)测试接口获取返回值
3)断言:判断实际结果是否符合预期

 

7、如何定位接口的问题?

接口问题一般就是一些业务逻辑的处理问题了或者设计金额计算的问题,小数点取舍的问题

举例:拿一个计算金额的来举例。首先要F12看下,页面输入值和接口的入参是否一致,不一致说明前端传值有问题。了解金额的最后处理是在前端还是后台,然后查看取舍的结果。如果是前台计算,就查一下后台返回的计算数据是否有问题,然后看前端计算是否有问题。如果是后台计算就看接口的业务逻辑,服务器日志,计算方式,等号包含的情况,小数点取舍问题,在哪一步进行取舍。

 

8、你觉得开展接口自动化的意义是什么?价值在哪里?

引用自动化测试之后,能代替大量繁琐的回归测试工作,把业务测试人员解放出来,既而让业务测试人员把精力集中在复杂的业务功能模块上,自动化测试一般是对稳定下来的功能进行自动化,保证不会因为产品的更新导致之前稳定下来的功能出现BUG。

Linux

1、进程方面、打包、解压、权限、top相关命令

数据库:

1、数据查询关键字是什么?多表查询关键字是什么,原理是什么?

性能测试:

1、性能测试如何开展?由谁做?流程是怎样的?

2、具体如何设计性能测试场景?

3、你们的并发用户数是多少?系统承载用户数是多少?并发用户量是多少?

4、如何分析性能的结果报告?

5、常见的性能指标有哪些?TPSQPS是什么意思?

 

 

面试题:https://www.cnblogs.com/mrgavin/p/14148100.html

分类:

技术点:

相关文章: