测试（面经 && 八股）

① 发现缺陷：尽早，尽可能多的发现 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" 等多维度终止标准