每天十道软件测试面试题（二）

每天十道软件测试面试题（二）)

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。
    日期格式：年月日，年月日时分秒，日期格式(包括/,-,:等)。
    错误码异常覆盖

• 其他的关注点补充

  • 接口有翻页时，页码与页数的异常值测试
  • 数据库的增删改查后，接口数据是否保持一致性
  • 类似文件地址接口，需要查看返回的地址是否可以打开下载
  • 所有列表页接口必须考虑排序值
  • 所有功能都要考虑兼容旧版本