20、用于测试并发实时系统的真实世界基准模型

用于测试并发实时系统的真实世界基准模型

1. 系统测试的一级分解

在并发实时系统测试中，涉及到多种类型的功能，如IgnSwitchBusRouting（点火开关总线路由）、NormalAndEmerFlashing（正常和紧急闪烁）、OpenCloseFlashing（开关闪烁）、CrashFlashing（碰撞闪烁）、TheftFlashing（防盗闪烁）、PriorityHandling（优先级处理）、OnOffDuration（开关持续时间）、MessageHandling（消息处理）、AffectedLamps（受影响的灯具）和LampControl（灯具控制）等。这些构成了系统测试的一级分解内容。

离散和延迟转换在并发实时形式化中很常见。离散转换可能因超时条件而超过下一个启用的时间点，在延迟转换结束时，可在每个接口上放置新的输入到被测系统（SUT）。这种区分也适用于交错语义，如在定时自动机中。

2. 基准参考工具

2.1 工具组件和基本概念

使用基于模型的测试工具RT - Tester创建基准参考数据。它包含以下组件和流程：
1. 解析器前端 ：将文本模型表示（CASE工具提供的XMI导出）转换为抽象模型语法的内部表示。
2. 约束生成器 ：从抽象语法树导出所有模型覆盖目标，并可输入用户定义的符号测试用例。用户可选择在同一测试过程中要执行的符号测试用例。
3. 转换关系生成器 ：遍历模型的抽象语法树，生成根据公式（1）表达计算目标所需的模型转换关系Φ。
4. 抽象解释器 ：在测试数据和测试过程生成过程中，接收与符号测试用例相关的约束，对在预定义的n步内从当前模型状态可达的模型状态进行抽象保守近似。
5. SMT求解器 ：以析取形式接收抽象解释器认为在n步内可覆盖的目标，逐步展开转换关系并尝试解决至少一个目标。若成功，从SMT求解器提供的解决方案中提取到SUT的定时输入向量序列。
6. 具体解释器 ：从当前模型状态开始，执行该序列，直到达到新的稳定状态，此时可生成更多输入以覆盖剩余目标。若求解器在n步内无法解决任何目标，可进行随机模拟和/或回溯到已访问的模型状态。

约束生成器、解释器和求解器构成了工具的核心，即测试生成引擎。其组件仅依赖于模型的抽象语法表示及其转换关系，而不依赖于具体的建模语法和测试执行环境所需的测试过程语法。最终生成多线程测试过程，根据求解器生成的输入序列刺激SUT，并同时检查SUT的反应与模型的一致性。

2.2 SMT求解器

类型（1）的约束求解问题可能包含线性和非线性算术表达式、位操作、数组引用、比较谓词和常用的布尔连接词。数据类型包括布尔值、有符号和无符号整数、IEEE - 754浮点数和数组。

SMT求解器SONOLAR使用经典的位爆破方法，将公式转换为命题可满足性问题，让SAT求解器尝试寻找解决方案。具体步骤如下：
1. 公式表示 ：将公式表示为无环表达式图，其中公式的每个变量和操作都表示为一个节点。
2. 结构哈希 ：使用结构哈希共享表达式中的相同项，以便进行字级简化、规范化和替换。
3. 位爆破 ：将表达式图位爆破为与非门图（AIG）。AIG中的每个节点要么是命题变量，要么是有两个输入边（可选择取反）的与节点。
4. AIG处理 ：对AIG进行结构哈希，以进行位级简化。
5. 转换为CNF ：使用标准的Tseitin编码将AIG转换为合取范式（CNF），并提交给SAT求解器。

为处理数组的外延理论，采用一种方法：不预先将所有数组表达式位爆破为SAT，而是将与数组读取或数组相等检查相关的返回位向量的数组表达式替换为新变量。若SAT求解器能找到解决方案，则检查模型是否存在数组不一致性，必要时按需添加额外约束，重复此过程直到SAT求解器认为精炼后的公式不可满足或不再有数组不一致性。在展开转换关系时，约束会逐步添加到SMT求解器中。

2.3 抽象解释器

抽象解释器用于快速计算可能的模型计算的过近似。其主要应用是确定公式（1）中参数c的下界，即转换关系Φ必须展开的次数，以有机会解决tc(c, G)。这可显著减少生成时间，原因如下：
1. SMT求解器可跳过对tc(c, G)的求解尝试，因为某些c值会使tc(c, G)无解。
2. 抽象解释技术为从已访问的前一个模型状态尝试解决tc(c, G)的情况提供了非时间顺序回溯的方法。

抽象解释器在抽象域上操作，使用抽象状态空间ΣA而不是具体状态空间来解释模型行为。ΣA通过将具体状态空间Σ中的每个具体数据类型D替换为适当的抽象对应物L(D)获得。定义在具体数据类型D0, …, Dn上的函数被提升到相关的抽象域L(D0), …, L(Dn)。具体和抽象状态通过伽罗瓦连接相互关联。每个抽象域L(D)都配备了一个连接运算符⊔，用于在两个抽象状态上进行操作，这有助于减少解释大型模型时通常出现的复杂性。

抽象解释器分别使用区间、布尔和幂集格作为数值数据类型、布尔值和状态机位置的抽象域。对给定模型的解释由初始抽象状态σ0A∈ΣA、表示要解释的最大转换步数的整数cmax和要检查可满足性的测试用例目标G参数化。从给定的初始状态开始，解释器计算最多cmax个抽象状态的序列⟨σ1A, σ2A, …⟩，其中每个状态σi + 1A保证“包含”从σiA表示的任何具体状态可达的每个具体状态σi + 1。解释在达到最大步数或测试用例目标G评估为真或⊤时停止，在后一种情况下返回实际步数。

3. MBT基准分类

3.1 测试强度基准

测试强度基准用于研究MBT工具生成的具体测试用例和测试数据的错误检测能力。即使两个MBT工具产生具有等效模型覆盖的测试套件，由于符号测试用例的不同选择、等价类的代表、边界值和传递给SUT的输入向量的时间安排，或从模型生成的测试预言的不同精度，它们通常具有不同的强度。采用变异测试来评估测试套件的强度，即生成模型突变体，并将从无偏模型生成的测试套件作为模型在环测试对这些突变体运行，评估标准是固定一组突变模型的未覆盖突变的百分比。

3.2 测试生成基准

测试生成基准输入第3节中介绍的符号测试用例，并测量生成具体测试数据所需的时间。建议为给定模型提供这些测试目标的标准程序，将符号测试用例分为以下几组：
1. 控制状态覆盖 ：SUT模型的每个控制状态至少被一个测试访问。
2. 状态机转换覆盖 ：每个状态机的每个转换至少被执行一次。
3. MC/DC覆盖 ：对类型为φ1 ∧ φ2的条件，至少对每个赋值(φ1, φ2) = (false, true), (true, false), (true, true)进行一次测试；对类型为φ1 ∨ φ2的条件，至少对(φ1, φ2) = (false, false), (true, false), (false, true)进行测试。
4. 基本控制状态对和输入等价类组合 ：由于考虑所有状态向量组合的覆盖对于大型模型来说不可行，因此建议最大化交互组件C1, C2的所有基本控制状态对的覆盖，并结合影响C1, C2的信号的输入等价类对。
5. 特定应用测试用例 ：定义特定感兴趣的应用特定测试用例。

对于特定模型，这会产生5个测试套件以实现全面的测试生成基准。

3.3 测试生成基准的评估标准

除了生成具体测试数据所需的时间外，还应尽量减少生成的测试过程中涉及的SUT重置次数。因为在测试嵌入式系统时，SUT重置通常会消耗大量时间，避免重置的硬件在环测试可显著减少测试套件的执行时间。此外，覆盖多个测试用例的测试执行比在两个或少量测试用例之间重置SUT的测试执行能使SUT进入更多内部状态，从而通常会提高测试过程的错误检测能力。然而，避免重置与减少生成时间相矛盾：如果从给定模型状态σ0到达某个目标Fφ非常耗时，回溯到前一个模型状态（从该状态更容易达到满足Fφ的计算片段）通常有助于显著减少生成时间。由于SUT通常无法回滚到先前状态，回溯会强制进行SUT重置，之后可以执行新的计算。为比较工具的性能，建议计算每个竞争工具的（生成时间，重置次数）对的帕累托前沿，并比较工具相关的前沿。

3.4 测试生成基准的重要性

根据适用于安全关键系统验证的标准，测试套件的错误检测强度只是证明测试用例充分性时要解决的一个方面。此外，标准要求在需求、设计和代码层面考虑足够的覆盖。因此，测试自动化工具生成足够测试用例以实现这种覆盖的能力对验证和认证工作有重大影响。

4. 测试生成示例

基准网站包含两类符号测试用例：
1. 用户定义的测试用例 ：反映测试工程师确定的特定测试目的，用于测试无法在模型中追溯到简单基本控制状态或转换集的更复杂要求，或探索怀疑发生故障的特定情况下SUT的反应。
2. 模型定义的测试用例 ：根据预定义策略（如基本控制状态覆盖、状态机转换覆盖和MC/DC覆盖）覆盖模型的某些部分，由工具从模型的抽象语法表示自动派生。

下面以基于用户定义的测试用例[Test UD 003]的测试生成为例，其测试目的是研究防盗警报和开关闪烁之间的交互。防盗警报闪烁仅在车门锁定时启用，警报传感器激活时，转向指示灯应在两侧开始闪烁，按下遥控器解锁车门会自动关闭警报闪烁。

不明确确定适合覆盖上述测试目的的定时输入向量序列，而是指定更简单和更短的符号测试用例，这些用例也可引用内部模型状态，让工具的生成引擎计算具体的测试输入数据及其时间安排。以下是具体的符号测试用例：

TC-turn_indication-THEFT_ALARM-0001;
[ SystemUnderTest.TheftFlashing.TheftFlashing.THEFT_ALARM_ACTIVE.ALARM_OFF
&& ! in_TheftAlarm ]
Until
[ _timeTick >= 2000 && in_TheftAlarm ]

该测试用例涉及SUT输入（防盗警报传感器in_TheftAlarm）、模型执行时间(_timeTick)和SUT模型中状态机的基本控制状态（SystemUnderTest.TheftFlashing…ALARM_OFF）。LTL公式指示测试生成引擎找到一个计算，最终达到防盗警报闪烁已启用但尚未激活的模型状态（即达到基本控制状态…ALARM_OFF时），并且防盗警报传感器应在测试开始后2000ms内保持被动。生成引擎为覆盖此测试用例而导出的输入将SUT带入一个发出警报的状态，SUT必须通过激活防盗警报闪烁来做出反应。

TC-turn_indication-THEFT_ALARM-0002;
[ SystemUnderTest.TheftFlashing.TheftFlashing.THEFT_ALARM_ACTIVE.ALARM_ON
&& in_TheftAlarm ]
Until
[ _timeTick >= 4000 && IMR.in_TheftAlarm &&
SystemUnderTest.oc_CentralLockingStatus == 1 ]

此公式指示在防盗警报状态下至少再保持2秒，之后达到内部模型变量oc_CentralLockingStatus值为1（表示“解锁”）的模型状态，即通过遥控器发出“解锁车门”命令。相关的输入和时间安排由测试生成引擎计算。

TC-turn_indication-THEFT_ALARM-0003;
[ SystemUnderTest.TheftFlashing.TheftFlashing.THEFT_ALARM_OFF ]
Until
[ _timeTick >= 6000 &&
SystemUnderTest.TheftFlashing.TheftFlashing.THEFT_ALARM_OFF ]

该公式指示在“防盗警报禁用”状态…THEFT_ALARM_OFF下至少再保持两秒，以便观察到在一个闪烁周期信号“车门已解锁”后，不再有进一步的警报指示。

生成器创建的输入向量序列首先通过远程控制输入in_CentralLockingRM（2 = 锁定，1 = 解锁）关闭车门，这触发左右指示灯的三个闪烁周期（pwmRatio_FR, pwmRatio_FL）。对于开关闪烁，闪烁周期的开启持续时间为340ms，这记录在内部模型变量ood_OnDuration中，其内容将由SUT通过CAN总线传输，因此可以由运行在测试引擎上并作为测试预言的线程观察和检查。两秒后，通过设置in_TheftAlarm = 1发出警报，这将闪烁周期的开启持续时间更改为220ms。防盗警报闪烁在模型执行时间戳4000时关闭，大约在发出“解锁车门”信号（in_CentralLockingRM = 1）后500ms；内部oc_CentralLockingStatus从0变为1表示“车门已解锁”状态已实现。一个闪烁周期信号“车门已解锁”（再次开启持续时间为340ms），之后不再有进一步的警报指示。

5. 结论

介绍了一个汽车控制应用的模型，涵盖了与转向指示、紧急闪烁、碰撞、防盗和开关闪烁相关的全部功能。该模型是当前使用的模型的1 - 1转录。通过上述的测试方法和工具，可以更有效地对并发实时系统进行测试，提高系统的可靠性和安全性。

6. 总结与展望

6.1 核心要点回顾

在这一系列的研究中，我们围绕并发实时系统的测试展开了深入探讨。首先，明确了系统测试的一级分解，涵盖了 IgnSwitchBusRouting、NormalAndEmerFlashing 等多种功能类型，并且阐述了离散和延迟转换在并发实时形式化中的应用。

接着，详细介绍了基准参考工具 RT - Tester，其核心的测试生成引擎由约束生成器、解释器和求解器组成。SMT 求解器 SONOLAR 通过位爆破等方法解决复杂的约束求解问题，抽象解释器则能快速计算模型计算的过近似，有效减少生成时间。

在 MBT 基准分类方面，分为测试强度基准和测试生成基准。测试强度基准通过变异测试评估测试套件的错误检测能力，测试生成基准将符号测试用例分为五组以实现全面测试，并提出了评估标准和重要性。

最后，通过基于用户定义测试用例的测试生成示例，展示了如何利用工具生成具体的测试输入数据和时间安排，验证了系统在不同场景下的功能。

6.2 未来研究方向

尽管目前的研究已经取得了一定的成果，但仍有一些方面值得进一步探索：
1. 模型扩展与优化 ：随着汽车控制应用的不断发展，模型需要不断扩展以涵盖更多的功能和场景。例如，考虑加入自动驾驶相关的功能，如自适应巡航控制、车道保持辅助等。同时，对模型进行优化，提高其计算效率和准确性。
2. 测试用例生成策略改进 ：目前的符号测试用例生成策略虽然已经较为全面，但仍有提升空间。可以研究更加智能的生成策略，根据系统的实时状态和历史数据动态生成测试用例，提高测试的覆盖率和有效性。
3. 多系统协同测试 ：在实际应用中，汽车系统往往与其他系统（如智能交通系统、移动设备等）进行协同工作。未来的研究可以考虑如何进行多系统的协同测试，确保系统之间的兼容性和互操作性。
4. 硬件与软件协同优化 ：目前的研究主要集中在软件层面的测试，未来可以加强硬件与软件的协同优化。例如，通过优化硬件设计，提高系统的实时性能，同时结合软件测试，确保系统的整体可靠性。

6.3 实际应用建议

对于从事并发实时系统测试的工程师和研究人员，可以参考以下实际应用建议：
1. 合理选择工具和方法 ：根据系统的特点和需求，选择合适的测试工具和方法。例如，对于复杂的约束求解问题，可以使用 SMT 求解器；对于快速计算模型过近似，可以使用抽象解释器。
2. 注重测试用例的设计 ：设计全面、有效的测试用例是保证测试质量的关键。可以结合多种覆盖策略，如控制状态覆盖、状态机转换覆盖和 MC/DC 覆盖，确保测试用例能够覆盖系统的各个方面。
3. 加强团队协作 ：并发实时系统测试涉及多个领域的知识，需要硬件工程师、软件工程师和测试工程师等多方面的人员协作。加强团队协作，提高沟通效率，能够更好地完成测试任务。
4. 持续学习和创新 ：并发实时系统技术不断发展，测试方法和工具也在不断更新。持续学习和关注行业动态，积极尝试新的方法和技术，能够提高测试的效率和质量。

7. 相关技术对比

7.1 不同求解器对比

在解决约束求解问题时，除了 SONOLAR 求解器，还有其他一些常见的求解器，如 Z3、CVC4 等。以下是它们的对比：
| 求解器 | 特点 | 适用场景 |
| ---- | ---- | ---- |
| SONOLAR | 使用经典的位爆破方法，能精确捕捉操作的实际语义，考虑整数运算的溢出和浮点数运算的正确舍入 | 适用于对运算语义要求较高，涉及线性和非线性算术表达式、位操作等复杂问题的场景 |
| Z3 | 支持多种逻辑和理论，具有强大的推理能力和高效的求解性能 | 适用于各种类型的约束求解问题，尤其是在软件验证、程序分析等领域应用广泛 |
| CVC4 | 具有良好的扩展性和灵活性，支持多种输入格式和求解策略 | 适用于需要处理复杂约束和进行定制化求解的场景 |

7.2 不同抽象解释方法对比

抽象解释是一种重要的技术，不同的抽象解释方法在性能和精度上有所差异。以下是几种常见的抽象解释方法对比：
| 抽象解释方法 | 特点 | 优势 | 劣势 |
| ---- | ---- | ---- | ---- |
| 区间抽象解释 | 使用区间作为抽象域，对数值数据进行抽象 | 简单易懂，计算效率高 | 精度相对较低，可能会产生较大的过近似 |
| 布尔抽象解释 | 对布尔值进行抽象，适用于处理布尔逻辑相关的问题 | 能够准确处理布尔逻辑，计算速度快 | 只能处理布尔类型的数据，适用范围有限 |
| 幂集格抽象解释 | 以幂集作为抽象域，对状态机位置等进行抽象 | 能够处理复杂的状态机模型，精度较高 | 计算复杂度较高，对于大规模模型可能效率较低 |

8. 流程总结

为了更清晰地展示整个测试过程，以下是一个 mermaid 格式的流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(系统测试一级分解):::process
    B --> C(基准参考工具 RT - Tester):::process
    C --> D(SMT 求解器 SONOLAR):::process
    C --> E(抽象解释器):::process
    C --> F(测试生成引擎):::process
    F --> G(MBT 基准分类):::process
    G --> H(测试强度基准):::process
    G --> I(测试生成基准):::process
    I --> J(生成测试用例):::process
    J --> K(测试用例分组):::process
    K --> L(控制状态覆盖):::process
    K --> M(状态机转换覆盖):::process
    K --> N(MC/DC 覆盖):::process
    K --> O(基本控制状态对和输入等价类组合):::process
    K --> P(特定应用测试用例):::process
    J --> Q(生成具体测试数据):::process
    Q --> R(执行测试):::process
    R --> S{测试是否通过?}:::decision
    S -->|是| T([结束]):::startend
    S -->|否| U(分析问题并改进):::process
    U --> J

这个流程图展示了从系统测试的一级分解开始，经过基准参考工具的使用、MBT 基准分类、测试用例生成和执行，最终根据测试结果进行反馈和改进的整个过程。通过这个流程，可以更加系统地对并发实时系统进行测试，提高测试的效率和质量。

综上所述，并发实时系统的测试是一个复杂而重要的领域。通过不断地研究和实践，我们可以不断完善测试方法和工具，提高系统的可靠性和安全性，为汽车控制等领域的发展提供有力支持。