为什么支付功能要同时做单元、集成和端到端测试?
团队上线优惠券叠加和退款功能。
只测试页面可能漏掉金额函数错误,只测试函数又无法发现支付平台接入和完整流程问题。
Unit Test 验证计算规则,Integration Test 验证数据库和支付接口,E2E Test 模拟用户完成结算。
验收用例覆盖主要角色、金额边界、网络异常和重复操作。
理解软件上线前如何验证,上线后如何观察和恢复。
订单与支付、文件与 Excel、稳定性与运维、项目与协作
测试验证预期行为,可观测性揭示运行状态,稳定性工程控制故障影响并支持恢复。
真实软件会持续变化和失败,团队需要自动验证、快速发现、准确定位和可控恢复。
横跨开发、CI/CD、生产运行和事故响应。
Unit、Integration、API、E2E、Logs、Metrics、Traces、Alert、SLO、Incident 和 Postmortem。
发布前自动跑测试,上线后监控错误率,异常时告警并回滚。
不同测试以不同成本覆盖从函数到用户流程的风险。
先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。
团队上线优惠券叠加和退款功能。
只测试页面可能漏掉金额函数错误,只测试函数又无法发现支付平台接入和完整流程问题。
Unit Test 验证计算规则,Integration Test 验证数据库和支付接口,E2E Test 模拟用户完成结算。
验收用例覆盖主要角色、金额边界、网络异常和重复操作。
Unit Test 验证小函数和组件,Integration Test 验证模块协作,API Test 验证接口契约,E2E Test 模拟完整用户流程。
越接近真实用户流程,覆盖范围越大,执行速度和稳定性成本也越高。团队通常建立大量快速底层测试和少量关键 E2E。
设计验收关注视觉和体验,自动测试还要覆盖规则、边界、权限和回归。
正常路径只是测试的一部分,风险常藏在边界和异常。
先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。
用户可能上传空文件、超大文件、错误格式、重复文件,也可能中途断网。
只覆盖 Happy Path 会让真实边界在上线后集中暴露。
围绕 Edge Case 建立测试矩阵,并通过 Regression 防止后续改动破坏已有能力。
设计稿要提供失败、重试、取消、超限、重复和部分成功状态。
表单要测试空值、最大长度、非法格式、重复提交和网络失败;权限要测试角色、资源归属和数据范围;异步任务要测试重试、取消和部分失败。
回归测试确认新变化没有破坏已有功能。测试数据和环境需要可重复,避免只在某个账号下偶然通过。
完整状态设计本身就是高质量测试用例的来源。
三类信号分别提供事件细节、整体趋势和请求路径。
先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。
同一时间系统处理了数万笔订单。
只有用户截图无法知道请求经过哪里、耗时多少和具体错误。
Logging 记录事件详情,Metric 观察整体错误率与延迟,Trace 还原单次请求链路。
错误页提供时间、订单号和可复制的请求编号,客服工具可关联诊断信息。
Logs 记录具体事件和上下文,Metrics 以数字观察请求量、延迟、错误率和资源,Traces 追踪一次请求跨服务的路径。
结构化日志和统一 Trace ID 可以快速关联用户操作、接口和下游服务。敏感信息需要脱敏,日志也需要保留周期和访问权限。
用户问题描述越包含时间、账号、操作和界面状态,工程越容易关联可观测数据。
监控持续采集信号,告警在风险超过阈值时通知团队。
先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。
第三方支付接口在凌晨出现异常,用户开始失败。
等待用户投诉会延长故障时间。
Monitoring 持续采集指标,Dashboard 展示趋势,Alert 触发值班,Runbook 给出排查和处置步骤。
故障提示需要与真实状态联动,提供替代支付或稍后重试。
Dashboard 汇总流量、延迟、错误和资源。Alert 应围绕用户影响和可执行动作设置,避免大量无意义通知造成告警疲劳。
错误率突增、队列积压、磁盘不足和证书到期都可以触发告警。告警需要负责人、优先级和处理手册。
产品指标与技术指标需要连接:支付失败率比单纯 CPU 升高更接近用户影响。
稳定性目标需要可测量指标和明确承诺。
先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。
企业客户依赖工作日随时登录系统。
只说“系统稳定”无法衡量,也无法决定投入多少工程成本。
SLI 是成功率或延迟指标,SLO 是内部目标,SLA 是对客户承诺,Error Budget 衡量可接受失败额度。
关键路径要定义可接受等待、降级方式和对外状态说明。
SLI 是服务指标,例如成功率或延迟;SLO 是内部目标,例如 99.9% 请求成功;SLA 是对客户的正式承诺,可能包含补偿。
Error Budget 表示在目标范围内允许的失败空间,用于平衡新功能速度和可靠性投入。
“稳定”需要翻译成用户可感知的成功率、速度、数据正确性和恢复时间。
事故响应的目标是先降低用户影响,再定位根因和改进系统。
先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。
数据库连接配置错误导致生产故障。
临时修复可以恢复服务,但缺少复盘会重复发生。
Incident 触发 On-call 处置,恢复后通过 Postmortem 还原时间线、根因和改进项。
状态页、维护提示、数据恢复说明和用户补偿都属于产品响应。
事故发生后需要确认影响范围、建立指挥、采取止损措施、保持沟通并验证恢复。回滚、降级和切换备用系统都可能用于恢复。
Postmortem 记录时间线、技术和流程原因、有效措施与改进项。高质量复盘关注系统改进,不把复杂故障简单归咎于个人。
故障页面和状态通知需要明确影响、进展、临时方案和恢复情况。
体验验收、功能测试和运行稳定共同构成产品质量。
先看用户动作和业务风险,再理解技术为什么出现,以及它会怎样改变页面、状态和流程。
按钮视觉还原正确,但缺少焦点状态和语义。
只做视觉验收会遗漏可访问性和交互回归。
Visual Regression 检测样式变化,Accessibility Test 检查语义和键盘,Design QA 验证状态与规范。
设计规范中要包含焦点、禁用、错误、响应式和辅助技术要求。
视觉走查可以发现间距、字体和状态问题;可访问性测试覆盖键盘、语义和对比度;功能测试验证业务;监控验证线上表现。
Design QA 最有效的输入包括组件规范、页面状态、断点规则、真实数据和关键流程。设计系统也需要自动化视觉回归和组件测试。
设计验收向前进入组件和状态定义,向后连接真实数据、性能和线上反馈。
为“登录接口”写出 2 个 Unit、2 个 API、2 个 E2E 场景,并选择三个生产监控指标。