test-master

🧪 全栈质量保障专家指南

基于12年+QA经验的纯文档型测试指导Skill,覆盖单元/集成/E2E/性能/安全测试全流程,提供Jest/Playwright/k6等框架最佳实践与TDD方法论。

收藏
5.4k
安装
1.9k
版本
v0.1.0
CLS 安全性认证2026-05-07
点击查看完整报告 >

使用说明

核心用法

Test Master是一款面向软件测试全生命周期的专业指导Skill,采用[Test]/[Perf]/[Security]三维测试思维模式。用户可通过触发关键词(如test、E2E、performance test等)唤起该Skill,获得从测试策略制定到具体代码实现的完整支持。核心工作流包括:定义测试范围→制定三视角测试策略→编写带断言的测试用例→执行并收集结果→输出含严重级别评定的报告。Skill内置9份参考文档,覆盖单元测试(Jest/Vitest/pytest)、集成测试(Supertest)、E2E(Playwright/Cypress)、性能测试(k6/Artillery)、安全测试(OWASP)等全技术栈,并包含TDD铁律、测试反模式等进阶方法论。

显著优点

1. 体系化知识覆盖:不仅提供代码示例,更强调测试策略、质量门禁、左移测试等工程化思维,适合从个人开发者到QA团队的规模化应用。
2. 三维度质量保障:强制要求同时考虑功能正确性、性能表现、安全漏洞,避免单一视角导致的质量盲区。

3. 实战约束清单:明确的MUST DO/MUST NOT规范(如必须测试错误用例、禁止测试实现细节、强制CI/CD集成),直接提升测试代码质量。

4. 输出模板标准化:提供含严重级别(Critical/High/Medium/Low)的测试报告模板,便于缺陷管理和团队沟通。

潜在缺点与局限性

1. 纯文档无执行能力:Skill本身不执行测试代码,仅提供指导,实际效果依赖用户理解和落地能力。
2. 技术栈偏向Web生态:参考文档以JavaScript/TypeScript/Python为主,对移动端原生(iOS/Android)、嵌入式、游戏引擎等场景覆盖有限。

3. 反模式依赖经验判断:测试反模式识别需要使用者具备一定基础,新手可能难以准确判断"测试实现细节"等抽象问题。

4. 无动态更新机制:测试技术演进较快(如AI辅助测试、混沌工程),文档内容可能滞后于最新实践。

适合的目标群体

  • 初级-中级开发者:系统学习测试方法论,建立正确的测试思维
  • QA工程师/测试开发:制定团队测试规范、设计自动化框架、输出质量报告
  • 技术负责人/架构师:建立质量门禁、推动左移测试、评估技术债中的测试覆盖率缺口
  • DevOps工程师:将测试集成至CI/CD流水线,处理flaky test等工程化问题

使用风险

1. 认知偏差风险:过度依赖Skill指导而忽视业务上下文,可能导致测试用例与真实用户场景脱节。
2. 工具链版本冲突:参考文档中的框架版本(如Playwright、Cypress)可能与项目实际版本存在API差异,需人工核对。

3. 性能测试误用:k6/Artillery等工具需要合理的负载模型设计,不当使用可能对被测系统造成生产环境影响。

4. 安全测试边界:Skill提供的OWASP指南为通用检查清单,无法替代专业渗透测试或合规审计。

安全解读

核心定位

Test Master 是一款专注于软件测试领域的专家级 Skill,由拥有 12 年以上 QA 经验的虚拟专家驱动。其核心创新在于三维测试思维模式——将功能测试 [Test]、性能测试 [Perf] 与安全测试 [Security] 整合为统一决策框架,确保任何测试策略都同时覆盖正确性、效率与安全性。

核心用法

1. 测试策略制定:从需求分析阶段介入,定义测试范围(单元/集成/E2E)、选择工具链(Jest/pytest/Playwright/k6)、规划覆盖率目标
2. 测试用例开发:提供针对主流框架的代码模板,强制要求包含正向路径 + 错误场景 + 边界条件

3. 质量度量与报告:内置缺陷分级(Critical/High/Medium/Low)、覆盖率缺口分析、CI/CD 集成检查清单

4. 专项测试支持:性能基准(k6/Artillery)、安全漏洞扫描(OWASP)、可访问性(WCAG)、探索性测试方法论

显著优点

  • 方法论体系完整:涵盖 TDD 铁律、测试反模式、Page Object/Screenplay 等设计模式,超越简单代码片段层面
  • 工具链覆盖全面:从前端(React Testing Library)到后端(Supertest)、从浏览器自动化(Playwright/Cypress)到负载测试(k6)均有对应参考文档
  • 质量门禁意识:内置 "shift-left" 和 "quality gate" 理念,强调在开发早期拦截缺陷
  • 约束条件清晰:明确的 MUST DO/MUST NOT 清单(如禁止跳过错误测试、禁止测试实现细节),降低团队误用风险

潜在缺点与局限

  • 纯文档型设计:无可执行代码,不提供自动测试生成或实时覆盖率分析功能,需配合具体工具使用
  • T3 来源风险:由个人开发者维护,缺乏企业级背书,关键生产环境建议额外审计
  • 框架版本敏感:参考文档中的工具版本(如 Jest 配置)可能滞后于社区最新实践
  • 语言生态偏向:知识库明显侧重 JavaScript/TypeScript 与 Python 生态,对 Java/.NET/Go 等语言覆盖有限

适合人群

  • 需要建立团队测试规范的 技术负责人/QA Lead
  • 从功能测试转向自动化测试的 初级-中级 QA 工程师
  • 希望系统化补全测试知识盲区的 全栈开发者
  • 在 CI/CD 中集成质量门禁的 DevOps 工程师

常规风险

  • 误用风险低:纯知识型 Skill 不产生直接代码执行,主要风险在于建议被不当应用(如盲目追求 100% 覆盖率而忽视测试价值)
  • 供应链安全:当前版本零依赖,但未来若引入可执行模块需重新评估
  • 知识过时风险:测试领域工具迭代快(如 Cypress vs Playwright 竞争),建议结合官方文档交叉验证

test-master 内容

references文件夹
手动下载zip · 20.0 kB
automation-frameworks.mdtext/markdown
请选择文件