当前位置:   article > 正文

测开——基础理论面试题整理_测开面试题

测开面试题

1. 测试流程

  • 需求了解分析
  • 需求评审
  • 制定测试计划【包括测试人员、时间、每人负责的模块、测试的风险项以及预防】
  • 编写自动化测试用例 —— 测试评审【尽量丰富测试点】
  • 编写测试框架和脚本(若是功能测试 可省去这步骤)
  • 执行测试
  • 提交缺陷报告
  • 测试分析与评审
  • 预发布环境验收测试
  • 提交测试总结
  • 准备下一版测试

2.项目流程

  • 项目立项
  • 需求分析
  • 概要设计
  • 详细设计
  • 编码开发
  • 测试
  • 验收

3.测试过程中发现的印象最深的Bug是什么?

 7.测试资源需求有哪些方面?

  • 人力资源
  • 硬件资源【性能、自动化、功能  服务器 分布式+高并发 】
  • 软件资源【JMeter、postman等等】

8.什么时候进行冒烟测试?

冒烟测试就是完成一个新版本的开发后,对该版本最基本的功能进行测试,保证基本的功能和流程能走通。

冒烟测试也叫版本验证测试、转测测试等。冒烟测试主要是为了确定开发交付的转测物能否正常运行,检查主功能是否能够正常运行,一般有一个人进行短时间的测试判断转测物是否达到转测标准,是否值得进行大规模的测试,冒烟测试中一般不测试次要功能和各种细微错误

9.什么是验收测试,验收测试的目的是什么?

验收测试:一般供求双方达成。一般由用户进行的,确认是否可以接收一个系统的验证性测试,验收测试是根据用户需求,对业务流程进行正式测试,以确保系统符合验收标准。一般由客户、产品经理、测试、项目经理等介入参加,目的在于对系统建立信心,对系统非功能性的特性赢得客户认可【例如:小图标、界面的设计】。

一般有三种验收测试的主体。

α测试:软件的开发商自己进行的交付前的测试

β测试:软件的需求方自己进行的测试

γ测试:第三方的测试

10.测试计划的内容和目的是什么?

测试计划一般包含了产品概述,测试策略【测试方法:功能 自动化 性能】,测试资源,测试周期【时间】,进度安排,测试方法、风险分析等

目的:指导测试过程,规定测试活动的范围,方法,资源进度。明确测试项目、要测试的内容,以及人员责任范围的划分。确保测试工作能够根据计划正常开展。

11.详细说下用例设计的完整过程

  • 通读需求文档,理解需求和设计思路
  • 想好测试策略,确定好测试环境,评估测试周期,确定影响范围
  • 根据需求文档,输出测试点,XMind 包含整个需求相关的测试点及影响范围内的测试内容
  • 根据XMind输出测试用例,利用等价值、边界分析法、场景法确保每个测试点都被测试用例覆盖
  • 进入用例评审阶段,根据评审建议优化我的测试用例
  • 开始执行测试用例

**12.测试中发现了Bug但开发不认为是Bug怎么办?

  • 首先自我分析,是否是自己测试数据错误或者需求理解错误,先确保不是因为自己的问题导致的
  • 如果确定测试数据、操作都没有问题,会先和开发沟通,阐述我的操作和理解以及复现福州,并以需求文档作为佐证,证明Bug的真实性和修复的价值
  • 如果开发不认可,联系产品经理,同时对Bug进行跟进和判断,确定是否为Bug以及后续处理

 13.TCP和UDP协议的区别?

  • 相同点:都工作在传输层,目标都是在程序之间传输数据【大多数情况下使用TCP连接】
  • 不同点:
    • TCP是基于连接的,三次握手【在不可靠的信道上建立可靠的连接】+传输确认【解决了丢包、乱序问题】+四次挥手【关闭连接】;UDP是无连接的,直接进行数据传输
    • TCP是可靠传输【丢包重传机制】;UDP是不可靠传输
    • UDP是面向报文传输,TCP是面向字节流的
    • UDP适合直播,实时游戏等场景

14.怎么定位一个Bug是前端还是后端?

主要通过接口进行判断,产品开发基本是前后端分离的

抓包获取接口信息

1.判断请求接口URL、传参是否正确,页面展示数据异常,数据精度【100.00—> 100】异常的,交互流程异常都是属于前端的Bug

2.接口传参异常、业务处理异常、接口异常报错等错误,基本属于后端的Bug

3.也有时可能为前后端都能处理,要考虑处理成本和影响范围,使用最优解决方案来处理

15.抓包工具、为什么使用抓包工具?

Fiddler、Charles 主要是抓取http协议的接口信息用于辅助测试

用途:

1.从功能测讨的角度来说,通过抓包工具能够查看到页面上未显示的隐藏字段。而这些隐藏字段通常都有一些特的作用,能帮助查看前后端功能是否有异常。

2.通过抓包工具能够详细了解接口信息,方便开展接口或性能测试

3、通过抓包工具能够检查前端传参字段加密是否正确,例如登录的接口 密码是否加密 检查数据加密是否正确,安全行考虑
4、通过抓包也能更对的理解整个系统,通过抓包工具检查接口我能够确定提供接口服务的是哪个后端服务,方便我定位问题及分配bug。
5、基于抓包工具代理的特殊性,我能手动篡改接口请求及返回信息,帮助我提交一些页面上不能构造的数据情况或数据结构,尽可能全面的测试覆盖后端代码逻辑,发现一些隐藏的bug。【不太了解】
6、同时,我也可以通过抓包工具限制网络带宽,构造特殊场景完成一些专项测试,比如说app弱网测试。【例如:APP弱网测试】

17.平时工作中Bug分为哪些等级?

致命、严重、一般、提示

18.如果线上发现了一个较为严重的Bug怎么处理?【当问到这个问题时,面试通过率60%】

首先需要审视Bug的严重程度是否影响大部分用户使用,判断问题的轻重缓急
如果问题非常严重,已经影响了大部分用户的使用,这时候可能需要选择版本回退方案,尽快回复线上环境的正常运行

如果是个别用户收到了影响,就需要开发团队整体上协作,紧急迭代下一个版本上去进行Bug修复,同时对已经产生异常的数据进行修复

Bug解决后,需要进行复盘,分析问题发生的原因,总结经验教训,避免下次错误发生

19.对测试开发的理解以及日常工作


20.为什么选择测开

21.安全方面,了解哪些攻击?



22.http请求过程 session cookie token

域名解析 —> 与服务器建立连接【TCP连接】 —> 发起HTTP请求 —> 服务器响应HTTP请求,浏览器得到html代码 —> 浏览器解析html代码,并请求html代码中的资源(如js、css、图片) —> 浏览器对页面进行渲染呈现给用户



22.1 TCP为什么需要三次握手

通过三次握手可以确定客户端—服务器双方接收数据是否都正常

22.2 TCP协议为什么要四次挥手?

TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式,这就意味着,当主机1发出FIN报文段时,只是表示主机1已经没有数据要发送了,主机1告诉主机2,它的数据已经全部发送完毕了;但是,这个时候主机1还是可以接受来自主机2的数据;当主机2返回ACK报文段时,表示它已经知道主机1没有数据发送了,但是主机2还是可以发送数据到主机1的;当主机2也发送了FIN报文段时,这个时候就表示主机2也没有数据要发送了,就会告诉主机1,我也没有数据要发送了,之后彼此就会愉快的中断这次TCP连接。

22.3 HTTP协议

计算机通过网络进行通信的规则,是一个基于请求与响应,无状态的,应用层的协议,常基于TCP/IP协议传输数据。目前任何终端(手机,笔记本电脑。。)之间进行任何一种通信都必须按照Http协议进行,否则无法连接。
请求与响应:客户端发送数据,服务器端响应数据

无状态的:协议对于事务的处理能力没有记忆

23.http是报文还是二进制

HTTP(超文本传输协议)是一种应用层协议,它是基于文本的协议,使用 ASCII 字符串来进行通信。因此,HTTP是报文格式的,而不是二进制格式的。

HTTP报文由纯文本组成,通常包括请求报文和响应报文两种类型。每个报文都由三个部分组成:起始行、头部字段和消息主体。起始行描述了请求或响应的基本信息,头部字段包含了一系列键值对,描述了报文的属性和特征,消息主体包含了实际的数据内容。

由于HTTP是基于文本的协议,因此它的报文可以直接通过文本编辑器查看和编辑,便于理解和调试。但与二进制协议相比,HTTP的文本格式可能会导致传输效率稍低,因为文本数据需要转换成二进制数据进行传输。

24.cookie是附加在http什么地方

Cookie 是附加在 HTTP 报文的请求头部或响应头部的字段中的一种信息。具体来说,对于客户端而言,Cookie 会附加在 HTTP 请求头部中的 Cookie 字段中;而对于服务器而言,Cookie 则会附加在 HTTP 响应头部中的 Set-Cookie 字段中。

客户端发送请求时,会将之前服务器设置的 Cookie 信息包含在请求头部的 Cookie 字段中,以便服务器能够识别客户端的身份或状态。服务器在收到请求后,会根据 Cookie 字段中的信息进行相应的处理。

服务器在响应中可以通过设置 Set-Cookie 字段来向客户端发送 Cookie 信息,客户端收到响应后,会根据 Set-Cookie 字段中的信息将 Cookie 存储在本地,并在后续的请求中自动附加在请求头部的 Cookie 字段中。

24.请求响应与预期响应不符合怎么排查?

1. 验证测试环境

  • 确保测试环境稳定且配置正确,与预期的测试环境一致。

2. 核对请求参数

  • 仔细检查发送的请求参数是否正确,包括请求头、请求体、URL参数等,确保与API文档或接口规格说明一致。

3. 检查网络连接

  • 确认测试机器与服务器之间的网络连接是通畅的,没有防火墙或网络策略阻止了请求。

4. 复现问题

  • 尝试在不同的环境或使用不同的工具(如Postman、Curl)重复发送相同的请求,看是否能复现问题。

5. 查看服务器日志

  • 检查服务器端的应用日志和错误日志,查找处理该请求时是否有异常抛出或错误记录。

6. 分析响应内容

  • 详细分析实际响应的内容,查看是否有错误代码或错误消息,这些信息可能直接指向问题的原因。

7. 代码审查

  • 对涉及处理该请求的后端代码进行审查,检查业务逻辑处理是否有漏洞或错误。

8. 检查数据依赖

  • 验证数据库或依赖的外部服务中的数据是否正确,确保数据问题没有导致响应异常。

9. 使用抓包工具

  • 使用网络抓包工具(如Wireshark、Fiddler)捕获请求和响应的详细信息,以获得更深入的网络层面的洞察。

25.接口有哪些信息?

  1. 请求方法(HTTP 方法): 定义了客户端如何与服务器进行通信的方式,包括常见的 GET、POST、PUT、DELETE 等方法。

  2. URL(统一资源定位符): 指定了客户端请求的资源的位置。URL 包括协议、主机名、端口号、路径以及查询参数等信息。

  3. 请求头部(HTTP 头部): 包含了请求的元数据,例如身份验证信息、内容类型、预期响应类型等。

  4. 请求体(HTTP 请求体): 对于 POST、PUT 等需要传递数据的请求,请求体中包含了客户端发送给服务器的数据。

  5. 响应状态码(HTTP 状态码): 表示服务器对请求的处理结果的状态码,常见的包括 200(成功)、404(未找到)、500(服务器内部错误)等。

  6. 响应头部(HTTP 头部): 包含了响应的元数据,例如响应的内容类型、内容长度、缓存控制等。

  7. 响应体(HTTP 响应体): 包含了服务器返回给客户端的数据,通常是 JSON、XML、HTML 等格式的文本数据。

  8. 认证信息(Authorization): 如果接口需要进行身份验证,客户端可能需要提供相应的认证信息,例如基本认证、Bearer 令牌等。

  9. 参数(Query Parameters / Path Parameters): 用于指定客户端请求的具体要求或条件,可以包括查询参数、路径参数等。

26.对一个登录界面如何使用白盒和黑盒测试

黑盒测试:主要关注输入和输出,不关注代码内部的逻辑

  1. 功能测试

    • 测试正确的用户名和密码能否成功登录。
    • 测试错误的用户名或密码应被拒绝,并给出适当的错误提示。
    • 测试密码输入错误次数过多时的账户锁定功能。
    • 测试“记住我”功能是否按预期工作。
  2. 边界值测试

    • 测试用户名和密码的最小和最大长度限制。
    • 测试特殊字符在用户名和密码中的处理。
  3. 兼容性测试

    • 测试登录界面在不同浏览器和设备上的显示和行为是否一致。
  4. 安全测试

    • 测试SQL注入、XSS攻击等常见的安全漏洞。
    • 测试输入过滤和验证机制是否有效。
  5. 性能测试

    • 测试登录操作的响应时间和系统的承载能力

白盒测试:白盒测试着眼于程序的内部结构,通过了解代码和内部工作机制来设计测试用例

  1. 逻辑测试

    • 根据登录功能的代码逻辑,测试所有可能的执行路径,确保每个条件分支都被执行到。
    • 检查循环和递归逻辑是否存在潜在的问题。
  2. 代码覆盖测试

    • 使用代码覆盖工具确保登录功能的每行代码都至少执行一次,包括所有的条件分支。
  3. 静态代码分析

    • 使用静态代码分析工具检查潜在的编码问题,如未使用的变量、代码规范不一致、潜在的空指针引用等。
  4. 单元测试

    • 为登录功能的每个模块编写单元测试,特别是关键的业务逻辑部分,如用户认证、会话管理等。
  5. 集成测试

    • 测试登录模块与系统中其他模块(如用户数据库、会话管理、安全模块等)的集成是否无缝。

27.用户名长度使用等价类划分 有效 无效

假设用户名长度不能超过20

  • 等价类 1:有效长度范围内的用户名(6 到 20 个字符)
  • 等价类 2:无效长度范围内的用户名(小于 6 个字符)
  • 等价类 3:无效长度范围内的用户名(大于 20 个字符)

28.http有哪些传输方式?get 和post等

http长连接和短连接

http和rpc的区别

29.token怎么存储,过期了怎么办

30.怎么防止别人用你的token登录

  1. 保护令牌的安全性:

    • 不要将令牌泄露给他人,特别是不要将令牌明文显示在公共场合。
    • 使用安全的存储方式,例如在客户端使用安全的存储机制(如安全的 Cookie、localStorage、sessionStorage)或在服务器端进行安全存储。
    • 仅在安全的环境下使用令牌,避免在不受信任的设备或网络中使用。
  2. 使用短期令牌:

    • 使用短期令牌,并定期更新令牌,以减少令牌泄露的影响时间。
    • 考虑使用单次令牌,每次登录或会话结束后都生成新的令牌。
  3. 限制令牌的使用范围:

    • 限制令牌的使用范围,例如限制令牌只能在特定的设备、IP 地址或用户代理中使用。
    • 限制令牌的访问权限,确保令牌只能访问特定的资源或执行特定的操作。
  4. 使用额外的身份验证机制:

    • 结合其他身份验证机制,如双因素认证(2FA),以增加登录的安全性。
    • 监控和检测异常登录行为,及时发现并阻止未经授权的登录尝试。
  5. 定期审查和更新安全措施:

    • 定期审查令牌管理策略和安全措施,及时更新以适应新的威胁和攻击。
    • 对于安全漏洞或问题,及时采取修复措施,并向用户提供相关的安全建议和指导。

http1.0和http2.0的区别

http和https区别

URL解析

组成:<协议>://<主机>:<端口>/<路径> 注:端口和路径有时可以省略(HTTP默认端口号是80)

https://localhost:8080/index.html?key1=value1&keys2=value2


 

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Li_阴宅/article/detail/809791
推荐阅读
相关标签
  

闽ICP备14008679号