功能测试实战：用状态、契约与风险把关

功能测试实战：用状态、契约与风险把关
别测页面，测行为。好的功能测试，把数据、状态、契约放在关键位置。
一个本可避免的静默问题
我辅导的某金融团队，用户在结账改币种后，部分退款会偶发丢失。UI 测试通过，日志正常。根因是状态机少了一条转移。用 State transition testing 画清允许与禁止的跳转，当天定位问题。
模式要点：契约、状态、神谕
– 契约优先：先在服务边界锁定输入/输出，再做 UI；尽早拦截接口漂移。
– 建立状态模型：列出有效状态与转移；用 State transition testing 覆盖非法与边界转移。
– 能判真的神谕：用业务规则判定（费率、进位、权限），而非截图像素。
– 真实数据集：引入时区、本地化、大金额、幂等键等边界数据。
– 风险热区：把精力放在资金流、数据变更、配额与限流点。
本周可执行清单
1) 为最高风险流程（登录、结账）画状态图。
2) 给两个关键 API 写契约测试。
3) 为用户在意的规则加神谕（例如退款精确到分）。
4) 跑三个负向转移和一条长用户路径。
5) 用“状态”而非“页面”来归类缺陷。
将 [内链：登录流程设计]、[内链：测试用例管理]、[内链：回归测试策略] 放在用户预期的位置。你的系统模型越清晰，功能测试越锋利。