test-infrastructure

测试基础设施

为当前项目建立、改进或迁移测试基础设施，按用户请求提供设计或实施。优先复用项目已有工具，规模可以小到一组夹具和命令，也可以大到一个平台。

同类测试通过仓库维护的入口，共用环境准备、就绪判断、超时处理、资源回收及其失败判定；具体场景保留自己的输入、操作和断言。

原则

• 入口易用：通过项目惯用工具集中组织职责明确、用法一致的命令，并提供简明说明。每条命令的前置条件及对环境生命周期的影响应清晰；常用流程可提供组合命令，复用相同实现。
• 职责独立：业务代码不依赖测试设施，目录和包的划分按项目需要决定。
• 生产路径：按验收范围选择生产模块或实际交付产物，通过稳定接缝验证。替换点位于被测范围之外，环境准备不能绕过本次要验证的行为。
• 依赖可选：常规反馈使用受控依赖和数据，真实外部服务按需显式启用。优先使用成本合适的真实实现；需要替身时，核对它与真实依赖的行为约定。
• 本地与持续集成一致：同一验收范围共用执行逻辑和判定规则，环境差异通过配置或适配处理。声明依赖版本、测试输入及其取得方式，在同一组受控条件下复现结果；真实外部运行记录实际条件和验证范围。
• 隔离与重建：隔离影响结果的测试状态，昂贵依赖可按需复用。允许保留环境供连续运行或排查；资源归属和环境清理范围明确，清理可在失败或中断后重新执行，并能按相同配置重建初始环境。
• 缓存复用：优先使用工具链原生缓存，跨运行复用依赖和构建资源，减少重复下载与计算。遵循工具的校验、共享与失效规则；复用产物或结果时，核对影响其有效性的输入和环境。日常环境清理保留可复用缓存，支持按需清除或绕过，并能在缓存缺失时重建。缓存命中应保持既定的验证范围和判定标准。
• 快速反馈：按风险与成本提供可单独运行的检查，从足以验证当前变化的较小范围开始，按需覆盖集成和真实外部依赖。
• 结果可信：报告实际验证范围，区分通过、失败与未执行，并保留重试信息。清理前留存必要的失败证据和复现条件，供运行结束后定位问题。先观察被测行为，再做兜底回收，回收成功不能掩盖产品失败。

改进既有设施

沿现有入口核对调用关系和验证范围，根据实际问题确定本轮改动边界。迁移时保留原有的有效验证目标，并明确仍由旧设施承担的部分。新路径接管相关调用和验证后，移除已替代的重复实现；必要的旧入口可转调共用实现。

优化反馈速度时，先测量瓶颈，同时关注总等待时间与累计计算成本，计入环境准备、重复调用和重试。保持验证范围，在相同运行条件下复测，确认改动带来稳定收益。