3. 测试用例设计原则：等价类划分、边界值分析、场景法
本章将 ECP、BVA 与场景法固化到 IoT 原型测试的 SOP 流程中，确保测试用例同时具备数学覆盖、边界极限与端到端业务完整性。
3.1 适用场景
- 功能测试前期：对传感器数据域（温度、湿度、电压）进行分区设计。
- 兼容性与极限测试：验证协议参数边界（如 MQTT KeepAlive 超时值、CoAP 消息块大小）。
- 端到端业务场景验证：设备入网、OTA 升级、断网续传等复杂流程。
- 回归测试用例裁剪：使用等价类合并冗余用例，提高执行效率。
3.2 前置条件
- 需求基线就绪：产品需求文档（PRD）、用户故事或史诗故事已完成评审。
- 接口与数据规范固化：包括 MQTT 主题树、CoAP 资源路径、JSON/Protobuf Schema。
- 原型或 Mock 可用：至少具备硬件 Mock 或云服务仿真环境。
- 测试工具链准备：如 MQTT Box、Wireshark、Postman、串口监听工具。
3.3 操作步骤
核心工作流：特性分解 → ECP 分区 → BVA 定界 → 场景串联 → 矩阵整合。下方 SVG 展示了三者如何协作产出高置信度测试集。
步骤 1：特性与模块分解
从 PRD 中提取被测模块，识别所有输入域、输出域与外部接口。例如，智能温控器需要分解温度采集、WiFi 配网、云端同步、本地策略执行等模块。
步骤 2：应用等价类划分 (ECP)
- 有效类：符合需求且预期被正常处理的数据集合。
- 无效类：违反需求或被系统拒绝的异常数据集合。
// MQTT 有效载荷（温度控制）
// 策略：温度 10~40°C 为有效类，<10 或 >40 为无效类
{
"device_id": "TH-001",
"temperature": 25.5,
"humidity": 60.0,
"mode": "cool"
}步骤 3：应用边界值分析 (BVA)
- 上点 (On Point)：边界上的值（例如 10.0, 40.0）。
- 内点 (In Point)：有效类内远离边界的值（例如 25.0）。
- 离点 (Out Point)：无效类中紧邻边界的值（例如 9.9, 40.1）。
IoT 典型边界：MQTT KeepAlive 间隔（20~120 秒）、CoAP 块大小（64~1024 字节）、固件版本号比较、信号强度 RSSI 阈值。
步骤 4：应用场景法
- 基本流：最常用、无障碍的成功旅途（例如首次开箱配网成功）。
- 备选流：分支或备选路径（例如使用二维码替代声波配网）。
- 异常流：错误处理（例如配网时断网、服务器超时）。
步骤 5：合并与优先级排序
将 ECP、BVA、场景的用例去重后写入测试矩阵，使用追踪矩阵与需求关联。优先执行高影响、高风险的边界与异常场景。
3.4 输入输出物
| 方向 | 名称 | 描述 | 来源/去向 |
|---|---|---|---|
| 输入 | 需求规格说明书 (SRS) | 功能与性能指标定义 | 产品经理 |
| 输入 | 接口定义文档 | MQTT 主题、CoAP 资源、JSON Schema | 开发团队 |
| 输出 | 测试用例矩阵 | 包含 ECP / BVA / 场景列的设计表 | QA 团队 |
| 输出 | 需求追踪矩阵 (RTM) | 保证 100% 覆盖 | QA & PM |
3.5 责任边界
| 角色 | 职责 |
|---|---|
| QA 工程师 | 主导测试用例设计，执行与缺陷跟踪 |
| 开发工程师 | 技术澄清、代码审查，提供 Mock 接口 |
| 产品经理 | 确认场景优先级，评审用例完整性 |
| 系统架构师 | 审核边界值选取与极端场景的合理性 |
3.6 记录材料
- Jira / TestRail：创建测试计划，并将用例与需求 Issue 关联。
- ECP 分析表：记录每个输入域的等价类划分结果与类别判断。
- 边界值审计单：列出所有被测边界及其选择理由。
- 场景故事板：包含用户操作序列、系统预期行为。
3.7 异常处理
| 异常情况 | 处理措施 |
|---|---|
| 需求未定义或模糊 | 标记为“待定 (TBD)”，发起三方（QA/Dev/PM）澄清会议。 |
| 等价类重叠 | 重新分析数据域逻辑，拆分亚类直到互斥。 |
| 边界不明确（如浮点精度） | 与开发约定精度位，按规范 IEEE 754 单精度/双精度选取。 |
| 场景遗漏 | 执行启发式审查，参照同类 IoT 产品事故报告补充。 |
3.8 验收标准
- ECP 完全性：每个输入域至少包含 1 个有效类用例和 1 个无效类用例。
- BVA 覆盖：每个边界必须包含上点、内点、离点测试，共计至少 3 个用例。
- 场景覆盖：100% 覆盖已识别的用户故事主线与异常分支。
- 评审通过：测试矩阵经过至少一次同行评审与一次产品确认。
- 可追溯性：每条测试用例均能通过 ID 反向定位到原始需求或用户故事。