{"id":"9eddb195-5d5b-4472-9f41-24cee0c81136","entityType":"agent","slug":"clawhub-gechengling-ai-test-strategy-architect","name":"AI Test Strategy Architect","canonicalUrl":"https://www.xpersona.co/agent/clawhub-gechengling-ai-test-strategy-architect","canonicalPath":"/agent/clawhub-gechengling-ai-test-strategy-architect","generatedAt":"2026-10-11T21:56:01.672Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T19:17:12.200Z","emptyReason":null},"description":"AI-powered test strategy and automation assistant — design comprehensive testing frameworks, generate unit/integration/e2e test cases, implement test automation for web/mobile/API, and build CI/CD testing pipelines. Covers Test-Driven Development (TDD), Behavior-Driven Development (BDD), property-based testing, and AI-augmented test generation. Built for QA engineers, software developers, test leads, and DevOps teams shipping reliable software. Keywords: test automation, unit testing, integration testing, e2e testing, TDD, BDD, CI/CD testing, Selenium, Playwright, Pytest, Jest, testing framework, test strategy, quality assurance, 测试自动化, 单元测试, 集成测试, 端到端测试, 测试策略, 质量保障. Skill: AI Test Strategy Architect Owner: gechengling Summary: AI-powered test strategy and automation assistant — design comprehensive testing frameworks, generate unit/integration/e2e test cases, implement test automation for web/mobile/API, and build CI/CD testing pipelines. Covers Test-Driven Development (TDD), Behavior-Driven Development (BDD), property-based testing, and AI-augmented test generation. Built for Q","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17ewqc4f2s6gpcbm88hy7fgvn85kg1g:ai-test-strategy-architect","sourceUrl":"https://clawhub.ai/gechengling/ai-test-strategy-architect","homepage":"https://clawhub.ai/gechengling/skills/ai-test-strategy-architect","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/gechengling/ai-test-strategy-architect","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/gechengling/skills/ai-test-strategy-architect","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"AI-powered test strategy and automation assistant — design comprehensive testing frameworks, generate unit/integration/e2e test cases, implement test automation"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T19:17:12.200Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T19:17:12.200Z","emptyReason":null},"stars":null,"forks":null,"downloads":1004,"likes":null,"task":null,"library":null,"packageName":null,"latestVersion":"1.0.2","tractionLabel":"1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T19:17:12.021Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T19:17:12.200Z","lastCrawledAt":"2026-10-11T19:17:12.021Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T19:17:12.021Z","lastVerifiedAt":null,"highlights":[{"version":"1.0.2","createdAt":"2026-09-28T05:23:43.046Z","changelog":"修复Playwright Python示例toBeVisible()→to_be_visible()真实代码缺陷（SDI-4）并补Python/JS断言名对照表；新增Language Policy（SQP-3）；收窄触发加必需上下文与非触发表（SQP-1）；三张表各新增一列；新增Example 6门禁设计；生态动态更新至2026-09-28","fileCount":3,"zipByteSize":17068},{"version":"1.0.1","createdAt":"2026-09-10T05:32:43.271Z","changelog":"1.0.1: 四模块各补实例、金字塔配比表、框架对比扩至10列12行、示例4(ETL)-5(高覆盖仍出事故)、质量门禁配置、生态现状、修正Python Playwright断言","fileCount":3,"zipByteSize":14518},{"version":"1.0.0","createdAt":"2026-05-19T12:18:35.985Z","changelog":"AI Test Strategy Architect 1.0.0 - Initial release of an AI-powered assistant for comprehensive test strategy and automation. - Designs robust testing frameworks for unit, integration, and end-to-end (E2E) testing across web, mobile, and API applications. - Generates test cases, implements automation (including TDD, BDD, property-based testing), and integrates with CI/CD pipelines. - Supports multiple frameworks and tools (Selenium, Playwright, Pytest, Jest). - Offers workflows for test strategy development and quick test case generation. - Provides seamless prompts and triggers in both English and Chinese for ease of use.","fileCount":3,"zipByteSize":6810}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17ewqc4f2s6gpcbm88hy7fgvn85kg1g:ai-test-strategy-architect","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-ai-test-strategy-architect/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-ai-test-strategy-architect/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-ai-test-strategy-architect/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-ai-test-strategy-architect/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-ai-test-strategy-architect/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-ai-test-strategy-architect/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T21:56:01.670Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-ai-test-strategy-architect/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-ai-test-strategy-architect/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-ai-test-strategy-architect/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-ai-test-strategy-architect/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T19:17:12.200Z","emptyReason":null},"readme":"Skill: AI Test Strategy Architect\n\nOwner: gechengling\n\nSummary: AI-powered test strategy and automation assistant — design comprehensive testing frameworks, generate unit/integration/e2e test cases, implement test automation for web/mobile/API, and build CI/CD testing pipelines. Covers Test-Driven Development (TDD), Behavior-Driven Development (BDD), property-based testing, and AI-augmented test generation. Built for QA engineers, software developers, test leads, and DevOps teams shipping reliable software. Keywords: test automation, unit testing, integration testing, e2e testing, TDD, BDD, CI/CD testing, Selenium, Playwright, Pytest, Jest, testing framework, test strategy, quality assurance, 测试自动化, 单元测试, 集成测试, 端到端测试, 测试策略, 质量保障.\n\nTags: ai-test-strategy-architect:1.0.2, latest:1.0.2\n\nVersion history:\n\nv1.0.2 | 2026-09-28T05:23:43.046Z | user\n\n修复Playwright Python示例toBeVisible()→to_be_visible()真实代码缺陷（SDI-4）并补Python/JS断言名对照表；新增Language Policy（SQP-3）；收窄触发加必需上下文与非触发表（SQP-1）；三张表各新增一列；新增Example 6门禁设计；生态动态更新至2026-09-28\n\nv1.0.1 | 2026-09-10T05:32:43.271Z | user\n\n1.0.1: 四模块各补实例、金字塔配比表、框架对比扩至10列12行、示例4(ETL)-5(高覆盖仍出事故)、质量门禁配置、生态现状、修正Python Playwright断言\n\nv1.0.0 | 2026-05-19T12:18:35.985Z | auto\n\nAI Test Strategy Architect 1.0.0\n\n- Initial release of an AI-powered assistant for comprehensive test strategy and automation.\n- Designs robust testing frameworks for unit, integration, and end-to-end (E2E) testing across web, mobile, and API applications.\n- Generates test cases, implements automation (including TDD, BDD, property-based testing), and integrates with CI/CD pipelines.\n- Supports multiple frameworks and tools (Selenium, Playwright, Pytest, Jest).\n- Offers workflows for test strategy development and quick test case generation.\n- Provides seamless prompts and triggers in both English and Chinese for ease of use.\n\nArchive index:\n\nArchive v1.0.2: 3 files, 17068 bytes\n\nFiles: skill-card.md (1707b), SKILL.md (36474b), _meta.json (145b)\n\nFile v1.0.2:SKILL.md\n\n---\r\nname: \"AI Test Strategy Architect\"\r\ndescription: \"AI-powered test strategy and automation assistant — design comprehensive testing frameworks, generate unit/integration/e2e test cases, implement test automation for web/mobile/API, and build CI/CD testing pipelines. Covers Test-Driven Development (TDD), Behavior-Driven Development (BDD), property-based testing, and AI-augmented test generation. Built for QA engineers, software developers, test leads, and DevOps teams shipping reliable software. Keywords: test automation, unit testing, integration testing, e2e testing, TDD, BDD, CI/CD testing, Selenium, Playwright, Pytest, Jest, testing framework, test strategy, quality assurance, 测试自动化, 单元测试, 集成测试, 端到端测试, 测试策略, 质量保障.\"\r\nversion: \"1.0.2\"\r\n---\r\n\r\n# AI Test Strategy Architect\r\n\r\n## Overview\r\n\r\nBuild testing that catches bugs before users do. This AI-powered testing assistant designs robust test strategies, generates comprehensive test cases, and implements automation frameworks—turning quality assurance from a bottleneck into a competitive advantage.\r\n\r\n## Language Policy（语言策略 / SQP-3）\r\n\r\n本技能同时提供中英双语触发词与内容，语言使用规则如下，避免输出语言飘移：\r\n\r\n| 项目 | 规则 |\r\n|---|---|\r\n| 默认语言 | 跟随提问语言：中文提问用中文回答，英文提问用英文回答 |\r\n| 术语 | 保留英文原词（`property-based testing`、`page object`、`flaky`），首次出现时括注中文 |\r\n| 代码与配置 | 一律原样保留，不翻译标识符、字符串与注释语言之外的部分 |\r\n| 混合提问 | 以正文主体语言为准；若仍不明确，直接询问一次，不要自行猜测 |\r\n| 表格与模板 | 同一份产物内保持单一语言，不要中英混排 |\r\n| 切换 | 用户任何时候说“用英文/用中文回答”，立即切换，不影响技术内容 |\r\n\r\n\r\n\r\n## Triggers\r\n\r\n- 中文触发词：`测试策略`、`单元测试`、`集成测试`、`E2E测试`、`自动化测试`、`测试用例`、`TDD`、`BDD`、`Playwright测试`、`Selenium`、`测试覆盖率`\r\n- English triggers: `test strategy`, `unit testing`, `integration testing`, `e2e testing`, `automated testing`, `test cases`, `TDD`, `BDD`, `Playwright`, `Selenium`, `test coverage`, `CI/CD testing`\r\n\r\n**Required context（至少满足一条才激活）**\r\n1. 需要设计或改进一套测试策略、分层比例或门禁；或\r\n2. 需要为具体代码/接口/流程设计用例；或\r\n3. 需要把测试接入 CI/CD 并设定质量门禁；或\r\n4. 需要诊断测试体系本身的健康问题（覆盖率虚高、flaky、断言强度不足）。\r\n\r\n**Non-triggers（不激活）**\r\n\r\n| 请求 | 为什么不归本技能 | 应转向 |\r\n|---|---|---|\r\n| “帮我修这个 bug” | 缺陷修复，不是测试设计 | 通用调试 |\r\n| “这个接口返回 500，帮我看看” | 生产问题排查 | 运维/日志排查 |\r\n| “压测一下能扛多少 QPS” | 性能工程，目标与方法都不同 | 性能测试工具（k6/Locust） |\r\n| “做一次安全渗透测试” | 安全测试需专门授权与方法 | 安全测试流程 |\r\n| “把这份需求文档总结一下” | 文档处理，无测试对象 | 文档摘要 |\r\n| “安装 Playwright 环境” | 环境搭建操作 | 官方安装文档 |\r\n\r\n**执行边界声明**：本技能输出测试代码、配置形态与策略文档，供你在自己的环境中\r\n审阅后运行。它不执行测试、不写入你的仓库、不访问你的 CI。文中代码仅作参考材料。\r\n\r\n## Features\r\n\r\n### 1. Test Strategy Design\r\n- Assess project requirements and risk profiles\r\n- Design tailored testing pyramids (unit/integration/e2e ratios)\r\n- Select appropriate testing frameworks per use case\r\n- Define test data management strategies\r\n- Create test environment specifications\r\n\r\n\r\n**Worked example — risk-based scope for a payments-style service**\r\n\r\n| Module | 失效影响 | 发生概率 | 风险分 | 测试投入 | 具体手段 | 门禁归属 |\r\n|---|---|---|---|---|---|---|\r\n| 保费计算 | 资金错误，监管风险 | 中 | 9 | 最高 | 属性测试 + 黄金样本回归 + 变更检测 | PR 阻断 + nightly 变异测试 |\r\n| 投保校验 | 单用户受阻 | 高 | 6 | 高 | 边界表 + 参数化 | PR 阻断 |\r\n| 支付回调 | 重复扣款 | 低 | 6 | 高 | 幂等性专项 + 故障注入 | PR 阻断 + nightly 故障注入 |\r\n| 报表导出 | 内部使用 | 中 | 3 | 中 | 快照测试 | nightly 快照比对 |\r\n| 邮件通知 | 体验问题 | 中 | 2 | 低 | 冒烟 + 手动抽查 | 不设门禁，仅冒烟 |\r\n| 管理后台筛选 | 内部低效 | 低 | 1 | 最低 | 冒烟即可 | 不设门禁 |\r\n\r\n评分方式：影响（1–5）× 概率（1–2），≥8 必须有属性测试与变更检测，\r\n≤3 只做冒烟。这样把预算集中在真正会出钱的地方，而不是平均撒。\r\n\r\n**测试环境规格清单（常被忽略的 5 项）**\r\n1. 数据种子能否一键重建（不能就要先解决这个，否则一切自动化都是脆弱的）\r\n2. 第三方依赖是否有稳定的测试替身（沙箱/契约/Mock 三选一）\r\n3. 环境之间配置差异是否有单一来源（配置漂移是\"本地能跑线上挂\"的主因）\r\n4. 测试数据是否含脱敏后的真实分布（用全是合法值的假数据测不出边界）\r\n5. 每个环境的重置成本与时限（重置超过 10 分钟的流水线会被绕过）\r\n\r\n\r\n### 2. Test Case Generation\r\n- Generate unit tests from code functions/methods\r\n- Create integration test scenarios from API specs\r\n- Design end-to-end user journey tests\r\n- Build property-based tests for edge cases\r\n- Generate negative test cases (error handling)\r\n\r\n\r\n**Worked example — 一个参数的完整用例矩阵（参数化而非堆砌）**\r\n\r\n以 `calculate_discount(price, discount_percent, is_loyal)` 为例，不要写 12 个\r\n独立函数，用一张表驱动：\r\n\r\n| price | discount_percent | is_loyal | 期望 | 覆盖的意图 |\r\n|---|---|---|---|---|\r\n| 100.00 | 0 | False | 100.00 | 恒等 |\r\n| 100.00 | 20 | False | 80.00 | 基本路径 |\r\n| 100.00 | 20 | True | 76.00 | 忠诚用户叠加 |\r\n| 100.00 | 100 | False | 0.00 | 上边界 |\r\n| 0.00 | 50 | False | 0.00 | 零值 |\r\n| 99.99 | 33 | False | 66.99 | 舍入 |\r\n| -10.00 | 10 | False | ValueError | 负价 |\r\n| 100.00 | -5 | False | ValueError | 下越界 |\r\n| 100.00 | 150 | False | ValueError | 上越界 |\r\n\r\n对应的参数化写法要点：把\"期望异常\"也放进同一张表，用哨兵值标记，\r\n不要在参数化之外再补一批独立的异常测试——那会让两套用例逐渐分叉。\r\n\r\n**属性测试该测什么（property-based，不是随机测试）**\r\n\r\n对同一个函数，属性测试关心的是不变量，例如：\r\n- 对任意合法输入，`0 <= result <= price`\r\n- 对任意合法输入，`discount_percent` 单调不减时，`result` 单调不增\r\n- 对任意合法输入，`result == round(result, 2)`\r\n- 对任意合法输入，同样参数调用两次结果相同（纯函数性）\r\n\r\n最小可运行的 Hypothesis 形态：\r\n\r\n```python\r\nfrom hypothesis import given, strategies as st\r\n\r\n@given(\r\n    price=st.floats(min_value=0, max_value=1e6, allow_nan=False),\r\n    pct=st.floats(min_value=0, max_value=100, allow_nan=False),\r\n    loyal=st.booleans(),\r\n)\r\ndef test_result_within_bounds(price, pct, loyal):\r\n    r = calculate_discount(price, pct, loyal)\r\n    assert 0 <= r <= price\r\n    assert r == round(r, 2)\r\n```\r\n\r\n注意：这段代码是给你在自己环境运行的参考材料，本技能不代为执行。\r\n\r\n\r\n### 3. Test Automation Implementation\r\n- Scaffold test projects with proper structure\r\n- Implement page object models for UI tests\r\n- Set up API test frameworks with data-driven approaches\r\n- Configure test parallelization and distribution\r\n- Implement visual regression testing\r\n\r\n\r\n**Worked example — page object 的正确粒度**\r\n\r\n反例（把业务流程塞进 page object，导致一改就全崩）：\r\n\r\n```python\r\nclass CheckoutPage:\r\n    def buy_whole_flow(self, card):   # 不要这样\r\n        ...\r\n```\r\n\r\n正例（page object 只暴露页面能力，流程留在测试里）：\r\n\r\n```python\r\nclass ProductPage:\r\n    def __init__(self, page): self.page = page\r\n    def add_to_cart(self):\r\n        self.page.get_by_test_id(\"add-to-cart\").click()\r\n    def cart_count(self) -> int:\r\n        return self.page.get_by_test_id(\"cart-item\").count()\r\n\r\nclass CheckoutPage:\r\n    def __init__(self, page): self.page = page\r\n    def pay_with(self, card: str, expiry: str, cvv: str):\r\n        self.page.get_by_label(\"card number\").fill(card)\r\n        self.page.get_by_label(\"expiry\").fill(expiry)\r\n        self.page.get_by_label(\"cvv\").fill(cvv)\r\n        self.page.get_by_test_id(\"place-order\").click()\r\n    def order_number(self) -> str:\r\n        return self.page.get_by_test_id(\"order-number\").inner_text()\r\n```\r\n\r\n判据：page object 里不应出现断言（`assert` 属于测试），也不应出现跨页面跳转。\r\n跳转留在测试用例里，页面对象只负责\"这一页能做什么\"。\r\n\r\n**并行化的三条硬约束**\r\n1. 数据隔离：并行 worker 不能共用同一条测试数据，用 worker id 生成唯一前缀。\r\n2. 端口与临时目录：并行时端口冲突是最常见的\"随机失败\"，必须动态分配。\r\n3. 共享服务：若必须共用一个外部服务（如支付沙箱），要么串行，要么限流——\r\n   否则你会得到一批看起来像 flaky 的资源竞争失败。\r\n\r\n\r\n### 4. CI/CD Pipeline Integration\r\n- Design testing stages in CI/CD pipelines\r\n- Configure test reporting and dashboards\r\n- Set up automated quality gates\r\n- Implement canary/feature flag testing strategies\r\n- Create performance test thresholds in pipelines\r\n\r\n\r\n**Worked example — 四阶段流水线与门禁**\r\n\r\n| 阶段 | 运行内容 | 时限 | 失败处理 | 门禁指标 |\r\n|---|---|---|---|---|\r\n| commit (pre-push) | lint + 单元测试(受影响模块) | ≤ 60 s | 阻断提交 | 0 失败 |\r\n| PR | 全量单元 + 集成 + 契约 | ≤ 8 min | 阻断合并 | 覆盖率不低于基线 |\r\n| merge (main) | 全量 + E2E 冒烟 | ≤ 20 min | 阻断发布流水线 | 冒烟 100% 通过 |\r\n| nightly | 全量 E2E + 性能 + 变异测试 | ≤ 2 h | 次日处理，不阻断 | 变异分趋势不下降 |\r\n\r\n关键设计：把慢的、不稳定的放 nightly，把快的、确定的放 PR。\r\n如果 PR 阶段超过 8 分钟，工程师会开始绕过它——这是流水线失效的真实起点。\r\n\r\n**质量门禁配置示例（概念形态，按你的 CI 语法调整）**\r\n\r\n```yaml\r\nquality_gates:\r\n  coverage:\r\n    metric: line\r\n    floor: 72            # 当前实际值 + 2，不要一上来写 90\r\n    ratchet: true        # 只允许上升，不允许回落\r\n    exclude: [\"generated/*\", \"migrations/*\"]\r\n  flakiness:\r\n    quarantine_threshold: 0.01   # 100 次里失败 1 次即隔离\r\n    quarantine_expiry_days: 14   # 隔离不是删除，到期必须处理\r\n  performance:\r\n    p95_latency_ms: 800\r\n    regression_tolerance: 0.10   # 允许 10% 波动，超过即失败\r\n  blocking:\r\n    - name: critical_path_e2e\r\n      on_failure: stop_pipeline\r\n    - name: visual_diff\r\n      on_failure: require_human_approval   # 视觉差异必须人看\r\n```\r\n\r\n注意：以上为配置形态示例，需在用户自己的 CI 环境中运行与调整。\r\n\r\n\r\n## Workflow\r\n\r\n### Comprehensive Test Strategy Workflow\r\n\r\n```\r\nPhase 1: Assessment\r\n├── Analyze project architecture\r\n├── Identify critical user flows\r\n├── Assess technical risks\r\n├── Define quality metrics\r\n└── Select testing tools\r\n\r\nPhase 2: Design\r\n├── Design test pyramid\r\n├── Define test scope per layer\r\n├── Create test data strategy\r\n├── Document test environment needs\r\n└── Plan test automation approach\r\n\r\nPhase 3: Implementation\r\n├── Set up test project structure\r\n├── Implement unit tests\r\n├── Build integration test suite\r\n├── Create e2e test scenarios\r\n└── Configure test runners\r\n\r\nPhase 4: Automation\r\n├── Integrate with CI/CD\r\n├── Set up test reporting\r\n├── Configure parallel execution\r\n├── Implement test monitoring\r\n└── Create quality dashboards\r\n\r\nPhase 5: Maintenance\r\n├── Review test effectiveness\r\n├── Optimize slow tests\r\n├── Update for new features\r\n└── Archive obsolete tests\r\n```\r\n\r\n### Quick Test Generation Workflow\r\n\r\n```\r\n1. INPUT: Source code or feature description\r\n   ↓\r\n2. ANALYZE: Identify testable units\r\n   - Functions/methods\r\n   - User interactions\r\n   - API endpoints\r\n   ↓\r\n3. GENERATE: Create test cases\r\n   - Happy path scenarios\r\n   - Edge cases\r\n   - Error scenarios\r\n   - Boundary conditions\r\n   ↓\r\n4. VALIDATE: Run tests, fix failures\r\n   ↓\r\n5. OPTIMIZE: Improve coverage and speed\r\n```\r\n\r\n## Pyramid Ratios by Project Type\r\n\r\nThe classic 60/30/10 split is a starting point, not a law. Use this instead:\r\n\r\n| 项目类型 | Unit | Integration | E2E | 额外层 | 理由 | 常见误判 |\r\n|---|---|---|---|---|---|---|\r\n| 纯前端 Web 应用 | 50% | 20%（组件/契约） | 30% | 视觉回归 | UI 是主要风险面，E2E 占比自然更高 | 把视觉回归当成 E2E 的替代品 |\r\n| 后端 API 服务 | 60% | 35% | 5% | 契约测试 | 逻辑在服务端，E2E 只需关键链路 | 用 E2E 去覆盖所有业务分支 |\r\n| 数据/ETL 管道 | 45% | 25% | 5% | 25% 数据质量测试 | 行数、空值率、分布漂移比功能更重要 | 只测转换函数，忽略数据质量层 |\r\n| 移动端 | 55% | 20% | 25% | 设备矩阵冒烟 | 设备与系统版本碎片化推高 UI 层 | 只在一台真机上跑冒烟就算设备覆盖 |\r\n| 金融/保险核心 | 65% | 25% | 10% | 属性测试 + 审计测试 | 计算正确性优先，且需可追溯 | 只靠单元测试，缺审计留痕测试 |\r\n| 内部工具 | 40% | 30% | 30% | 探索式测试 | 用户少、变更快，重自动化反而拖慢 | 照搬 60/30/10 做全套自动化 |\r\n\r\n**如何判断比例是否合适**\r\n- E2E 占比高且经常红 → 逻辑下沉不足，把验证前移到集成层\r\n- 单元覆盖高但线上仍有事故 → 断言太弱，引入变异测试检验\"断言强度\"\r\n- 集成层几乎为零 → 多半是\"只能整体起来才能测\"，这是架构问题不是测试问题\r\n\r\n## Input Examples\r\n\r\n### Example 1: Function to Unit Test\r\n\r\n**Input Code:**\r\n```python\r\ndef calculate_discount(price: float, discount_percent: float, is_loyal: bool) -> float:\r\n    \"\"\"\r\n    Calculate final price after discount.\r\n    \r\n    Args:\r\n        price: Original price\r\n        discount_percent: Discount percentage (0-100)\r\n        is_loyal: Whether customer is a loyalty member\r\n    \r\n    Returns:\r\n        Final price after discount\r\n    \"\"\"\r\n    if price < 0:\r\n        raise ValueError(\"Price cannot be negative\")\r\n    if discount_percent < 0 or discount_percent > 100:\r\n        raise ValueError(\"Discount must be between 0 and 100\")\r\n    \r\n    discount_multiplier = 1 - (discount_percent / 100)\r\n    \r\n    if is_loyal:\r\n        # Loyalty members get extra 5% off\r\n        final_multiplier = discount_multiplier * 0.95\r\n    else:\r\n        final_multiplier = discount_multiplier\r\n    \r\n    return round(price * final_multiplier, 2)\r\n```\r\n\r\n**Generated Test Cases:**\r\n```python\r\nimport pytest\r\nfrom your_module import calculate_discount\r\n\r\nclass TestCalculateDiscount:\r\n    \"\"\"Unit tests for calculate_discount function\"\"\"\r\n    \r\n    # Happy path tests\r\n    def test_no_discount_returns_original_price(self):\r\n        \"\"\"No discount should return the original price\"\"\"\r\n        assert calculate_discount(100.00, 0, False) == 100.00\r\n    \r\n    def test_standard_discount(self):\r\n        \"\"\"Basic discount calculation\"\"\"\r\n        assert calculate_discount(100.00, 20, False) == 80.00\r\n    \r\n    def test_loyal_customer_extra_discount(self):\r\n        \"\"\"Loyal customers get additional 5% off\"\"\"\r\n        result = calculate_discount(100.00, 20, True)\r\n        expected = round(100 * 0.80 * 0.95, 2)  # 76.00\r\n        assert result == expected\r\n    \r\n    def test_full_discount(self):\r\n        \"\"\"100% discount should result in 0\"\"\"\r\n        assert calculate_discount(100.00, 100, False) == 0.00\r\n    \r\n    # Edge cases\r\n    def test_zero_price(self):\r\n        \"\"\"Zero price should return zero\"\"\"\r\n        assert calculate_discount(0.00, 50, False) == 0.00\r\n    \r\n    def test_rounding_to_cents(self):\r\n        \"\"\"Prices should round to 2 decimal places\"\"\"\r\n        result = calculate_discount(99.99, 33, False)\r\n        assert result == round(99.99 * 0.67, 2)\r\n    \r\n    # Error cases\r\n    def test_negative_price_raises_error(self):\r\n        \"\"\"Negative price should raise ValueError\"\"\"\r\n        with pytest.raises(ValueError, match=\"Price cannot be negative\"):\r\n            calculate_discount(-10.00, 10, False)\r\n    \r\n    def test_negative_discount_raises_error(self):\r\n        \"\"\"Negative discount should raise ValueError\"\"\"\r\n        with pytest.raises(ValueError, match=\"Discount must be between\"):\r\n            calculate_discount(100.00, -5, False)\r\n    \r\n    def test_over_100_discount_raises_error(self):\r\n        \"\"\"Discount over 100% should raise ValueError\"\"\"\r\n        with pytest.raises(ValueError, match=\"Discount must be between\"):\r\n            calculate_discount(100.00, 150, False)\r\n    \r\n    # Boundary tests\r\n    def test_boundary_zero_percent_discount(self):\r\n        \"\"\"0% is valid discount\"\"\"\r\n        assert calculate_discount(50.00, 0, False) == 50.00\r\n    \r\n    def test_boundary_hundred_percent_discount(self):\r\n        \"\"\"100% is valid discount\"\"\"\r\n        assert calculate_discount(50.00, 100, False) == 0.00\r\n```\r\n\r\n### Example 2: API Integration Test\r\n\r\n**Input:** OpenAPI endpoint definition\r\n```yaml\r\npaths:\r\n  /api/v1/users/{userId}/orders:\r\n    get:\r\n      summary: Get user orders\r\n      parameters:\r\n        - name: userId\r\n          in: path\r\n          required: true\r\n          schema:\r\n            type: string\r\n        - name: status\r\n          in: query\r\n          schema:\r\n            type: string\r\n            enum: [pending, shipped, delivered]\r\n      responses:\r\n        '200':\r\n          description: List of orders\r\n        '401':\r\n          description: Unauthorized\r\n        '404':\r\n          description: User not found\r\n```\r\n\r\n**Generated Integration Test:**\r\n```python\r\nimport pytest\r\nimport requests\r\nfrom typing import Dict\r\n\r\nBASE_URL = \"https://api.example.com\"\r\nHEADERS = {\"Authorization\": \"Bearer <test_token>\"}\r\n\r\nclass TestUserOrdersAPI:\r\n    \"\"\"Integration tests for User Orders endpoint\"\"\"\r\n    \r\n    @pytest.fixture\r\n    def test_user_id(self):\r\n        \"\"\"Fixture providing a test user with known orders\"\"\"\r\n        return \"user_123\"\r\n    \r\n    def test_get_orders_success(self, test_user_id: str):\r\n        \"\"\"Should return 200 with list of orders\"\"\"\r\n        response = requests.get(\r\n            f\"{BASE_URL}/api/v1/users/{test_user_id}/orders\",\r\n            headers=HEADERS\r\n        )\r\n        \r\n        assert response.status_code == 200\r\n        data = response.json()\r\n        assert \"orders\" in data\r\n        assert isinstance(data[\"orders\"], list)\r\n    \r\n    def test_get_orders_with_status_filter(self, test_user_id: str):\r\n        \"\"\"Should filter orders by status\"\"\"\r\n        response = requests.get(\r\n            f\"{BASE_URL}/api/v1/users/{test_user_id}/orders\",\r\n            params={\"status\": \"pending\"},\r\n            headers=HEADERS\r\n        )\r\n        \r\n        assert response.status_code == 200\r\n        orders = response.json()[\"orders\"]\r\n        assert all(order[\"status\"] == \"pending\" for order in orders)\r\n    \r\n    def test_get_orders_unauthorized(self, test_user_id: str):\r\n        \"\"\"Should return 401 without valid token\"\"\"\r\n        response = requests.get(\r\n            f\"{BASE_URL}/api/v1/users/{test_user_id}/orders\"\r\n        )\r\n        \r\n        assert response.status_code == 401\r\n    \r\n    def test_get_orders_user_not_found(self):\r\n        \"\"\"Should return 404 for non-existent user\"\"\"\r\n        response = requests.get(\r\n            f\"{BASE_URL}/api/v1/users/nonexistent_user/orders\",\r\n            headers=HEADERS\r\n        )\r\n        \r\n        assert response.status_code == 404\r\n        assert \"error\" in response.json()\r\n```\r\n\r\n### Example 3: E2E Test with Playwright\r\n\r\n**API 风格提醒（Python 与 JS 不同名，混用会静默失效）**\r\n\r\nPlaywright 的 Python 绑定用 snake_case，JavaScript/TypeScript 用 camelCase。\r\n同一个断言在两种语言里名字不同：\r\n\r\n| 意图 | Python | JS / TS |\r\n|---|---|---|\r\n| 可见 | `expect(loc).to_be_visible()` | `expect(loc).toBeVisible()` |\r\n| 数量 | `expect(loc).to_have_count(1)` | `expect(loc).toHaveCount(1)` |\r\n| 文本 | `expect(loc).to_have_text(\"ok\")` | `expect(loc).toHaveText(\"ok\")` |\r\n| 非空 | `expect(loc).not_to_be_empty()` | `expect(loc).not.toBeEmpty()` |\r\n\r\nPython 里写 `toBeVisible()` 不会报语法错误，但会抛 `AttributeError`；更糟的情况是\r\n被 IDE 自动补全\"修正\"成一个存在但语义不同的方法。**复制示例时先确认语言绑定。**\r\n下方示例统一使用 Python（snake_case）风格。\r\n\r\n**Input:** User journey description\r\n```\r\nUser flow: Login -> Add item to cart -> Checkout -> Verify order confirmation\r\n```\r\n\r\n**Generated E2E Test:**\r\n```python\r\nimport pytest\r\nfrom playwright.sync_api import Page, expect\r\n\r\n@pytest.fixture\r\ndef logged_in_page(page: Page):\r\n    \"\"\"Fixture that logs in user before each test\"\"\"\r\n    page.goto(\"https://shop.example.com/login\")\r\n    page.fill('[name=\"email\"]', \"test@example.com\")\r\n    page.fill('[name=\"password\"]', \"testpassword123\")\r\n    page.click('[type=\"submit\"]')\r\n    page.wait_for_url(\"**/dashboard\")\r\n    return page\r\n\r\ndef test_complete_checkout_flow(logged_in_page: Page):\r\n    \"\"\"End-to-end test: Login -> Add to cart -> Checkout -> Confirmation\"\"\"\r\n    page = logged_in_page\r\n    \r\n    # Step 1: Browse to product\r\n    page.goto(\"https://shop.example.com/products/widget-pro\")\r\n    page.click('[data-testid=\"add-to-cart\"]')\r\n    \r\n    # Step 2: Verify cart\r\n    page.click('[data-testid=\"cart-icon\"]')\r\n    expect(page.locator('[data-testid=\"cart-item\"]')).to_have_count(1)\r\n    \r\n    # Step 3: Proceed to checkout\r\n    page.click('[data-testid=\"checkout-button\"]')\r\n    page.fill('[name=\"shipping_address\"]', \"123 Test Street\")\r\n    page.fill('[name=\"zip_code\"]', \"12345\")\r\n    page.click('[data-testid=\"continue-payment\"]')\r\n    \r\n    # Step 4: Complete payment\r\n    page.fill('[name=\"card_number\"]', \"4242424242424242\")\r\n    page.fill('[name=\"expiry\"]', \"12/28\")\r\n    page.fill('[name=\"cvv\"]', \"123\")\r\n    page.click('[data-testid=\"place-order\"]')\r\n    \r\n    # Step 5: Verify confirmation\r\n    expect(page.locator('[data-testid=\"order-confirmation\"]')).to_be_visible()\r\n    expect(page.locator('[data-testid=\"order-number\"]')).not_to_be_empty()\r\n```\r\n\r\n## Output Templates\r\n\r\n### Template: Test Strategy Document\r\n```markdown\r\n# Test Strategy Document\r\n\r\n## Project Overview\r\n- Project Name: [Name]\r\n- Version: [Version]\r\n- Test Scope: [What's in/out]\r\n\r\n## Quality Objectives\r\n| Metric | Target | Measurement |\r\n|--------|--------|-------------|\r\n| Code Coverage | >80% | Codecov |\r\n| Bug Escape Rate | <5% | Bug Tracker |\r\n| Test Execution Time | <10 min | CI Pipeline |\r\n\r\n## Test Pyramid\r\n\r\n        ╱╲\r\n       ╱  ╲\r\n      ╱ E2E╲         [Few - 10%]\r\n     ╱──────╲\r\n    ╱Integration╲     [Some - 30%]\r\n   ╱────────────╲\r\n  ╱  Unit Tests  ╲   [Many - 60%]\r\n ╱────────────────╲\r\n\r\n## Testing Tools\r\n\r\n| Layer | Tool | Language |\r\n|-------|------|----------|\r\n| Unit | Pytest | Python |\r\n| Integration | pytest | Python |\r\n| E2E | Playwright | TypeScript |\r\n| API | REST Assured | Java |\r\n\r\n## Test Environments\r\n- Dev: https://dev.example.com\r\n- Staging: https://staging.example.com\r\n- Production: https://example.com\r\n\r\n## Test Data Strategy\r\n- [Strategy details]\r\n\r\n## Release Criteria\r\n- [ ] All critical tests pass\r\n- [ ] Coverage meets target\r\n- [ ] No P0 bugs open\r\n```\r\n\r\n### Example 4: 数据管道（ETL）的测试策略\r\n\r\n**Input:**\r\n```\r\n我们有一个每日跑批：从业务库抽数 → 清洗 → 计算保费指标 → 写入报表库。\r\n目前没有测试，每次出问题都要人工对数。怎么设计测试？\r\n```\r\n\r\n**Output:**\r\n```\r\nETL 的测试重点不是\"函数对不对\"，而是\"数据对不对\"。分四层：\r\n\r\n第 1 层：转换逻辑单元测试（占比 40%）\r\n  把清洗与计算函数抽成纯函数（输入 DataFrame → 输出 DataFrame），\r\n  用小型固定样本断言。关键是让转换逻辑不依赖 IO。\r\n\r\n第 2 层：数据质量测试（占比 30%）—— 大多数团队缺的就是这层\r\n  | 检查 | 断言 | 失败含义 |\r\n  |---|---|---|\r\n  | 行数波动 | 今日行数在近 30 日 P10–P90 区间内 | 上游抽数缺失 |\r\n  | 主键唯一 | 无重复保单号 | 关联放大（fan-out） |\r\n  | 空值率 | 关键字段空值率 < 阈值 | 上游字段变更 |\r\n  | 分布漂移 | 金额分布 PSI < 0.2 | 口径或业务突变 |\r\n  | 汇总对账 | 明细合计 == 汇总表 | 口径不一致 |\r\n  | 时间完整性 | 每个分区都有数据 | 跑批漏跑 |\r\n\r\n第 3 层：端到端小样本回归（占比 20%）\r\n  用 100 条脱敏真实数据跑完整管道，与上一次的黄金结果文件比对。\r\n  黄金文件需要有明确的更新流程，否则会变成\"永远批准\"。\r\n\r\n第 4 层：生产监控（占比 10%）\r\n  把第 2 层的检查搬到生产，作为数据契约告警。\r\n\r\n三个最常见的坑：\r\n1. 用\"全是合法值\"的假数据 —— 测不出脏数据路径，务必混入脏样本\r\n2. 没有幂等性测试 —— 同一天重跑两次结果必须一致\r\n3. 把测试写在对生产库的直连上 —— 必须有独立的可重置环境\r\n```\r\n\r\n### Example 5: 从\"覆盖率 85% 但仍在出事故\"说起\r\n\r\n**Input:**\r\n```\r\n我们覆盖率 85%，质量门禁也过了，但线上还是出低级事故。测试策略哪里有问题？\r\n```\r\n\r\n**Output:**\r\n```\r\n覆盖率衡量的是\"代码被执行过\"，不是\"结论被验证过\"。85% 且仍出事故，\r\n通常是以下四种情况之一：\r\n\r\n1. 断言太弱（最常见）\r\n   症状：测试只写 assert result is not None\r\n   检验：跑一次变异测试（mutmut / Stryker / PIT），变异分低于 40% 即确认\r\n   修复：对每个分支断言具体值或具体不变量\r\n\r\n2. 测试写成了实现镜像\r\n   症状：改实现时测试必须同步改，且改完仍然绿\r\n   检验：故意引入一个业务错误，看测试是否变红\r\n   修复：从需求/规格推导期望值，不从当前实现推导\r\n\r\n3. 关键路径没有端到端覆盖\r\n   症状：单元全绿，但串起来就错\r\n   检验：列出\"出钱/出合规风险\"的 3 条链路，看是否有跨层测试\r\n   修复：这 3 条链路各补一个端到端用例，其余不必追求\r\n\r\n4. 覆盖率数字被稀释\r\n   症状：DTO、generated、migrations 计入分母\r\n   修复：排除这些目录后重算，通常真实覆盖率会显著下降\r\n\r\n两周可落地的改进顺序：\r\n- 第 1 天：排除 generated/migrations，重算真实基线\r\n- 第 2–3 天：对核心模块跑一次变异测试，拿到变异分\r\n- 第 4–8 天：给 3 条关键链路各补 1 个端到端用例\r\n- 第 9–10 天：把覆盖率门禁从\"绝对值\"改为\"棘轮\"（只升不降）\r\n\r\n判断改进是否有效的唯一标准：变异分上升，而不是覆盖率上升。\r\n```\r\n\r\n### Example 6: 门禁设在哪里才不会被绕过\r\n\r\n**Input:**\r\n```\r\n我们把覆盖率门禁设成 85%，结果工程师开始写\"只为覆盖率\"的测试。\r\n门禁是不是设错了？\r\n```\r\n\r\n**Output:**\r\n```\r\n问题不在阈值，在门禁挂错了指标，也挂错了阶段。\r\n\r\n三个常见错误与修正：\r\n\r\n1. 门禁挂在\"绝对值\"上 → 改为棘轮（ratchet）\r\n   绝对值会让团队围绕数字优化。棘轮只要求\"不比上一次低\"，\r\n   把激励从\"刷数字\"改成\"别变差\"。\r\n\r\n2. 门禁挂在\"全量覆盖率\"上 → 改为关键路径覆盖率\r\n   全量分母里混着 DTO、generated、migrations，谁都能靠补这些拉高数字。\r\n   只统计\"出钱/出合规风险\"的模块，数字会下降但可信度上升。\r\n\r\n3. 门禁挂在\"唯一阶段\"上 → 分阶段分层挂\r\n   PR 阶段只挂快且确定的（单元 + 集成 + 契约，≤ 8 分钟）；\r\n   慢的挂 nightly 且不阻断；视觉差异挂人工审批。\r\n   PR 阶段超过 8 分钟，工程师就会开始绕过它。\r\n\r\n再补一条反刷分规则：新增代码的行覆盖率单独统计，\r\n不允许用存量代码的高覆盖率去掩盖新增代码的低覆盖。\r\n\r\n验证门禁是否健康的可观测信号：\r\n- 门禁失败后，有多少次是\"改了测试\"而不是\"改了代码\"？前者占比过高即为刷分\r\n- 变异分是否随覆盖率一起上升？不上升说明新增测试没有断言强度\r\n```\r\n\r\n\r\n\r\n## Best Practices\r\n\r\n### For Test Design\r\n1. **Follow FIRST principles:** Fast, Independent, Repeatable, Self-validating, Timely\r\n2. **Name tests descriptively:** `test_user_cannot_login_with_invalid_password`\r\n3. **Test one thing per test:** Easier debugging and maintenance\r\n4. **Use data-driven tests:** Reduce duplication with parameterized tests\r\n5. **Test edge cases:** Empty inputs, null values, maximum limits\r\n\r\n### For Test Automation\r\n1. **Prioritize stability:** Flaky tests are worse than no tests\r\n2. **Keep tests fast:** Slow tests don't run often\r\n3. **Use page objects:** Encapsulate UI structure changes\r\n4. **Isolate tests:** No shared state between tests\r\n5. **Clean up after yourself:** Reset what you change\r\n\r\n### For CI/CD Integration\r\n1. **Fail fast:** Run fastest tests first\r\n2. **Parallelize:** Split tests across workers\r\n3. **Report properly:** Generate actionable reports\r\n4. **Set quality gates:** Block releases below thresholds\r\n5. **Monitor trends:** Track flakiness over time\r\n\r\n## Ecosystem Status (as of 2026-09-28 / 截至 2026-09-28)\r\n\r\nTool versions and best practice shift quickly. Verify against official release\r\nnotes before committing to a stack.\r\n\r\n| 关注点 | 需要确认什么 | 影响 |\r\n|---|---|---|\r\n| 浏览器自动化版本 | Playwright / Cypress / Selenium 当前主版本 | 等待机制与选择器 API 差异 |\r\n| 变异测试工具链 | 与你的语言和测试框架是否兼容 | 决定能否把变异分纳入门禁 |\r\n| CI 运行成本 | 并行 worker 的计费与上限 | 决定金字塔各层能跑多频繁 |\r\n| 视觉回归方案 | SaaS 还是自托管 | 涉及截图是否出网（受监管行业敏感） |\r\n| AI 生成测试的合入政策 | 本单位对生成代码的评审要求 | 决定人工检查点设在哪里 |\r\n\r\n**最近动态（截至 2026-09-28，以官方发布为准）**\r\n1. 变异测试与\"断言强度\"指标正从学术研究走向工程实践，部分团队已用它替代\r\n   单纯的覆盖率门禁。\r\n2. 视觉回归的自托管方案受关注度上升，主要驱动是数据驻留与合规要求。\r\n3. AI 生成测试用例已成常见能力，行业关注点转向\"生成用例的评审与可追溯\"，\r\n   而非生成数量。\r\n4. 质量门禁的口径正在从\"覆盖率绝对值\"转向\"棘轮 + 关键路径覆盖率 + 变异分\"\r\n   的组合，单纯提高覆盖率阈值被普遍认为会产生反向激励。\r\n5. AI 生成测试用例的评审成为落地瓶颈：多数团队反馈瓶颈不在生成速度，而在\r\n   \"生成用例是否与需求一致、是否可追溯\"，评审环节的人工成本被低估。\r\n6. 以上为趋势描述，具体工具版本与能力请以官方最新发布为准。\r\n\r\n## Testing Framework Comparison\r\n\r\n| Framework | Best For | Languages | 学习曲线 | 并行能力 | 调试体验 | 适合团队规模 | 主要坑 | 何时不要用 | 多语言 API 差异风险 |\r\n|---|---|---|---|---|---|---|---|---|---|\r\n| Pytest | Python APIs, unit tests | Python | 低 | 中（pytest-xdist） | 好（--pdb、丰富报错） | 1–20 | fixture 作用域误用导致状态泄漏 | 需要浏览器级交互时 | 无（纯 Python） |\r\n| Jest | JS/TS 单元与组件测试 | JS/TS | 低 | 好（内置） | 好 | 1–20 | mock 过深，测到 mock 而非实现 | 需要真实浏览器行为时 | 无（纯 JS/TS） |\r\n| Vitest | Vite 生态单元测试 | JS/TS | 低 | 好 | 好 | 1–15 | 与 Jest 的 mock API 差异 | 非 ESM/老构建体系 | 无（纯 JS/TS） |\r\n| JUnit 5 | Java 应用 | Java | 中 | 中 | 中 | 5–50 | 扩展模型复杂，配置易失控 | 快速原型阶段 | 无（纯 Java） |\r\n| Playwright | Web E2E | TS, Python, Java | 中 | 好（内置分片） | 很好（trace viewer） | 2–30 | 自动等待让人误解为\"不需要断言状态\" | 需测极老浏览器 | 高：Python snake_case 与 JS camelCase 断言不同名 |\r\n| Cypress | Web E2E（开发体验优先） | JS/TS | 低 | 需付费/自建 | 很好（时间旅行） | 1–15 | 多标签、多域限制 | 跨域/多窗口场景 | 无（仅 JS/TS） |\r\n| Selenium | 遗留浏览器与网格 | 多语言 | 高 | 好（Grid） | 差（报错不直观） | 10+ | 等待与驱动版本地狱 | 新项目（有更好选择） | 中：多语言绑定的命名并不总是一致 |\r\n| REST Assured | API 测试 | Java, Groovy | 中 | 好 | 中 | 5–30 | DSL 冗长，维护成本高 | 团队不以 Java 为主 | 无（Java/Groovy） |\r\n| SuperTest | Node API 测试 | JavaScript | 低 | 好 | 好 | 1–10 | 只覆盖 HTTP 层，无契约能力 | 需要跨语言契约时 | 无（JavaScript） |\r\n| Pact | 消费者驱动契约测试 | 多语言 | 中高 | 好 | 中 | 5–30 | Broker 运维被低估 | 单体应用、调用方单一 | 中：各语言 DSL 差异较大 |\r\n| Hypothesis | 属性/不变量测试 | Python | 中 | 好 | 中（反例收缩优秀） | 2–20 | 策略写不好等于随机测试 | 纯 CRUD、无计算逻辑 | 无（仅 Python） |\r\n| k6 / Locust | 性能与负载 | JS / Python | 中 | 好 | 中 | 2–20 | 把负载测试当功能测试跑 | 只需要单次基准时 | 中：k6 用 JS，Locust 用 Python，脚本不可互换 |\r\n\r\n**选型判据（比\"哪个更流行\"更可靠）**：团队已有语言 > 调试体验 > 并行能力 >\r\n生态插件。调试体验决定日常成本，流行度不决定。\r\n\r\n## Version History\r\n\r\n- **1.0.1** (2026-09-10)\r\n  - Added worked examples to all four feature groups (risk-based scope table and\r\n    environment checklist; parameterised case matrix and property-based invariants;\r\n    page-object granularity and parallelism constraints; four-stage pipeline with\r\n    quality-gate config)\r\n  - Added \"Pyramid Ratios by Project Type\" (6 project types, 6 columns) and a\r\n    self-check for whether your ratio is right\r\n  - Expanded framework comparison from 3 to 10 columns and 8 to 12 rows\r\n    (learning curve, parallelism, debugging, team size, main pitfall, when not to use)\r\n  - Added Example 4 (ETL/data-pipeline strategy incl. data-quality checks) and\r\n    Example 5 (high coverage but still shipping incidents)\r\n  - Added \"Ecosystem Status (as of 2026-09-10)\"\r\n  - Corrected Python Playwright assertions (`to_have_count`, `not_to_be_empty`)\r\n- **1.0.2** (2026-09-28)\r\n  - Fixed a real code defect in the Playwright example: `toBeVisible()` (JS/TS\r\n    camelCase) inside a Python snippet corrected to `to_be_visible()`, and added a\r\n    Python vs JS/TS assertion-name table explaining why the mix-up fails silently\r\n    (SDI-4)\r\n  - Added a Language Policy section covering default-language, terminology, code,\r\n    mixed-language and switching rules (SQP-3)\r\n  - Narrowed triggers with a required-context rule, a six-row non-trigger table and\r\n    an explicit execution-boundary statement (SQP-1)\r\n  - Added a 门禁归属 column to the risk-based scope table, a 常见误判 column to the\r\n    pyramid-ratio table and a 多语言 API 差异风险 column to the framework comparison\r\n  - Added Example 6 on where to place quality gates so they are not bypassed\r\n  - Ecosystem status updated to 2026-09-28 with two added dynamics\r\n- **1.0.0** (2026-05-15): Initial release\r\n  - Test strategy design framework\r\n  - Unit test generation\r\n  - Integration test scaffolding\r\n  - E2E test patterns (Playwright)\r\n  - CI/CD integration guidance\r\n\r\n**Last Updated**: 2026-09-28\n\nFile v1.0.2:_meta.json\n\n{\n  \"ownerId\": \"kn74e704j3ygjcygnpf02rdvd185js13\",\n  \"slug\": \"ai-test-strategy-architect\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1790573023046\n}\n\nFile v1.0.2:skill-card.md\n\n## Description:\n\nHelps teams design risk-based test strategies, generate test cases and automation examples, and plan CI/CD quality gates.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[gechengling](https://clawhub.ai/user/gechengling)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers, developers, test leads, and DevOps teams use this skill to plan unit, integration, and end-to-end testing, draft automation, and define CI/CD quality gates.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated tests or CI snippets may not fit the target project and could produce misleading results or quality gates.\n\nMitigation: Review and adapt examples to the project before running them or adding them to CI.\n\nRisk: Example credentials or placeholders could be replaced with real production secrets.\n\nMitigation: Use safe test credentials and never put production credentials in examples.\n\n## Reference(s):\n\n- [AI Test Strategy Architect on ClawHub](https://clawhub.ai/gechengling/skills/ai-test-strategy-architect)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Code, Configuration, Guidance]\n\n**Output Format:** [Markdown with code and configuration examples]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Proposed examples are for review and adaptation before execution.]\n\n## Skill Version(s):\n\n1.0.2 (source: frontmatter and release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.0.1: 3 files, 14518 bytes\n\nFiles: skill-card.md (2213b), SKILL.md (29966b), _meta.json (145b)\n\nFile v1.0.1:SKILL.md\n\n---\r\nname: \"AI Test Strategy Architect\"\r\ndescription: \"AI-powered test strategy and automation assistant — design comprehensive testing frameworks, generate unit/integration/e2e test cases, implement test automation for web/mobile/API, and build CI/CD testing pipelines. Covers Test-Driven Development (TDD), Behavior-Driven Development (BDD), property-based testing, and AI-augmented test generation. Built for QA engineers, software developers, test leads, and DevOps teams shipping reliable software. Keywords: test automation, unit testing, integration testing, e2e testing, TDD, BDD, CI/CD testing, Selenium, Playwright, Pytest, Jest, testing framework, test strategy, quality assurance, 测试自动化, 单元测试, 集成测试, 端到端测试, 测试策略, 质量保障.\"\r\nversion: \"1.0.1\"\r\n---\r\n\r\n# AI Test Strategy Architect\r\n\r\n## Overview\r\n\r\nBuild testing that catches bugs before users do. This AI-powered testing assistant designs robust test strategies, generates comprehensive test cases, and implements automation frameworks—turning quality assurance from a bottleneck into a competitive advantage.\r\n\r\n## Triggers\r\n\r\n- 中文触发词：`测试策略`、`单元测试`、`集成测试`、`E2E测试`、`自动化测试`、`测试用例`、`TDD`、`BDD`、`Playwright测试`、`Selenium`、`测试覆盖率`\r\n- English triggers: `test strategy`, `unit testing`, `integration testing`, `e2e testing`, `automated testing`, `test cases`, `TDD`, `BDD`, `Playwright`, `Selenium`, `test coverage`, `CI/CD testing`\r\n\r\n## Features\r\n\r\n### 1. Test Strategy Design\r\n- Assess project requirements and risk profiles\r\n- Design tailored testing pyramids (unit/integration/e2e ratios)\r\n- Select appropriate testing frameworks per use case\r\n- Define test data management strategies\r\n- Create test environment specifications\r\n\r\n\r\n**Worked example — risk-based scope for a payments-style service**\r\n\r\n| Module | 失效影响 | 发生概率 | 风险分 | 测试投入 | 具体手段 |\r\n|---|---|---|---|---|---|\r\n| 保费计算 | 资金错误，监管风险 | 中 | 9 | 最高 | 属性测试 + 黄金样本回归 + 变更检测 |\r\n| 投保校验 | 单用户受阻 | 高 | 6 | 高 | 边界表 + 参数化 |\r\n| 支付回调 | 重复扣款 | 低 | 6 | 高 | 幂等性专项 + 故障注入 |\r\n| 报表导出 | 内部使用 | 中 | 3 | 中 | 快照测试 |\r\n| 邮件通知 | 体验问题 | 中 | 2 | 低 | 冒烟 + 手动抽查 |\r\n| 管理后台筛选 | 内部低效 | 低 | 1 | 最低 | 冒烟即可 |\r\n\r\n评分方式：影响（1–5）× 概率（1–2），≥8 必须有属性测试与变更检测，\r\n≤3 只做冒烟。这样把预算集中在真正会出钱的地方，而不是平均撒。\r\n\r\n**测试环境规格清单（常被忽略的 5 项）**\r\n1. 数据种子能否一键重建（不能就要先解决这个，否则一切自动化都是脆弱的）\r\n2. 第三方依赖是否有稳定的测试替身（沙箱/契约/Mock 三选一）\r\n3. 环境之间配置差异是否有单一来源（配置漂移是\"本地能跑线上挂\"的主因）\r\n4. 测试数据是否含脱敏后的真实分布（用全是合法值的假数据测不出边界）\r\n5. 每个环境的重置成本与时限（重置超过 10 分钟的流水线会被绕过）\r\n\r\n\r\n### 2. Test Case Generation\r\n- Generate unit tests from code functions/methods\r\n- Create integration test scenarios from API specs\r\n- Design end-to-end user journey tests\r\n- Build property-based tests for edge cases\r\n- Generate negative test cases (error handling)\r\n\r\n\r\n**Worked example — 一个参数的完整用例矩阵（参数化而非堆砌）**\r\n\r\n以 `calculate_discount(price, discount_percent, is_loyal)` 为例，不要写 12 个\r\n独立函数，用一张表驱动：\r\n\r\n| price | discount_percent | is_loyal | 期望 | 覆盖的意图 |\r\n|---|---|---|---|---|\r\n| 100.00 | 0 | False | 100.00 | 恒等 |\r\n| 100.00 | 20 | False | 80.00 | 基本路径 |\r\n| 100.00 | 20 | True | 76.00 | 忠诚用户叠加 |\r\n| 100.00 | 100 | False | 0.00 | 上边界 |\r\n| 0.00 | 50 | False | 0.00 | 零值 |\r\n| 99.99 | 33 | False | 66.99 | 舍入 |\r\n| -10.00 | 10 | False | ValueError | 负价 |\r\n| 100.00 | -5 | False | ValueError | 下越界 |\r\n| 100.00 | 150 | False | ValueError | 上越界 |\r\n\r\n对应的参数化写法要点：把\"期望异常\"也放进同一张表，用哨兵值标记，\r\n不要在参数化之外再补一批独立的异常测试——那会让两套用例逐渐分叉。\r\n\r\n**属性测试该测什么（property-based，不是随机测试）**\r\n\r\n对同一个函数，属性测试关心的是不变量，例如：\r\n- 对任意合法输入，`0 <= result <= price`\r\n- 对任意合法输入，`discount_percent` 单调不减时，`result` 单调不增\r\n- 对任意合法输入，`result == round(result, 2)`\r\n- 对任意合法输入，同样参数调用两次结果相同（纯函数性）\r\n\r\n最小可运行的 Hypothesis 形态：\r\n\r\n```python\r\nfrom hypothesis import given, strategies as st\r\n\r\n@given(\r\n    price=st.floats(min_value=0, max_value=1e6, allow_nan=False),\r\n    pct=st.floats(min_value=0, max_value=100, allow_nan=False),\r\n    loyal=st.booleans(),\r\n)\r\ndef test_result_within_bounds(price, pct, loyal):\r\n    r = calculate_discount(price, pct, loyal)\r\n    assert 0 <= r <= price\r\n    assert r == round(r, 2)\r\n```\r\n\r\n注意：这段代码是给你在自己环境运行的参考材料，本技能不代为执行。\r\n\r\n\r\n### 3. Test Automation Implementation\r\n- Scaffold test projects with proper structure\r\n- Implement page object models for UI tests\r\n- Set up API test frameworks with data-driven approaches\r\n- Configure test parallelization and distribution\r\n- Implement visual regression testing\r\n\r\n\r\n**Worked example — page object 的正确粒度**\r\n\r\n反例（把业务流程塞进 page object，导致一改就全崩）：\r\n\r\n```python\r\nclass CheckoutPage:\r\n    def buy_whole_flow(self, card):   # 不要这样\r\n        ...\r\n```\r\n\r\n正例（page object 只暴露页面能力，流程留在测试里）：\r\n\r\n```python\r\nclass ProductPage:\r\n    def __init__(self, page): self.page = page\r\n    def add_to_cart(self):\r\n        self.page.get_by_test_id(\"add-to-cart\").click()\r\n    def cart_count(self) -> int:\r\n        return self.page.get_by_test_id(\"cart-item\").count()\r\n\r\nclass CheckoutPage:\r\n    def __init__(self, page): self.page = page\r\n    def pay_with(self, card: str, expiry: str, cvv: str):\r\n        self.page.get_by_label(\"card number\").fill(card)\r\n        self.page.get_by_label(\"expiry\").fill(expiry)\r\n        self.page.get_by_label(\"cvv\").fill(cvv)\r\n        self.page.get_by_test_id(\"place-order\").click()\r\n    def order_number(self) -> str:\r\n        return self.page.get_by_test_id(\"order-number\").inner_text()\r\n```\r\n\r\n判据：page object 里不应出现断言（`assert` 属于测试），也不应出现跨页面跳转。\r\n跳转留在测试用例里，页面对象只负责\"这一页能做什么\"。\r\n\r\n**并行化的三条硬约束**\r\n1. 数据隔离：并行 worker 不能共用同一条测试数据，用 worker id 生成唯一前缀。\r\n2. 端口与临时目录：并行时端口冲突是最常见的\"随机失败\"，必须动态分配。\r\n3. 共享服务：若必须共用一个外部服务（如支付沙箱），要么串行，要么限流——\r\n   否则你会得到一批看起来像 flaky 的资源竞争失败。\r\n\r\n\r\n### 4. CI/CD Pipeline Integration\r\n- Design testing stages in CI/CD pipelines\r\n- Configure test reporting and dashboards\r\n- Set up automated quality gates\r\n- Implement canary/feature flag testing strategies\r\n- Create performance test thresholds in pipelines\r\n\r\n\r\n**Worked example — 四阶段流水线与门禁**\r\n\r\n| 阶段 | 运行内容 | 时限 | 失败处理 | 门禁指标 |\r\n|---|---|---|---|---|\r\n| commit (pre-push) | lint + 单元测试(受影响模块) | ≤ 60 s | 阻断提交 | 0 失败 |\r\n| PR | 全量单元 + 集成 + 契约 | ≤ 8 min | 阻断合并 | 覆盖率不低于基线 |\r\n| merge (main) | 全量 + E2E 冒烟 | ≤ 20 min | 阻断发布流水线 | 冒烟 100% 通过 |\r\n| nightly | 全量 E2E + 性能 + 变异测试 | ≤ 2 h | 次日处理，不阻断 | 变异分趋势不下降 |\r\n\r\n关键设计：把慢的、不稳定的放 nightly，把快的、确定的放 PR。\r\n如果 PR 阶段超过 8 分钟，工程师会开始绕过它——这是流水线失效的真实起点。\r\n\r\n**质量门禁配置示例（概念形态，按你的 CI 语法调整）**\r\n\r\n```yaml\r\nquality_gates:\r\n  coverage:\r\n    metric: line\r\n    floor: 72            # 当前实际值 + 2，不要一上来写 90\r\n    ratchet: true        # 只允许上升，不允许回落\r\n    exclude: [\"generated/*\", \"migrations/*\"]\r\n  flakiness:\r\n    quarantine_threshold: 0.01   # 100 次里失败 1 次即隔离\r\n    quarantine_expiry_days: 14   # 隔离不是删除，到期必须处理\r\n  performance:\r\n    p95_latency_ms: 800\r\n    regression_tolerance: 0.10   # 允许 10% 波动，超过即失败\r\n  blocking:\r\n    - name: critical_path_e2e\r\n      on_failure: stop_pipeline\r\n    - name: visual_diff\r\n      on_failure: require_human_approval   # 视觉差异必须人看\r\n```\r\n\r\n注意：以上为配置形态示例，需在用户自己的 CI 环境中运行与调整。\r\n\r\n\r\n## Workflow\r\n\r\n### Comprehensive Test Strategy Workflow\r\n\r\n```\r\nPhase 1: Assessment\r\n├── Analyze project architecture\r\n├── Identify critical user flows\r\n├── Assess technical risks\r\n├── Define quality metrics\r\n└── Select testing tools\r\n\r\nPhase 2: Design\r\n├── Design test pyramid\r\n├── Define test scope per layer\r\n├── Create test data strategy\r\n├── Document test environment needs\r\n└── Plan test automation approach\r\n\r\nPhase 3: Implementation\r\n├── Set up test project structure\r\n├── Implement unit tests\r\n├── Build integration test suite\r\n├── Create e2e test scenarios\r\n└── Configure test runners\r\n\r\nPhase 4: Automation\r\n├── Integrate with CI/CD\r\n├── Set up test reporting\r\n├── Configure parallel execution\r\n├── Implement test monitoring\r\n└── Create quality dashboards\r\n\r\nPhase 5: Maintenance\r\n├── Review test effectiveness\r\n├── Optimize slow tests\r\n├── Update for new features\r\n└── Archive obsolete tests\r\n```\r\n\r\n### Quick Test Generation Workflow\r\n\r\n```\r\n1. INPUT: Source code or feature description\r\n   ↓\r\n2. ANALYZE: Identify testable units\r\n   - Functions/methods\r\n   - User interactions\r\n   - API endpoints\r\n   ↓\r\n3. GENERATE: Create test cases\r\n   - Happy path scenarios\r\n   - Edge cases\r\n   - Error scenarios\r\n   - Boundary conditions\r\n   ↓\r\n4. VALIDATE: Run tests, fix failures\r\n   ↓\r\n5. OPTIMIZE: Improve coverage and speed\r\n```\r\n\r\n## Pyramid Ratios by Project Type\r\n\r\nThe classic 60/30/10 split is a starting point, not a law. Use this instead:\r\n\r\n| 项目类型 | Unit | Integration | E2E | 额外层 | 理由 |\r\n|---|---|---|---|---|---|\r\n| 纯前端 Web 应用 | 50% | 20%（组件/契约） | 30% | 视觉回归 | UI 是主要风险面，E2E 占比自然更高 |\r\n| 后端 API 服务 | 60% | 35% | 5% | 契约测试 | 逻辑在服务端，E2E 只需关键链路 |\r\n| 数据/ETL 管道 | 45% | 25% | 5% | 25% 数据质量测试 | 行数、空值率、分布漂移比功能更重要 |\r\n| 移动端 | 55% | 20% | 25% | 设备矩阵冒烟 | 设备与系统版本碎片化推高 UI 层 |\r\n| 金融/保险核心 | 65% | 25% | 10% | 属性测试 + 审计测试 | 计算正确性优先，且需可追溯 |\r\n| 内部工具 | 40% | 30% | 30% | 探索式测试 | 用户少、变更快，重自动化反而拖慢 |\r\n\r\n**如何判断比例是否合适**\r\n- E2E 占比高且经常红 → 逻辑下沉不足，把验证前移到集成层\r\n- 单元覆盖高但线上仍有事故 → 断言太弱，引入变异测试检验\"断言强度\"\r\n- 集成层几乎为零 → 多半是\"只能整体起来才能测\"，这是架构问题不是测试问题\r\n\r\n## Input Examples\r\n\r\n### Example 1: Function to Unit Test\r\n\r\n**Input Code:**\r\n```python\r\ndef calculate_discount(price: float, discount_percent: float, is_loyal: bool) -> float:\r\n    \"\"\"\r\n    Calculate final price after discount.\r\n    \r\n    Args:\r\n        price: Original price\r\n        discount_percent: Discount percentage (0-100)\r\n        is_loyal: Whether customer is a loyalty member\r\n    \r\n    Returns:\r\n        Final price after discount\r\n    \"\"\"\r\n    if price < 0:\r\n        raise ValueError(\"Price cannot be negative\")\r\n    if discount_percent < 0 or discount_percent > 100:\r\n        raise ValueError(\"Discount must be between 0 and 100\")\r\n    \r\n    discount_multiplier = 1 - (discount_percent / 100)\r\n    \r\n    if is_loyal:\r\n        # Loyalty members get extra 5% off\r\n        final_multiplier = discount_multiplier * 0.95\r\n    else:\r\n        final_multiplier = discount_multiplier\r\n    \r\n    return round(price * final_multiplier, 2)\r\n```\r\n\r\n**Generated Test Cases:**\r\n```python\r\nimport pytest\r\nfrom your_module import calculate_discount\r\n\r\nclass TestCalculateDiscount:\r\n    \"\"\"Unit tests for calculate_discount function\"\"\"\r\n    \r\n    # Happy path tests\r\n    def test_no_discount_returns_original_price(self):\r\n        \"\"\"No discount should return the original price\"\"\"\r\n        assert calculate_discount(100.00, 0, False) == 100.00\r\n    \r\n    def test_standard_discount(self):\r\n        \"\"\"Basic discount calculation\"\"\"\r\n        assert calculate_discount(100.00, 20, False) == 80.00\r\n    \r\n    def test_loyal_customer_extra_discount(self):\r\n        \"\"\"Loyal customers get additional 5% off\"\"\"\r\n        result = calculate_discount(100.00, 20, True)\r\n        expected = round(100 * 0.80 * 0.95, 2)  # 76.00\r\n        assert result == expected\r\n    \r\n    def test_full_discount(self):\r\n        \"\"\"100% discount should result in 0\"\"\"\r\n        assert calculate_discount(100.00, 100, False) == 0.00\r\n    \r\n    # Edge cases\r\n    def test_zero_price(self):\r\n        \"\"\"Zero price should return zero\"\"\"\r\n        assert calculate_discount(0.00, 50, False) == 0.00\r\n    \r\n    def test_rounding_to_cents(self):\r\n        \"\"\"Prices should round to 2 decimal places\"\"\"\r\n        result = calculate_discount(99.99, 33, False)\r\n        assert result == round(99.99 * 0.67, 2)\r\n    \r\n    # Error cases\r\n    def test_negative_price_raises_error(self):\r\n        \"\"\"Negative price should raise ValueError\"\"\"\r\n        with pytest.raises(ValueError, match=\"Price cannot be negative\"):\r\n            calculate_discount(-10.00, 10, False)\r\n    \r\n    def test_negative_discount_raises_error(self):\r\n        \"\"\"Negative discount should raise ValueError\"\"\"\r\n        with pytest.raises(ValueError, match=\"Discount must be between\"):\r\n            calculate_discount(100.00, -5, False)\r\n    \r\n    def test_over_100_discount_raises_error(self):\r\n        \"\"\"Discount over 100% should raise ValueError\"\"\"\r\n        with pytest.raises(ValueError, match=\"Discount must be between\"):\r\n            calculate_discount(100.00, 150, False)\r\n    \r\n    # Boundary tests\r\n    def test_boundary_zero_percent_discount(self):\r\n        \"\"\"0% is valid discount\"\"\"\r\n        assert calculate_discount(50.00, 0, False) == 50.00\r\n    \r\n    def test_boundary_hundred_percent_discount(self):\r\n        \"\"\"100% is valid discount\"\"\"\r\n        assert calculate_discount(50.00, 100, False) == 0.00\r\n```\r\n\r\n### Example 2: API Integration Test\r\n\r\n**Input:** OpenAPI endpoint definition\r\n```yaml\r\npaths:\r\n  /api/v1/users/{userId}/orders:\r\n    get:\r\n      summary: Get user orders\r\n      parameters:\r\n        - name: userId\r\n          in: path\r\n          required: true\r\n          schema:\r\n            type: string\r\n        - name: status\r\n          in: query\r\n          schema:\r\n            type: string\r\n            enum: [pending, shipped, delivered]\r\n      responses:\r\n        '200':\r\n          description: List of orders\r\n        '401':\r\n          description: Unauthorized\r\n        '404':\r\n          description: User not found\r\n```\r\n\r\n**Generated Integration Test:**\r\n```python\r\nimport pytest\r\nimport requests\r\nfrom typing import Dict\r\n\r\nBASE_URL = \"https://api.example.com\"\r\nHEADERS = {\"Authorization\": \"Bearer <test_token>\"}\r\n\r\nclass TestUserOrdersAPI:\r\n    \"\"\"Integration tests for User Orders endpoint\"\"\"\r\n    \r\n    @pytest.fixture\r\n    def test_user_id(self):\r\n        \"\"\"Fixture providing a test user with known orders\"\"\"\r\n        return \"user_123\"\r\n    \r\n    def test_get_orders_success(self, test_user_id: str):\r\n        \"\"\"Should return 200 with list of orders\"\"\"\r\n        response = requests.get(\r\n            f\"{BASE_URL}/api/v1/users/{test_user_id}/orders\",\r\n            headers=HEADERS\r\n        )\r\n        \r\n        assert response.status_code == 200\r\n        data = response.json()\r\n        assert \"orders\" in data\r\n        assert isinstance(data[\"orders\"], list)\r\n    \r\n    def test_get_orders_with_status_filter(self, test_user_id: str):\r\n        \"\"\"Should filter orders by status\"\"\"\r\n        response = requests.get(\r\n            f\"{BASE_URL}/api/v1/users/{test_user_id}/orders\",\r\n            params={\"status\": \"pending\"},\r\n            headers=HEADERS\r\n        )\r\n        \r\n        assert response.status_code == 200\r\n        orders = response.json()[\"orders\"]\r\n        assert all(order[\"status\"] == \"pending\" for order in orders)\r\n    \r\n    def test_get_orders_unauthorized(self, test_user_id: str):\r\n        \"\"\"Should return 401 without valid token\"\"\"\r\n        response = requests.get(\r\n            f\"{BASE_URL}/api/v1/users/{test_user_id}/orders\"\r\n        )\r\n        \r\n        assert response.status_code == 401\r\n    \r\n    def test_get_orders_user_not_found(self):\r\n        \"\"\"Should return 404 for non-existent user\"\"\"\r\n        response = requests.get(\r\n            f\"{BASE_URL}/api/v1/users/nonexistent_user/orders\",\r\n            headers=HEADERS\r\n        )\r\n        \r\n        assert response.status_code == 404\r\n        assert \"error\" in response.json()\r\n```\r\n\r\n### Example 3: E2E Test with Playwright\r\n\r\n**Input:** User journey description\r\n```\r\nUser flow: Login -> Add item to cart -> Checkout -> Verify order confirmation\r\n```\r\n\r\n**Generated E2E Test:**\r\n```python\r\nimport pytest\r\nfrom playwright.sync_api import Page, expect\r\n\r\n@pytest.fixture\r\ndef logged_in_page(page: Page):\r\n    \"\"\"Fixture that logs in user before each test\"\"\"\r\n    page.goto(\"https://shop.example.com/login\")\r\n    page.fill('[name=\"email\"]', \"test@example.com\")\r\n    page.fill('[name=\"password\"]', \"testpassword123\")\r\n    page.click('[type=\"submit\"]')\r\n    page.wait_for_url(\"**/dashboard\")\r\n    return page\r\n\r\ndef test_complete_checkout_flow(logged_in_page: Page):\r\n    \"\"\"End-to-end test: Login -> Add to cart -> Checkout -> Confirmation\"\"\"\r\n    page = logged_in_page\r\n    \r\n    # Step 1: Browse to product\r\n    page.goto(\"https://shop.example.com/products/widget-pro\")\r\n    page.click('[data-testid=\"add-to-cart\"]')\r\n    \r\n    # Step 2: Verify cart\r\n    page.click('[data-testid=\"cart-icon\"]')\r\n    expect(page.locator('[data-testid=\"cart-item\"]')).to_have_count(1)\r\n    \r\n    # Step 3: Proceed to checkout\r\n    page.click('[data-testid=\"checkout-button\"]')\r\n    page.fill('[name=\"shipping_address\"]', \"123 Test Street\")\r\n    page.fill('[name=\"zip_code\"]', \"12345\")\r\n    page.click('[data-testid=\"continue-payment\"]')\r\n    \r\n    # Step 4: Complete payment\r\n    page.fill('[name=\"card_number\"]', \"4242424242424242\")\r\n    page.fill('[name=\"expiry\"]', \"12/28\")\r\n    page.fill('[name=\"cvv\"]', \"123\")\r\n    page.click('[data-testid=\"place-order\"]')\r\n    \r\n    # Step 5: Verify confirmation\r\n    expect(page.locator('[data-testid=\"order-confirmation\"]')).toBeVisible()\r\n    expect(page.locator('[data-testid=\"order-number\"]')).not_to_be_empty()\r\n```\r\n\r\n## Output Templates\r\n\r\n### Template: Test Strategy Document\r\n```markdown\r\n# Test Strategy Document\r\n\r\n## Project Overview\r\n- Project Name: [Name]\r\n- Version: [Version]\r\n- Test Scope: [What's in/out]\r\n\r\n## Quality Objectives\r\n| Metric | Target | Measurement |\r\n|--------|--------|-------------|\r\n| Code Coverage | >80% | Codecov |\r\n| Bug Escape Rate | <5% | Bug Tracker |\r\n| Test Execution Time | <10 min | CI Pipeline |\r\n\r\n## Test Pyramid\r\n\r\n        ╱╲\r\n       ╱  ╲\r\n      ╱ E2E╲         [Few - 10%]\r\n     ╱──────╲\r\n    ╱Integration╲     [Some - 30%]\r\n   ╱────────────╲\r\n  ╱  Unit Tests  ╲   [Many - 60%]\r\n ╱────────────────╲\r\n\r\n## Testing Tools\r\n\r\n| Layer | Tool | Language |\r\n|-------|------|----------|\r\n| Unit | Pytest | Python |\r\n| Integration | pytest | Python |\r\n| E2E | Playwright | TypeScript |\r\n| API | REST Assured | Java |\r\n\r\n## Test Environments\r\n- Dev: https://dev.example.com\r\n- Staging: https://staging.example.com\r\n- Production: https://example.com\r\n\r\n## Test Data Strategy\r\n- [Strategy details]\r\n\r\n## Release Criteria\r\n- [ ] All critical tests pass\r\n- [ ] Coverage meets target\r\n- [ ] No P0 bugs open\r\n```\r\n\r\n### Example 4: 数据管道（ETL）的测试策略\r\n\r\n**Input:**\r\n```\r\n我们有一个每日跑批：从业务库抽数 → 清洗 → 计算保费指标 → 写入报表库。\r\n目前没有测试，每次出问题都要人工对数。怎么设计测试？\r\n```\r\n\r\n**Output:**\r\n```\r\nETL 的测试重点不是\"函数对不对\"，而是\"数据对不对\"。分四层：\r\n\r\n第 1 层：转换逻辑单元测试（占比 40%）\r\n  把清洗与计算函数抽成纯函数（输入 DataFrame → 输出 DataFrame），\r\n  用小型固定样本断言。关键是让转换逻辑不依赖 IO。\r\n\r\n第 2 层：数据质量测试（占比 30%）—— 大多数团队缺的就是这层\r\n  | 检查 | 断言 | 失败含义 |\r\n  |---|---|---|\r\n  | 行数波动 | 今日行数在近 30 日 P10–P90 区间内 | 上游抽数缺失 |\r\n  | 主键唯一 | 无重复保单号 | 关联放大（fan-out） |\r\n  | 空值率 | 关键字段空值率 < 阈值 | 上游字段变更 |\r\n  | 分布漂移 | 金额分布 PSI < 0.2 | 口径或业务突变 |\r\n  | 汇总对账 | 明细合计 == 汇总表 | 口径不一致 |\r\n  | 时间完整性 | 每个分区都有数据 | 跑批漏跑 |\r\n\r\n第 3 层：端到端小样本回归（占比 20%）\r\n  用 100 条脱敏真实数据跑完整管道，与上一次的黄金结果文件比对。\r\n  黄金文件需要有明确的更新流程，否则会变成\"永远批准\"。\r\n\r\n第 4 层：生产监控（占比 10%）\r\n  把第 2 层的检查搬到生产，作为数据契约告警。\r\n\r\n三个最常见的坑：\r\n1. 用\"全是合法值\"的假数据 —— 测不出脏数据路径，务必混入脏样本\r\n2. 没有幂等性测试 —— 同一天重跑两次结果必须一致\r\n3. 把测试写在对生产库的直连上 —— 必须有独立的可重置环境\r\n```\r\n\r\n### Example 5: 从\"覆盖率 85% 但仍在出事故\"说起\r\n\r\n**Input:**\r\n```\r\n我们覆盖率 85%，质量门禁也过了，但线上还是出低级事故。测试策略哪里有问题？\r\n```\r\n\r\n**Output:**\r\n```\r\n覆盖率衡量的是\"代码被执行过\"，不是\"结论被验证过\"。85% 且仍出事故，\r\n通常是以下四种情况之一：\r\n\r\n1. 断言太弱（最常见）\r\n   症状：测试只写 assert result is not None\r\n   检验：跑一次变异测试（mutmut / Stryker / PIT），变异分低于 40% 即确认\r\n   修复：对每个分支断言具体值或具体不变量\r\n\r\n2. 测试写成了实现镜像\r\n   症状：改实现时测试必须同步改，且改完仍然绿\r\n   检验：故意引入一个业务错误，看测试是否变红\r\n   修复：从需求/规格推导期望值，不从当前实现推导\r\n\r\n3. 关键路径没有端到端覆盖\r\n   症状：单元全绿，但串起来就错\r\n   检验：列出\"出钱/出合规风险\"的 3 条链路，看是否有跨层测试\r\n   修复：这 3 条链路各补一个端到端用例，其余不必追求\r\n\r\n4. 覆盖率数字被稀释\r\n   症状：DTO、generated、migrations 计入分母\r\n   修复：排除这些目录后重算，通常真实覆盖率会显著下降\r\n\r\n两周可落地的改进顺序：\r\n- 第 1 天：排除 generated/migrations，重算真实基线\r\n- 第 2–3 天：对核心模块跑一次变异测试，拿到变异分\r\n- 第 4–8 天：给 3 条关键链路各补 1 个端到端用例\r\n- 第 9–10 天：把覆盖率门禁从\"绝对值\"改为\"棘轮\"（只升不降）\r\n\r\n判断改进是否有效的唯一标准：变异分上升，而不是覆盖率上升。\r\n```\r\n\r\n## Best Practices\r\n\r\n### For Test Design\r\n1. **Follow FIRST principles:** Fast, Independent, Repeatable, Self-validating, Timely\r\n2. **Name tests descriptively:** `test_user_cannot_login_with_invalid_password`\r\n3. **Test one thing per test:** Easier debugging and maintenance\r\n4. **Use data-driven tests:** Reduce duplication with parameterized tests\r\n5. **Test edge cases:** Empty inputs, null values, maximum limits\r\n\r\n### For Test Automation\r\n1. **Prioritize stability:** Flaky tests are worse than no tests\r\n2. **Keep tests fast:** Slow tests don't run often\r\n3. **Use page objects:** Encapsulate UI structure changes\r\n4. **Isolate tests:** No shared state between tests\r\n5. **Clean up after yourself:** Reset what you change\r\n\r\n### For CI/CD Integration\r\n1. **Fail fast:** Run fastest tests first\r\n2. **Parallelize:** Split tests across workers\r\n3. **Report properly:** Generate actionable reports\r\n4. **Set quality gates:** Block releases below thresholds\r\n5. **Monitor trends:** Track flakiness over time\r\n\r\n## Ecosystem Status (as of 2026-09-10 / 截至 2026-09-10)\r\n\r\nTool versions and best practice shift quickly. Verify against official release\r\nnotes before committing to a stack.\r\n\r\n| 关注点 | 需要确认什么 | 影响 |\r\n|---|---|---|\r\n| 浏览器自动化版本 | Playwright / Cypress / Selenium 当前主版本 | 等待机制与选择器 API 差异 |\r\n| 变异测试工具链 | 与你的语言和测试框架是否兼容 | 决定能否把变异分纳入门禁 |\r\n| CI 运行成本 | 并行 worker 的计费与上限 | 决定金字塔各层能跑多频繁 |\r\n| 视觉回归方案 | SaaS 还是自托管 | 涉及截图是否出网（受监管行业敏感） |\r\n| AI 生成测试的合入政策 | 本单位对生成代码的评审要求 | 决定人工检查点设在哪里 |\r\n\r\n**最近动态（截至 2026-09-10，以官方发布为准）**\r\n1. 变异测试与\"断言强度\"指标正从学术研究走向工程实践，部分团队已用它替代\r\n   单纯的覆盖率门禁。\r\n2. 视觉回归的自托管方案受关注度上升，主要驱动是数据驻留与合规要求。\r\n3. AI 生成测试用例已成常见能力，行业关注点转向\"生成用例的评审与可追溯\"，\r\n   而非生成数量。\r\n4. 以上为趋势描述，具体工具版本与能力请以官方最新发布为准。\r\n\r\n## Testing Framework Comparison\r\n\r\n| Framework | Best For | Languages | 学习曲线 | 并行能力 | 调试体验 | 适合团队规模 | 主要坑 | 何时不要用 |\r\n|---|---|---|---|---|---|---|---|---|\r\n| Pytest | Python APIs, unit tests | Python | 低 | 中（pytest-xdist） | 好（--pdb、丰富报错） | 1–20 | fixture 作用域误用导致状态泄漏 | 需要浏览器级交互时 |\r\n| Jest | JS/TS 单元与组件测试 | JS/TS | 低 | 好（内置） | 好 | 1–20 | mock 过深，测到 mock 而非实现 | 需要真实浏览器行为时 |\r\n| Vitest | Vite 生态单元测试 | JS/TS | 低 | 好 | 好 | 1–15 | 与 Jest 的 mock API 差异 | 非 ESM/老构建体系 |\r\n| JUnit 5 | Java 应用 | Java | 中 | 中 | 中 | 5–50 | 扩展模型复杂，配置易失控 | 快速原型阶段 |\r\n| Playwright | Web E2E | TS, Python, Java | 中 | 好（内置分片） | 很好（trace viewer） | 2–30 | 自动等待让人误解为\"不需要断言状态\" | 需测极老浏览器 |\r\n| Cypress | Web E2E（开发体验优先） | JS/TS | 低 | 需付费/自建 | 很好（时间旅行） | 1–15 | 多标签、多域限制 | 跨域/多窗口场景 |\r\n| Selenium | 遗留浏览器与网格 | 多语言 | 高 | 好（Grid） | 差（报错不直观） | 10+ | 等待与驱动版本地狱 | 新项目（有更好选择） |\r\n| REST Assured | API 测试 | Java, Groovy | 中 | 好 | 中 | 5–30 | DSL 冗长，维护成本高 | 团队不以 Java 为主 |\r\n| SuperTest | Node API 测试 | JavaScript | 低 | 好 | 好 | 1–10 | 只覆盖 HTTP 层，无契约能力 | 需要跨语言契约时 |\r\n| Pact | 消费者驱动契约测试 | 多语言 | 中高 | 好 | 中 | 5–30 | Broker 运维被低估 | 单体应用、调用方单一 |\r\n| Hypothesis | 属性/不变量测试 | Python | 中 | 好 | 中（反例收缩优秀） | 2–20 | 策略写不好等于随机测试 | 纯 CRUD、无计算逻辑 |\r\n| k6 / Locust | 性能与负载 | JS / Python | 中 | 好 | 中 | 2–20 | 把负载测试当功能测试跑 | 只需要单次基准时 |\r\n\r\n**选型判据（比\"哪个更流行\"更可靠）**：团队已有语言 > 调试体验 > 并行能力 >\r\n生态插件。调试体验决定日常成本，流行度不决定。\r\n\r\n## Version History\r\n\r\n- **1.0.1** (2026-09-10)\r\n  - Added worked examples to all four feature groups (risk-based scope table and\r\n    environment checklist; parameterised case matrix and property-based invariants;\r\n    page-object granularity and parallelism constraints; four-stage pipeline with\r\n    quality-gate config)\r\n  - Added \"Pyramid Ratios by Project Type\" (6 project types, 6 columns) and a\r\n    self-check for whether your ratio is right\r\n  - Expanded framework comparison from 3 to 10 columns and 8 to 12 rows\r\n    (learning curve, parallelism, debugging, team size, main pitfall, when not to use)\r\n  - Added Example 4 (ETL/data-pipeline strategy incl. data-quality checks) and\r\n    Example 5 (high coverage but still shipping incidents)\r\n  - Added \"Ecosystem Status (as of 2026-09-10)\"\r\n  - Corrected Python Playwright assertions (`to_have_count`, `not_to_be_empty`)\r\n- **1.0.0** (2026-05-15): Initial release\r\n  - Test strategy design framework\r\n  - Unit test generation\r\n  - Integration test scaffolding\r\n  - E2E test patterns (Playwright)\r\n  - CI/CD integration guidance\r\n\r\n**Last Updated**: 2026-09-10\n\nFile v1.0.1:_meta.json\n\n{\n  \"ownerId\": \"kn74e704j3ygjcygnpf02rdvd185js13\",\n  \"slug\": \"ai-test-strategy-architect\",\n  \"version\": \"1.0.1\",\n  \"publishedAt\": 1789018363271\n}\n\nFile v1.0.1:skill-card.md\n\n## Description:\n\nAI-powered test strategy and automation assistant for designing testing frameworks, generating unit, integration, and end-to-end test cases, implementing web, mobile, and API automation, and building CI/CD testing pipelines.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[gechengling](https://clawhub.ai/user/gechengling)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers, software developers, test leads, and DevOps teams use this skill to design risk-based test strategies, generate practical test cases, scaffold automation patterns, and define CI/CD quality gates.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated test examples can contain placeholders, environment-specific assumptions, or assertions that are unsafe to copy directly.\n\nMitigation: Review generated tests before running them, replace placeholder URLs and tokens with safe test-environment values, and validate framework-specific assertions.\n\nRisk: Testing guidance can be misapplied to production systems or regulated data if examples are adapted without local review.\n\nMitigation: Run generated tests only in controlled test environments, use sanitized data, and route CI/CD quality gates through the team's normal review process.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/gechengling/skills/ai-test-strategy-architect)\n- [ClawHub publisher profile](https://clawhub.ai/user/gechengling)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown with code blocks, tables, workflow steps, and configuration examples]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces advisory testing artifacts and examples for review before use; it does not execute tests or bundled code.]\n\n## Skill Version(s):\n\n1.0.1 (source: frontmatter and server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.0.0: 3 files, 6810 bytes\n\nFiles: skill-card.md (2200b), SKILL.md (14769b), _meta.json (145b)\n\nFile v1.0.0:SKILL.md\n\n---\r\nname: \"AI Test Strategy Architect\"\r\ndescription: \"AI-powered test strategy and automation assistant — design comprehensive testing frameworks, generate unit/integration/e2e test cases, implement test automation for web/mobile/API, and build CI/CD testing pipelines. Covers Test-Driven Development (TDD), Behavior-Driven Development (BDD), property-based testing, and AI-augmented test generation. Built for QA engineers, software developers, test leads, and DevOps teams shipping reliable software. Keywords: test automation, unit testing, integration testing, e2e testing, TDD, BDD, CI/CD testing, Selenium, Playwright, Pytest, Jest, testing framework, test strategy, quality assurance, 测试自动化, 单元测试, 集成测试, 端到端测试, 测试策略, 质量保障.\"\r\nversion: \"1.0.0\"\r\n---\r\n\r\n# AI Test Strategy Architect\r\n\r\n## Overview\r\n\r\nBuild testing that catches bugs before users do. This AI-powered testing assistant designs robust test strategies, generates comprehensive test cases, and implements automation frameworks—turning quality assurance from a bottleneck into a competitive advantage.\r\n\r\n## Triggers\r\n\r\n- 中文触发词：`测试策略`、`单元测试`、`集成测试`、`E2E测试`、`自动化测试`、`测试用例`、`TDD`、`BDD`、`Playwright测试`、`Selenium`、`测试覆盖率`\r\n- English triggers: `test strategy`, `unit testing`, `integration testing`, `e2e testing`, `automated testing`, `test cases`, `TDD`, `BDD`, `Playwright`, `Selenium`, `test coverage`, `CI/CD testing`\r\n\r\n## Features\r\n\r\n### 1. Test Strategy Design\r\n- Assess project requirements and risk profiles\r\n- Design tailored testing pyramids (unit/integration/e2e ratios)\r\n- Select appropriate testing frameworks per use case\r\n- Define test data management strategies\r\n- Create test environment specifications\r\n\r\n### 2. Test Case Generation\r\n- Generate unit tests from code functions/methods\r\n- Create integration test scenarios from API specs\r\n- Design end-to-end user journey tests\r\n- Build property-based tests for edge cases\r\n- Generate negative test cases (error handling)\r\n\r\n### 3. Test Automation Implementation\r\n- Scaffold test projects with proper structure\r\n- Implement page object models for UI tests\r\n- Set up API test frameworks with data-driven approaches\r\n- Configure test parallelization and distribution\r\n- Implement visual regression testing\r\n\r\n### 4. CI/CD Pipeline Integration\r\n- Design testing stages in CI/CD pipelines\r\n- Configure test reporting and dashboards\r\n- Set up automated quality gates\r\n- Implement canary/feature flag testing strategies\r\n- Create performance test thresholds in pipelines\r\n\r\n## Workflow\r\n\r\n### Comprehensive Test Strategy Workflow\r\n\r\n```\r\nPhase 1: Assessment\r\n├── Analyze project architecture\r\n├── Identify critical user flows\r\n├── Assess technical risks\r\n├── Define quality metrics\r\n└── Select testing tools\r\n\r\nPhase 2: Design\r\n├── Design test pyramid\r\n├── Define test scope per layer\r\n├── Create test data strategy\r\n├── Document test environment needs\r\n└── Plan test automation approach\r\n\r\nPhase 3: Implementation\r\n├── Set up test project structure\r\n├── Implement unit tests\r\n├── Build integration test suite\r\n├── Create e2e test scenarios\r\n└── Configure test runners\r\n\r\nPhase 4: Automation\r\n├── Integrate with CI/CD\r\n├── Set up test reporting\r\n├── Configure parallel execution\r\n├── Implement test monitoring\r\n└── Create quality dashboards\r\n\r\nPhase 5: Maintenance\r\n├── Review test effectiveness\r\n├── Optimize slow tests\r\n├── Update for new features\r\n└── Archive obsolete tests\r\n```\r\n\r\n### Quick Test Generation Workflow\r\n\r\n```\r\n1. INPUT: Source code or feature description\r\n   ↓\r\n2. ANALYZE: Identify testable units\r\n   - Functions/methods\r\n   - User interactions\r\n   - API endpoints\r\n   ↓\r\n3. GENERATE: Create test cases\r\n   - Happy path scenarios\r\n   - Edge cases\r\n   - Error scenarios\r\n   - Boundary conditions\r\n   ↓\r\n4. VALIDATE: Run tests, fix failures\r\n   ↓\r\n5. OPTIMIZE: Improve coverage and speed\r\n```\r\n\r\n## Input Examples\r\n\r\n### Example 1: Function to Unit Test\r\n\r\n**Input Code:**\r\n```python\r\ndef calculate_discount(price: float, discount_percent: float, is_loyal: bool) -> float:\r\n    \"\"\"\r\n    Calculate final price after discount.\r\n    \r\n    Args:\r\n        price: Original price\r\n        discount_percent: Discount percentage (0-100)\r\n        is_loyal: Whether customer is a loyalty member\r\n    \r\n    Returns:\r\n        Final price after discount\r\n    \"\"\"\r\n    if price < 0:\r\n        raise ValueError(\"Price cannot be negative\")\r\n    if discount_percent < 0 or discount_percent > 100:\r\n        raise ValueError(\"Discount must be between 0 and 100\")\r\n    \r\n    discount_multiplier = 1 - (discount_percent / 100)\r\n    \r\n    if is_loyal:\r\n        # Loyalty members get extra 5% off\r\n        final_multiplier = discount_multiplier * 0.95\r\n    else:\r\n        final_multiplier = discount_multiplier\r\n    \r\n    return round(price * final_multiplier, 2)\r\n```\r\n\r\n**Generated Test Cases:**\r\n```python\r\nimport pytest\r\nfrom your_module import calculate_discount\r\n\r\nclass TestCalculateDiscount:\r\n    \"\"\"Unit tests for calculate_discount function\"\"\"\r\n    \r\n    # Happy path tests\r\n    def test_no_discount_returns_original_price(self):\r\n        \"\"\"No discount should return the original price\"\"\"\r\n        assert calculate_discount(100.00, 0, False) == 100.00\r\n    \r\n    def test_standard_discount(self):\r\n        \"\"\"Basic discount calculation\"\"\"\r\n        assert calculate_discount(100.00, 20, False) == 80.00\r\n    \r\n    def test_loyal_customer_extra_discount(self):\r\n        \"\"\"Loyal customers get additional 5% off\"\"\"\r\n        result = calculate_discount(100.00, 20, True)\r\n        expected = round(100 * 0.80 * 0.95, 2)  # 76.00\r\n        assert result == expected\r\n    \r\n    def test_full_discount(self):\r\n        \"\"\"100% discount should result in 0\"\"\"\r\n        assert calculate_discount(100.00, 100, False) == 0.00\r\n    \r\n    # Edge cases\r\n    def test_zero_price(self):\r\n        \"\"\"Zero price should return zero\"\"\"\r\n        assert calculate_discount(0.00, 50, False) == 0.00\r\n    \r\n    def test_rounding_to_cents(self):\r\n        \"\"\"Prices should round to 2 decimal places\"\"\"\r\n        result = calculate_discount(99.99, 33, False)\r\n        assert result == round(99.99 * 0.67, 2)\r\n    \r\n    # Error cases\r\n    def test_negative_price_raises_error(self):\r\n        \"\"\"Negative price should raise ValueError\"\"\"\r\n        with pytest.raises(ValueError, match=\"Price cannot be negative\"):\r\n            calculate_discount(-10.00, 10, False)\r\n    \r\n    def test_negative_discount_raises_error(self):\r\n        \"\"\"Negative discount should raise ValueError\"\"\"\r\n        with pytest.raises(ValueError, match=\"Discount must be between\"):\r\n            calculate_discount(100.00, -5, False)\r\n    \r\n    def test_over_100_discount_raises_error(self):\r\n        \"\"\"Discount over 100% should raise ValueError\"\"\"\r\n        with pytest.raises(ValueError, match=\"Discount must be between\"):\r\n            calculate_discount(100.00, 150, False)\r\n    \r\n    # Boundary tests\r\n    def test_boundary_zero_percent_discount(self):\r\n        \"\"\"0% is valid discount\"\"\"\r\n        assert calculate_discount(50.00, 0, False) == 50.00\r\n    \r\n    def test_boundary_hundred_percent_discount(self):\r\n        \"\"\"100% is valid discount\"\"\"\r\n        assert calculate_discount(50.00, 100, False) == 0.00\r\n```\r\n\r\n### Example 2: API Integration Test\r\n\r\n**Input:** OpenAPI endpoint definition\r\n```yaml\r\npaths:\r\n  /api/v1/users/{userId}/orders:\r\n    get:\r\n      summary: Get user orders\r\n      parameters:\r\n        - name: userId\r\n          in: path\r\n          required: true\r\n          schema:\r\n            type: string\r\n        - name: status\r\n          in: query\r\n          schema:\r\n            type: string\r\n            enum: [pending, shipped, delivered]\r\n      responses:\r\n        '200':\r\n          description: List of orders\r\n        '401':\r\n          description: Unauthorized\r\n        '404':\r\n          description: User not found\r\n```\r\n\r\n**Generated Integration Test:**\r\n```python\r\nimport pytest\r\nimport requests\r\nfrom typing import Dict\r\n\r\nBASE_URL = \"https://api.example.com\"\r\nHEADERS = {\"Authorization\": \"Bearer <test_token>\"}\r\n\r\nclass TestUserOrdersAPI:\r\n    \"\"\"Integration tests for User Orders endpoint\"\"\"\r\n    \r\n    @pytest.fixture\r\n    def test_user_id(self):\r\n        \"\"\"Fixture providing a test user with known orders\"\"\"\r\n        return \"user_123\"\r\n    \r\n    def test_get_orders_success(self, test_user_id: str):\r\n        \"\"\"Should return 200 with list of orders\"\"\"\r\n        response = requests.get(\r\n            f\"{BASE_URL}/api/v1/users/{test_user_id}/orders\",\r\n            headers=HEADERS\r\n        )\r\n        \r\n        assert response.status_code == 200\r\n        data = response.json()\r\n        assert \"orders\" in data\r\n        assert isinstance(data[\"orders\"], list)\r\n    \r\n    def test_get_orders_with_status_filter(self, test_user_id: str):\r\n        \"\"\"Should filter orders by status\"\"\"\r\n        response = requests.get(\r\n            f\"{BASE_URL}/api/v1/users/{test_user_id}/orders\",\r\n            params={\"status\": \"pending\"},\r\n            headers=HEADERS\r\n        )\r\n        \r\n        assert response.status_code == 200\r\n        orders = response.json()[\"orders\"]\r\n        assert all(order[\"status\"] == \"pending\" for order in orders)\r\n    \r\n    def test_get_orders_unauthorized(self, test_user_id: str):\r\n        \"\"\"Should return 401 without valid token\"\"\"\r\n        response = requests.get(\r\n            f\"{BASE_URL}/api/v1/users/{test_user_id}/orders\"\r\n        )\r\n        \r\n        assert response.status_code == 401\r\n    \r\n    def test_get_orders_user_not_found(self):\r\n        \"\"\"Should return 404 for non-existent user\"\"\"\r\n        response = requests.get(\r\n            f\"{BASE_URL}/api/v1/users/nonexistent_user/orders\",\r\n            headers=HEADERS\r\n        )\r\n        \r\n        assert response.status_code == 404\r\n        assert \"error\" in response.json()\r\n```\r\n\r\n### Example 3: E2E Test with Playwright\r\n\r\n**Input:** User journey description\r\n```\r\nUser flow: Login -> Add item to cart -> Checkout -> Verify order confirmation\r\n```\r\n\r\n**Generated E2E Test:**\r\n```python\r\nimport pytest\r\nfrom playwright.sync_api import Page, expect\r\n\r\n@pytest.fixture\r\ndef logged_in_page(page: Page):\r\n    \"\"\"Fixture that logs in user before each test\"\"\"\r\n    page.goto(\"https://shop.example.com/login\")\r\n    page.fill('[name=\"email\"]', \"test@example.com\")\r\n    page.fill('[name=\"password\"]', \"testpassword123\")\r\n    page.click('[type=\"submit\"]')\r\n    page.wait_for_url(\"**/dashboard\")\r\n    return page\r\n\r\ndef test_complete_checkout_flow(logged_in_page: Page):\r\n    \"\"\"End-to-end test: Login -> Add to cart -> Checkout -> Confirmation\"\"\"\r\n    page = logged_in_page\r\n    \r\n    # Step 1: Browse to product\r\n    page.goto(\"https://shop.example.com/products/widget-pro\")\r\n    page.click('[data-testid=\"add-to-cart\"]')\r\n    \r\n    # Step 2: Verify cart\r\n    page.click('[data-testid=\"cart-icon\"]')\r\n    expect(page.locator('[data-testid=\"cart-item\"]')).toHaveCount(1)\r\n    \r\n    # Step 3: Proceed to checkout\r\n    page.click('[data-testid=\"checkout-button\"]')\r\n    page.fill('[name=\"shipping_address\"]', \"123 Test Street\")\r\n    page.fill('[name=\"zip_code\"]', \"12345\")\r\n    page.click('[data-testid=\"continue-payment\"]')\r\n    \r\n    # Step 4: Complete payment\r\n    page.fill('[name=\"card_number\"]', \"4242424242424242\")\r\n    page.fill('[name=\"expiry\"]', \"12/28\")\r\n    page.fill('[name=\"cvv\"]', \"123\")\r\n    page.click('[data-testid=\"place-order\"]')\r\n    \r\n    # Step 5: Verify confirmation\r\n    expect(page.locator('[data-testid=\"order-confirmation\"]')).toBeVisible()\r\n    expect(page.locator('[data-testid=\"order-number\"]')).not_toBeEmpty()\r\n```\r\n\r\n## Output Templates\r\n\r\n### Template: Test Strategy Document\r\n```markdown\r\n# Test Strategy Document\r\n\r\n## Project Overview\r\n- Project Name: [Name]\r\n- Version: [Version]\r\n- Test Scope: [What's in/out]\r\n\r\n## Quality Objectives\r\n| Metric | Target | Measurement |\r\n|--------|--------|-------------|\r\n| Code Coverage | >80% | Codecov |\r\n| Bug Escape Rate | <5% | Bug Tracker |\r\n| Test Execution Time | <10 min | CI Pipeline |\r\n\r\n## Test Pyramid\r\n\r\n        ╱╲\r\n       ╱  ╲\r\n      ╱ E2E╲         [Few - 10%]\r\n     ╱──────╲\r\n    ╱Integration╲     [Some - 30%]\r\n   ╱────────────╲\r\n  ╱  Unit Tests  ╲   [Many - 60%]\r\n ╱────────────────╲\r\n\r\n## Testing Tools\r\n\r\n| Layer | Tool | Language |\r\n|-------|------|----------|\r\n| Unit | Pytest | Python |\r\n| Integration | pytest | Python |\r\n| E2E | Playwright | TypeScript |\r\n| API | REST Assured | Java |\r\n\r\n## Test Environments\r\n- Dev: https://dev.example.com\r\n- Staging: https://staging.example.com\r\n- Production: https://example.com\r\n\r\n## Test Data Strategy\r\n- [Strategy details]\r\n\r\n## Release Criteria\r\n- [ ] All critical tests pass\r\n- [ ] Coverage meets target\r\n- [ ] No P0 bugs open\r\n```\r\n\r\n## Best Practices\r\n\r\n### For Test Design\r\n1. **Follow FIRST principles:** Fast, Independent, Repeatable, Self-validating, Timely\r\n2. **Name tests descriptively:** `test_user_cannot_login_with_invalid_password`\r\n3. **Test one thing per test:** Easier debugging and maintenance\r\n4. **Use data-driven tests:** Reduce duplication with parameterized tests\r\n5. **Test edge cases:** Empty inputs, null values, maximum limits\r\n\r\n### For Test Automation\r\n1. **Prioritize stability:** Flaky tests are worse than no tests\r\n2. **Keep tests fast:** Slow tests don't run often\r\n3. **Use page objects:** Encapsulate UI structure changes\r\n4. **Isolate tests:** No shared state between tests\r\n5. **Clean up after yourself:** Reset what you change\r\n\r\n### For CI/CD Integration\r\n1. **Fail fast:** Run fastest tests first\r\n2. **Parallelize:** Split tests across workers\r\n3. **Report properly:** Generate actionable reports\r\n4. **Set quality gates:** Block releases below thresholds\r\n5. **Monitor trends:** Track flakiness over time\r\n\r\n## Testing Framework Comparison\r\n\r\n| Framework | Best For | Languages |\r\n|-----------|----------|-----------|\r\n| Pytest | Python APIs, unit tests | Python |\r\n| Jest | JavaScript/TypeScript | JS/TS |\r\n| JUnit 5 | Java applications | Java |\r\n| Playwright | Web E2E testing | TS, Python |\r\n| Cypress | Web E2E testing | JS/TS |\r\n| Selenium | Legacy browser testing | Multi |\r\n| REST Assured | API testing | Java, Groovy |\r\n| SuperTest | Node.js API testing | JavaScript |\r\n\r\n## Version History\r\n\r\n- **1.0.0** (2026-05-15): Initial release\r\n  - Test strategy design framework\r\n  - Unit test generation\r\n  - Integration test scaffolding\r\n  - E2E test patterns (Playwright)\r\n  - CI/CD integration guidance\n\nFile v1.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn74e704j3ygjcygnpf02rdvd185js13\",\n  \"slug\": \"ai-test-strategy-architect\",\n  \"version\": \"1.0.0\",\n  \"publishedAt\": 1779193115985\n}\n\nFile v1.0.0:skill-card.md\n\n## Description: <br>\nAI-powered test strategy and automation assistant that designs testing strategies, generates unit, integration, and end-to-end test cases, implements web, mobile, and API test automation, and supports CI/CD testing pipelines. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[gechengling](https://clawhub.ai/user/gechengling) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nQA engineers, software developers, test leads, and DevOps teams use this skill to design practical test strategies, generate test cases, scaffold automation, and plan CI/CD quality gates for software projects. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Generated API and browser test examples may include placeholder URLs, login values, tokens, or payment details that are unsafe to use directly in production. <br>\nMitigation: Use sandbox or staging environments, provider-approved test payment data, and secret managers or environment variables for real test credentials. <br>\nRisk: Generated tests and quality gates may not fully match the target application behavior or risk profile. <br>\nMitigation: Review generated test cases, automation code, and CI/CD thresholds before adopting them in a release workflow. <br>\n\n\n## Reference(s): <br>\n- [ClawHub Skill Page](https://clawhub.ai/gechengling/ai-test-strategy-architect) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, code, configuration, guidance] <br>\n**Output Format:** [Markdown with code blocks, checklists, tables, and structured testing guidance] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May include sample test code, CI/CD configuration guidance, test strategy documents, and framework comparisons.] <br>\n\n## Skill Version(s): <br>\n1.0.0 (source: frontmatter and server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>","readmeExcerpt":"Skill: AI Test Strategy Architect Owner: gechengling Summary: AI-powered test strategy and automation assistant — design comprehensive testing frameworks, generate unit/integration/e2e test cases, implement test automation for web/mobile/API, and build CI/CD testing pipelines. Covers Test-Driven Development (TDD), Behavior-Driven Development (BDD), property-based testing, and AI-augmented test generation. Built for Q","codeSnippets":[],"executableExamples":[],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\r\nname: \"AI Test Strategy Architect\"\r\ndescription: \"AI-powered test strategy and automation assistant — design comprehensive testing frameworks, generate unit/integration/e2e test cases, implement test automation for web/mobile/API, and build CI/CD testing pipelines. Covers Test-Driven Development (TDD), Behavior-Driven Development (BDD), property-based testing, and AI-augmented test generation. Built for QA engineers, software developers, test leads, and DevOps teams shipping reliable software. Keywords: test automation, unit testing, integration testing, e2e testing, TDD, BDD, CI/CD testing, Selenium, Playwright, Pytest, Jest, testing framework, test strategy, quality assurance, 测试自动化, 单元测试, 集成测试, 端到端测试, 测试策略, 质量保障.\"\r\nversion: \"1.0.2\"\r\n---\r\n\r\n# AI Test Strategy Architect\r\n\r\n## Overview\r\n\r\nBuild testing that catches bugs before users do. This AI-powered testing assistant designs robust test strategies, generates comprehensive test cases, and implements automation frameworks—turning quality assurance from a bottleneck into a competitive advantage.\r\n\r\n## Language Policy（语言策略 / SQP-3）\r\n\r\n本技能同时提供中英双语触发词与内容，语言使用规则如下，避免输出语言飘移：\r\n\r\n| 项目 | 规则 |\r\n|---|---|\r\n| 默认语言 | 跟随提问语言：中文提问用中文回答，英文提问用英文回答 |\r\n| 术语 | 保留英文原词（`property-based testing`、`page object`、`flaky`），首次出现时括注中文 |\r\n| 代码与配置 | 一律原样保留，不翻译标识符、字符串与注释语言之外的部分 |\r\n| 混合提问 | 以正文主体语言为准；若仍不明确，直接询问一次，不要自行猜测 |\r\n| 表格与模板 | 同一份产物内保持单一语言，不要中英混排 |\r\n| 切换 | 用户任何时候说“用英文/用中文回答”，立即切换，不影响技术内容 |\r\n\r\n\r\n\r\n## Triggers\r\n\r\n- 中文触发词：`测试策略`、`单元测试`、`集成测试`、`E2E测试`、`自动化测试`、`测试用例`、`TDD`、`BDD`、`Playwright测试`、`Selenium`、`测试覆盖率`\r\n- English triggers: `test strategy`, `unit testing`, `integration testing`, `e2e testing`, `automated testing`, `test cases`, `TDD`, `BDD`, `Playwright`, `Selenium`, `test coverage`, `CI/CD testing`\r\n\r\n**Required context（至少满足一条才激活）**\r\n1. 需要设计或改进一套测试策略、分层比例或门禁；或\r\n2. 需要为具体代码/接口/流程设计用例；或\r\n3. 需要把测试接入 CI/CD 并设定质量门禁；或\r\n4. 需要诊断测试体系本身的健康问题（覆盖率虚高、flaky、断言强度不足）。\r\n\r\n**Non-triggers（不激活）**\r\n\r\n| 请求 | 为什么不归本技能 | 应转向 |\r\n|---|---|---|\r\n| “帮我修这个 bug” | 缺陷修复，不是测试设计 | 通用调试 |\r\n| “这个接口返回 500，帮我看看” | 生产问题排查 | 运维/日志排查 |\r\n| “压测一下能扛多少 QPS” | 性能工程，目标与方法都不同 | 性能测试工具（k6/Locust） |\r\n| “做一次安全渗透测试” | 安全测试需专门授权与方法 | 安全测试流程 |\r\n| “把这份需求文档总结一下” | 文档处理，无测试对象 | 文档摘要 |\r\n| “安装 Playwright 环境” | 环境搭建操作 | 官方安装文档 |\r\n\r\n**执行边界声明**：本技能输出测试代码、配置形态与策略文档，供你在自己的环境中\r\n审阅后运行。它不执行测试、不写入你的仓库、不访问你的 CI。文中代码仅作参考材料。\r\n\r\n## Features\r\n\r\n### 1. Test Strategy Design\r\n- Assess project requirements and risk profiles\r\n- Design tailored testing pyramids (unit/integration/e2e ratios)\r\n- Select appropriate testing frameworks per use case\r\n- Define test data management strategies\r\n- Create test environment specifications\r\n\r\n\r\n**Worked example — risk-based scope for a payments-style service**\r\n\r\n| Module | 失效影响 | 发生概率 | 风险分 | 测试投入 | 具体手段 | 门禁归属 |\r\n|---|---|---|---|---|---|---|\r\n| 保费计算 | 资金错误，监管风险 | 中 | 9 | 最高 | 属性测试 + 黄金样本回归 + 变更检测 | PR 阻断 + nightly 变异测试 |\r\n| 投保校验 | 单用户受阻 | 高 | 6 | 高 | 边界表 + 参数化 | PR 阻断 |\r\n| 支付回调 | 重复扣款 | 低 | 6 | 高 | 幂等性专项 + 故障注入 | PR 阻断 + nightly 故障注入 |\r\n| 报表导出 | 内部使用 |"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn74e704j3ygjcygnpf02rdvd185js13\",\n  \"slug\": \"ai-test-strategy-architect\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1790573023046\n}"},{"path":"skill-card.md","content":"## Description:\n\nHelps teams design risk-based test strategies, generate test cases and automation examples, and plan CI/CD quality gates.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[gechengling](https://clawhub.ai/user/gechengling)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers, developers, test leads, and DevOps teams use this skill to plan unit, integration, and end-to-end testing, draft automation, and define CI/CD quality gates.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated tests or CI snippets may not fit the target project and could produce misleading results or quality gates.\n\nMitigation: Review and adapt examples to the project before running them or adding them to CI.\n\nRisk: Example credentials or placeholders could be replaced with real production secrets.\n\nMitigation: Use safe test credentials and never put production credentials in examples.\n\n## Reference(s):\n\n- [AI Test Strategy Architect on ClawHub](https://clawhub.ai/gechengling/skills/ai-test-strategy-architect)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Code, Configuration, Guidance]\n\n**Output Format:** [Markdown with code and configuration examples]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Proposed examples are for review and adaptation before execution.]\n\n## Skill Version(s):\n\n1.0.2 (source: frontmatter and release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"AI-powered test strategy and automation assistant — design comprehensive testing frameworks, generate unit/integration/e2e test cases, implement test automation for web/mobile/API, and build CI/CD testing pipelines. Covers Test-Driven Development (TDD), Behavior-Driven Development (BDD), property-based testing, and AI-augmented test generation. Built for QA engineers, software developers, test leads, and DevOps teams shipping reliable software. Keywords: test automation, unit testing, integration testing, e2e testing, TDD, BDD, CI/CD testing, Selenium, Playwright, Pytest, Jest, testing framework, test strategy, quality assurance, 测试自动化, 单元测试, 集成测试, 端到端测试, 测试策略, 质量保障. Skill: AI Test Strategy Architect Owner: gechengling Summary: AI-powered test strategy and automation assistant — design comprehensive testing frameworks, generate unit/integration/e2e test cases, implement test automation for web/mobile/API, and build CI/CD testing pipelines. Covers Test-Driven Development (TDD), Behavior-Driven Development (BDD), property-based testing, and AI-augmented test generation. Built for Q","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1034,"uniquenessScore":45,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T19:17:12.200Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T19:17:12.200Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T21:56:01.672Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}