课程地图 测试、监控与稳定性
场景库 术语表
M4 · Chapter 13

测试、监控与稳定性

理解软件上线前如何验证,上线后如何观察和恢复。

7 个小节7 个业务案例4 类业务场景设计师视角
先看哪些场景

订单与支付、文件与 Excel、稳定性与运维、项目与协作

它是什么

测试验证预期行为,可观测性揭示运行状态,稳定性工程控制故障影响并支持恢复。

为什么需要

真实软件会持续变化和失败,团队需要自动验证、快速发现、准确定位和可控恢复。

位于哪一层

横跨开发、CI/CD、生产运行和事故响应。

和谁连接

Unit、Integration、API、E2E、Logs、Metrics、Traces、Alert、SLO、Incident 和 Postmortem。

项目里怎么出现

发布前自动跑测试,上线后监控错误率,异常时告警并回滚。

Learning Outcomes

学完这一章,你应该能

  • 区分主要测试层级
  • 理解日志、指标和追踪
  • 理解 SLI、SLO 与 SLA
  • 认识告警、事故响应和复盘
13.01

为什么需要多层测试?

不同测试以不同成本覆盖从函数到用户流程的风险。

Business Scenario First

先从真实业务问题进入

先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。

订单与支付CASE 01

为什么支付功能要同时做单元、集成和端到端测试?

用户正在做什么

团队上线优惠券叠加和退款功能。

业务会出什么问题

只测试页面可能漏掉金额函数错误,只测试函数又无法发现支付平台接入和完整流程问题。

技术怎样介入

Unit Test 验证计算规则,Integration Test 验证数据库和支付接口,E2E Test 模拟用户完成结算。

产品与设计怎样落地

验收用例覆盖主要角色、金额边界、网络异常和重复操作。

Unit Test 验证小函数和组件,Integration Test 验证模块协作,API Test 验证接口契约,E2E Test 模拟完整用户流程。

越接近真实用户流程,覆盖范围越大,执行速度和稳定性成本也越高。团队通常建立大量快速底层测试和少量关键 E2E。

Unit → Integration → API → E2E
System View
E2E:关键用户流程
API / Integration:模块协作
Unit:函数与组件
Static Checks:类型与规则
Designer Lens

设计验收关注视觉和体验,自动测试还要覆盖规则、边界、权限和回归。

Unit TestIntegration TestE2E Test
13.02

测试哪些状态和边界?

正常路径只是测试的一部分,风险常藏在边界和异常。

Business Scenario First

先从真实业务问题进入

先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。

文件与 ExcelCASE 01

文件上传测试为什么不能只测成功?

用户正在做什么

用户可能上传空文件、超大文件、错误格式、重复文件,也可能中途断网。

业务会出什么问题

只覆盖 Happy Path 会让真实边界在上线后集中暴露。

技术怎样介入

围绕 Edge Case 建立测试矩阵,并通过 Regression 防止后续改动破坏已有能力。

产品与设计怎样落地

设计稿要提供失败、重试、取消、超限、重复和部分成功状态。

表单要测试空值、最大长度、非法格式、重复提交和网络失败;权限要测试角色、资源归属和数据范围;异步任务要测试重试、取消和部分失败。

回归测试确认新变化没有破坏已有功能。测试数据和环境需要可重复,避免只在某个账号下偶然通过。

Happy Path + Boundary + Error + Permission + Concurrency + Regression
System View
正常成功
空与极值
格式错误
无权限
网络超时
重复操作
并发冲突
历史回归
Designer Lens

完整状态设计本身就是高质量测试用例的来源。

Happy PathEdge CaseRegression
13.03

Logs、Metrics 与 Traces

三类信号分别提供事件细节、整体趋势和请求路径。

Business Scenario First

先从真实业务问题进入

先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。

订单与支付CASE 01

用户说“昨晚 9 点订单一直转圈”,开发靠什么定位?

用户正在做什么

同一时间系统处理了数万笔订单。

业务会出什么问题

只有用户截图无法知道请求经过哪里、耗时多少和具体错误。

技术怎样介入

Logging 记录事件详情,Metric 观察整体错误率与延迟,Trace 还原单次请求链路。

产品与设计怎样落地

错误页提供时间、订单号和可复制的请求编号,客服工具可关联诊断信息。

Logs 记录具体事件和上下文,Metrics 以数字观察请求量、延迟、错误率和资源,Traces 追踪一次请求跨服务的路径。

结构化日志和统一 Trace ID 可以快速关联用户操作、接口和下游服务。敏感信息需要脱敏,日志也需要保留周期和访问权限。

Event Details = Logs;System Trends = Metrics;Request Journey = Traces
System View

三类信号

  • Logs:发生了什么
  • Metrics:整体是否健康
  • Traces:请求经过哪里

组合使用

  • 指标发现异常
  • 追踪定位链路
  • 日志查看细节
Designer Lens

用户问题描述越包含时间、账号、操作和界面状态,工程越容易关联可观测数据。

LoggingMetricTrace
13.04

Monitoring、Alert 与 Dashboard

监控持续采集信号,告警在风险超过阈值时通知团队。

Business Scenario First

先从真实业务问题进入

先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。

稳定性与运维CASE 01

支付错误率突然升高,系统怎样主动发现?

用户正在做什么

第三方支付接口在凌晨出现异常,用户开始失败。

业务会出什么问题

等待用户投诉会延长故障时间。

技术怎样介入

Monitoring 持续采集指标,Dashboard 展示趋势,Alert 触发值班,Runbook 给出排查和处置步骤。

产品与设计怎样落地

故障提示需要与真实状态联动,提供替代支付或稍后重试。

Dashboard 汇总流量、延迟、错误和资源。Alert 应围绕用户影响和可执行动作设置,避免大量无意义通知造成告警疲劳。

错误率突增、队列积压、磁盘不足和证书到期都可以触发告警。告警需要负责人、优先级和处理手册。

Telemetry → Dashboard → Alert Rule → On-call Response
System View
采集数据
监控平台
规则判断
发送告警
值班处理
恢复与记录
Designer Lens

产品指标与技术指标需要连接:支付失败率比单纯 CPU 升高更接近用户影响。

MonitoringAlertRunbook
13.05

SLI、SLO 与 SLA

稳定性目标需要可测量指标和明确承诺。

Business Scenario First

先从真实业务问题进入

先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。

稳定性与运维CASE 01

“登录服务 99.9% 可用”对用户意味着什么?

用户正在做什么

企业客户依赖工作日随时登录系统。

业务会出什么问题

只说“系统稳定”无法衡量,也无法决定投入多少工程成本。

技术怎样介入

SLI 是成功率或延迟指标,SLO 是内部目标,SLA 是对客户承诺,Error Budget 衡量可接受失败额度。

产品与设计怎样落地

关键路径要定义可接受等待、降级方式和对外状态说明。

SLI 是服务指标,例如成功率或延迟;SLO 是内部目标,例如 99.9% 请求成功;SLA 是对客户的正式承诺,可能包含补偿。

Error Budget 表示在目标范围内允许的失败空间,用于平衡新功能速度和可靠性投入。

SLI Measurement → SLO Target → SLA Commitment
System View
SLI:实际测量
SLO:团队目标
SLA:对外承诺
Error Budget:允许失败空间
RTO:恢复时间目标
RPO:可接受数据丢失点
Designer Lens

“稳定”需要翻译成用户可感知的成功率、速度、数据正确性和恢复时间。

SLISLOSLAError Budget
13.06

Incident、On-call 与 Postmortem

事故响应的目标是先降低用户影响,再定位根因和改进系统。

Business Scenario First

先从真实业务问题进入

先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。

稳定性与运维CASE 01

线上全站打不开后,团队怎样恢复并避免再次发生?

用户正在做什么

数据库连接配置错误导致生产故障。

业务会出什么问题

临时修复可以恢复服务,但缺少复盘会重复发生。

技术怎样介入

Incident 触发 On-call 处置,恢复后通过 Postmortem 还原时间线、根因和改进项。

产品与设计怎样落地

状态页、维护提示、数据恢复说明和用户补偿都属于产品响应。

事故发生后需要确认影响范围、建立指挥、采取止损措施、保持沟通并验证恢复。回滚、降级和切换备用系统都可能用于恢复。

Postmortem 记录时间线、技术和流程原因、有效措施与改进项。高质量复盘关注系统改进,不把复杂故障简单归咎于个人。

Detect → Triage → Mitigate → Recover → Review → Improve
System View
发现异常
确认影响
建立响应
止损与恢复
验证
复盘
落实改进
Designer Lens

故障页面和状态通知需要明确影响、进展、临时方案和恢复情况。

IncidentOn-callPostmortem
13.07

设计质量与工程质量如何连接?

体验验收、功能测试和运行稳定共同构成产品质量。

Business Scenario First

先从真实业务问题进入

先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。

项目与协作CASE 01

组件样式没变,为什么上线后键盘用户却无法操作?

用户正在做什么

按钮视觉还原正确,但缺少焦点状态和语义。

业务会出什么问题

只做视觉验收会遗漏可访问性和交互回归。

技术怎样介入

Visual Regression 检测样式变化,Accessibility Test 检查语义和键盘,Design QA 验证状态与规范。

产品与设计怎样落地

设计规范中要包含焦点、禁用、错误、响应式和辅助技术要求。

视觉走查可以发现间距、字体和状态问题;可访问性测试覆盖键盘、语义和对比度;功能测试验证业务;监控验证线上表现。

Design QA 最有效的输入包括组件规范、页面状态、断点规则、真实数据和关键流程。设计系统也需要自动化视觉回归和组件测试。

Design Spec → Implementation → Visual/Functional Tests → Production Signals
System View
设计规范
组件与页面实现
视觉与可访问性测试
功能与接口测试
生产监控与用户反馈
Designer Lens

设计验收向前进入组件和状态定义,向后连接真实数据、性能和线上反馈。

Visual RegressionAccessibility TestDesign QA
Chapter Recap

本章小结

  • 01
    多层测试覆盖函数、模块、接口和关键用户流程。
  • 02
    日志、指标、追踪共同形成可观测性。
  • 03
    SLI、SLO、SLA 把稳定性变成可衡量目标。
  • 04
    事故响应、复盘和设计质量共同支撑长期产品质量。
Practice

把认知变成一张图

为“登录接口”写出 2 个 Unit、2 个 API、2 个 E2E 场景,并选择三个生产监控指标。

Quick Check

随堂检查

QUESTION 01
哪一种信号最适合观察整体错误率趋势?
指标用于观察随时间变化的整体趋势。
QUESTION 02
SLO 是什么?
SLO 是团队为服务质量设定的可测目标。