1. 测试是什么#

测试是验证软件是否满足预期，重点在于发现实际结果和预期结果之间的差异。

例如：

• 预期点击“保存”后成功返回，实际点击后无响应，这是功能缺陷。
• 预期 2 秒内完成加载，实际 30 秒才展示，这是性能缺陷。
• 预期字段展示完整清晰，实际按钮错位、文案错误，这是 UI 缺陷。

2. 质量是什么#

质量不只是“测出来”，更重要的是“预防出来”。

• 测试：发现缺陷，验证功能。
• 质量：提前规避问题，降低风险。
• 需求评审：从源头发现遗漏和歧义。
• 代码规范：减少低级错误和风格混乱。

所以，质量工作一定要左移，越早介入越便宜。

1. 黑盒测试#

黑盒测试把系统当作一个“输入-输出盒子”，不关心内部代码细节，只关注功能对不对。

适合场景：

• 登录
• 注册
• 查询
• 下单
• 支付
• 权限控制

核心思路：

• 输入什么
• 触发什么操作
• 期望得到什么结果

这类测试适合从用户视角验证核心业务是否可用。

2. 集成测试#

集成测试不是单独验证某个函数，而是验证模块之间是否协同工作。

常见两类：

• 单服务内部集成：Controller、Service、DAO 之间是否串得起来。
• 跨服务集成：接口调用、消息队列、共享存储、第三方系统之间是否联通。

集成测试特别适合发现以下问题：

• 接口字段不一致
• 状态流转断裂
• 事务边界不清
• 配置错误
• 数据依赖缺失

如果业务涉及支付、库存、优惠券、退款、审批流、状态机，集成测试一定要重点覆盖。

3. 自动化测试#

自动化测试适合稳定、重复、高频的验证场景，不适合经常变化或一次性的探索性验证。

推荐遵循测试金字塔：

• 单元测试最多：执行快、定位准、成本低。
• 接口自动化居中：验证服务行为和数据契约。
• UI 自动化最少：维护成本高、稳定性相对弱。

可以把它理解为：

• 越底层，越应该多写。
• 越靠近界面，越应该少而精。

常见工具示例：

• JUnit / TestNG：单元测试
• RestAssured / Postman + Newman：接口测试
• Selenium：Web UI 自动化
• Appium：移动端自动化
• JMeter：性能压测

1. 什么是缺陷#

实际结果和预期结果不一致，就是缺陷。

缺陷可能出现在多个阶段：

• 需求阶段：需求本身不清晰、不完整。
• 设计阶段：方案不合理、遗漏边界。
• 开发阶段：实现错误、异常处理不全。

常见缺陷类型：

• 功能缺陷
• UI 缺陷
• 性能缺陷
• 安全缺陷
• 兼容性缺陷

2. 提 Bug 的目的是什么#

提 Bug 不是为了“证明自己发现了问题”，而是为了让问题更快地被定位、被修复、被追踪。

一个好的 Bug 报告，至少要做到四件事：

• 让问题可复现
• 让开发能快速定位
• 让团队能判断优先级
• 让后续可以追溯记录

3. 推荐的 Bug 模板#

建议使用 Given -> When -> Then 描述法：

1
标题：支付成功后订单状态未更新
2

3
前置条件：
4
1. 用户已登录
5
2. 账户余额充足
6
3. 存在待支付订单 ORD-001
7

8
复现步骤：
9
1. 打开订单详情页
10
2. 点击“确认支付”
11
3. 完成支付
12
4. 返回订单页查看状态
13

14
预期结果：
15
订单状态变为“已支付”，金额扣减成功
16

17
实际结果：
18
订单仍显示“待支付”，但余额已扣减
19

20
附件：
21
截图、请求参数、响应结果、日志时间点

4. 严重程度和优先级不要混为一谈#

• 严重程度：问题本身有多严重，偏客观。
• 优先级：团队要多快处理，偏主观。

常见理解：

• S1：核心功能不可用，必须立刻处理
• S2：主流程受影响，尽快处理
• S3：一般问题，可排期修复
• S4：轻微问题，体验优化类

而优先级通常会结合上线时间、影响范围、业务价值综合判断。

1. 一条测试用例至少要包含什么#

一条可执行、可回放、可复核的测试用例，至少要包含：

• 用例编号
• 用例标题
• 所属模块
• 前置条件
• 测试数据
• 操作步骤
• 预期结果
• 实际结果
• 执行状态

最小必备版可以记成：

编号 + 标题 + 前置条件 + 步骤 + 预期结果

2. 常用用例设计方法#

1. 需求评审重点看什么#

需求评审不是开发快做完了才参与，而是从需求阶段就介入。

至少看三件事：

• 需求是否可测试
• 需求是否有遗漏
• 需求是否合理

可以直接追问这些问题：

• 我怎么知道它做完了？
• 我怎么验证它是对的？
• 空状态怎么展示？
• 错误状态怎么处理？
• 没数据怎么办？
• 接口超时怎么办？
• 是否存在角色差异、权限差异、端差异？

一个很实用的经验是：

需求阶段发现问题的修复成本，远低于开发后、测试后、上线后的修复成本。

2. 服务端系统分析要输出什么#

对于稍复杂的需求，后端至少要补齐以下分析输出：

• 架构设计
• 业务流程设计
• 技术方案
• 模块划分
• 流程图、时序图、链路图
• 数据库表设计
• 配置设计
• 接口设计：URL、请求体、返回结构、错误码
• 状态机设计
• 资金流转设计

还要补上“三板斧”：

• 监控
• 灰度
• 应急预案

如果是订单、支付、库存、营销、结算类系统，状态流转、幂等性、补偿机制、对账策略必须单独分析。

3. 前端系统分析要输出什么#

前端分析文档不应该只写“做一个页面”，还应该明确：

• 页面字段映射
• 页面状态和状态切换
• 交互流程
• 组件拆分
• 空态展示
• 错误态展示
• 加载态展示
• 权限控制
• 设计稿还原边界

如果需求里只写“展示一个列表”，评审时要继续追问：

• 列表为空怎么办
• 加载失败怎么办
• 超长文本怎么处理
• 多终端样式是否一致

1. 先写单元测试，再做开发#

好的开发习惯不是“代码写完顺手测一下”，而是：

1. 先理解需求
2. 先设计测试点
3. 先写关键单元测试
4. 再实现代码
5. 最后做回归验证

这样做的好处是：

• 需求理解更清晰
• 边界条件更容易提前暴露
• 重构时更有安全感
• 回归成本更低

2. 使用 AI 生成单元测试#

AI 很适合帮助生成单元测试骨架，但前提是上下文给得足够完整。

给 AI 的输入建议包含：

• 技术栈和测试框架
• 目标类和方法
• 正常流程
• 异常流程
• 边界条件
• 依赖如何 Mock
• 断言风格要求

例如：

1
你是一个 Java 测试工程师，请为后端项目编写 JUnit 5 单元测试。
2

3
要求：
4
1. 使用等价类划分和边界值分析设计测试用例
5
2. 覆盖正常流程、异常流程和边界情况
6
3. 每个测试方法必须有断言
7
4. 依赖使用 Mockito 进行 Mock

注意两点：

• AI 生成的测试不等于测试设计完成，仍然需要人工补全关键断言。
• 不要把关键代码压缩成过短摘要再丢给 AI，否则很容易遗漏上下文和真实风险。

3. AI 做第一轮，人工做最后一轮#

AI 很适合做第一道质量防线：

• 检查代码规范
• 扫描空指针、异常处理遗漏
• 发现重复代码
• 提醒缺少参数校验
• 发现简单的接口契约问题

人工 Review 更擅长：

• 业务理解
• 架构判断
• 跨模块影响分析
• 风险取舍
• 经验传递和团队培养

比较务实的分工是：

• AI 做第一轮：快、全、标准一致
• 人工做第二轮：看业务、看架构、看取舍