1、黑盒测试、白盒测试、灰盒测试的区别

黑盒测试：

黑盒测试就是不看程序源代码，根据需求文档进行功能测试，验证输入输出是否符合预期结果；常用的方法有：等价类、边界值、场景法

白盒测试：

白盒测试，也称为结构测试，根据代码内部逻辑设计测试用例，检查代码有没有漏洞、逻辑错误；常用方法有：代码检查法、逻辑覆盖法、基本路径测试等

灰盒测试：

介于黑盒测试和白盒测试之间，不关注前端页面源码和底层代码实现，主要围绕接口和数据库开展测试。测试时通过调用接口传入参数，校验接口返回数据，同时核对数据库落地数据是否正确。常用于接口测试和集成测试。

2、单元测试–>集成测试–>系统测试–>验收测试

参考文章：

https://blog.csdn.net/qq_41539778/article/details/131087735

https://www.cnblogs.com/R-bear/p/17786698.html

单元测试：就是测单个函数、单个方法；白盒测试，开发自测代码

集成测试：模块和模块之间靠接口传数据，集成测试主要就是测接口，大多数基于灰盒测试

系统测试：全模块拼好，业务功能测试，基于黑盒测试方法。

验收测试：是以用户为主的测试，软件开发人员和质量保证人员也应参加，由用户参加设计测试用例，使用用户界面输入测试数据，并分析测试的输出结果。

3、如何定位前后端bug

参考文章：https://blog.csdn.net/weixin_40772077/article/details/138048778

1、前后端bug特点

• 前端bug：界面相关、布局相关、兼容性相关、交互相关
• 后端bug：数据相关、安全性下相关、逻辑相关、性能相关

2、前后端bug区分

• 如果是抓不到请求或者是请求参数有误–>则是前端bug
• 如果抓到请求并且请求正确，但是没有响应或者相应错误 -->则是后端bug
• 如果抓包有响应并且响应正确，但是页面显示报错 -->则是前后bug

3、后端bug定位

• 查看报错日志，通过日志进行分析问题点
• 查看数据库确认数据是否正确
• 查看缓存是否正确

4、B/S架构和C/S架构

参考文章：https://blog.csdn.net/Zhang5801/article/details/104416812

B/S架构

全称Browser/Server架构，也就是浏览器/服务器结构，将应用程序的核心功能和数据处理逻辑放在服务器端，用户则通过浏览器来访问和使用这些功能（此时浏览器充当了客户端）。

C/S架构

全程Client/Server架构，即客户端/服务器结构，App安装在手机上就是一个客户端，它向后台服务器请求数据、提交信息。

比如：电脑版 QQ、桌面端进销存软件、PC 客户端游戏，软件安装在本地设备，负责页面展示 + 大部分业务逻辑（胖客户端）：

• 大量业务代码、页面渲染逻辑全写在客户端安装包里面（APP / 桌面程序体积大）；
• 客户端既要画界面，又要算业务规则，还要拼接 SQL 和数据库打交道；

C/S 是两层客户端服务器架构，分为客户端、服务端；服务端分数据库直连、Socket 通信两种；属于胖客户端架构，绝大多数业务逻辑、界面都在客户端实现，客户端通过 SQL 或 Socket 和服务端交互数据。

---

python中数据类型——可变/不可变

变量的类型：可变、不可变

可变：表示内存中的数据可以修改

• 列表list
• 字典dict
• 集合set

不可变：表示内存中的数据不允许被修改

• 数字类型：int、float、bool
• 字符串：str
• 元组：tuple

集合和元组的区别
元组不可变、有序、可重复、支持索引
集合可变、无序、自动去重、不支持索引

---

TCP和UDP的主要区别是什么？

区别 ：TCP面向连接、可靠、有序、有流量控制；UDP无连接、不可靠、无序、但效率高。

TCP（面向连接、可靠、有序、较慢）：用在需要数据完整、准确、不丢失的地方

• 网页浏览（HTTP/HTTPS）：网页内容必须完整加载，不能缺图片或文字。
• 电子邮件（SMTP/POP3/IMAP）：邮件内容不能丢。
• 文件传输（FTP、SFTP）：文件少一个字节都可能损坏。
• 数据库连接（MySQL、PostgreSQL等）：查询结果必须准确。
• 远程登录（SSH、Telnet）：每一条命令都要正确执行。
• 微信/QQ的文字聊天、文件发送：消息不能丢，顺序不能乱。

---

UDP（无连接、不可靠、无序、但速度快、延迟低）：用在允许偶尔丢包、但要求实时性高的场景

• 实时音视频通话（微信语音/视频、Zoom、Skype）：偶尔卡一下或雪花点可接受，但延迟必须低。
• 直播（抖音、B站直播、斗鱼）：丢掉几帧画面观众基本无感，但卡顿会导致体验差。
• 在线游戏（FPS、MOBA类，如《英雄联盟》《绝地求生》）：玩家位置、射击等操作必须快速送达，偶尔丢一个位置包可以预测补偿。
• DNS域名解析：查询一个域名，发一个UDP包，如果没回应就重试，简单快速。
• SNMP（简单网络管理协议）：监控设备状态，允许少量丢失。
• DHCP（动态获取IP地址）：电脑开机时广播请求IP，用UDP效率高。

---

补充：有些软件会两者结合

• 微信/QQ：文字消息用TCP（可靠），语音/视频通话用UDP（实时）。
• BT下载：控制信息用TCP，实际数据传输有时用UDP（如µTP协议）。

TCP：要完整，不着急（网页、邮件、文件）。
UDP：要快，不怕丢（语音、视频、游戏）。

TCP/IP协议

参考文章：https://blog.csdn.net/weixin_53186633/article/details/120514627

TCP/IP协议主要由网络层的IP协议 和 传输层的TCP协议组成 。

TCP负责发现传输的问题，一有问题就发出信号，要求重新传输，直到所有数据安全正确地传输到目的地。而IP是给因特网的每一台联网设备规定一个地址。

TCP协议

TCP协议是传输控制协议，工作在传输层。提供面向链接的，可靠的传输服务（三次握手，四次挥手）

• 面向链接：数据传输之前，客户端与服务器之间要建立连接，才可以传输数据
• 可靠的：数据传输是有序的，要对数据进行校验，数据不会丢失

UDP协议

UDP协议：用户数据报协议，提供的是不可靠的，面向无连接的传输服务（只有数据的发送方和接收方）

• 面向无连接：传输方和接收方不需要建立连接，在传输数据之前没有明确的连接链路（即不是所有的数据都是通过一条链路传输）

• 不可靠：因为数据的传输不是通过一条链路完成的，因此接收方接收的数据不一定按照发送数据的顺序接收，这样就可能造成数据包的丢失

  传输方和接收方不需要建立连接，用于对数据实时性和安全性不高的场合。可以用于视频会议。

5、项目临上线发现影响体验的bug，开发没时间、PM不在，怎么办？

答案参考：https://blog.csdn.net/qd_lifeng/article/details/146985171

1.立即确认和复现bug，记录详细的信息

2.评估bug的优先级和严重性：影响核心功能（如无法发送消息）vs 轻微体验（如按钮颜色不对）。若致命bug，必须推迟上线。

bug严重级
- 致命级（如崩溃、数据丢失、核心功能失效）：必须修复，可能需延迟上线。
- 严重级（非核心功能异常）：评估修复时间和风险。
- 一般级（UI问题、边缘场景）：权衡是否紧急修复或后续处理。
- 风险评估：修复该BUG是否会引入新风险？是否有临时规避方案？

3.同步信息：如果产品经理不在，可以找产品或者上级进行沟通，开发没有时间，如果对bug评估后需要紧急修复的，就和开发沟通是否能协调时间先修复bug

4.配合修复与验证，开发修复完bug之后，对bug进行回归测试，确保bug完全修复

5.事后复盘与改进，为什么会出现这种情况，是否用测覆盖不全？

6.项目上线前3天，每天写一篇风控报告，怎么写？

风控报告 = 识别质量风险 + 给出应对措施 + 跟踪风险状态。我会按时间递进来写。

第一天：风险识别与基线报告

• 标题：《XX项目上线前72小时质量风控报告 v1》
• 内容：
  1. 当前bug情况：严重bug数量、待修复列表、解决率趋势
  2. 测试完成度：功能覆盖率、场景覆盖率、自动化通过率、性能测试结论
  3. 高风险点：比如支付模块改动、第三方SDK升级、弱网场景未覆盖
  4. 建议措施：
     • 冻结非紧急需求合入
     • 对高风险模块安排专人专项回归
     • 准备降级/回滚预案
  5. 风险等级：高/中/低（给出评估依据）

第二天：风险状态更新与应对进展

• 新增：
  1. 前一天遗留bug的修复情况，新增bug数量
  2. 重点回归结果（高风险模块是否通过）
  3. 新发现风险：比如性能压测发现某个接口在峰值下延迟超标
  4. 调整措施：增加灰度范围、建议后端扩容
  5. 给决策者（PM/技术负责人）的建议：是否如期上线，或需要部分功能降级

第三天：最终上线前风险评估

• 内容：
  1. 所有阻塞级bug已清零，已知遗留低概率或轻微体验问题清单（附上原因和用户影响评估）
  2. 线上监控方案是否就绪（关键指标、报警阈值、日志）
  3. 紧急联系人名单、回滚方案确认
  4. 最终结论：可上线 / 有风险但可控（需伴随灰度） / 建议延期
  5. 上线后24小时内的跟进计划

关键：每天报告要简洁、有数据、有结论、有可执行的下一步，而不是流水账。

7. 从用户角度测试抖音视频

播放体验、交流互动、内容推送、性能与资源：流量、电量、无障碍、关爱模式

8.如果发现领导给的流程不太合理，你会怎么办？

我会先确认自己是否完全理解了流程背景。如果确实不合理，就基于数据评估问题（如耗时、效率、质量影响），准备对比分析和改进建议，找合适时机与领导沟通，先肯定初衷再提议小范围试运行。
如果领导坚持，我会先执行，同时持续记录痛点，后续再用数据推动优化，并在自己权限内做局部微调。

9.了解过自动化测试吗？了解PO模式吗？

了解，并且在web项目测试中落地实现了

PO模式是UI自动化测试中的一种设计模式，即页面对象设计模式，它的核心思想是将页面封装成类，页面上的元素定位和操作方法都封装在该类中。

这样做的好处是：

• 可维护性高：页面元素一旦发生改变，只需修改对应的page类
• 复用性强：多个用例可以共享同一个页面的操作方法
• 可读性好：测试用例只调用方法，清晰易懂

10.测过APP吗，APP测试和web测试的区别

简单测过，区别在于：

• 框架不同：APP使用的是C/S框架、WEB使用的是B/S框架
• 传输数据不同：APP前后端交互的数据格式是以json为主的，而WEB前后端交互的数据格式为JSON/HTML等都有
• 测试范围不同：app测试还有专项测试（安装卸载更新、手机型号、版本兼容性测试、push消息推送、交叉事件、用户体验等）、web测试还有浏览器兼容性测试、易用性测试等

11.一个流程如何去设计测试用例

以账号密码登录流程为例简单说明：

1. 梳理流程：打开登录页→输入账号密码→点击登录→跳转首页；分支：清空输入、输错信息、网络断开、点击返回等。
2. 拆分节点：账号输入框、密码输入框、登录按钮、返回按钮。
3. 设计用例：
   • 正向：输入正确账号密码，正常登录；
   • 反向：账号 / 密码为空、输入超长字符、错误账号密码；
   • 流程异常：点击登录中途断网、输入一半返回上一页、连续多次点击登录按钮。

12.如何处理临时新增的紧急需求

第一，先快速对接产品、开发，吃透新增需求，明确改动点、关联模块、预期上线时间，评估测试范围和工作量。

第二，梳理自己手上正在进行的任务，分清优先级，和组长沟通协调，把非紧急任务延后，集中精力处理新需求。

第三，测试时抓重点，优先测核心功能、改动点以及受影响的关联模块，用例侧重主流程和高频异常，精简冗余用例，提升效率。

第四，测试完成后及时同步结果，若时间紧张，会和团队确认风险、做好备注。上线之后我也会重点做线上巡检，一旦发现问题立刻跟进修复。

13.bug开发没有进行修复但是着急上线，怎么和开发沟通

先明确bug等级和影响面。然后找开发沟通：

• 用事实说话：“这个bug影响用户支付成功率约5%，如果不修，上线后预计每天造成xxx单失败。”
• 给出折中方案：能否加配置开关临时屏蔽该功能？或者后端hotfix？或者在前端加提示/降级方案？
• 确认时间：问他最快多久能修？如果1小时内能修，我等他，再回归。
• 风险共担：如果实在不修，我会要求开发签字确认风险，并在上线报告中注明已知问题，同时建议灰度发布、加强监控。
  沟通时保持尊重，目标是解决问题，不是指责。

14.需求怎么划定测试范围

先精读需求，明确新增、修改的功能点，再顺着业务和数据流向，找出联动的模块、接口。区分必测、选测和无关模块，最后和产品、开发确认范围，避免漏测或重复测试。

15.偶发性bug怎么处理？

1. 记录现场：立刻截屏、录屏、抓日志、记下操作步骤和环境信息（时间、网络、设备、账号）。
2. 尝试复现：大概定位范围、记录出现频次，并评估重要程度
3. 提bug，清晰描述bug信息
4. 可以找开发查看日志记录，分析bug信息
5. 再次出现时，保留现场，让开发进行解决
6. 如果在上线前无法解决，需要想项目负责人抛出风险，评估之后决定是否上线
   • 如果决定上线，那么将风险点在测试报告上详细说明，并跟踪手机上线后的情况信息
   • 如果决定先修复再上线，那么提交bug后指配给开发进行修复

16. HTTP中4开头的状态码和5开头的状态码介绍

• 4xx：请求信息错误
  • 400：请求参数错误
  • 401：登录失效/未登录
  • 403：登录了但是没有权限访问
  • 404：资源不存在
  • 405：请求方式错误（预期是get方式，实际用成了post）
  • 429：请求过多
• 5xx：服务器端错误
  • 500：通用服务器错误，例如后端代码出错
  • 502：网关错误
  • 503：服务不可用，例如过载、维护
  • 504：网关超时

17.Linux怎么修改权限？777是什么意思？

使用chmod命令

777分别代表文件所有者、用户组、其他用户的权限

7表示：4（读r）、2（写w）、1（执行x）

18.selenium元素定位方式

ID、NAME、CSS_SELECTOR、LINK_TEXT、CLASS_NAME、XPATH

xpath定位方法：

• 绝对路径
• 相对路径+属性：//标签[@属性=‘值’]
• 文本匹配：//*[text()=‘内容’]

19.使用id定位无法定位到元素可能的问题？xpath定位页面修改后无法成功定位如何解决？

1. id定位失败：
   • 没有切换iframe
   • 页面未渲染完成
   • 有遮罩层（点击后toast弹窗遮挡）
   • id是动态生成的，每次刷新发生变化
2. xpath定位：
   • 避免使用绝对路径，使用相对xpath，例如//div[@class=‘content’]
   • 使用更稳定的属性组合
   • 使用css_selector代替xpath通常更稳定

20.缺陷提交到平台之后，是有哪几种状态，修改为fixed之后，在确认的时候发现还是有bug，那这时候状态要怎么修改

缺陷提交后，常规流转状态主要有新建、指派、修复中、已修复、重新打开、关闭，还有延期、作废这类辅助状态。
当开发修复完成，将 bug 状态改为 Fixed 后，我会执行复测。如果复测发现问题依然存在，不会直接关闭，而是把缺陷状态重新打开，详细备注复测情况和问题现象，再重新指派给开发，让其继续处理。等后续彻底修复、复测通过后，再把状态改为关闭。