3. 框架选型决策矩阵：从项目规模、团队技能、硬件平台、预算四个维度建立选型打分模型
说实话，我见过太多团队在框架选型上栽跟头。有的盲目追新，选了 Robot Framework 结果嵌入式板子跑不动；有的死守老工具，项目规模翻了几倍后维护成本直接爆炸。选型这事，不能靠拍脑袋，得有个能复用的决策模型。
这一章，我就把我在多个项目中打磨出来的「四维打分矩阵」拆开讲。你拿回去，对着自己的项目填一遍，结果基本就八九不离十了。
3.1 为什么需要决策矩阵？
先讲个真实案例。我之前带过一个团队，给某家电厂商做智能插座测试。团队 6 个人，3 个刚毕业，硬件平台是 STM32F103，项目周期 4 个月。结果技术负责人选了 pytest + 自研硬件抽象层，理由是「灵活、可扩展」。
然后呢？前两个月光搭框架就花了 60% 的时间，新人根本看不懂自研的底层封装。最后项目延期，测试覆盖率不到 40%。
你想想看，如果当时用 CppUTest + 简单的串口通信库，新人上手快，项目规模也不大，根本不会出这种问题。所以，选型不是选「最好的」，而是选「最合适的」。
3.2 四维打分模型详解
我习惯把每个维度拆成 3 个等级，分别对应 1 分、3 分、5 分。最后加权求和，总分决定推荐框架。
3.2.1 维度一：项目规模
项目规模不只是代码行数，我一般看三个指标：测试用例数、模块数、迭代频率。
| 等级 | 测试用例数 | 模块数 | 迭代频率 | 得分 |
|---|---|---|---|---|
| 小型 | < 100 | 1-3 | 月级 | 1 |
| 中型 | 100-500 | 4-10 | 双周级 | 3 |
| 大型 | > 500 | > 10 | 周级 | 5 |
举个例子，一个智能手表的固件测试，用例数大概 200-300，模块有蓝牙、传感器、显示、电源管理 4 个，迭代周期两周。这属于中型项目，得 3 分。
3.2.2 维度二：团队技能
这个维度我吃过亏。有一次团队里全是 C 语言老手，我硬推 Python 的 pytest，结果培训成本比开发成本还高。
| 等级 | 主流语言 | 自动化经验 | 学习曲线容忍度 | 得分 |
|---|---|---|---|---|
| 初级 | C/汇编 | 无或少量 | 低（≤1周） | 1 |
| 中级 | C/Python | 1-2年 | 中（1-2周） | 3 |
| 高级 | Python/Java | ≥3年 | 高（≥2周） | 5 |
这里有个坑：别只看团队「会什么」，要看他们「愿意学什么」。我曾经带过一个团队，嘴上说「Python 没问题」，结果真上手了，连 virtualenv 都不会配。所以，我建议在选型前先做个简单的技能摸底测试。
3.2.3 维度三：硬件平台
嵌入式测试绕不开硬件。资源受限的 MCU 和跑 Linux 的 MPU，选型逻辑完全不同。
| 等级 | 典型平台 | RAM | Flash | OS | 得分 |
|---|---|---|---|---|---|
| 受限 | 8位/32位MCU | < 64KB | < 512KB | 裸机/RTOS | 1 |
| 中等 | ARM Cortex-M系列 | 64KB-1MB | 512KB-4MB | FreeRTOS/ThreadX | 3 |
| 丰富 | ARM Cortex-A/RISC-V | ≥ 1MB | ≥ 4MB | Linux/Android | 5 |
我记得有一次，项目用的是 ESP32，RAM 只有 520KB。有人提议用 Python 写测试脚本，结果 MicroPython 固件一烧进去，RAM 直接吃掉 300KB，应用逻辑都没空间跑了。所以，硬件平台得分 ≤ 3 时，老老实实用 C/C++ 框架。
3.2.4 维度四：预算
预算不只是钱，还包括时间成本。我一般把预算分成三类：
- 零预算（1分）： 纯开源，社区支持，团队自学。适合初创项目或内部工具。
- 低预算（3分）： 可以买几本教材、几个月的云服务器，或者请一次外部培训。
- 充足预算（5分）： 可以买商业许可证、请咨询团队、搭建专用测试实验室。
这里有个反直觉的点：预算充足时，反而要警惕「花钱买省事」。我见过一个客户，花 50 万买了某商业测试平台，结果因为硬件适配问题，又花了 30 万做二次开发。最后算下来，还不如用开源框架自己搭。
3.3 打分模型与框架映射
四个维度打完分，加权求和。我常用的权重分配是：项目规模 30%、团队技能 25%、硬件平台 30%、预算 15%。当然，你可以根据实际情况调整。
总分范围 4-20 分，映射到三类框架：
| 总分区间 | 推荐框架类型 | 典型代表 | 适用场景 |
|---|---|---|---|
| 4-9 | 轻量级单元测试框架 | CppUTest, Unity, CMock | 小型 MCU 项目，团队 C 语言为主 |
| 10-15 | 中量级集成测试框架 | pytest + pyserial, Google Test | 中型项目，有 Python 基础，硬件资源中等 |
| 16-20 | 重量级系统测试框架 | Robot Framework, Squish | 大型项目，多模块，硬件资源丰富，预算充足 |
3.4 实战案例：智能家居网关测试选型
拿我最近做的一个项目举例。智能家居网关，主控是 RK3568（ARM Cortex-A55，4GB RAM），跑 Linux。团队 8 个人，3 个精通 Python，5 个 C 语言为主。测试用例预计 400+，迭代周期两周。预算 10 万。
打分过程：
- 项目规模：中型（3分）
- 团队技能：中级（3分）—— Python 和 C 都有，但自动化经验一般
- 硬件平台：丰富（5分）—— 4GB RAM，跑 Linux，随便折腾
- 预算：低预算（3分）—— 10 万够买设备，但不够买商业许可证
加权总分 = 3×30% + 3×25% + 5×30% + 3×15% = 0.9 + 0.75 + 1.5 + 0.45 = 3.6（换算成 20 分制为 14.4 分）。
落在 10-15 区间，推荐中量级框架。我们最后选了 pytest + pyserial + 自研硬件抽象层，两个月就搭完了框架，测试覆盖率稳定在 75% 以上。
3.5 决策矩阵知识图谱
下面这张图，我把整个决策逻辑画出来了。你可以把它打印出来，贴在工位上，每次选型前过一遍。
3.6 决策矩阵的局限性
说实话，这个模型不是万能的。我遇到过几次「模型推荐 A，实际选了 B」的情况。比如：
- 组织惯性： 公司统一要求用某个框架，你没法选。
- 客户指定： 甲方爸爸说「必须用 XXX」，你只能照做。
- 生态绑定： 某个芯片厂商的 SDK 只支持特定测试框架。
遇到这些情况，我的建议是：先用模型算出「理想答案」，再跟现实约束做妥协。至少你知道自己放弃了什么，以及未来要补什么坑。