审核测试套件的真实有效性，而不是虚荣指标。识别提供错误置信度的测试（同义反复、模拟测试、直线命中者）和遗漏的极端情况。创建带有跟踪任务的 bd 史诗以进行改进。在执行之前对每个任务运行 SRE 任务细化。 **批判心态：假设测试是由针对覆盖率指标进行优化的初级工程师编写的。**默认持怀疑态度——测试为红色或黄色，直到被证明为绿色。在对测试进行分类之前，您必须阅读生产代码。绿色是例外，而不是规则。 <刚性级别> 中等自由度 - 严格遵循 5 阶段分析过程。分类标准（红色/黄色/绿色）是严格的。极端案例发现适应特定的代码库。输出格式很灵活，但必须包含所有部分。 <快速参考> 相|行动|输出 ---|---|--- 1\.库存|列出所有测试文件和函数 |测试目录 2\.阅读生产代码 |阅读每个测试声称要测试的实际代码 |分析背景 3\.跟踪调用路径 |验证测试练习生产，而不是模拟/实用程序 |调用路径验证 4\.分类（持怀疑态度）|应用红色/黄色/绿色 - 默认为更严格的评级 |分类测试 5\.自我检讨|挑战每一个 GREEN - 高级 SRE 会同意吗？ |已验证的类别 6\.角落案例 |识别每个模块缺失的边缘情况 |差距分析 7\.优先 |按业务重要性排名 |优先级矩阵 8\. bd 问题 |创建史诗+任务，运行SRE细化|跟踪改进计划 **强制：在对测试进行分类之前阅读生产代码。如果不了解测试声称要测试什么，就无法评估它。** **每项测试的核心问题：** 1. 这会捕获什么错误？（如果你不能说出一个名字→红色） 2. 它是否执行生产代码或模拟/测试实用程序？（模拟 → 红色或黄色） 3. 测试通过时代码会中断吗？（如果是→黄色或红色） 4. 对生产输出的有意义的断言？（`!= nil` 或测试装置 → 弱） **bd 集成（强制）：** * 创建 bd 史诗以提高测试质量 * 创建bd任务：删除红色，加强黄色，添加极端情况 * 对所有任务运行 hyperpowers:sre-task-refinement * 将任务链接到具有依赖关系的史诗 **突变测试验证：** * Java: Pitest (`mvn org.pitest:pitest-maven:mutationCoverage`) * JS/TS：Stryker（`npx stryker run`） * Python: mutmut (`mutmut run`) **在以下情况下使用此技能：** * 尽管测试覆盖率很高，但仍出现生产错误 * 怀疑覆盖游戏或同义反复测试 * 在重大重构之前（确保测试捕获回归） * 进入不熟悉的代码库（评估测试质量） * 超能力之后：审查-实施标记测试质量问题 * 规划测试改进举措 **请勿在以下情况下使用：** * 编写新测试（使用超能力：测试驱动开发） * 调试测试失败（使用超能力：debugging-with-tools） * 只需要运行测试（使用 hyperpowers:test-runner 代理） <进程> ## 公告 **宣布：**“我正在使用 hyperpowers:analyzing-test-efficiency 通过 Google Fellow SRE 级别的审查来审核测试质量。” ** ** ## 第一阶段：测试库存 **目标：** 创建要分析的完整测试目录。 # 查找所有测试文件（使模式适应语言） fd -e test.ts -e spec.ts -e _test.go -e Test.java -e test.py 。 # 或者使用grep查找测试函数 rg "func Test|it\(|test\(|def test_|@Test" --type-add 'test:*test*' -t test # 计算每个模块的测试数对于 src/*/ 中的目录；做 count=$(rg -c "func Test|it\(" "$dir" 2>/dev/null | wc -l) echo "$dir: $count 测试" 完成 **创建库存 TodoWrite：** - 分析 src/auth/ 中的测试 - 分析 src/api/ 中的测试 - 分析 src/parser/ 中的测试 [...每个模块一个] ** ** ## 第 2 阶段：首先阅读生产代码 **强制：在对任何测试进行分类之前，您必须：** 1. **阅读生产代码** 测试声称要执行 2. **了解生产代码实际做了什么** 3. **跟踪测试的调用路径**以验证它是否到达生产代码 **为什么这很重要：** 初级工程师通常： * 创建测试实用程序并测试它们而不是生产代码 * 设置确定测试结果的模拟（mock-testing-mock） * 对测试中定义的值（而不是生产中定义的值）编写断言 * 在不理解实际代码的情况下复制示例中的模式 **如果您还没有阅读过生产代码，当测试是黄色或红色时，您会将测试错误地分类为绿色。** ** ** ## 第 3 阶段：对每个测试进行分类（怀疑默认） **假设每个测试都是红色或黄色，直到你有具体证据表明它是绿色的。** 对于每个测试，应用以下标准： ### 危险信号 - 必须移除或更换 **2.1 同义反复测试**（根据定义通过） // ❌ 红色：验证非可选返回不为零 test('构建器返回值', () => { const 结果 = new Builder().build(); 期望(结果).not.toBeNull(); // 总是通过 - 返回类型保证了这一点 }); // ❌红色：验证枚举是否有情况（编译器检查这一点） test('状态枚举有值', () => { Expect(Object.values(Status).length).toBeGreaterThan(0); }); // ❌ 红色：重复实现 test('add 返回总和', () => { 期望(添加(2, 3)).toBe(2 + 3); // 同义反复：测试 2+3 == 2+3 }); **检测模式：** # 在非可选类型上查找 != nil / != null rg "expect$.*$\.not\.toBeNull|assertNotNull|!= nil" 测试/ # 查找枚举存在性检查 rg“对象\.值。*长度|案例\.count”测试/ # 查找没有有意义断言的测试 rg -l "expect\(" 测试/ | xargs -I {} sh -c 'grep -c "expect" {} | grep -q "^1$" && echo {}' **2.2 模拟测试**（测试模拟，而不是生产） // ❌ 红色：仅验证模拟是否被调用，而不是实际行为 test('服务获取数据', () => { const mockApi = { fetch: jest.fn().mockResolvedValue({ data: [] }) }; const 服务 = 新服务(mockApi); service.getData(); 期望(mockApi.fetch).toHaveBeenCalled(); // 测试模拟，而不是服务逻辑 }); // ❌ 红色：模拟决定测试结果 test('处理器处理数据', () => { const mockParser = { 解析：jest.fn().mockReturnValue({ valid: true }) }; const 结果=processor.process(mockParser); 期望(结果.有效).toBe(真); // 只返回模拟返回的内容 }); **检测模式：** # 查找仅验证模拟调用的测试 rg“toHaveBeenCalled|验证\(模拟|\.叫”测试/ # 找到繁重的模拟设置 rg -c "mock|Mock|jest\.fn|stub" 测试/ |排序 -t: -k2 -nr |头-20 **2.3 Line Hitters**（不断言执行） // ❌ 红色：调用函数，不验证结果 test('处理器运行', () => { 常量处理器=新处理器（）；处理器.run(); // 没有断言 - 只是验证没有崩溃 }); // ❌ 红色：断言很简单测试（'配置加载'，（）=> { const config = loadConfig(); 期望（配置）.toBeDefined（）； // 太弱 - 无法验证正确的值 }); **检测模式：** # 查找具有 0-1 断言的测试 rg -l "test\(|it\(" 测试/ | while read f; do 断言=$(rg -c "expect|assert" "$f" 2>/dev/null || echo 0) 测试=$(rg -c "测试\(|it\(" "$f" 2>/dev/null || echo 1) 比率=$((断言/测试)) [ "$ratio" -lt 2 ] && echo "$f: 低断言比率（$assertions 断言，$tests 测试）" 完成 **2.4 常青/骗子测试**（总是通过） // ❌ 红色：捕获并忽略异常 test('解析器处理输入', () => { 尝试{ 解析器.parse(输入); 期望（真）。toBe（真）； // 总是通过 } 捕获 (e) { // Swallowed - 即使出现异常，测试也会通过 } }); // ❌ 红色：测试设置绕过被测代码 test('验证器验证', () => { const 验证器 = new Validator({skipValidation: true }); // 哎呀期望(validator.validate(badInput)).toBe(true); }); ### 黄旗 - 必须加强 **2.5 仅快乐之路** // ⚠️ 黄色：仅测试有效输入 test('解析有效的json', () => { const result = parse('{"name": "test"}'); Expect(结果.name).toBe('测试'); }); // 缺失：空字符串、格式错误的 JSON、深度嵌套、unicode、巨大的有效负载 **2.6 弱断言** // ⚠️ 黄色：断言太弱 test('获取返回数据', () => { const 结果 = 等待 fetch('/api/users'); 期望(结果).not.toBeNull(); // 应该验证实际内容 Expect(result.length).toBeGreaterThan(0); // 应该验证确切的数量或特定的项目 }); **2.7 部分覆盖** // ⚠️ 黄色：测试成功，而不是失败 test('创建用户成功', () => { const user = createUser({ 名称: 'test', 电子邮件: 'test@example.com' }); 期望(user.id).toBeDefined(); }); // 缺失：重复电子邮件、无效电子邮件、缺失字段、数据库错误 ### 绿旗 - 需要卓越的品质 **绿色是例外，而不是规则。** 仅当以下所有条件都为真时，测试才是绿色的： 1. **练习实际的生产代码** \- 不是模拟，不是测试实用程序，不是逻辑的副本 2. **有精确的断言** \- 精确的值，而不是 `!= nil` 或 `> 0` 3. **如果生产中断将会失败** \- 您可以命名它捕获的特定错误 4. **测试行为，而不是实现** \- 不会在有效重构时中断 **在将任何测试标记为绿色之前，您必须声明：** *“本次测试练习[具体生产代码路径]” *“它会捕获[特定错误]，因为[原因]” *“断言验证[确切的生产行为]，而不是测试装置” **如果您无法填写这些空白，则测试充其量是黄色。** **3.1 行为验证（必须执行生产代码）** // ✅ 绿色：使用生产中的确切值验证特定行为 test('calculateTotal 正确应用折扣', () => { const cart = new Cart([{ 价格: 100, 数量: 2 }]); // 真实的购物车类 cart.applyDiscount('SAVE20'); // 真正的折扣逻辑期望（购物车。总计）。toBe（160）; // 200 - 20% = 160 }); // 绿色，因为：练习 Cart.applyDiscount 生产代码 // 会发现：折扣计算错误、舍入错误 // 断言：验证生产中的精确计算值 **3.2 边缘情况覆盖（必须测试生产路径）** // ✅ 绿色：测试生产代码中的边界条件 test('用户名拒绝空字符串', () => { Expect(() => new User({ 用户名: '' })).toThrow(ValidationError); }); // 绿色，因为：练习用户构造函数验证（生产） // 会捕获：缺少空字符串验证 // 断言：生产代码中的确切错误类型 test('用户名处理 unicode', () => { const user = new User({ 用户名: '日本语ユーザー' }); Expect(user.username).toBe('日本语ユーザー'); }); // 绿色，因为：练习用户构造函数和存储（生产） // 会发现：Unicode 损坏、编码错误 // 断言：通过生产代码保留精确值 **3.3 错误路径测试（必须验证生产错误）** // ✅ 绿色：验证生产代码中的错误处理 test('fetch 返回 404 的特定错误', () => { mockServer.get('/api/user/999').reply(404); // 外部模拟 OK 等待期望（fetchUser（999））.rejects.toThrow（UserNotFoundError）; }); // 绿色，因为：练习 fetchUser 错误处理（生产） // 会捕获：错误的错误类型，吞没的错误 // 断言：生产代码中的确切错误类型 **注意：** 如果使用模拟来实现外部依赖项（API、数据库），如果它执行生产逻辑，则该测试仍然可以是绿色的。模拟被测代码的测试是红色的。 ** ** ## 第 4 阶段：强制自我审查 **在最终确定任何分类之前，请完成此清单：** ### 对于每个绿色测试： * 我是否阅读了此测试练习的生产代码？ * 测试是否调用生产代码或测试实用程序/模拟？ * 我可以说出这个测试会发现的具体错误吗？ * 如果生产代码损坏，这个测试肯定会失败吗？ * 我是否因为测试“看起来合理”而过于慷慨？ ### 对于每个黄色测试： * 这实际上应该是红色的吗？这里有任何捕捉错误的价值吗？ * 这个弱点是根本性的（模拟测试）还是可以修复的（弱断言）？ * 如果我将其更改为红色，我会失去任何错误捕获能力吗？ ### 自我挑战问题： *“如果初级工程师向我展示此测试，我会接受它为绿色吗？” *“我将其标记为绿色是因为我想完成，还是因为它真的很好？” *“我可以向 Google SRE 辩护这个绿色分类吗？” **如果您对绿色有任何疑问，请降级为黄色。** **如果您对黄色有任何疑问，请考虑红色。** **导致假绿色的常见错误：** * 假设一个命名良好的测试测试其名称所说的内容（验证代码！） * 信任测试注释（注释会说谎，代码不会） * 不跟踪模拟/实用程序的使用情况来查看实际执行的内容 * 给予怀疑（初级工程师不值得） ** ** ## 阶段 4b：逐行调整红/黄 **强制：对于每个红色或黄色分类，请提供详细的理由。** 这迫使您通过准确解释测试出现问题的原因来验证您的分类是否正确。 ### 红色/黄色测试所需的格式： ### [测试名称] - 红色/黄色 **测试代码（文件：行）：** - 第 X 行：`代码` - [此行的作用] - Y 行：`代码` - [此行的作用] - Z 行：`断言` - [断言内容] **它声称要测试的生产代码（文件：行）：** - [生产代码作用的简要描述] **为什么是红色/黄色：** - [具体原因及线路参考] - [尽管测试通过了，但哪些错误可能会溜走] ### 红色理由示例： ### testAuthWorks - 红色（同义反复） **测试代码（auth_test.ts:45-52）：** - 第 46 行：`const auth = new AuthService()` - 创建 auth 实例 - 第 47 行：`const result = auth.login('user', 'pass')` - 调用登录 - 第 48 行：`expect(result).not.toBeNull()` - 断言结果存在 **生产代码（auth.ts:78-95）：** - login() 返回 AuthResult 对象（TypeScript 类型永远不会为 null） **为什么是红色：** - 第 48 行断言 `!= null` 但 TypeScript 保证返回非 null - 如果登录返回{success: false, error: "invalid"}，测试仍然通过 - Bug 示例：接受错误密码 → 返回 {success: true} → 测试通过 ### 黄色示例理由： ### testParseJson - 黄色（弱断言） **测试代码（parser_test.ts:23-30）：** - 第 24 行：`const input = '{"name": "test"}'` - 有效的 JSON 输入 - 第 25 行：`const result = parse(input)` - 调用生产解析器 - 第 26 行：`expect(result).toBeDefined()` - 断言结果存在 - 第 27 行：`expect(result.name).toBe('test')` - 验证一个字段 **生产代码（parser.ts:12-45）：** - parse() 通过错误处理和验证来处理 JSON 解析 **为什么是黄色：** - 第 26-27 行仅测试具有有效输入的快乐路径 - 缺失：格式错误的 JSON、空字符串、深度嵌套、unicode - Bug 示例：parse('') 抛出未处理的异常 → 未被测试捕获 - 升级路径：添加具有特定错误断言的边缘情况输入 ### 为什么这很重要：写下理由迫使你： 1.实际一行行读取测试代码 2.实际阅读生产代码 3. 明确具体差距 4. 考虑哪些错误可能会被忽略 **如果你写不出这个理由，说明你没有正确分析。** ** ** ## 第 5 阶段：发现极端案例对于每个模块，确定缺少的极端情况测试： ### 输入验证极端情况类别 |示例 |要添加的测试 ---|---|--- 空值 | `""`、`[]`、`{}`、`null` | test_empty_X_rejected/已处理边界值| 0、-1、MAX_INT、MAX_LEN | test_boundary_X_handled 统一码 | RTL、表情符号、组合字符、空字节 | test_unicode_X_preserved 注射| SQL: ''; DROP`，XSS：`<脚本>`，cmd：`； rm` | test_injection_X_escaped 畸形|截断的 JSON、无效的 UTF-8、错误的类型 | test_malformed_X_error ### 状态极端情况类别 |示例 |要添加的测试 ---|---|--- 未初始化|在init之前使用，双重init | test_uninitialized_X_error 已经关闭 |关闭后使用，双重关闭 | test_close_X_error 并发|并行写入，写入期间读取 |测试并发_X_安全可重入|回调调用相同的方法 | test_reentrant_X_safe ### 集成极端案例类别 |示例 |要添加的测试 ---|---|--- 网络|超时、连接被拒绝、DNS 失败 | test_network_X_timeout 部分回应 |被截断、损坏、缓慢 |测试部分响应处理速率限制 | 429，超出配额 |测试速率限制处理服务错误 | 500、503、格式错误的响应 |测试服务错误处理 ### 资源极端案例类别 |示例 |要添加的测试 ---|---|--- 疲惫| OOM、磁盘已满、最大连接数 | test_resource_X_graceful 争用|文件已锁定，资源繁忙 | test_contention_X_handled 权限 |访问被拒绝，只读 |测试权限X错误 **对于每个模块，创建极端情况清单：** ### 模块：src/auth/ **覆盖的角落案例：** - [x] 空密码被拒绝 - [x] 用户名中的 SQL 注入已转义 **缺少的极端情况（必须添加）：** - [ ] 往返后保留 Unicode 用户名 - [ ] 并发登录尝试不会破坏会话 - [ ] 处理空字节密码 - [ ] 很长的密码 (10KB) 优雅地拒绝 - [ ] 强制执行登录速率限制 **优先级：** 高（身份验证对业务至关重要） ** ** ## 第 6 阶段：按业务影响确定优先级 ### 优先级矩阵优先|标准|行动时间表 ---|---|--- P0 - 严重 |身份验证、支付、数据完整性 |这次冲刺 P1 - 高 |核心业务逻辑、面向用户的功能|下一个冲刺 P2 - 中 |内部工具、管理功能 |积压 P3 - 低 |公用事业、非关键路径 |在时间允许的情况下 **排名模块：** 1. P0: src/auth/ - 5 个 RED 测试，12 个缺失的极端情况 2. P0: src/ payments/ - 2 个 RED 测试，8 个缺失的极端情况 3. P1: src/api/ - 8 个 RED 测试，15 个缺失的极端情况 4. P2: src/admin/ - 3 个 RED 测试，6 个缺失的极端情况 ** ** ## 第 7 阶段：创建 bd 问题和改进计划 **关键：** 所有发现都必须在 bd 中进行跟踪并经过 SRE 任务细化。 ### 步骤 5.1：创建 bd Epic 以提高测试质量 bd 创建“测试质量改进：[模块/项目]”\ --输入史诗\ --优先级 1 \ --design "$(cat <<'EOF' ## 目标通过删除同义反复测试、加强弱测试和添加缺失的极端情况覆盖来提高测试有效性。 ## 成功标准 - [ ] 所有 RED 测试均被删除或替换为有意义的测试 - [ ] 所有黄色测试都通过适当的断言得到加强 - [ ] 涵盖所有 P0 缺失的极端情况 - [ ] P0 模块的突变分数 ≥80% ## 范围 [模块分析和结果摘要] ## 反模式 - ❌ 添加仅检查 `!= nil` 的测试 - ❌添加验证模拟行为的测试 - ❌ 添加仅快乐路径测试 - ❌ 留下同义反复测试“以覆盖范围” EOF ）” ### 步骤 5.2：为每个类别创建 bd 任务 **任务 1：删除同义反复测试（立即）** bd create“从[模块]中删除同义反复测试”\ --输入任务\ --优先级0 \ --design "$(cat <<'EOF' ## 目标无论代码正确性如何，都通过通过来删除提供错误信心的测试。 ## 要删除的测试 [用 file:line 列出每个 RED 测试] -tests/auth.test.ts:45 -testUserExists（同义反复：验证非可选！= nil） -tests/auth.test.ts:67 -testEnumHasCases（同义反复：编译器检查此） ## 成功标准 - [ ] 删除所有列出的测试 - [ ] 没有引入新的同义反复测试 - [ ] 测试套件仍然通过 - [ ] 覆盖范围可能会减少（这是预期的并且很好） ## 反模式 - ❌ 保持测试“以防万一” - ❌ 用同样无意义的测试代替 - ❌ 添加仅覆盖测试以进行补偿 EOF ）” **任务 2：加强弱测试（本 Sprint）** bd create“加强[模块]中的弱断言”\ --输入任务\ --优先级 1 \ --design "$(cat <<'EOF' ## 目标用捕获真正错误的有意义的断言替换弱断言。 ## 强化测试 [列出每个黄色测试以及当前与推荐的断言] - 测试/parser.test.ts:34 - testParse - 当前：`expect(结果).not.toBeNull()` - 加强：`expect(result).toEqual(expectedAST)` - 测试/validator.test.ts:56 - testValidate - 当前：`expect(isValid).toBe(true)`（仅限快乐之路） - 添加边缘情况：空输入、unicode、最大长度 ## 成功标准 - [ ] 所有弱断言替换为精确值检查 - [ ] 边缘情况添加到仅快乐路径测试中 - [ ] 每个测试都会记录它捕获的错误 ## 反模式 - ❌ 将 `!= nil` 替换为 `!= undefined` （仍然很弱） - ❌ 添加没有有意义断言的边缘情况 EOF ）” **任务 3：添加缺失的极端情况（每个模块）** bd create“为[模块]添加缺少的极端情况测试”\ --输入任务\ --优先级 1 \ --design "$(cat <<'EOF' ## 目标添加针对可能导致生产错误的极端情况的测试。 ## 添加的极端情况 [列出每个它可以防止的错误] - test_empty_password_rejected - 防止身份验证绕过 - test_unicode_username_preserved - 防止编码损坏 - test_concurrent_login_safe - 防止会话损坏 ## 实施清单 - [ ] 首先编写失败的测试（红色） - [ ] 验证测试因正确原因失败 - [ ] 测试捕获列出的特定错误 - [ ] 测试有有意义的断言（不仅仅是 `!= nil`） ## 成功标准 - [ ] 编写并通过所有极端情况测试 - [ ] 每个测试都记录了它在测试名称/评论中捕获的错误 - [ ] 未添加同义反复测试 ## 反模式 - ❌ 编写立即通过的测试（没有测试任何东西） - ❌ 测试模拟行为而不是生产代码 - ❌只有快乐的道路（违背了目的） EOF ）” ### 步骤 5.3：运行 SRE 任务细化 **强制：** 创建 bd 任务后，运行 SRE 任务细化：宣布：“我正在使用 hyperpowers:sre-task-refinement 来审查这些测试改进任务。” 使用技能工具：hyperpowers:sre-task-refinement 将所有 8 个类别应用于每项任务，特别是： * **类别 8（测试意义）**：验证建议的测试是否确实捕获了错误 * **类别 6（边缘情况）**：确保边缘情况全面 * **类别 3（成功标准）**：确保标准是可衡量的 ### 步骤 5.4：将任务链接到 Epic # 将所有任务链接为史诗的子任务 bd dep add bd-2 bd-1 --type 父子 bd dep add bd-3 bd-1 --type 父子 bd dep add bd-4 bd-1 --type 父子 # 设置依赖关系（先删除，后增强，后添加） bd dep add bd-3 d-2 # 加强依赖于删除 bd dep add bd-4 bd-3 # 添加依赖于强化 ### 步骤 5.5：验证任务 bd 创建“通过突变测试验证测试改进”\ --输入任务\ --优先级 1 \ --design "$(cat <<'EOF' ## 目标使用突变测试验证测试改进是否确实捕获了更多错误。 ## 验证命令 ````bash # Java mvn org.pitest:pitest-maven:mutationCoverage # JavaScript/TypeScript npx 斯赛克运行 # Python 突变运行 #.NET 点网斯特赖克 ## 成功标准 * P0模块：突变得分≥80% * P1模块：突变得分≥70% * 关键路径（授权、支付）中没有幸存的突变体 ## 如果分数低于目标 * 识别幸存的突变体 * 创建额外的任务来添加杀死它们的测试 * 重新运行验证 EOF )" --- ## 输出格式 ``降价 # 测试效果分析：[项目名称] ## 执行摘要 |公制|计数 | % | |--------|--------|---| |分析的总测试次数 |尼 | 100% | |红色（删除/替换）|尼 | X% | |黄色（加强）|尼 | X% | |绿色（保持）|尼 | X% | |缺少极端情况 |尼 | - | **总体评估：** [关键/需要工作/可接受/良好] ## 详细调查结果 ### 红色测试（必须删除/更换） #### 同义反复测试 |测试|文件：行|问题 |行动| |------|------------|---------|--------| #### 模拟测试 |测试|文件：行|问题 |行动| |------|------------|---------|--------| #### 线击球手 |测试|文件：行|问题 |行动| |------|------------|---------|--------| #### 常青测试 |测试|文件：行|问题 |行动| |------|------------|---------|--------| ### 黄色测试（必须加强） #### 弱断言 |测试|文件：行|当前|推荐| |------|---------|---------|----------| #### 仅限快乐之路 |测试|文件：行|缺少边缘案例 | |------|---------|--------------------| ### 绿色测试（示例） [列出 3-5 个测试来说明此代码库的良好测试实践] ## 模块缺失的极端情况 ### [模块：名称] - 优先级：P0 |角箱 |错误风险 |推荐测试 | |----------|----------|------------------| [对每个模块重复] ## bd 问题已创建 ### 史诗 - **bd-N**：测试质量改进：[项目名称] ### 任务 | BD ID |任务|优先|状态 | |--------|------|----------|--------| | BD-N |从 [module] | 中删除同义反复测试P0|创建 | | BD-N |加强[模块]中的弱断言 | P1 |创建 | | BD-N |为 [module] 添加缺少的极端情况测试 | P1 |创建 | | BD-N |通过突变测试进行验证 | P1 |创建 | ### 依赖树 bd-1（史诗：测试质量改进）├──bd-2（删除同义反复测试）├──bd-3（加强弱断言）←取决于bd-2├──bd-4（添加极端情况测试）←取决于bd-3└──bd-5（通过突变测试进行验证）←取决于bd-4 ## SRE 任务细化状态 - [ ] 所有任务都经过超级权限审查：sre-task-refinement - [ ] 类别 8（测试意义）应用于每项任务 - [ ] 成功标准是可衡量的 - [ ] 指定反模式 ## 后续步骤 1. 运行 `bd ready` 查看准备好执行的任务 2. 使用超能力执行任务：执行计划 3. 运行验证任务以验证改进 # 然而生产问题： * 通过空密码绕过身份验证 * 并发更新时数据损坏 * unicode 用户名崩溃 <为什么失败> * 覆盖率衡量执行情况，而不是断言质量 * 测试可能的同义反复或弱断言 * 未测试极端情况（空、并发、unicode） * 高覆盖率造成虚假信心第一阶段 - 库存： fd -e test.ts src/ # 找到：auth.test.ts、user.test.ts、data.test.ts 第 2 阶段 - 分类： ### auth.test.ts |测试|类别 |问题 | |------|----------|---------| |测试AuthWorks |红色|只检查 `!= null` | |测试登录流程 |黄色|唯有快乐之路，无空密码| |测试令牌过期 |绿色|验证确切的错误 | ### 数据.test.ts |测试|类别 |问题 | |------|----------|---------| |测试数据保存|红色|没有断言，只是调用 save() | |测试并发写入 |失踪|完全没有测试过 | 第 3 阶段 - 极端情况： ### 授权模块 (P0) 缺失： - [ ] test_empty_password_rejected - [ ] test_unicode_username_preserved - [ ] test_concurrent_login_safe 第 5 阶段 - 计划： ### 立即 - 删除 testAuthWorks（同义反复） - 删除 testDataSaves（线击球手） ### 这个冲刺 - 添加 test_empty_password_rejected - 添加test_concurrent_writes_safe - 通过边缘情况加强 testLoginFlow **结果：** 通过有意义的测试防止了生产错误。 test('服务处理数据', () => { const mockDb = jest.fn().mockReturnValue({ data: [] }); const mockCache = jest.fn().mockReturnValue(null); const mockLogger = jest.fn(); const mockValidator = jest.fn().mockReturnValue(true); const service = new Service(mockDb、mockCache、mockLogger、mockValidator); service.process({ id: 1 }); 期望(mockDb).toHaveBeenCalled();期望（mockValidator）.toHaveBeenCalled（）； // 测试模拟接线，而不是实际行为 }); <为什么失败> * 测试验证模拟设置，而不是生产行为 * 更改实现会破坏没有错误的测试 * 没有发现真正的错误（验证逻辑、数据处理） *“嘲笑嘲笑嘲笑”反模式 ### 服务.test.ts |测试|类别 |问题 |行动| |------|----------|---------|--------| |测试服务流程 |红色|仅验证名为 | 的模拟替换为集成测试 | |测试服务验证 |红色|模拟决定结果 |测试真实验证器 | |测试服务缓存 |红色|测试模拟缓存 |使用真实缓存与测试数据 | **更换策略：** // ❌之前：测试模拟接线 test('服务验证', () => { const mockValidator = jest.fn().mockReturnValue(true); const 服务 = 新服务(mockValidator); 期望（mockValidator）.toHaveBeenCalled（）； }); // ✅ 之后：测试真实行为 test('服务拒绝无效数据', () => { const 服务 = new Service(new RealValidator()); const 结果 = service.process({ id: -1 }); // 无效的ID 期望（结果。错误）。toBe（'INVALID_ID'）; }); test('服务接受有效数据', () => { const 服务 = new Service(new RealValidator()); const result = service.process({ id: 1, name: '测试' }); 期望(结果.成功).toBe(true); 期望（结果.data.name）.toBe（'测试'）; }); **结果：** 测试验证行为，而不是实现。重构不会破坏测试。真正的错误被捕获。 <关键规则> ## 没有例外的规则 1. **假设初级工程师的质量** → 测试质量较低，除非另有证明 2. **分类之前阅读生产代码** → 没有上下文就无法评估 3. **绿色是例外** → 大多数测试是红色或黄色；绿色需要证明 4. **每个测试都必须回答：“这个捕获了什么错误？”** → 如果没有答案，则为红色 5. **必须删除同义反复测试** → 它们提供了错误的置信度 6. **必须更换模拟测试** → 测试生产代码，而不是模拟 7. **最终确定前的自我审查** → 挑战每一个 GREEN 分类 8. **突变测试验证改进** → 覆盖率本身就是虚荣指标 9. **bd 中跟踪的所有发现** → 为发现的每个问题创建史诗 + 任务 10. **对所有任务进行 SRE 细化** → 在执行之前运行 hyperpowers:sre-task-refinement ## 常见分析失败 **你会忍不住：** * 将测试标记为绿色，因为它们“看起来合理” → 首先验证调用路径 * 信任测试名称和注释 → 代码不会说谎，注释会说谎 * 假定无罪 → 初级工程师不值得 * 紧急分类 → 首先阅读生产代码 * 当实际是红色时标记黄色 → 如果模拟确定结果，则它是红色 **假绿色比假黄色更糟糕。** 如有疑问，请更加严厉。 ## 常见借口所有这些都意味着：**停止。测试可能是红色或黄色。** * “这只是一个冒烟测试”（没有断言的冒烟测试是没有用的） *“报道需要它”（报道博弈=虚假信心） *“它以前有效”（过去的成功并不意味着它捕获了错误） *“Mocks make it fast”（快但没用还是没用） *“边缘情况很少见”（身份验证/付款中的罕见错误至关重要） *“我们稍后会添加断言”（没有断言的测试不是测试） *“它正在测试快乐路径”（仅快乐路径=一半测试） *“测试看起来很合理”（初级工程师写出看似合理的垃圾） *“测试名称说它测试X”（名称谎言，追踪实际代码） *“它执行该功能”（调用！=测试；断言很重要） *“我会在没有bd的情况下修复这些”（未跟踪的工作=忘记的工作） *“SRE 细化对于测试修复而言太过分了”（测试任务需要与功能任务相同的严格性）完成分析之前： **分析质量（强制）：** * 在分类之前阅读每个测试的生产代码 * 跟踪调用路径以验证测试练习生产，而不是模拟/实用程序 * 应用怀疑默认值（假设为红色/黄色，绿色需要证明） * 完成所有绿色测试的自我审查清单 * 每个绿色测试都有明确的理由（什么生产路径，它捕获什么错误） * 每个 RED 测试都有生产代码上下文的逐行论证 * 每个黄色测试都有逐行的理由和升级路径 **每个模块：** * 所有测试分类（红色/黄色/绿色） * RED 测试具有特定的移除/更换操作 * YELLOW测试有特定的强化动作 * 识别极端情况（空、unicode、并发、错误） * 分配优先级 (P0/P1/P2/P3) **总体：** * 包含计数和百分比的执行摘要 * 绿色计数占少数（如果>40% 绿色，则以更多怀疑的态度重新审查） * 每个类别的详细调查结果表 * 每个模块缺少记录的极端情况 **bd 集成（强制）：** * 创建 bd Epi 以提高测试质量 *为每个类别创建bd任务（删除、加强、添加） * 通过亲子关系将任务链接到史诗 * 设置任务依赖关系（删除→强化→添加→验证） * 运行超能力：对所有任务进行重新任务细化 * 创建带有突变测试的验证任务 **SRE 细化验证：** * 第 8 类（测试意义）适用于每项任务 * 成功标准是可衡量的（不是“测试工作”） * 为每个任务指定反模式 * 任务设计中没有占位符文本 **验证：** * 删除 RED 测试会失去任何错误捕获能力吗？（否=正确） * 加强黄色测试会捕获更多错误吗？（是=正确） * 添加极端情况会捕获已知的生产错误吗？（是=正确） **此技能调用（强制）：** * hyperpowers:sre-task-refinement (对于创建的所有 bd 任务) * hyperpowers:test-runner 代理（在分析期间运行测试） * 超能力：测试有效性分析代理（用于详细分析） **此技能创造：** * BD Epic 用于测试质量改进 * 用于删除、加强和添加测试的 bd 任务 * 带有突变测试的 bd 验证任务 **工作流程链：** 分析测试有效性 ↓（产生 bd 问题） sre-task-refinement（针对每个任务） ↓（细化任务）执行计划（实施任务） ↓（运行验证）审查实施（验证质量） **此技能告知：** * hyperpowers:sre-task-refinement（计划中的测试规范） * 超级能力：测试驱动开发（什么才是好的测试） **突变测试工具：** * Java: [Pitest]() (`mvn org.pitest:pitest-maven:mutationCoverage`) * JS/TS: [Stryker]() (`npx stryker run`) * Python: mutmut (`mutmut run`) * .NET：Stryker.NET（`dotnet stryker`） **来自 Google 的关键见解：** “覆盖率主要告诉您没有测试的代码：它不会告诉您‘覆盖’的代码的测试质量。” **卡住时：** * 测试似乎处于红/黄边缘 → 问：“如果我删除这个测试，什么 bug 会漏掉？”如果没有，则为红色。 * 不确定断言是否弱 → 问：“断言通过时代码是否会返回错误的值？”如果是的话，加强。 * 不确定极端情况是否重要 → 问：“这是否曾在任何地方导致过生产错误？”如果是的话，测试一下。

分析测试有效性

包含技能