测试面试经验1
6. 自动化编写规范
自动化编写规范核心是保证脚本的可读性、可维护性、稳定性，主要包括：
- 命名规范：用清晰的英文命名（如
test_login_success），避免拼音 / 缩写，变量 / 函数名体现用途； - 代码结构：模块化设计（如页面封装 POM 模式），分离测试用例、元素定位、业务逻辑；
- 元素定位：优先用 ID/Name/ 数据属性（如
data-testid），避免 XPath 绝对路径或易变的 Class； - 等待机制：禁用强制等待（
sleep），优先显式 / 智能等待，避免元素未加载导致失败； - 异常处理：捕获常见异常（如元素不存在、超时），添加重试机制；
- 日志与报告：输出关键步骤日志，集成 Allure 等报告工具；
- 复用性：封装公共方法（如登录、数据生成），避免重复代码；
- 版本控制：通过 Git 管理脚本，标注用例覆盖场景
7. UI 自动化的页面加载等待逻辑
UI 自动化的等待逻辑是为了避免 “元素未加载完成就操作” 导致的失败，主要分四类：
- 强制等待（Sleep）：固定时间等待（如
sleep(3)），简单但低效，易因网络波动失效； - 隐式等待：全局设置超时时间（如 Selenium 的
implicitly_wait(10)），在查找元素时自动等待，缺点是无法区分 “元素存在但不可点击”； - 显式等待：针对特定元素设置条件（如 “元素可点击”“文本出现”），超时后抛异常（如 Selenium 的
WebDriverWait），精准且灵活； - 智能等待：Playwright 等框架内置的自动等待，操作元素前会检查可见性、可操作性，无需手动设置。
8. Playwright 框架和 Selenium 框架的区别
| 维度 | Selenium | Playwright |
|---|---|---|
| 架构 | 基于浏览器驱动（多进程通信） | 直接与浏览器内核通信（单进程） |
| 自动等待 | 需手动设置显式 / 隐式等待 | 内置智能等待（操作前自动检查元素状态） |
| 浏览器支持 | 主流浏览器，但移动端支持弱 | 支持 Chrome/Firefox/Safari，含移动端仿真 |
| 录制功能 | 需插件（如 Selenium IDE） | 内置codegen命令，一键生成脚本 |
| 执行速度 | 相对较慢（驱动通信开销） | 更快（无中间层） |
| 并发测试 | 需手动管理线程 | 原生支持多浏览器 / 多页面并发 |
| 语言支持 | Java/Python/C# 等 | Python/Java/JS/Go 等 |
9. AI 需求测试与其他需求的区别
AI 需求测试因模型的不确定性、数据依赖性，与传统需求测试差异显著：
- 测试对象：传统测试针对 “功能逻辑”（确定输入→确定输出）；AI 测试针对 “模型能力”（输入相同可能输出不同）；
- 数据依赖：AI 测试需覆盖海量 / 边缘数据（如噪声数据、极端场景），传统测试只需验证用例数据；
- 评估指标：传统测 “功能是否实现”，AI 测 “准确率、召回率、推理速度、鲁棒性”；
- 黑盒特性：AI 模型内部逻辑不可见（黑盒），难以追踪缺陷根因；传统软件逻辑透明；
- 伦理安全：AI 需测试偏见（如性别 / 种族歧视）、数据隐私泄露，传统需求无此维度；
- 动态性：AI 模型迭代后需重新测试（数据漂移影响效果），传统软件版本稳定后测试成本低。
10. 多问题解答
（1）输入 URL 到页面展示的阶段
- DNS 解析：将域名（如
www.baidu.com）转为 IP 地址； - TCP 连接：通过三次握手建立浏览器与服务器的连接；
- HTTP 请求：浏览器发送请求（请求行、头、体）；
- 服务器响应：服务器处理请求并返回 HTML/CSS/JS 等资源；
- 浏览器解析渲染：
- 解析 HTML 生成 DOM 树，解析 CSS 生成 CSSOM 树；
- 合并生成渲染树，计算布局（Layout）；
- 绘制（Paint）像素到屏幕；
- JS 执行：若有 JS 脚本，通过 JS 引擎执行并修改 DOM/CSSOM。
POST /api/login HTTP/1.1 请求行
下面四行key：value是请求头
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0.0.0
Content-Type: application/json
Content-Length: 45{请求体"username": "test","password": "123456"
}（2）TCP 三握四挥
-
三次握手（建立连接）：
- 客户端→服务器：发送 SYN 包（请求建立连接）；
- 服务器→客户端：回复 SYN+ACK 包（同意连接）；
- 客户端→服务器：发送 ACK 包（确认连接）；
目的：确保双方收发能力正常，避免无效连接。
-
四次挥手（断开连接）：
- 客户端→服务器：发送 FIN 包（请求断开）；
- 服务器→客户端：回复 ACK 包（确认断开请求）；
- 服务器→客户端：发送 FIN 包（准备断开）；
- 客户端→服务器：回复 ACK 包（最终确认）；
目的：确保双方数据都传输完毕，避免数据丢失。
（3）MySQL 和 Redis 区别
| 维度 | MySQL | Redis |
|---|---|---|
| 类型 | 关系型数据库（SQL） | 内存键值数据库（NoSQL） |
| 存储介质 | 磁盘为主，内存为辅 | 内存为主，支持持久化到磁盘 |
| 数据模型 | 表结构（行 / 列）、关系约束 | 字符串 / 哈希 / 列表等多样结构 |
| 事务特性 | 支持 ACID 事务 | 弱事务（仅保证单命令原子性） |
| 适用场景 | 存储结构化数据（如用户信息） | 缓存、高频读写（如秒杀计数） |
（4）Redis 阻塞主进程的命令
Redis 主进程是单线程，以下操作会阻塞：
- 高复杂度命令：
KEYS *（遍历所有键）、FLUSHDB/FLUSHALL（清空库）、SORT（排序）、ZRANGEBYSCORE（大偏移量查询）； - 大集合操作：
SMEMBERS（返回大集合所有元素）、HGETALL（获取大哈希所有字段）； - 慢查询命令：对超大键的增删改查（如
DEL一个百万元素的集合）； - 持久化相关：
BGSAVE时的fork()操作（短暂阻塞）、AOF重写的fork()； - 长时间 Lua 脚本：执行复杂 / 死循环的 Lua 脚本。