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