第1章 测试目标与范围定义

IoT原型测试的首要任务是在启动任何验证活动之前，精准锚定测试对象、划定测试边界、并设定可量化的通过标准。本章提供一套结构化的SOP流程，确保测试团队与干系人对“测什么、不测什么、怎样算通过”达成一致，避免测试活动后期出现范围蔓延或标准争议。

1.1 适用场景

本章规程适用于以下典型场景，测试负责人应根据项目阶段选择触发时机：

• 新IoT项目启动：原型硬件选型完成、固件基线版本确定后，首次建立测试范围。
• 原型迭代测试：每个迭代周期开始前，重新确认本次测试的对象边界与通过标准。
• 需求变更：产品需求、技术规格或通信协议发生变更时，需同步调整测试范围定义。
• 跨团队协作测试：多个团队（硬件、固件、云平台）联合测试前，统一范围认知。

1.2 前置条件

执行本章流程前，必须满足以下条件，否则应暂停流程并推动补齐：

1. 文档就绪：产品需求文档（PRD）已评审通过，技术规格书（TRS）已完成内部审核。
2. 资源到位：测试负责人、产品经理、硬件工程师、固件工程师已确认参与范围定义会议。
3. 基线标识：待测硬件版本号（如 PCB Rev 2.0）、固件版本号（如 FW v2.1.0）已冻结。
4. 环境预检：测试实验室环境（电源、网络、通信网关）可正常使用。

1.3 操作步骤

按以下5个步骤依次执行，每个步骤完成后需在《测试范围定义检查表》中打勾确认。

1. 识别测试对象
   • 列出所有待测硬件模组（主控、传感器、无线模块、执行器）。
   • 明确固件版本号及构建配置（如 Debug / Release）。
   • 确认通信协议栈版本（如 MQTT 5.0、CoAP RFC 7252）。
2. 划定测试边界
   • 功能边界：列出核心功能列表（数据采集、上报、远程控制、OTA升级），标记“本次必测”与“暂不测”。
   • 性能边界：定义性能指标覆盖范围（响应时间、吞吐量、并发数、功耗）。
   • 兼容边界：明确需要验证的网络环境（Wi-Fi信道、蓝牙版本、云端平台版本）。
3. 设定通过标准
   • 每个测试项必须设定可量化的通过条件（例如：响应时间 ≤ 500ms，丢包率 ≤ 0.1%）。
   • 明确“阻塞级”缺陷定义：任何导致原型无法完成核心功能的缺陷视为阻塞。
   • 设定兼容性测试覆盖率目标（如：支持设备列表覆盖率达100%）。
4. 组织范围评审
   • 召集测试负责人、产品经理、硬件/固件负责人举行评审会议。
   • 逐项过审《测试范围定义文档》，记录争议项并现场决策。
   • 评审通过后，三方在文档上签字确认。
5. 基线化确认
   • 将最终版的测试范围定义文档纳入项目配置管理库（如 Git、SVN）。
   • 冻结测试范围基线，后续任何变更必须通过变更控制流程（CCB）。

1.4 输入输出物

输入物	来源角色	输出物	去向角色
产品需求文档（PRD）	产品经理	《测试范围定义文档》	测试团队 / 项目干系人
技术规格书（TRS）	硬件 / 固件工程师	《测试通过标准清单》	测试执行人员
用户故事 / 用例	产品经理	《测试边界清单》	测试团队 / 评审组
硬件 / 固件版本清单	硬件 / 固件工程师	《测试对象配置表》	测试环境准备人员

{
  "testScopeDefinition": {
    "testObject": {
      "hardwareModules": ["ESP32-C3", "SHT35", "WS2812B"],
      "firmwareVersion": "v2.1.0",
      "communicationProtocols": ["MQTT 5.0", "CoAP RFC 7252"]
    },
    "testBoundary": {
      "functional": ["温湿度采集", "数据MQTT上报", "远程LED控制", "OTA升级"],
      "performance": ["上报响应时间 ≤ 500ms", "并发设备 ≥ 100台"],
      "compatibility": ["Wi-Fi 2.4GHz 802.11b/g/n", "蓝牙 5.0 BLE"]
    },
    "passCriteria": {
      "functionalPassRate": "100%",
      "performanceTargets": ["响应时间 ≤ 500ms", "丢包率 ≤ 0.1%"],
      "compatibilityCoverage": "100%"
    }
  }
}

1.5 责任边界

角色	职责范围	交付物 / 决策
测试负责人	牵头编写测试范围定义文档，组织评审，确保可测性	《测试范围定义文档》
产品经理	确认功能边界与通过标准，代表用户验收	功能列表确认、通过标准签字
硬件工程师	提供硬件规格与版本信息，确认硬件测试边界	硬件版本清单、硬件能力说明
固件工程师	提供固件版本与配置，确认固件测试边界	固件版本清单、功能开关配置
项目经理	审批测试范围基线，协调资源冲突	基线变更审批、争议仲裁

1.6 记录材料

本章执行过程中必须产生并归档以下记录：

• 《测试范围定义文档》（含版本号、修改历史、签字页）。
• 《测试范围评审纪要》（记录争议项、决策结果、待办事项）。
• 《测试范围定义检查表》（每步骤完成确认打勾）。
• 《测试边界清单》（含功能、性能、兼容三类边界的详细列表）。
• 《测试通过标准清单》（每个测试项对应的量化通过条件）。

1.7 异常处理

执行本章流程时，可能遇到以下异常情况，请按对应预案处理：

异常情形	影响	处理预案
测试对象版本未冻结	范围定义基线无效，后续测试结果无法追溯	暂停流程，推动硬件/固件团队冻结版本；必要时使用“候选版本+锁定标识”过渡
测试边界存在重大争议	评审会议无法达成一致，范围定义卡滞	升级至项目经理仲裁，记录争议项并设定“暂缓测试区”，后续迭代再补测
通过标准无法量化	测试结果无法判定通过/失败	与产品经理和开发工程师重新定义可测量指标（如用“95分位响应时间”替代“响应快”）
关键干系人缺席评审	范围定义缺乏必要输入，决策效力不足	延期评审，待关键角色确认后重新组织；紧急情况下可线上异步会签

1.8 验收标准

本章流程执行完成后，必须满足以下所有验收条件，方可进入下一章：

• 1.8.1 测试对象已明确列出所有硬件模组、固件版本及通信协议，版本号已冻结。
• 1.8.2 测试边界已清晰划定功能、性能、兼容三类边界，并标记“本次必测”与“暂不测”项。
• 1.8.3 每个测试项均设定了可量化的通过标准，且已通过评审组确认。
• 1.8.4 《测试范围定义文档》已完成三方会签（测试负责人、产品经理、项目经理）。
• 1.8.5 所有记录材料（检查表、评审纪要、边界清单、标准清单）已归档至项目配置管理库。
• 1.8.6 任何异常处理均有书面记录和审批签字，无遗留未关闭的争议项。