每天十道软件测试面试题(二)
每天十道软件测试面试题(二))
1、tcp和udp有什么区别
- udp是无连接的,tcp是面向连接的;
- udp是不可靠传输,tcp是可靠传输;
- udp是面向报文传输,tcp是面向字节流传输
2、cookie、session和token的联系和区别
- Cookies
是服务器生成,保存在本地机器上存储的小段文本,随每一个请求发送至同一服务器,是在客户端保持状态的方案。 - Session
存在服务器端的一种用来存放对象的HashTable结构,是一种保存上下文信息的机制,它通过sessionId来区分不同的客户端,而sessionId是保存在客户端的,做为客户端与服务器的验证标识,它是一个24位的随机字符串,用户每次提交页面时,浏览器都会把这个sessionId包含在HTTP头中提交给WEB服务器。 - Token
token意思是令牌,是用户身份的验证方式。最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名)等元素加密产生的加密字符串。 - cookie和session的区别
存储数据方面:session存储对象,cookie存储String- 存放地址:cookie保存在客户端,session保存在服务端
- Session过多时会消耗服务器资源,大型网站会有专门Session服务器;每个域的Cookie数量和数据大小都是有限的,单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。
- session不区分路径,同一个用户在同一个网站期间,所有的session在任何一个地方都可以访问到。而cookies是区分路径的,如果设置了路径参数,那么同一个网站不同路径下的cookies是互相访问不到的。
- 单点登录中,cookie 被禁用了怎么办?
- 单点登录的原理是后端生成一个 session ID,设置到 cookie,后面所有请求浏览器都会带上cookie,然后服务端从cookie获取 session ID,查询到用户信息。所以,保持登录的关键不是cookie,而是通过cookie 保存和传输的 session ID,本质是能获取用户信息的数据。除了cookie,还常用 HTTP 请求头来传输。但这个请求头浏览器不会像cookie一样自动携带,需手工处理
- Token和session的区别
- session是一种认证方式;token是认证授权的方式,认证是针对用户,授权是针对App,其目的是让 某App有权利访问 某用户 的信息。
- 多数场景上使用 session 会更合理;如果在单点登录(一次性命令认证上),或者第三方共享、允许第三方调用 API 接口,使用 token 会更合适,最好在不同的业务场景中合理选型,才能达到事半功倍的效果。
- Session是存放在服务器端的,可以保存在:内存、数据库、NoSQL中。它采用空间换时间的策略来进行身份识别,若Session没有持久化落地存储,一旦服务器重启,Session数据会丢失。Token是放在客户端存储的,采用了时间换空间策略,它也是无状态的,所以在分布式环境中应用广泛。
3、B/S架构和C/S架构有什么区别
- c/s架构主要应用于局域网内,而b/s架构主要应用于广域网中;
- c/s架构一般面向相对固定的用户群,对信息安全的控制能力很强,而b/s架构对安全的控制能力相对弱;
- B/S架构维护升级比较简单,而C/S架构维护升级相对困难。
4、浏览器中输入url他经历了什么操作
-
1.用户输入URL,会使用浏览器默认搜索引擎加上搜索内容合成url;如果是域名会加上协议(如https)合成完整的url。
-
2.然后按下回车。浏览器进程通过进程间通信把url传给网络进程。(网络进程接收到url才发起真正的网络请求)。
-
3.网络进程接收到url后,先查找有没有缓存。有缓存,直接返回缓存的资源。 没有缓存。(进入真正的网络请求)。
首先获取域名的IP,系统会首先自动从hosts文件中寻找域名对应的 IP 地址,一旦找到,和服务器建立TCP连接;如果没有找到,则系统会将网址提交 DNS 域名解析服务器进行 IP 地址的解析。
-
4.利用IP地址和服务器建立TCP连接(3次握手)
-
5.建立连接后,浏览器构建数据包(包含请求行,请求头,请求正文,并把该域名相关Cookie等数据附加到请求头),然后向服务器发送请求消息。
-
6.服务器接收到消息后根据请求信息构建响应数据(包括响应行,响应头,响应正文),然后发送回网络进程。
-
7.网络进程接收到响应数据后进行解析。如果发现响应行的返回的状态码为301,302,说明服务器要我们去找别人要数据。找响应头中的Location字段要,Location的内容是需要重定向的地址url。获取到这个url一切重新来过。如果返回的状态码为200,说明服务器返回了数据。
-
8.数据传输完成,TCP四次挥手断开连接。如果,浏览器或者服务器在HTTP头部加上如下信息,TCP就一直保持连接。保持TCP连接可以省下下次需要建立连接的时间,提示资源加载速度Connection:Keep-Alive 。
-
9.网络进程将获取到的数据包进行解析,根据响应头中的Content-type来判断响应数据的类型,如果是字节流类型,就将该请求交给下载管理器,该导航流程结束,不再进行;如果是text/html类型,就通知浏览器进程获取到文档准备渲染。
浏览器进程获取到通知之后。新建一个渲染进程。
渲染进程对文档进行页面解析和子资源加载。解析html生成DOM树,解析css生成规则树。
两个树结合生成渲染树(render tree),浏览器会根据渲染树布局,计算css样式,即每个元素在页面中的位置好和大小等信息。最后浏览器绘制各个节点,将页面展现给用户。
5、接口测试怎么做
- 常见的HTTP接口测试工具有Jmeter、Postman
- 接口测试流程:和普通的web测试一样,也是先进行需求分析、测试用例编写、执行测试、提交bug、回归测试、提交 测试报告等。
- 开发接口测试案例的整体方案
- 分析出测试需求,并拿到开发提供的接口说明文档;
- 从接口说明文档中整理出接口测试案例,里面要包括详细的入参和出参数据以及明确的格式和检查点;
- 和开发一起对接口测试案例进行评审;
- 结合开发库,准备接口测试案例中的入参和出参数据,并整理成csv格式的文件;
- 结合接口测试案例文档和csv格式的数据文档,做接口测试案例的自动化案例开发。
2 接口自动化适用场景
6、Python中不那些是可变的数据类型和那些是不可变的数据类型
- 可变的
- 列表
- 字典
- 集合
- 不可变类型
- 元组
- 整数
- 字符串
- 浮点数
- 布尔型
- 元组
7、列表和元组有什么区别,列表和字典有什么区别
- 列表是可变的,而元组是不可变的,这标志着两者之间的关键差异。我们可以修改列表的值,但是不修改元组的值。
- 都是序列
- 都可以存储任何数据类型
- 可以通过索引访问
- 列表有序,要用偏移量定位,
字典无序,通过唯一的键来取值
8、支付功能怎么测(测试思维)
-
测试思维
-
第一步:梳理产品的核心业务流程:明白这是个什么项目,实现了什么业务,以及是怎么实现的?
这个步骤一般是参考公司的需求文档来的,如果产品提供需求文档的同时提供了业务流程图,可以遵循流程图来梳理;如果产品没有提供流程图,就需要测试人员根据需求的理解自己画出流程图,达到梳理业务的目的。 -
第二步:根据流程进行模块细分,然后针对每个功能模块进行详细的测试点设计和提取。
这个单个功能的测试点提取要覆盖一下几个方面:正常功能验证:优先覆盖正常的业务流程和功能验证,这其实也是单个功能的冒烟测试。冒烟测试先行,如果不通过,可以直接停止测试等开发修复后继续测试。
异常功能验证:为了更加贴近用户的使用产经,我们也要验证各种异常的场景,故意操作导致 出错,检查系统的反馈和提示,保证用户操作失误的情况能够得到系统的友好指示。
因为有很多地方的操作都有可能会导致系统异常和抛错,所以为了不漏测,我们需要找出所有可能导致异常的输入项和选项。所以就到了第三步:
-
第三步:针对具体功能,寻找每个输入项和步骤,从以下三个角度来分析测试点 。
长度,数据类型,必填项,重复
需求的约束条件 + 隐形需求
功能之间的交互这其中就需要用到一些用例的具体设计方法了,比如场景法,等价类法,边界值法,错误推测法等等
-
第四步:考虑非功能测试点,包括界面、易用性、兼容性、安全性、性能压力
支付功能的测试点
-
-
支付功能的测试点
基于上面的测试思路,我们可以分析得出“支付功能”测试点如下:-
一、梳理支付的业务流程如下:
点击支付—> 选择支付方式 —> 确认金额—> 输入密码 —> 成功支付完成这个流程测试,也就是完成了项目的冒烟测试!然后需要测试针对流程中的每个阶段和步骤,具体分析可能导致异常的测试点,所以我们按阶段和输入项来进行划分如下:
1)点击支付,提交订单但是取消了,检查可以取消成功
2)选择支付方式:
正常:可以支持的支付方式有:信用卡,储蓄卡,网银支付,余额,第三方支付(微信,支付宝,京东、百度、聚合支付、组合支付),找人代付,验证是否支持并且可以正常选择并支付;
异常: 没有绑定任何的支付方式时,支付报错。
功能交互:支付时结合优惠券/折扣券/促销价抵扣进行相关的抵扣,验证规则正确,并且可以正常抵扣和支付。
3)确认支付金额:这个步骤可以用到等价类和边界值的用例设计方法
正常:正常金额里用边界值法去测试点:
最大支付金额(单日最大,单笔最大,余额最大)
最小支付金额
异常:同样也用边界值方法提取测试点:
超过支付方式单日最大消费金额/单笔最大/余额最大
异常金额支付:非数字、负数、0,小数点超过 2 位等
4)支付密码:
正常:可以支持的支付密码类型有:指纹,人脸识别,账号密码,动态获取验证码,手势,信用卡和支付码,小额免密等,确认自己的产品所支持的密码类型,确认可以验证并支付成功;
异常:输入错误的密码,检查有无提示信息且正确;超过密码错误上限,检查是否冻结等。
5)其他场景测试点:
a、多笔订单合并支付,是否可以成功;
b、重复点击支付按钮,是否会出现多次购买,并同步检查数据库的数据帐账目正确;
c、支付中断:
主动中断:可以继续支付并成功
被动中断:比如电话、低电量、闹钟,断网、切换后台、耳机插拔等,验证可以继续支付;
d、网络测试:
验证各种网络类型:2G、3G, 4G,5G,wifi 下都可以正常支付;
进行网络切换,支付功能正常;
弱网测试下支付功能正常:不会重复支付多次,APP 不会闪退 崩溃,而且页面提示友好;
e、使用 fiddler 等抓包篡改价格:不允许抓包或者数据加密,篡改不成功
-
二、退款流程
正常:验证正常的退款流程,也就是退款的冒烟测试:1、点击退款可以退款成功,并且检查交易状态是退款,退款金额可以到账;
2、结合优惠券等抵扣,可以退款实际支付金额;
3、同步检查数据库的数据和账目是正确的;
异常:提交错误退款(退款订单号不对),或者退款金额错误,都能够退款失败(此处一般会借助工具进行测试,比如进行接口测试);
-
三、测试方法
那么以上的测试点在具体公司项目中要怎么进行测试呢?我们有不同的一些测试方法:1) 小额支付:
需要让开发修改代码,不管支付多少钱,实际支付都是 1 分钱;不顾这种方法只能测试小额支付,就有可能会出现产品小额支付没问题,但是大额支付就错误的漏测情况;
2)申请测试金额:
这种方式一般会作为小额支付的一种补充,比如测试完小额支付后,再测试一些大额支付,这就需要跟公司申请测试基金,走报销流程;
3)沙箱支付:
沙箱支付是一种虚拟的支付,不是真实的金额;这种方法可以验证小额和大额的支付流程;不过目前只有支付宝沙箱比较成熟可用,其他的支付方法不可用。
-
四、非功能测试点
测试完以上的功能测试点之后,我们还需要验证一些非功能测试点,主要包括以下几个方面:1)界面
验证界面的美观,排版和错别字等。
2)兼容性
BS:如果是 BS 架构的产品,需要测试跟浏览器的兼容性;所以就需要根据浏览器的内核,选择一些主流的浏览器进行测试;
CS:如果 CS 架构的产品,测试手机移动端的兼容,比如手机型号,系统版本和屏幕大小及分辨率等。
3)易用性
测试站在用户的角度考虑用户体验,使用是否方便等。
4)性能
比如考虑多用户支付,长时间运行等,关注产品的响应时间等,一般需要借助工具或者代码进行测试。
5)安全
验证敏感信息是否加密,是否可以篡改;通过一些工具进行安全扫描,检查是否有安全漏洞;或者采用一些其他的手段进行专门的安全测试。
-
9、没有接口文档如何做接口测试
- 首先去跟开发沟通,是否真正没有编写接口说明文档或者存在相关的设计文档,如果真是没有,可以推动一下是否可以进行补充(站在开发的角度进行沟通)
- 如果存在前端界面,通过抓包工具进行抓包,整理出接口相关信息,与开发进行沟通是否存在遗漏
不存在前端界面,有代码能力,直接去查看开发代码实现,获取接口信息 - 将整理的接口信息,编写出对应的接口测试用例
使用接口测试工具,执行测试用例,例如:Postman或Jmeter - 记录测试结果,存在问题及时与开发沟通
提交缺陷,开发修改之后进行回归测试
测试完成提交测试报告 - 做接口测试项目复盘,主要推动开发对接口文档重要性
10、怎么设计接口测试用例
-
接口逻辑测试是指根据业务逻辑、输入参数、输出值的描述,对正常输入情况下所得的输出值
-
是否正确的验证,需要覆盖到接口实现的所有业务场景。
-
其他测试点
-
例如需要登录状态(以token为例,token为空、错误的token、失效的token)。
-
参数异常情况
-
必填项验证
参数的长度、类型、格式异常:
常规参数:(数字、字符串、日期)
参数长度:6-18位。或身份证、电话的长度。
参数类型:数字(精度),字母,中文,带空格的参数,特殊字符、NULL。
日期格式:年月日,年月日时分秒,日期格式(包括/,-,:等)。
错误码异常覆盖
-
-
其他的关注点补充
- 接口有翻页时,页码与页数的异常值测试
- 数据库的增删改查后,接口数据是否保持一致性
- 类似文件地址接口,需要查看返回的地址是否可以打开下载
- 所有列表页接口必须考虑排序值
- 所有功能都要考虑兼容旧版本