测试（面经 八股）

目录

前言

一，软件测试（定义）

1，定义

2，目的

3，价值

4，实践

二，软件测试（目的）

1，找 bug

2，验证达标

3，质量评价

4，避免风险

三，测试分类

1，按阶段划分

Ⅰ 单元测试

Ⅱ 集成测试

Ⅲ 系统测试

Ⅳ 验收测试

2，按方法划分

Ⅰ 黑盒测试

A. 等价类

B. 边界 

C. 错误推测

D. 因果图

E. 判定表

F. 正交

G. 功能图 

H. 场景设计

Ⅱ 白盒测试

A. 代码检查 

B. 静态结构分析

C. 静态质量度量

D. 逻辑覆盖 

Ⅲ 灰盒

3，按类型划分

Ⅰ 功能

Ⅱ 性能

Ⅲ 界面

Ⅳ 可靠性

Ⅴ 配置

Ⅵ 兼容性

Ⅶ 易用性

Ⅷ 安全

四，测试流程

1，需求分析 

2，需求评审

3，测试计划 

4，测试用例设计

5，用例评审 

6，实施测试 

7，回归测试 

8，测试报告

五，测试报告

1，关键要素

2，5C标准：高质量缺陷报告

3，常见问题

4，面试深度

六，测试策略

1，分层 + 上下游

2，左移

3，右移

4，回归测试

七，测试原则

1，需求出发

2，尽早开始

3，避免开发自测

4，终止条件

---

前言

目录来源于以下文章，初始链接牛客，第二链接ceshiren

软件测试/游戏测试/测开能投吗？（非科班秋招经验总结）_牛客网

软件测试/游戏测试/测开能投吗？（非科班秋招经验总结） - 面试专辑 / 面经汇总 - 爱测-测试人社区

一，软件测试（定义）

1，定义

在软件开发的各个阶段，

通过人工或自动化，对软件系统的功能，性能，安全，兼容性等方面，

进行验证和确认，以发现软件中的 bug，

以便提升用户体验，并降低软件上线后的风险和商业损失

2，目的

① 发现缺陷：尽早，尽可能多的发现 bug，包括功能性，性能，安全性，易用性

② 质量保障：确保质量达到语气标准，减少因为 bug 产生的投诉，数据丢失，系统崩溃

③ 风险控制：提前识别 / 规避，潜在的商业风险，避免软件故障带来的经济损失，名誉受损

④ 用户体验：模拟真实用户场景，优化影响体验的问题，提高用户满意度

3，价值

① 预防 > 补救，测试不只是找 bug，还要在开发早期介入，推动需求，设计评审，预防 bug

② 衡量和反馈，测试时的缺陷数据，覆盖率，通过率，可以为项目决策提供量化依据

③ 团队协作，测试和开发，产品，运维协作，推动问题闭环

4，实践

① 全流程介入：优秀的测试团队，会在需求，设计，开发，上线各个阶段参与，进行需求评审，代码走查，持续集成测试

② 自动化 / 工具化：强调自动化测试（单元测试，接口测试，UI 自动化），持续集成 CI，持续交付 CD，提升测试效率和覆盖率

③ 用户视角 / 业务理解：

a. 测试中，最重要的就是，对整个业务流程的理解

b. 比如电商下单，从用户下单，到加入购物车，到待付款，到付款，到商家接单，到商品出货，再到物流配送，快递配送，直到最终送达用户手中的整个流程

c. 整个业务流程，核心场景，边界条件等，怎么发现隐藏的高风险问题

二，软件测试（目的）

软件测试的目的，不只是为了找 bug，还要保障软件质量，验证需求，识别和规避风险，推动团队协作和流程优化，最终实现产品高质量交付和用户满意度的提升

1，找 bug

① 核心：尽早，尽可能多地发现 bug，包括功能 / 性能 / 安全 / 兼容性

② 定位：不但要发现 bug，还要协助开发定位和复现问题，提供详细的 bug 报告，便于修复

③ 预防：通过前置的需求评审，提前发现潜在 bug，降低后期成本

2，验证达标

① 需求一致：保证软件实现和需求说明书，产品原型，用户场景的一致，防止“需求漂移”或“功能遗漏”

② 验收标准：详细的测试用例和验收标准，验证每个功能，每个业务流程，都符合预期

③ 用户视角：除了文档需求，还要关注用户的真实使用场景 / 隐性需求，发现需求文档未覆盖的边界和异常情况

3，质量评价

① 多维度：除了功能的正确性，还有性能（响应时间 / 并发能力），安全性（数据泄露 / 越权访问），可用性（易用 / 界面友好），兼容性（多平台 / 多浏览器）

② 质量度量：通过缺陷密度，覆盖率，回归缺陷率，量化软件质量

③ 持续优化：测试结果为开发，产品，运维等提供反馈，推动流程和产品的优化

4，避免风险

① 识别：借助测试，识别出高风险模块，关键路径，易出错场景，提前优化代码

② 规避：通过回归测试，压力测试，安全测试等，降低软件上线的故障率

③ 业务连续性保障：对核心业务流程，支付，数据一致性，进行重点测试

三，测试分类

1，按阶段划分

Ⅰ 单元测试

① 定义：验证软件中最小的可测试单元（函数 / 方法 / 类）

② 目标：验证单元模块的功能实现，是否符合设计和需求，及时发现底层逻辑错误

③ 主体：由开发编写，测试参与代码走查和用例设计

④ 关注点：输入输出的正确性 + 边界 + 异常 + 分支覆盖率

⑤ 实践要点：自动化集成到 CI 流程；使用 Mock 隔离外部依赖；追求高覆盖率；更重视关键路径 + 高风险逻辑

⑥ 常用工具：JUnit(Java)，pytest(Python)

Ⅱ 集成测试

① 定义：将多个单元模块，按要求组装在一起，验证它们之间的接口 / 交互 / 数据流

② 目标：发现模块间接口 / 数据传递 / 依赖关系等集成层面的问题

③ 主体：开发测试共同参与

④ 关注点：接口调用的正确性 + 数据流的完整性 + 外部依赖（数据库 / 第三方服务）

⑤ 实践要点：分阶段集成（增量集成 / 非增量集成） + Mock模拟来隔离未完成模块 + 自动化接口测试

⑥ 常用工具：Postman

Ⅲ 系统测试

① 定义：集成测试后，将整个软件系统作为一个整体，基于需求说明，进行全面验证

② 目标：验证系统的功能 / 性能 / 安全 / 兼容性，是否满足业务需求和用户场景

③ 主体：测试负责

④ 关注点：全业务流程 + 核心场景；非功能性需求（性能 / 安全 / 兼容性）；系统边界，异常场景

⑤ 实践要点：黑盒测试为主 + 端到端测试 + 自动化和手动结合

⑥ 常用工具：Selenium，JMeter，Appium

Ⅳ 验收测试

① 定义：用户基于业务需求和合同约定，对系统进行验收

② 目标：确认软件是否达到交付标准，能否投入生产环境，满足用户实际业务需求

③ 主体：用户 / 产品经理

④ 关注点：关键业务流程 + 核心功能；用户体验 + 易用性；合同 / 需求文档的验收标准

⑤ 实践要点：用户可接受的测试环境，和生产环境高度一致；业务场景和用户操作为主；验收标准可量化

⑥ 常用工具：Alpha 测试（内部用户），Beta测试（外部用户），灰度发布

2，按方法划分

Ⅰ 黑盒测试

黑盒测试，不考虑程序内部结构和实现细节，只关注输入输出，验证软件功能

强调 “用户视角” 的测试，关注功能 + 业务流程 

A. 等价类

① 定义：所有可能的输入划分为若干等价类，每个等价类是等效的，只需选取代表性的测试

② 适用：输入域较大，或无法穷举

③ 要点：有效 + 无效等价类；覆盖所有等价类

④ 举例：年龄输入框，合法范围 18-60，小于 18，18-60，大于 60，非数字

B. 边界 

① 定义：针对输入 / 输出的边界测试

② 适用：输入有明确范围

③ 要点：边界本身 + 边界内外

C. 错误推测

① 定义：基于测试的经验和对业务流程的理解，推测可能出错的地方，设计测试用例

② 适用：复杂业务 / 历史遗留系统 / 缺乏需求文档

③ 要点：结合以往缺陷 + 常见错误形式 + 边界 + 异常场景

④ 举例：输入 nullptr，特殊字符，超长输入，重复提交

D. 因果图

① 定义：输入和输出的关系，用图形表示

② 适用：输入条件复杂，条件组合多

③ 要点：列出所有输入 / 输出 + 绘制因果图分析条件之间的关系 + 转换判定表

④ 举例：登录功能中，输入用户名 / 密码 / 验证码，缺一不可

E. 判定表

① 定义：多条件，多动作的业务规则，用判定表表示

② 适用：业务规则复杂，条件组合多，比如审批流 / 计费规则

③ 要点：明确所有条件和可能的取值 + 构建判定表列出所有条件组合，以及对应的动作

④ 举例：订单优惠规则中，满减 / 折扣 / 会员价，多条件组合

F. 正交

① 定义：覆盖所有因子和水平的组合，减少用例数量的同时，保证覆盖率

② 适用：输入参数较多，组合爆炸的场景，比如配置测试，兼容性测试

③ 要点：确定参数因子和水平取值 + 选择正交表 + 适合大规模测试

④ 举例：浏览器（Chrome，IE，Firefox），操作系统（Win，Mac，Linux），分辨率（1080p，2K，4K）等组合测试

G. 功能图 

① 定义：建立系统的状态转移图，分析不同输入下，系统状态的变化，设计覆盖所有状态和转移的测试用例

② 适用：系统有明显状态变化（工作流 / 订单状态 / 权限切换）

③ 要点：所有状态和转移条件(路径) + 异常状态和非法转移

④ 举例：订单从 “待支付” 到 “已支付” 再到 “已发货” 最后到 “已收货”，以及异常取消

H. 场景设计

① 定义：基于用户实际业务流程和典型使用场景，端到端，验证系统在真实场景的表现

② 适用：复杂业务流程，跨模块集成，用户体验测试

③ 要点：业务流程为基础 + 用例覆盖主流程 / 分支流程 / 异常流程 + 跨系统

④ 举例：电商下单中，商品浏览 / 加入购物车 / 下单 / 支付 / 发货 / 收获 / 评价的全流程

Ⅱ 白盒测试

对程序内部结构和实现逻辑，有所了解，设计用例并验证

强调 “从代码视角” 出发，关注测序的内部流程 / 分支 / 路径 / 数据流

主要用于发现代码层面的逻辑错误，分支遗漏，异常处理失败

A. 代码检查 

① 定义：人工检查源代码，发现缺陷 / 规范性问题 / 安全隐患

② 适用：开发阶段 + 代码合并前 + 关键模块上线前

③ 要点：关注代码规范 / 可读性 / 可扩展性 + 检查逻辑错误 / 内存泄露 / 安全漏洞 + 结合自动化工具和人工走查

B. 静态结构分析

① 定义：静态分析工具对代码结构进行分析，不用运行程序就能发现潜在问题

② 适用：大规模代码库 + 持续集成流程

③ 要点：检查未使用的变量 / 循环依赖 / 复杂度是否过高；结合 Coverity 等自动化工具

C. 静态质量度量

① 定义：检查静态属性（复杂度 / 耦合度 / 注释率）

② 指标：代码行数，函数长度，类的深度，耦合度

③ 要点：设定合理阈值，超标需重构  +  持续监控，纳入 CI 流程

D. 逻辑覆盖 

① 语句覆盖

覆盖到程序中的每条语句，所有分支路径

② 判定覆盖

每个判定（if, switch）为 true 和 false 各一次

③ 条件覆盖

每个条件表达式的 true 和 false 各出现一次

④ 判定条件覆盖

结合判定覆盖和条件覆盖，要求每个判定和每个条件的所有取值都被覆盖

⑤ 条件组合覆盖

用例覆盖所有条件的所有可能组合

⑥ 路径覆盖

覆盖所有可能的路径，通常只覆盖关键路径

⑦ 圈复杂度

衡量控制流复杂度的指标， V(G) = 判断节点数 + 1，单个函数复杂度不超过 10

Ⅲ 灰盒

① 定义：结合了黑盒 / 白盒的优点，测试既了解内部实现，又从用户和业务出发进行测试

② 适用：验证接口 / 数据库 / 系统集成  +  复杂业务流程 / 跨系统集成 / 接口安全性测试

③ 要点

既考虑输入 / 输出，又关注内部数据流 / 状态变化

结合日志分析 / 接口抓包 / 数据库校验

适合 API 测试 / 集成测试 / 渗透测试

3，按类型划分

Ⅰ 功能

① 定义：验证功能师傅符合预期

② 目标：发现功能实现与预期不符，功能缺失，逻辑错误

③ 关注点：业务流程 / 功能点 / 边界 / 异常处理

④ 实践要点：需求文档 / 用户需求为主  +  覆盖主流程 / 分支流程 / 异常流程  +  自动化结合手工

⑤ 类型细分

A. UI 测试

• 验证界面元素（按钮，输入框，菜单）正确显示，布局合理，交互符合预期
• 界面一致性 / 响应性 / 易用性
• 关注点：界面布局，控件状态，输入校验，提示信息，无障碍支持
• 工具：Selenium，Appium

B. 接口测试

• 验证系统各模块，系统和外部系统之间的接口（RESTful API，WebService）的实现
• 检查接口功能，数据格式，参数校验，异常处理，安全性
• 关注点：请求 / 响应数据，状态码，边界，并发，幂等性
• 工具：Postman，JMeter

Ⅱ 性能

① 定义：评估不同负载下的响应速度，并发处理能力，资源消耗

② 目标：发现系统瓶颈，确保系统在预期负载下稳定运行

③ 关注点：响应时间，吞吐量，并发用户数，资源利用率（CPU，内存，IO）

④ 实践要点

性能指标 / 测试场景（峰值 / 持续 / 突发负载）

合理的负载模型，模拟真实用户场景

关注性能瓶颈和优化建议

⑤ 类型细分

A. 压力测试：超出系统设计负载，观察系统极限和恢复能力

B. 负载测试：正常和高负载下测试

C. 稳定性：长时间运行，检测资源泄露和性能衰竭

⑥ 工具：JMeter，LoadRunner

Ⅲ 界面

① 定义：专注图形用户界面（GUI）的正确性和一致性

② 目标：发现界面显示 / 交互 / 兼容性的问题

③ 关注点：界面布局 / 控件显示 / 交互流程 / 兼容性

④ 实践要点

• 跨浏览器，跨分辨率，跨设备
• 检查界面响应，动画，样式一致性

Ⅳ 可靠性

① 定义：规定条件下，规定时间内，0 故障运行

② 目标：稳定性和容错能力

③ 关注点：长时间运行，异常恢复，数据一致性

④ 实践要点

• 长时间运行 / 断点恢复的场景
• 异常处理 + 数据完整性
• 结合日志分析 / 监控工具

Ⅴ 配置

① 定义：验证在不同软硬件 / 网络 / 环境配置下的表现

② 目标：各种配置下都能运行

③ 关注点：操作系统 / 数据库 / 中间件 / 网络环境 / 参数配置

④ 实践要点

• 多种配置组合，覆盖主流程 / 边缘场景
• 自动化环境部署和测试
• 兼容性 / 性能差异

Ⅵ 兼容性

软件兼容性 

① 定义：在不同操作系统，浏览器，数据库，中间件下的兼容性

③ 关注点：功能一致性，界面显示，性能表现

④ 实践要点：多环境自动化测试，虚拟机 / 容器化部署

硬件兼容性 

① 定义：软件在不同硬件设备（PC，手机，平板，打印机，扫描仪，loT设备）上的兼容性

③ 关注点：驱动支持 / 外设兼容 / 性能差异

④ 实践要点：多设备实测 / 硬件模拟器辅助

Ⅶ 易用性

① 定义：易用性，用户体验，界面友好性

② 目标：发现影响用户操作效率和满意度的问题

③ 关注点：界面直观性，操作流程，提示信息，无障碍支持

④ 实践要点

• 真实用户参与测试，收集反馈
• 关注新手用户和特殊群体
• 结合 A/B 测试，可用性评分

Ⅷ 安全

② 目标：防止数据泄露，越权访问，恶意攻击

③ 关注点：身份认证，权限控制，数据加密，输入校验，漏洞扫描

④ 实践要点

• 模拟常见攻击场景（SQL注入，XSS，CSRF，弱口令）
• 结合自动化安全扫描 / 人工渗透测试
• 关注合规性和安全加固建议

⑥ 工具：Burp Suite，Kali Linux

四，测试流程

1，需求分析 

• 定义：测试团队对产品需求文档、用户故事、原型等进行深入理解和分析，明确测试范围和重点

• 目标：

•         理解业务逻辑、功能点、非功能需求

•         明确测试边界、输入输出、异常场景

• 关键产出：需求分析文档、需求疑问清单、测试关注点列表

• 实践要点：

•         参与需求澄清会议，主动提问，发现需求歧义和遗漏

•         结合历史缺陷、业务痛点，提前识别高风险点

•         关注非功能需求（性能、安全、兼容性等）

2，需求评审

• 定义：多角色（产品、开发、测试、运维等）共同对需求文档进行评审，确保需求的完整性、可测性和可实现性
• 目标：
  • 发现需求中的歧义、冲突、遗漏
•         明确需求变更和优先级

• 关键产出：评审记录、需求变更清单、评审结论

• 实践要点：

•         测试人员重点关注需求的可测性和边界条件

•         记录评审中的问题和决议，及时同步变更

•         推动需求文档标准化和版本管理

3，测试计划 

• 定义：制定本轮测试的整体策略和安排，明确测试目标、范围、资源、进度、风险和交付物
• 目标：
•         明确测试工作的组织和分工

•         预见和规避测试风险

• 关键产出：测试计划文档

• 实践要点：

•         明确测试类型、阶段、环境、工具

•         评估人力、时间、环境等资源需求

•         制定风险应对措施和里程碑计划

•         计划需动态维护，适应需求和进度变更

4，测试用例设计

• 定义：基于需求和设计文档，系统性地设计覆盖各类场景的测试用例
• 目标：

•         覆盖所有功能点、业务流程、边界和异常场景

•         明确每个用例的输入、操作、预期结果

• 关键产出：测试用例文档（Test Case）、用例管理表

• 实践要点：

•         采用等价类、边界值、场景法等设计方法

•         用例需可复现、可追溯、可维护

•         关注用例的独立性和可扩展性

•         用例编号、优先级、前置条件、数据准备等要素齐全

5，用例评审 

• 定义：多角色对测试用例进行评审，确保用例的完整性、有效性和可执行性
• 目标：

•         发现用例设计中的遗漏、冗余、歧义

•         优化用例结构和覆盖范围

• 关键产出：用例评审记录、用例优化建议

• 实践要点：

•         评审需覆盖主流程、分支流程、异常流程

•         结合开发、产品、测试多方视角

•         评审结论需及时反馈并落实到用例优化

6，实施测试 

• 定义：按照测试计划和用例，实际执行测试，记录测试结果和缺陷
• 目标：

•         发现并记录缺陷，推动缺陷闭环

•         验证软件质量，确保交付标准

• 关键产出：测试执行记录、缺陷报告（Bug Report）

• 实践要点：

•         严格按照用例执行，关注实际与预期差异

•         及时记录缺陷，描述清晰、重现步骤明确、截图/日志齐全

•         与开发、产品高效沟通，推动缺陷修复

•         关注回归测试和冒烟测试（早期针对主流程和主要功能）

7，回归测试 

• 定义：在缺陷修复、需求变更后，重新执行相关测试用例，验证修改未引入新问题
• 目标：

•         确保修复缺陷后系统功能和性能未受影响

•         防止“修复一个bug，引入新bug”

• 关键产出：回归测试记录、回归缺陷报告

• 实践要点：

•         制定回归用例集，优先覆盖高风险和易受影响模块

•         自动化回归测试提升效率

•         关注历史高发缺陷和核心业务流程

8，测试报告

• 定义：对本轮测试活动进行总结，汇报测试结果、缺陷情况、质量评估和改进建议

• 目标：

•         向项目干系人透明展示软件质量和测试结论

•         支持上线决策和后续改进

• 关键产出：测试报告

• 实践要点：

•         报告内容包括测试范围、执行情况、缺陷统计、风险分析、结论建议

•         结合数据和图表，直观展示质量状况

•         提出针对性的改进建议和后续关注点

五，测试报告

测试报告，是测试的重要交付物

是项目相关者，了解软件质量 / 缺陷分布 / 风险状况 / 上线建议的核心依据

高质量的测试报告，可以推动问题闭环 和 产品改进

1，关键要素

• 标题：XX 项目 v1.0 功能测试报告
• 报告人
• 测试时间和版本
• 测试范围：本次测试的功能模块 / 业务流程 / 环境说明
• 测试方法与策略：采用的测试类型 / 方法 / 工具

• 缺陷统计
  ① 缺陷类型：功能 / 界面 / 性能 / 安全 的缺陷
  ② 缺陷状态：新发现 / 已确认 / 已修复 / 已关闭 / 延期
  ③ 所属模块：缺陷归属的具体功能模块 或 子系统
  ④ 优先级：修复该缺陷的紧急程度 P0 / P1 / P2
  ⑤ 严重程度：缺陷对系统的影响 致命 / 严重 / 一般 / 轻微
  ⑥ 复现频率：缺陷出现的概率 必现 / 偶现 / 难以复现
  ⑦ 问题描述：详细描述缺陷的现象 操作步骤 / 入参出参
  ⑧ 预期结果：正确情况应有的表现
  ⑨ 附件：截图 / 日志 / 视频 / 接口请求包

• 缺陷分布图标：柱状图 / 饼图直观展示缺陷的分布和趋势
• 质量评估与风险分析：当前版本的质量状况 / 已知风险 / 遗留问题
• 上线建议：是否建议上线 / 关注的重点 / 后续改进建议
• 结论和签字：测试负责人签字确认，报告生效

2，5C标准：高质量缺陷报告

高质量缺陷报告，是推动问题高效修复的关键 

• Correct 准确：每个组成部分的描述必须准确，如 “点击保存按钮无响应” 而不是 “崩溃”
• Clear 清晰：用词清晰，逻辑严谨，便于开发 / 产品的理解，步骤分门别类，避免长篇大论
• Concise 简介：只包含必要信息，只描述与缺陷相关的操作和现象，不写无关背景
• Complete 完整：包含复现缺陷的完整步骤 / 环境信息 / 前置条件 / 数据准备；附带必要的截图 / 日志 / 视频，便于开发复现和定位
• Consistent 一致：全部缺陷报告，按统一的格式 / 术语 / 模板书写

3，常见问题

• 环境信息：明确操作系统 / 浏览器 / 客户端 / 网络环境，避免无法复现
• 优先级 / 严重程度的区分
• 复现频率：必现缺陷优先修复，偶现缺陷提供更多日志和环境信息
• 附件齐全：截图要标注关键点，日志要截取时间段，接口附完整请求包
• 缺陷生命周期：跟踪缺陷，从发现到关闭的全流程，确保每个缺陷有结论 / 负责人
• 数据统计和趋势分析：定期统计缺陷分布，修复率，回归缺陷

4，面试深度

• 如何处理 “无法复现” 的缺陷
  ---- 追溯环境 / 数据 / 操作步骤，必要时远程协助开发复现，或录制操作视频
• 如何界定优先级和严重程度
  ---- 结合业务影响 / 用户规模 / 上线时间
• 如何推动缺陷高效闭环
  ---- 明确责任人，定期跟进，推动跨部门协作
• 如何用数据驱动质量改进
  ---- 缺陷统计 / 根因分析

六，测试策略

测试策略，决定了测试的深度 / 广度 / 效率

优秀的策略，可以最大化测试资源的价值，提升缺陷发现率，降低项目风险

1，分层 + 上下游

① 定义：按系统架构 / 业务流程，分为不同层级（单元测试，接口测试，系统测试，UI 测试），并与上下游（开发，运维，产品）协同配合

② 目标

• 各层级各司其职，分层发现和定位缺陷
• 上下游协同，推动问题高效闭环

③ 要点

• 单元测试由开发主导，接口 / 系统 / UI 由测试主导
• 关键路径 / 核心模块要重点测
• 与开发，运维，产品简历高效沟通机制

④ 业务实践：微服务架构下，接口测试和契约测试特别重要；DevOps 流程中，测试和运维协同保障交付质量

2，左移

① 定义：测试活动前置，尽早介入需求 / 设计 / 开发的早期阶段，强调 “预防 > 补救”

② 目标

• 尽早发现缺陷
• 推动需求澄清 / 设计评审 / 代码走查

③ 要点

• 测试参与需求评审 / 设计评审，提出可测性和边界问题
• 推动开发自测，单元测试，静态代码分析
• 建立持续集成（CI）和自动化测试体系

④ 业务实践：敏捷开发 / DevOps / 持续交付（CD）

3，右移

① 定义：测试活动延伸到软件上线后，关注真实用户环境下的质量保障 / 体验优化

② 目标

• 发现线上环境的潜在问题 / 用户痛点
• 持续收集反馈，推动产品迭代优化

③ 要点

• 部署灰度发布，A/B 测试，用户行为分析
• 监控系统日志 / 性能指标 / 异常警告
• 快速响应线上缺陷和用户反馈

④ 业务实践：互联网公司常用的灰度发布 / 蓝绿部署 / 实时监控

4，回归测试

① 定义：缺陷修复 / 需求变更后，重新执行测试用例，确保不引入新的问题

② 目标

• 防止 “修复一个 bug，引入新的 bug”
• 保证稳定性 / 可靠性

③ 要点

• 建立自动化回归测试集，覆盖核心业务 + 高风险模块
• 每次迭代后 / 上线前，必须做回归测试
• 关注历史高发缺陷和易受影响区域

七，测试原则

1，需求出发

① 定义：需求为核心，测试用例 / 测试范围 / 测试目标 都要围绕需求展开

② 目标

• 确保所有功能 / 业务流程 / 非功能性需求（性能，安全，兼容性）都被覆盖
• 防止 “需求漂移” / 功能遗漏 / 误测

③ 要点

• 测试用例和需求点，一一对应，便于追溯和覆盖率统计
• 需求变更时，及时同步更新测试用例 / 测试计划
• 关注隐性需求和用户场景，主动与产品 / 开发沟通需求细节

④ 业务实践：需求追踪矩阵（RTM），确保每个需求都有对应的测试用例

2，尽早开始

① 定义：测试尽早介入项目生命周期，从需求 / 设计阶段，就开始参与质量保障

② 目标

• 及早发现需求 / 设计中的缺陷
• 推动需求澄清 / 设计评审 / 代码走查

④ 业务实践：敏捷开发，DevOps 都强调测试的早期介入，“预防为主，发现为辅”

3，避免开发自测

① 定义：开发的自测，不能替代独立的专业测试

② 目标

• 防止 “灯下黑”，避免开发对自身代码的盲区
• 提高缺陷发现率

③ 要点

• 开发自测只是基础保障
• 测试用例，可以覆盖开发自测难以发现的边界 / 异常 / 集成等场景
• 推动开发和测试分工协作，互为补充

④ 业务实践：大中型企业，一般有独立测试团队

4，终止条件

① 定义：测试活动要有明确的终止条件，避免无休止测试 / 过早结束

② 目标

• 明确何时结束测试，支持上线决策
• 保证测试覆盖率 / 质量达标

③ 要点

• 终止条件包括：所有高优先级缺陷关闭 / 测试用例执行率达标 / 回归测试通过 / 关键业务流程无缺陷 / 上线前评审通过
• 动态调整终止标准
• 终止条件要在测试计划中明确，与项目干系人达成一致

④ 业务实践：采用 “缺陷漏检率” / “用例通过率” / “上线阻断缺陷为 0” 等多维度终止标准