📚 课程目录第3章自动化测试需求分析与验收标准制定

3. 自动化测试需求分析与验收标准制定

在TIA Portal项目中，自动化测试能否真正落地，往往不取决于测试脚本写得多复杂，而取决于测试需求是否被正确地从工艺描述中“翻译”出来。很多项目验收阶段出现争议，根源不是程序有Bug，而是双方对“什么算合格”理解不一致。本节围绕从工艺描述到可测需求、验收准则、测试用例来源、需求追溯矩阵与风险分析这条主线，说明如何把模糊的工艺语言转化为可执行、可判定、可追溯的测试资产。

一、从工艺描述到可测需求

工艺描述通常以自然语言给出，例如“按下启动按钮后，输送带运行，物料到位后气缸推出，保持2秒后返回”。这类描述包含动作顺序和大致时序，但缺少测试所需的精确条件。可测需求必须补齐四类信息：触发条件（哪个信号、什么边沿）、前置状态（设备处于什么模式、有无报警）、期望输出（哪个输出置位、延时多久）、判定依据（观察哪个变量、允许误差多少）。

以“气缸推出保持2秒”为例，可测化后应写成：在自动模式下，当物料检测传感器B3由0变1且无急停、无报警时，输出Q2.1置1；从Q2.1上升沿开始计时，T45达到2.0s后Q2.1复位。这样一条需求，测试人员可以直接在PLC变量表中监视B3、Q2.1和T45.ET，无需再向工艺人员追问。需要强调的是，示例中的地址、定时器编号和2.0s均为教学假设值，实际项目应按电气图纸和工艺文件填写。

二、验收准则的量化

验收准则决定“通过”与“不通过”的边界。对于开关量逻辑，准则通常是状态一致性；对于模拟量或节拍类需求，必须给出数值容差。例如“输送带启动响应时间不超过300ms”，应明确测量起点是启动按钮信号上升沿，终点是输送带接触器反馈信号上升沿，允许偏差±50ms。若只写“响应及时”，测试结果就无法复现。

验收准则还应区分功能准则与非功能准则。功能准则关注动作是否正确，非功能准则关注响应时间、循环周期、报警响应、断电恢复等。两者混在一起，容易导致测试用例遗漏。建议每条验收准则都对应一个可观测变量或HMI画面元素，避免依赖“目测设备动作”这种主观判断。

三、测试用例的来源与组织

测试用例不应凭空编写，主要来自四个渠道：工艺描述中的正常流程、电气原理图中的互锁关系、程序中的状态机分支、以及历史故障与风险分析结果。正常流程生成基本功能用例；互锁关系生成安全与联锁用例；状态机分支生成模式切换与异常恢复用例；风险分析生成边界与故障注入用例。

组织用例时，建议按“需求编号—用例编号—前置条件—操作步骤—期望结果—实际结果—判定”七列记录。用例编号与需求编号建立映射，后续追溯矩阵直接引用。对于同一需求，可设计正常、边界、异常三类用例。例如定时2.0s的需求，正常用例测2.0s，边界用例测1.9s与2.1s，异常用例测计时过程中急停触发是否立即复位输出。

四、需求追溯矩阵与风险分析

需求追溯矩阵（RTM）用于回答两个问题：每条需求是否都有测试覆盖？每个测试用例是否都对应真实需求？矩阵的行是需求，列是用例，交叉点标记覆盖关系。若某行无标记，说明该需求未被测试；若某列无标记，说明存在无来源用例，可能是冗余或需求遗漏。矩阵不必追求一次性完整，可在迭代中逐步补齐。

风险分析则决定测试的优先级。常用方法是按“发生概率×影响程度”分级。影响程度可依据安全、停机时间、产品质量三个维度评估。高风险需求必须安排故障注入测试，例如模拟传感器抖动、通信中断、电源瞬时跌落。风险分析结果应反馈到用例设计，而不是停留在文档中。

五、一个可复用的需求转化示例

下面给出一条从工艺描述到测试用例的完整转化示例，便于在实际项目中套用。工艺原文为：“自动模式下，物料到位后气缸推出，保持2秒后自动返回，返回到位后允许下一次循环。”转化过程如下：

需求编号：REQ-002
需求描述：自动模式下，B3上升沿且无急停/报警时，Q2.1置1；
          T45计时2.0s后Q2.1复位；B4上升沿后允许下一循环。
前置条件：模式选择=自动，急停=0，无报警，B4=0
测试用例：
  TC-02-01 正常：B3置1 → Q2.1=1，2.0s后Q2.1=0，B4置1后循环允许
  TC-02-02 边界：T45设定1.9s/2.1s，观察Q2.1复位时刻偏差
  TC-02-03 异常：计时中急停=1 → Q2.1立即复位，T45复位
判定依据：PLC变量表监视Q2.1、T45.ET、B4；时间偏差≤±50ms
风险等级：高（影响节拍与安全）

该示例中的地址、定时器和时间值均为教学假设，实际使用时需替换为项目真实变量。可以看到，一条可测需求最终会自然派生出正常、边界、异常三类用例，并直接进入追溯矩阵。测试人员拿到这份记录，无需再猜测“2秒”是从哪个信号开始算、急停时输出是否立即断开。

建议在项目早期就建立需求编号规则，例如按功能区域编号（REQ-CONV-001、REQ-CYL-002），使需求、用例、程序块和HMI画面能够通过编号快速关联。编号一旦确定，不要在后期随意更改，否则追溯矩阵会失效。

常见误区是把“程序已下载并运行正常”当作验收通过。运行正常只说明当前工况下逻辑成立，不代表边界条件、异常恢复和联锁关系已被验证。验收准则必须独立于程序实现，以工艺结果和可观测变量为准。

总结来看，需求分析的核心动作是“翻译”与“量化”：把工艺语言翻译成带触发、前置、输出和判定的可测需求，把验收标准量化为可观测的阈值与容差。测试用例从工艺、电气、程序和风险四个渠道收集，追溯矩阵保证覆盖完整，风险分析决定测试深度。四者形成闭环后，自动化测试才有明确的执行边界和判定依据，验收阶段也才能减少争议、提高效率。