按标准测试特征给现有测试打标签并审计分布

当团队需要理解现有测试套件中正向/负向、边界、关键路径、冒烟等测试类型的组成时，用固定 trait 属性分类、汇总分布，并在可安全编辑的框架中验证编译与发现。

适用场景

解决思路

1. 解析输入：Test project or files（可选；省略则从当前 workspace 发现）、Scope（可选：tag 应用 canonical attributes 或已确认的项目约定；audit 只报告；both 默认）、Framework（可选；自动检测，检测失败时手动覆盖）。
2. 检测语言、框架和 tagging 能力：先从当前 workspace 解析请求的测试范围，不要因为技能 Base directory 不代表用户仓库就声称文件不可用；先检查当前工作目录。若 prompt 中的相对路径不存在，搜索 workspace 中命名的 project/file 并重试精确结果。搜索成功证明目标存在；若正常 reader 随后报告同一路径缺失，视为 reader 路径规范化或传输失败，不要向用户要文件。仅在确认 reader 可用性、传输或路径规范化失败时使用 shell 文本读取器（Unix 用 sed/cat，PowerShell 用 Get-Content），且必须先验证 canonical path 仍在当前 workspace 内。遇到 content-exclusion、permission/policy、workspace-boundary 或未知读取失败时停止。workspace 搜索已找到可读目标后，绝不再向用户索要路径或文件内容。
3. 对 auto-edit 框架，patch/editor 调用失败不是停止条件，仅当失败确认为工具可用性、传输或路径规范化问题时继续；不要绕过 stale-context、concurrent-change、permission/policy 或 path-boundary 错误。在 shell fallback 前，在当前 workspace 内解析 canonical path，重新读取文件，并使用 anchored transformation，除非 expected old text 和 exact match count 未变否则中止。然后重新打开完整文件，检查 diff，并运行 Step 6 验证。用户要求应用属性时，不要把 proposed attributes 当作完成。
4. 识别语言和框架后，尝试匹配的 test-analysis-extensions 指导一次。若不可用，立即按内置规则分类能力，不要因 helper 阻塞 tagging。
5. auto-edit 能力：框架有 canonical tag syntax 且本技能可安全插入——.NET [TestCategory]/[Trait]/[Category]/[Property]，pytest @pytest.mark.<name>，JUnit 5 @Tag("...")，TestNG groups = {"..."}，RSpec metadata it "..." , :tag => true，Pester -Tag '...'，Kotest @Tags(...)，Swift Testing @Tag(.tagName)，Catch2 [tag]，doctest * doctest::test_suite("tag") decorator。
6. report-only 能力：框架没有 canonical、agreed-upon tag attribute——只在 Markdown 表格中报告 tags，不编辑源码（Go standard testing 无 build-tag 约定、Jest/Vitest 无一致 describe-prefix 约定、Rust 无项目特定 cfg 约定、XCTest 无 test plan、GoogleTest 无 test-name prefix 约定、Mocha 无 describe-prefix 约定）。
7. convention-based 能力：框架使用命名或文件约定 tagging（Go //go:build integration build tags、*_integration_test.go 文件名后缀、GoogleTest INTEGRATION_* filter prefix）。仅在用户确认项目约定后才输出 canonical edits；否则按 report-only 处理。在 Step 4 前捕获能力。
8. Step 2：扫描已有 traits。检查哪些测试已有 trait attributes。加载了 extension 就用 extension；否则用内置表作为事实来源：MSTest [TestCategory("...")] 如 [TestCategory("positive")]；xUnit [Trait("Category", "...")] 如 [Trait("Category", "positive")]；NUnit [Category("...")] 如 [Category("positive")]；TUnit [Property("Category", "...")] 如 [Property("Category", "positive")]；JUnit 5 @Tag("...") 如 @Tag("positive")；TestNG @Test(groups = {"..."}) 如 @Test(groups = {"positive"})；pytest @pytest.mark.<name> 如 @pytest.mark.positive；RSpec metadata after it 如 it "...", :positive do；Pester -Tag '...' 如 It '...' -Tag 'positive'；Kotest @Tags(...) 如 @Tags(Positive)；Swift Testing @Tag(.<name>) 如 @Test(.tags(.positive))；Catch2 [tag] in name 如 TEST_CASE("...", "[positive]")；doctest * doctest::test_suite("...") decorator 如 TEST_CASE("..." *doctest::test_suite("positive"))。记录已有 tags 的测试以避免重复。
9. Step 3：为每个测试方法建立唯一 canonical inventory，每个发现的测试只出现一次。记录 test identifier、behavioral classification 和 traits；source edits、per-test reporting、totals、distribution counts 都使用同一组行。不要单独手工计数分母。发布前，用 inventory 行数核对报告总数，并确认每一行都计入每个显示的 trait count。
10. 使用以下固定 trait 名称和值，不要发明表外 trait values。单个测试可有多个 traits（如 negative 和 boundary）。每个测试至少应获得 positive 或 negative 之一。
11. positive：验证正常/有效条件下的预期行为；heuristics：断言成功、有效输出、预期状态、有效输入无异常。
12. negative：验证无效输入、错误或边缘情况的正确处理；heuristics：断言异常、错误码、验证失败、拒绝坏输入。
13. boundary：测试限制、阈值、empty/null/None/nil 输入、min/max 值；heuristics：操作 0、-1、int.MaxValue / sys.maxsize / Number.MAX_SAFE_INTEGER / math.MaxInt64 / i32::MAX、empty string、null/None/nil/undefined、empty collection、有效范围边界。
14. critical-path：绝不能破坏的核心工作流；破坏会阻塞用户；heuristics：测试关键 public API 或用户面向功能的主要成功场景。
15. smoke：系统可运行的快速 sanity check；heuristics：快、无复杂 setup、验证基本 wiring（如 service resolves、endpoint returns 200）。
16. regression：复现特定 previously-reported bug；heuristics：在名称或注释中引用 bug ID、issue number，或描述 fix。
17. integration：跨越进程、网络或持久化边界；heuristics：使用真实 database、HTTP client、file system、external service 或多组件 setup。
18. end-to-end：跨越整个 application stack 的完整用户工作流；heuristics：从 entry point 到 final result 执行完整场景，区别于单边界 integration。
19. performance：验证 timing、throughput 或资源消耗；heuristics：断言 elapsed time、memory、allocations，或使用 benchmark harness（BenchmarkDotNet、pytest-benchmark、benchmark.js、JMH、go test -bench、criterion.rs、XCTMetric、kotlinx-benchmark、Google Benchmark）。
20. security：验证 authentication、authorization、input sanitization 或 secrets handling；heuristics：测试 SQL injection、XSS、CSRF、unauthorized access、token validation、permission checks。
21. concurrency：验证 thread safety、parallelism 或 async correctness；heuristics：使用 Task.WhenAll / Parallel.ForEach / SemaphoreSlim (.NET)；asyncio.gather / threading.Lock / multiprocessing (Python)；Promise.all / worker threads (JS/TS)；CompletableFuture / ExecutorService / synchronized (Java)；go func / sync.WaitGroup / sync.Mutex / chan (Go)；Mutex / Thread.new (Ruby)；tokio::spawn / Arc<Mutex<_>> / crossbeam (Rust)；DispatchQueue / actor (Swift)；coroutineScope / Mutex (Kotlin)；Start-Job / RunspacePool (PowerShell)；std::thread / std::mutex (C++)；复现 race conditions。
22. resilience：测试 retry logic、timeouts、circuit breakers 或 graceful degradation；heuristics：断言 transient failures、network drops 或 service unavailability 下的行为（如 Polly、tenacity、p-retry、resilience4j、hystrix、opossum、retry-go）。
23. destructive：修改难以回滚的共享或外部状态；heuristics：删除 records、drops resources、修改 global config——用于 CI isolation 决策。
24. configuration：验证 settings loading、defaults、environment behavior；heuristics：测试 missing config keys、invalid values、environment variable fallbacks、options validation。
25. flaky：已知会间歇性失败（用于 test health tracking 的 meta-tag）；heuristics：标记团队已知不可靠的测试；用于 quarantine 或优先稳定化。
26. 对每个没有 traits 的测试方法，按以下启发式分析：1) Method name——名称含 Invalid、Fail、Error、Throw、Reject、BadInput、Null、None、Nil、Negative、raises_、_throws_、_returns_error 提示 negative。
27. 2) Assertion type——Assert.ThrowsException / Assert.Throws / Should().Throw() / pytest.raises / expect(fn).toThrow / assertThrows / assert.Error(t, err) / expect { ... }.to raise_error / #[should_panic] / XCTAssertThrowsError / Should -Throw / EXPECT_THROW 提示 negative。
28. 3) Input values——null / None / nil / undefined、""、0、-1、int.MaxValue / sys.maxsize / Number.MAX_SAFE_INTEGER / math.MaxInt64 / i32::MAX、empty collections 提示 boundary。
29. 4) Setup complexity——minimal setup 加 basic assertions 提示 smoke；external dependencies（file/db/net/env）提示 integration。
30. 5) Comments and names——引用 issue numbers 或 "regression" / "bug" / "fix for #..." 提示 regression。
31. 6) Timing assertions——Stopwatch、BenchmarkDotNet、elapsed-time checks；pytest-benchmark fixtures；benchmark.js；JMH @Benchmark；go test -bench；criterion.rs；XCTMetric；Google Benchmark；kotlinx-benchmark 提示 performance。
32. 7) Feature centrality——测试 primary public API entry points 或 critical user workflows 提示 critical-path。
33. 8) Security patterns——验证 auth、检查 permissions、sanitizes input、测试 injection、处理 tokens/secrets 提示 security。
34. 9) Parallel/async constructs——按语言的 concurrency primitives（见 Trait Taxonomy 表）提示 concurrency。
35. 10) Fault injection——模拟 failures、测试 retries、timeouts 或 circuit breakers 提示 resilience。
36. 11) State mutation——删除 external records、drops resources、修改 shared/global state 提示 destructive。
37. 12) Full-stack flow——测试跨越 entry point 到 data layer 再到 final response，覆盖完整 user scenario 提示 end-to-end。
38. 13) Config/settings——加载 configuration、测试 missing keys、验证 options、检查 environment variables 提示 configuration。
39. 14) Known instability——测试有 skip / ignore annotations 且注释与 flakiness 相关，或名称含 "flaky" / "intermittent" 提示 flaky。
40. 15) Default——若测试验证正常 success path，tag positive。
41. 在 positive 和 negative 之间犹豫时，读 assertion：断言成功 -> positive；断言失败 -> negative。
42. 若请求 distribution 或 coverage-shape audit，在总结前用可用 production code 将每个测试映射到它执行的具体 outcome。指出重复的 boundary coverage，以及 test inventory 是否代表 named thresholds 的两侧和 business-critical paths 上可观察的 collaborator outcomes。保持为简洁的 distribution observations，不要新增 trait values。不要执行 mutation reasoning、指定新测试，或扩展到 test-gap-analysis 负责的 behavioral-gap audit。
43. Step 4：若能力是 auto-edit，为每个 test method 添加适当 attribute。将 trait attributes 放在现有 test attribute 附近。在 individual test-method/case 级别应用 traits。不要用一个 class-level category 代替 method-level classification：不同 method 通常执行不同 positive、negative 和 boundary behavior。
44. auto-edit 框架应用示例：MSTest： [TestMethod] [TestCategory("negative")] [TestCategory("boundary")] public void Parse_NullInput_ThrowsArgumentNullException() { ... }
45. xUnit： [Fact] [Trait("Category", "positive")] [Trait("Category", "critical-path")] public void CreateOrder_ValidItems_ReturnsConfirmation() { ... }
46. NUnit： [Test] [Category("regression")] [Category("negative")] public void Calculate_OverflowInput_ReturnsError() // Fix for #1234 { ... }
47. pytest： @pytest.mark.negative @pytest.mark.boundary def test_parse_none_input_raises_value_error(): ...
48. JUnit 5： @Test @Tag("positive") @Tag("critical-path") void createOrder_validItems_returnsConfirmation() { ... }
49. TestNG： @Test(groups = {"negative", "boundary"}) public void parse_nullInput_throwsIllegalArgumentException() { ... }
50. RSpec： it "rejects null input", :negative, :boundary do ... end
51. Pester： It 'Rejects null input' -Tag 'negative','boundary' { ... }
52. Kotest： @Tags(Negative, Boundary) class ParserSpec : StringSpec({ "rejects null input" { ... } })
53. Swift Testing： @Test(.tags(.negative, .boundary)) func parseNullInputThrows() throws { ... }
54. Catch2： TEST_CASE("Parse null input throws", "[negative][boundary]") { ... }
55. 若能力是 report-only（Go standard testing、plain Jest/Vitest without convention、Rust without project-specific cfg、plain XCTest、plain GoogleTest、plain Mocha），不要修改源文件。改为输出每个测试到 suggested tags 的简洁映射。仅当用户询问如何持久化或过滤这些 tags 时，才推荐 project-wide convention；analysis-only 请求应报告后停止。
56. 若能力是 convention-based（如 Go //go:build integration、*_integration_test.go、GoogleTest INTEGRATION_* prefix），仅在用户已确认项目约定时输出 canonical edits。否则按 report-only 处理。
57. Step 5：tagging 后生成 summary table。除非用户要求完整 taxonomy，否则只包含 count 非零的 traits；zero-filled rows 会掩盖 suite 实际 shape。对于小型 report-only suite，将 per-test mapping 和非零 distribution 放在一起，不要扩展成 dashboard。表格格式： | Trait | Count | % of Total |，示例 positive 50 64.1%、negative 28 35.9%、boundary 8 10.3%、critical-path 12 15.4%、**Total tests** **78** --；注明 Percentages 超过 100% 是因为 tests 可有多个 traits。
58. summary 中包括 observations：positive 与 negative tests 的 ratio；关键 public APIs 是否存在 critical-path tests；任何无法自信分类的 tests（列出供人工 review）。
59. boundary 和每个其他 specialized trait 都是 additive。boundary success case 仍计入 positive；rejected boundary 仍计入 negative。应用此规则后再推导 positive/negative distribution。
60. Step 6：在报告前验证 edits。对每个 auto-edit 框架，运行最窄的命令来编译被编辑的 attributes 并确认 test discovery。即使用户只要求 add tags 也必需：语法上看似合理的 attributes 不算完成的 edit。
61. .NET 最低验证：运行 dotnet build <test-project>，然后用 dotnet test <test-project> --list-tests --no-build 确认 discovery。除非用户要求，不要执行 suite；把执行路由到 run-tests。
62. pytest 最低验证：用仓库配置的 pytest command collect 被编辑的 suite。
63. JUnit/TestNG 最低验证：通过仓库的 Maven/Gradle test task 编译 tests。
64. 其他 auto-edit 框架最低验证：使用仓库最窄的 compile 或 test-discovery command。
65. 若 edit 或 patch application 不确定，在验证前重新打开完整 edited file，并用每个 inventory row 与该 test 旁的实际 attribute 对账。不要根据 partial diff 或 intended patch 报告成功。若验证失败，报告 exact command 和 error；绝不为未编译的 edits 发布 successful distribution handoff。
66. 验证清单：每个 test method 至少有一个 trait classification（minimum positive 或 negative）——report-only 框架在报告中，auto-edit 框架作为 attribute。
67. 验证清单：total 等于 per-test inventory count，且显示的 trait counts 来自该 inventory。
68. 验证清单：不发明 taxonomy table 之外的 trait values。
69. 验证清单：已有 trait attributes 被保留，未重复。
70. 验证清单：trait summary table 已生成。
71. 验证清单：对 auto-edit 框架，项目仍能 build / tests 仍能 discover，且不执行未请求的 tests（dotnet build 加 list mode / pytest --collect-only / mvn test-compile / go vet ./... / cargo check --tests / npm run test:list / equivalent）。
72. 验证清单：final summary 引用成功的 validation commands，并在有 discovery command 时引用 discovered test count。
73. 验证清单：对 report-only 框架，未修改任何 source files。
74. 验证清单：对 convention-based 框架，仅在确认 project convention 后才应用 edits。
75. 常见陷阱与处理：不要不读 test body 就猜 traits；始终读 assertions 和 setup 以准确分类。
76. 不要只把测试标为 boundary 而没有 positive/negative；每个测试还应是 positive 或 negative——boundary 是 additive。
77. 不要对检测到的框架使用错误 attribute syntax；匹配加载的 extension 或内置表（不要在 xUnit 放 [TestCategory]，不要在 unittest 放 @pytest.mark.x）。
78. 不要重复已有 category attribute；在 Step 2 添加前检查 pre-existing traits。
79. 不要过度标为 critical-path；仅保留给 primary public entry points 的测试，而不是每个 helper。
80. 不要编辑 Go / plain Jest / plain Rust / plain XCTest / plain GoogleTest 源码；这些默认是 report-only——改为输出 Markdown 表格。仅当用户确认 project-wide convention（build tag、file suffix、describe-prefix、test-plan grouping）时才编辑。
81. 不要为 convention-based 框架发明 tag prefixes；采用前确认项目现有约定——不要在 _integration_test.go、//go:build integration 或 IntegrationTest prefix 之间猜。
82. 不要遗漏语言特定的 concurrency / async primitives；可用时用 loaded extension，否则用 Trait Taxonomy 的 concurrency row。

适用边界 · 注意事项

• 不用于从零编写新测试；应使用 code-testing-agent（任意语言）或 writing-mstest-tests（MSTest）。
• 不用于运行/过滤测试、迁移测试框架、通用质量/smell/flakiness/断言审计，也不接管 coverage-analysis、crap-score、test-gap-analysis 的职责。
• 不用于默认 report-only 框架（Go standard testing、无约定 Jest/Vitest、无项目 cfg 的 Rust、无 test plan 的 XCTest、无前缀约定的 GoogleTest、无 describe-prefix 约定的 Mocha）的源码编辑，除非用户确认项目约定；convention-based 框架也仅在确认约定后编辑。