back
loading skill details...
当团队要选测试工具（自动化框架/性能工具/管理平台）、现有工具不能满足需求需要替换、或者公司要求做技术评估时使用此技能。通过多维度对比评估（功能覆盖/学习成本/社区活跃度/维护成本/扩展性）输出推荐方案和迁移实施建议。不要只看 Gartner 象限或者技术网红推荐——工具好不好取决于你的团队能力、技术栈和实际场景...
---
name: qa-tech-selection
version: 1.6.0
description: >-
当团队要选测试工具（自动化框架/性能工具/管理平台）、现有工具不能满足需求需要替换、或者公司要求做技术评估时使用此技能。通过多维度对比评估（功能覆盖/学习成本/社区活跃度/维护成本/扩展性）输出推荐方案和迁移实施建议。不要只看 Gartner 象限或者技术网红推荐——工具好不好取决于你的团队能力、技术栈和实际场景。每个推荐方案附带 POC 验证计划和风险提示。
when_to_use: 用户说"技术选型"、"工具选择"、"框架选择"、"用什么工具"、"工具对比"、需要评估测试技术方案、现有工具不能满足需求需要替换时
allowed-tools: Read Grep Glob WebFetch
related_skills:
upstream:
- qa-test-strategy-design # 输入：测试策略确定需求
downstream:
- qa-ci-cd-testing # 输出：技术选型用于CI/CD集成
- qa-test-automation-arch
input_format:
required:
- name: 项目需求
type: string
description: 项目技术需求和非功能需求
- name: 技术约束
type: string
description: 技术栈限制和团队能力
optional:
- name: 预算限制
type: string
description: 工具和资源预算
output_format:
traceability:
- 每次选型评估带唯一ID（SEL-XXXX）
structure:
- tech_evaluation: 技术评估报告
- comparison_matrix: 对比矩阵
- recommendation: 推荐方案
- risk_assessment: 技术风险评估
categories: ['Development','Testing','DevOps']
depth_requirement_quantification:
reference_value: "根据选型复杂度调整评估深度：简单×1/中等×2/复杂×3"
minimum: "至少对比3个候选工具的核心维度"
error_recovery_guidance:
on_failure: "工具选型遗漏关键维度时回退到测试策略补充需求"
retry_behavior: "补充需求后重新评估候选工具"
---
# 测试技术选型
## 核心原则
工具替换快，思维不过时——选型要基于业务需求，不是技术偏好。
## 选型框架
### 维度1：需求分析
```text
需求收集：
├─ 业务需求
│ ├─ 测试类型：功能/性能/安全/兼容
│ ├─ 测试规模：用例数量/执行频率
│ ├─ 团队规模：人员数量/技能水平
│ └─ 预算限制：采购预算/维护成本
│
├─ 技术需求
│ ├─ 技术栈：语言/框架/协议
│ ├─ 集成需求：CI/CD/监控/报告
│ ├─ 扩展需求：并发/分布式/云化
│ └─ 维护需求：升级/扩展/迁移
│
└─ 约束条件
├─ 时间约束：上线时间
├─ 资源约束：人力/预算
├─ 技术约束：现有技术栈
└─ 合规约束：安全/隐私
```
### 维度2：方案评估
```text
评估维度：
├─ 功能性
│ ├─ 功能覆盖：是否满足需求
│ ├─ 功能深度：功能完善程度
│ ├─ 扩展性：是否支持扩展
│ └─ 定制性：是否支持定制
│
├─ 易用性
│ ├─ 学习成本：上手难度
│ ├─ 使用体验：操作便捷性
│ ├─ 文档质量：文档完善程度
│ └─ 社区支持：社区活跃度
│
├─ 性能
│ ├─ 执行效率：执行速度
│ ├─ 资源消耗：CPU/内存/磁盘
│ ├─ 并发能力：支持并发数
│ └─ 稳定性：长期运行稳定性
│
├─ 成本
│ ├─ 采购成本：License费用
│ ├─ 实施成本：部署/集成成本
│ ├─ 维护成本：升级/维护成本
│ └─ 培训成本：人员培训成本
│
└─ 风险
├─ 技术风险：技术成熟度
├─ 供应商风险：供应商稳定性
├─ 迁移风险：迁移难度
└─ 锁定风险：厂商锁定
```
### 维度3：决策矩阵
**决策矩阵：**
| 方案 | 功能性 | 易用性 | 性能 | 成本 | 风险 | 总分 |
|------|--------|--------|------|------|------|------|
| 方案A | 9 | 8 | 7 | 6 | 7 | 37 |
| 方案B | 8 | 9 | 8 | 7 | 8 | 40 |
| 方案C | 7 | 7 | 9 | 8 | 6 | 37 |
**权重：**
- 功能性：30%
- 易用性：25%
- 性能：20%
- 成本：15%
- 风险：10%
## 常见选型场景
### 场景1：自动化框架选型
```text
选项对比：
├─ Playwright
│ ├─ 优点：多浏览器、自动等待、调试友好
│ ├─ 缺点：社区相对较小
│ └─ 适用：现代Web应用、多浏览器测试
│
├─ Cypress
│ ├─ 优点：实时调试、自动重试、CI友好
│ ├─ 缺点：仅支持Chrome、iframe支持差
│ └─ 适用：单页应用、快速反馈
│
├─ Selenium
│ ├─ 优点：生态成熟、语言支持多、社区大
│ ├─ 缺点：配置复杂、调试困难
│ └─ 适用：传统Web应用、多语言团队
│
└─ 决策依据：
├─ 团队技术栈
├─ 应用架构
├─ 测试需求
└─ 维护成本
```
### 场景2：性能测试工具选型
```text
选项对比：
├─ JMeter
│ ├─ 优点：功能全面、插件丰富、社区大
│ ├─ 缺点：界面复杂、资源消耗大
│ └─ 适用：复杂性能测试、协议测试
│
├─ Locust
│ ├─ 优点：代码化、分布式、轻量
│ ├─ 缺点：需要编程能力
│ └─ 适用：API性能测试、分布式测试
│
├─ k6
│ ├─ 优点：现代化、脚本化、CI友好
│ ├─ 缺点：社区相对较小
│ └─ 适用：现代应用、DevOps集成
│
└─ 决策依据：
├─ 测试类型
├─ 团队技能
├─ 集成需求
└─ 性能要求
```
### 场景3：测试管理平台选型
```text
选项对比：
├─ 开源方案
│ ├─ TestLink：功能简单、免费
│ ├─ 飞书/钉钉：协作方便、集成度高
│ └─ 自研：完全定制、成本高
│
├─ 商业方案
│ ├─ 禅道：功能全面、中文友好
│ ├─ JIRA：生态丰富、扩展性强
│ └─ Zephyr：JIRA集成、测试专业
│
└─ 决策依据：
├─ 团队规模
├─ 功能需求
├─ 预算限制
└─ 集成需求
```
## 选型报告模板
```markdown
# 技术选型报告
## 1. 背景和目标
- 选型背景：[为什么要做选型]
- 选型目标：[要解决什么问题]
- 约束条件：[时间/预算/资源]
## 2. 需求分析
- 业务需求：[需求列表]
- 技术需求：[需求列表]
- 优先级：[需求优先级]
## 3. 方案对比
- 候选方案：[方案列表]
- 评估维度：[维度列表]
- 对比结果：[对比表格]
## 4. 推荐方案
- 推荐方案：[方案名称]
- 推荐理由：[为什么推荐]
- 风险提示：[风险和应对]
## 5. 实施计划
- 实施步骤：[步骤列表]
- 时间计划：[时间节点]
- 资源需求：[人力/预算]
```
## Examples
**需要选择Web UI自动化框架（Selenium vs Playwright vs Cypress）**
→ 需求分析：团队技术栈（Java/JS）、测试规模（100/1000/10000用例）、维护能力
→ 方案评估：社区活跃度、跨浏览器支持、稳定性、学习曲线
→ 决策矩阵：按权重打分，推荐Playwright（社区活跃+跨浏览器+速度快）
**团队想引入性能测试工具（JMeter vs Locust vs k6）**
→ 按技术栈（Python/Javascript）、协议支持、分布式能力、报告输出综合评估
## Guidelines
技术选型完成后检查：
- [ ] 需求分析是否完整？
- [ ] 候选方案是否全面？
- [ ] 评估维度是否合理？
- [ ] 对比结果是否客观？
- [ ] 推荐理由是否充分？
- [ ] 实施计划是否可行？
## 检查清单
- [ ] 候选工具是否≥3个？
- [ ] 核心维度是否对比？
- [ ] 维护成本是否评估？
- [ ] 团队适配是否考虑？
- [ ] 选型报告是否生成？
don't have the plugin yet? install it then click "run inline in claude" again.