测试、调试与质量
测试不是只在最后做
Section titled “测试不是只在最后做”测试是把“我觉得应该能用”变成可以重复验证的检查。越靠近代码的小测试越快，越接近真实用户的测试越能发现跨模块问题。
| 类型 | 检查什么 | 例子 |
|---|---|---|
| 单元测试 | 一个函数或组件的规则 | 金额格式、表单校验 |
| 集成测试 | 多个模块如何协作 | API + 数据库、登录流程 |
| 端到端测试 | 用户完整操作 | 注册、创建内容、退出 |
| 静态检查 | 类型、语法、风格和依赖 | TypeScript、lint、构建 |
| 人工验收 | 视觉、文案和真实体验 | 手机布局、无障碍、错误提示 |
一个小测试应该写什么
Section titled “一个小测试应该写什么”准备：给函数一个有效输入执行：调用函数断言：输出等于期望结果边界：空值、超长、非法格式和重复操作测试名称要说明行为，不要只写 test1。失败时应能快速看出输入、期望和实际结果。
调试的固定顺序
Section titled “调试的固定顺序”- 先稳定复现：记录环境、步骤和完整错误；
- 缩小范围：判断是浏览器、前端、API、数据库还是第三方服务；
- 查看证据：Network、日志、状态码、请求 ID、Git diff；
- 提出最小假设：一次只验证一个可能原因；
- 做最小修改并重新验证；
- 补一个测试或文档，避免同类问题再次出现。
不要一看到错误就重装全部依赖、清空数据库或升级所有包。
浏览器开发者工具
Section titled “浏览器开发者工具”- Elements：查看实际 DOM 和 CSS；
- Console：看运行时错误和警告；
- Network：看请求 URL、方法、状态码、响应和耗时；
- Application/Storage：查看 Cookie、Local Storage 和缓存；
- Performance：分析卡顿和长任务。
敏感信息截图前要脱敏；不要把完整 Cookie、Token 和 API Key 发给他人。
日志应该记录什么
Section titled “日志应该记录什么”记录时间、请求 ID、操作类型、耗时、状态和可定位的错误信息。不要记录密码、完整 Key、身份证号、完整支付信息或不必要的用户内容。
让 AI 协助排错
Section titled “让 AI 协助排错”环境：[系统、运行时、依赖版本]复现步骤：[从哪里开始，做了什么]期望：[应该发生什么]实际：[实际发生什么]错误原文：[完整但已脱敏]最近改动：[文件、版本或配置]请先按可能性排序给出排查步骤，不要执行破坏性命令；每一步说明看到什么结果后如何继续。发布前的最低质量线
Section titled “发布前的最低质量线”- 核心流程至少有一条自动或人工可重复验证；
- 失败、空数据、权限不足和网络超时有提示；
- 生产构建成功，日志和错误可查看；
- 关键数据有备份和恢复方式；
- 修改可以通过 Git 差异和版本回滚追踪。