TESTING RULES
文件五：05_TESTING_RULES.md
# 文件五：05_TESTING_RULES.md
# 测试、验收与回归永久规则
版本：1.0
状态：长期有效
作用：防止 AI “代码写完 = 功能完成”。
# 1. 测试是开发的一部分
任何功能完成必须包含：
- 实现。
- 测试。
- 验证。
# 2. 测试分层
至少考虑：
- 静态检查。
- 单元测试。
- 接口测试。
- 集成测试。
- UI测试。
- 用户流程测试。
- 安全测试。
- 构建测试。
根据项目规模合理选择。
# 3. 静态检查不能替代运行测试
代码看起来没错：
- 不代表真的能运行。
# 4. 每项核心功能必须测试
正常情况。
- 异常情况。
- 边界情况。
- 无权限情况。
- 网络异常。
# 5. 页面测试
检查：
- 能加载。
- 无白屏。
- 无关键Console Error。
- 资源加载正常。
- 功能可操作。
# 6. 按钮测试
每个正式按钮必须判断：
- 点击结果。
- 重复点击。
- Loading。
- Disabled。
- 失败。
# 7. 表单测试
测试：
- 正常输入。
- 空输入。
- 错误输入。
- 超长。
- 特殊字符。
- 重复提交。
# 8. API测试
每个核心接口至少测试：
- 正常请求。
- 参数缺失。
- 非法参数。
- 未登录。
- 无权限。
# 9. 权限必须用实际角色测试
不能看代码后说：
- “有中间件，所以正常。”
- 必须实际模拟：
- 游客。
- 用户。
- 管理员。
# 10. 登录完整流程
必须测试：
- 正确登录。
- 错误密码。
- 无账号。
- 退出。
- 登录状态。
- 过期状态。
- 受保护页面。
# 11. 用户核心流程
建立：
- Happy Path。
- 从用户进入网站到完成核心目标完整跑通。
# 12. 异常流程
至少考虑：
- API失败。
- 数据库失败。
- 网络中断。
- 第三方失败。
- 超时。
# 13. 空状态
测试：
- 无数据。
- 无搜索结果。
- 首次用户。
# 14. 大数据状态
如果可能：
- 测试大量列表。
- 长文本。
- 大量历史记录。
- 避免只用三条Demo数据。
# 15. 响应式测试
至少检查：
- 手机。
- 平板。
- 桌面。
# 16. 浏览器测试
主要支持浏览器必须明确。
- 至少重点验证项目主支持浏览器。
# 17. Console必须检查
任何：
- Error。
- Unhandled Promise。
- 资源404。
- 都必须记录。
# 18. Network必须检查
确认：
- 接口地址。
- 方法。
- 状态码。
- 请求次数。
- 重复请求。
# 19. 修Bug必须有复现步骤
BUG记录：
- 触发环境。
- 步骤。
- 预期。
- 实际。
# 20. 修Bug后复测原步骤
保证：
- 原问题消失。
# 21. 修Bug必须做关联回归
例如：
- 修Token。
- 需要重新测试：
- 登录。
- 退出。
- 刷新。
- 权限。
- 管理员。
- 而不是只点一次登录。
# 22. 修改公共组件必须测试所有关键使用位置
因为影响范围大。
# 23. 修改Design Token必须检查全站主要页面
# 24. 修改API Client必须检查主要接口
# 25. 修改数据库必须检查数据相关功能
# 26. 修改权限系统必须重新执行权限矩阵
# 27. Build属于测试
正式提交前：
- Production Build必须通过。
# 28. Dev运行不等于Production通过
必须明确区分。
# 29. 测试结果状态
统一使用：
- ✅ 实际验证通过
- 🔎 静态检查通过
- ⚠️ 有问题
- ❌ 验证失败
- ❓ 无法验证
- ⏳ 未测试
# 30. 无法测试必须说原因
例如：
- 缺少API Key。
- 没有浏览器环境。
- 第三方服务不可访问。
- 数据库不存在。
不得直接标记通过。
# 31. 测试不得修改真实生产数据
除非有明确授权和安全测试环境。
# 32. 删除类操作特别谨慎
测试删除功能：
- 优先使用测试数据。
# 33. 管理员测试不能破坏真实数据
# 34. 自动化测试优先覆盖稳定核心逻辑
尤其：
- 登录。
- 权限。
- 关键API。
- 数据处理。
# 35. 不为测试数量而写无价值测试
测试的目标：
- 发现回归。
- 证明核心行为。
# 36. 每次完成任务输出测试报告
内容：
- 测试内容。
- 测试方式。
- 通过。
- 失败。
- 未测试。
- 异常。
- 风险。
# 37. 上线前必须进行全局回归
不能只测试本次改动。
- 至少重新确认：
- 启动。
- 首页。
- 登录。
- 核心功能。
- 管理员。
- API。
- Production Build。
六大规则共同执行协议
以下内容同时适用于全部六份文件。
A. AI每次任务开始前
先阅读：
- 与当前任务有关的规则文件。
- 如果任务涉及多个领域：
- 全部读取。 例如：
- 修改登录：
- 必须读取：
- 01_REQUIREMENTS_RULES.md
- 03_ENGINEERING_RULES.md
- 04_SECURITY_RULES.md
- 05_TESTING_RULES.md 修改视觉：
- 读取：
- 01_REQUIREMENTS_RULES.md
- 02_DESIGN_SYSTEM_RULES.md
- 05_TESTING_RULES.md 准备上线：
- 六份全部读取。
B. 规则冲突优先级
如发生冲突：
- 安全与数据完整性 明确用户需求 产品规则 架构规则 设计规则 优化建议
C. AI不能自行修改规则
除非用户明确要求：
- “修改规则文件”。
- 否则：
- 这些文件只读。
D. 现有项目与规则冲突怎么办
不得为了符合规则立即大规模重写。
- 先输出：
- 规则：
- 当前实现：
- 差异：
- 严重程度：
- 建议迁移方式： 再决定是否修复。
E. 每次修改之前
先回答自己：
- 我正在解决什么问题？
- 哪些文件必须修改？
- 哪些文件不应该碰？
- 是否涉及数据？
- 是否涉及权限？
- 是否影响API？
- 是否影响UI？
- 如何验证？
F. 每次修改之后
必须检查：
- 代码是否能运行。
- 是否引入新错误。
- 相关功能是否正常。
- 是否影响其他模块。
- 是否需要更新文档。
G. 禁止假完成
以下情况不得说：
- “全部完成”。
- 仍有未测试。
- 仍有报错。
- Build失败。
- 接口未验证。
- 缺少环境。
- 第三方服务没测试。 应明确：
- 已完成：
- 未完成：
- 无法验证：
- 风险：
H. 修改范围原则
永远优先：
- 小范围。
- 可验证。
- 可回滚。
- 低耦合。 而不是：
- 一次改几十个无关文件。
I. 项目长期目标
本项目必须尽量保持：
- 可理解。
- 可修改。
- 可维护。
- 可测试。
- 可部署。
- 可恢复。
- 可扩展。
- 安全。 最终目标不是：
- “AI这次把它跑起来了。”
- 而是：
- “即使换一个AI、换一台电脑、换一个开发者，这个项目依然能够继续维护。”
AI任务统一结束报告模板
每一次AI开发任务结束，都使用：
本次任务
修改文件
新增文件
删除文件
修改功能
配置变化
依赖变化
数据库变化
安全影响
实际测试
Build状态
未验证内容
已知问题
后续建议
最后只能使用：
- ✅ 完成并验证
- ⚠️ 完成但仍有未验证项目
- ❌ 未完成
- 三种结论之一。