第二章 需求分析：确定测试范围、兼容性矩阵设计、目标平台与版本规划

很多团队一上来就写自动化脚本，结果测到一半发现漏了十几个平台版本，矩阵乱了，连基础功能都没覆盖全。我个人习惯是先花一天做需求分析。这一步看起来像「设计文档」，其实它决定了整个框架的骨架。你想想看，方向错了，跑得再快也没用。

2.1 为什么需求分析是第一步

说白了，需求分析就是为了回答三个问题：

• 测什么？——测试范围，哪些功能、哪些接口、哪些场景必须覆盖。
• 在哪儿测？——目标平台与版本，操作系统、芯片架构、系统级库的版本组合。
• 怎么算过？——兼容性矩阵，哪些组合必须通过，哪些可以降级容忍。

我在项目中遇到过一种情况：SDK刚发布时只支持 Android 9+，但客户实际用 Android 8 的设备特别多。如果我们一开始没把 Android 8 放进兼容性矩阵，后期临时加测，整个自动化流程都要改，非常被动。所以这一步千万别跳过。

2.2 确定测试范围

测试范围不是「把所有功能都测一遍」。实际做的时候，我习惯按三个维度裁剪：

1. SDK 核心 API——公开接口、必须稳定、必须向后兼容。比如初始化、配置、核心功能调用。
2. 边界条件——参数极限、空指针、并发、中断、资源不足。这些最容易在平台切换时出问题。
3. 集成场景——SDK 被接入宿主应用后的行为：生命周期管理、多线程安全、内存泄漏。

举个例子，我之前做过的图像识别 SDK，核心 API 只有 5 个，但边界条件却有 70 多个。我们按优先级分了 P0 ~ P2，P0 必须自动化，P2 手动抽测。这样既保证了质量，又没让自动化框架一开始就膨胀到失控。

2.3 兼容性矩阵设计

兼容性矩阵是整个框架的「地图」。设计得好，自动化脚本能复用 80%；设计不好，每个平台都得单独写一套判断逻辑。

我拿一个实际 SDK 项目举个例子（简化版）：

注意看，每个平台我都列了 OS 版本范围和芯片架构。设计矩阵时有个原则：版本不要贪多，选稳定版+最新版+一个过渡版。比如 Android 我选了 9（过渡）、10/11/12（稳定主力）、13（最新）。这样能覆盖大部分用户，又不会让测试量爆炸。

2.4 目标平台与版本规划

确定了矩阵之后，还要考虑一个现实问题：每个平台的版本号是写死在配置文件，还是做成参数化？

我建议做成参数化，至少把 OS 版本、架构、SDK 版本三个变量抽出来。这样矩阵变化时只需要改配置文件，不用动自动化脚本。举个例子，我们的自动化框架里会有一个 platform_config.json：

{
  "android": {
    "versions": ["9", "10", "11", "12", "13"],
    "archs": ["arm64", "x86_64"],
    "prerequisites": {
      "minSdk": 26,
      "targetSdk": 33
    }
  },
  "ios": {
    "versions": ["14.0", "15.0", "16.0", "17.0"],
    "archs": ["arm64", "x86_64"],
    "prerequisites": {
      "deploymentTarget": "14.0"
    }
  }
}

为什么这么做？我记得有一次客户要求增加对 Android 14（预览版）的支持。如果版本号硬编码在脚本里，我得挨个文件改；但参数化之后，只加了 "14" 到列表里，重新拉一遍镜像就完事了——省了至少半天。

2.5 本章核心逻辑

下面这张 SVG 图把需求分析的整体脉络画出来了。你可以看到输入是什么，经过哪些步骤，最后产出什么。每次搭建新框架时，我都会对着这个图把每个节点过一遍，确保没有遗漏。

好了，需求分析阶段的核心内容就这些。你可以在实际项目中直接把上面那个矩阵表格和配置文件拿来用，稍作调整就能套进自己的 SDK。记住一点：测试范围宁可收窄 20%，也不要漏掉 1% 的潜在用户场景——因为漏掉的往往最致命。