用途：这是测试工作中的策略环节，在实现开始前决定应当证明哪些行为、用什么方式证明。适用于判断需要测试的行为、设计测试用例、选择自动与手动验证、审查测试覆盖质量或规划测试。
核心原则：BDD 先行，先写自然语言行为场景再写测试代码；测行为而非实现，关注外部可观察结果；真实优先于 mock，仅在系统边界处 mock；可信度优先于覆盖率；测试基础设施属于架构，fixtures/状态/环境薄弱时先修架构。
何时写自动化测试：中大型、有风险、改变行为的工作，修 bug（条件允许先写），已有测试套件的项目，作为初始设置的绿地项目，可复用的内部工具/CLI/脚本/库，难以手动验证的复杂边界。不写：纯配置变更、文档更新、无行为影响的静态内容、一次性脚本、无法真实测试的 CI/CD 或基础设施流程。大型无测试仓库不应为小改动搭建整套测试系统。
策略流程：识别待证明的行为或风险，先写 BDD 场景，检查现有测试基础设施能否支持，再路由到下一技能。BDD 默认格式：Feature/Scenario/Given/When/Then/And。小工作可内联；中大型或有风险工作建议保存到 docs/test-cases/YYYY-MM-DD-<feature>.md。非 BDD 套件可保留本地框架风格，但需在测试附近保留场景文本。
测试类型选择：纯逻辑用单元测试；API/领域/存储交互用集成测试；CLI/工具用真实命令执行并隔离临时目录与环境；浏览器/UI 用运行时验证加自动化；外部服务用契约驱动的测试服务器、契约 fixture 或手动/预发验证；难以自动化的基础设施用手动冒烟/端到端。质量规则：断言外部可观察行为，避免内部调用验证、私有函数、mock 存在性断言、无人审查的快照；仅在慢、不安全、不确定、昂贵、外部或难控的依赖处 mock；测试追求 DAMP 而非 DRY；必要时用流式断言。
基础设施就绪检查：案例能否确定性运行、状态是否隔离、所需服务/环境变量/二进制是否预先检查、认证与数据构建是否可复用、并行是否会冲突，有风险则先做 architecting-test-infra。输出紧凑测试策略，包含 BDD 案例、额外手动场景、基础设施需求与下一技能（test-driven-development / manual-testing / architecting-test-infra）。常见错误包括先写测试代码、测试 mock、为小改搭建庞大测试栈、忽视薄弱 fixtures、把覆盖率数字当成功。