📚 课程目录第1章验证任务拆解与测试用例设计

第1章验证任务拆解与测试用例设计

验证任务拆解与测试用例设计是机器人原型验证的起点，决定了验证工作的覆盖度与执行效率。该方法适用于以下典型场景：

建议：首次进行机器人原型验证的团队，应优先在核心功能（如运动控制、感知避障）上实践本方法，再逐步推广至全部模块。

进入本章节操作前，必须确认以下条件已满足：

注意：若需求文档尚未定稿或原型存在已知未修复阻塞缺陷，不建议启动验证任务拆解，否则会导致大量返工与用例废弃。

验证任务拆解与测试用例设计遵循“需求→任务→用例”的逐层分解路径，共包含四个核心步骤。

步骤	操作内容	输入物	输出物
步骤1 需求分析与任务识别	逐条阅读需求文档，提取功能、性能、安全、可靠性等可验证条目，形成初始验证项清单。	PRD、TRD、系统架构图	初始验证项清单
步骤2 任务拆解与层级划分	将验证项按子系统/模块/功能点进行分层拆解，确保每个任务原子化、可执行、可测量。	初始验证项清单	验证任务分解表
步骤3 测试用例设计	为每个验证任务设计至少一条测试用例，明确前置条件、操作步骤、预期结果与通过判据。	验证任务分解表	测试用例集（含用例模板）
步骤4 用例评审与确认	组织产品、系统、测试三方对用例的完整性、正确性、可执行性进行评审，并签字确认。	测试用例集	评审通过确认单

验证任务分解表（示例模板）

验证任务拆解与用例设计涉及多个角色，必须提前约定各角色的职责与交付边界，避免分工模糊导致的推诿或遗漏。

角色	职责	关键交付物	审核节点
产品经理	提供已评审的需求文档，确认验证范围与优先级，参与用例评审。	PRD、需求优先级清单	步骤1、步骤4
系统工程师	主导任务拆解，编写测试用例，确保用例可追溯至需求。	验证任务分解表、测试用例集	步骤2、步骤3、步骤4
测试工程师	审查用例的可执行性，补充边界与异常场景，执行用例并记录结果。	用例评审意见、执行记录	步骤3、步骤4
项目经理	协调资源，组织评审会议，跟踪任务拆解与用例设计进度。	评审会议纪要、计划跟踪表	步骤4

  责任边界黄金法则：系统工程师对“任务拆解的正确性”负责，测试工程师对“用例的可执行性”负责，产品经理对“需求的完整性”负责。三者不可互相替代。

本章涉及的所有记录材料必须统一编号、版本受控并存档至项目配置管理库。以下为核心模板与表单：

测试用例模板（标准格式）

用例编号	测试项	前置条件	测试步骤	预期结果	实际结果	状态
TC-001	直线行驶速度精度	电池电量>80%，地面平坦	1. 下发速度指令0.5m/s 2. 行驶5m，记录编码器数据	实际速度偏差≤±3%	—	待执行
TC-002	静态避障响应	障碍物置于路径前方1m	1. 启动自主移动 2. 测量停止距离	停止距离≥0.3m且≤0.5m	—	待执行

任务拆解与用例设计过程中可能出现以下异常情况，需按对应策略处理：

异常现象	可能原因	处理策略
需求描述模糊，无法拆解	需求文档未经过充分评审，存在二义性	暂停拆解，由产品经理发起需求澄清会议，补充量化指标
任务拆解粒度不一致	不同系统工程师对“原子任务”的理解不同	统一使用“WHY-HOW-WHAT”拆解原则，以“可独立测试”为粒度标尺
用例评审未通过	用例遗漏关键场景、步骤不可执行或预期结果不可测量	记录评审意见，由系统工程师在2个工作日内完成修改并重新提交评审
跨团队责任边界冲突	两个团队对同一验证项均认为“归对方负责”	项目经理组织专题仲裁会，依据“谁产生谁负责”原则划定主责方

关键警示：任何异常在未闭环前不得进入下一环节。建议在项目看板中设置“拆解与设计阻塞”列，每日站会跟踪直至解决。

本章工作完成时，必须逐条核对以下验收项，全部满足方可进入下一章节（测试执行与数据采集）：

  验收自检清单

  □ 需求追溯矩阵已建立且无断裂

  □ 每个任务均有明确责任人

  □ 用例前置条件可被独立满足

  □ 预期结果包含量化判据（非模糊描述）

  □ 评审遗留问题已录入跟踪表

第1章 验证任务拆解与测试用例设计