29、IoT系统测试与集成环境全解析

IoT系统测试与集成环境全解析

1. 开发团队测试与集成支持

在软件开发过程中，最基础的测试级别是基于结构的验证测试，通常在软件模拟器或硬件系统（如仿真器）上进行。无论是采用敏捷开发还是传统开发方式，开发测试的目的都是确保代码实现了设计信息和软件标准。这种测试一般在模块/对象级别进行，小代码段会与系统的其他部分隔离执行。若不使用自动化工具，在低验证级别进行结果比较和审查会非常耗费人力。

在开发测试环境中，被测软件（SUT）由驱动程序或调用SUT的软件驱动。如果SUT调用其他软件，可能需要存根或模拟对象代码元素。测试用例和程序驱动SUT产生测试结果，需要确定测试结果的正确性，这可以通过驱动程序或审查存储的数据结果来完成。最后，SUT需要在硬件、仿真器或模拟器（模拟硬件的软件）上执行。许多开发测试环境是商业化的，因此存在多种配置，各有优缺点。

随着SUT在其生命周期中的推进，软件集成会随之发生。软件集成方式包括自底向上、自顶向下、对象/类或混合方式。大多数开发运维和敏捷团队期望实现持续集成（CI），包括频繁（持续）构建、夜间完整构建和持续进行的测试（CD），这有助于将软件系统构建到系统级别，包括集成现成（OTS）元素。当软件准备好进行持续交付（CD）时，在开发测试环境中使用工具支持是很好的做法。支持工具包括编译器、项目生命周期管理、带有构建调度器的软件配置管理（SCM）、报告、静态代码分析（SCA）以及驱动/存根代码执行支持和分析等。

以下是开发测试环境的关键要点总结：
| 要点 | 详情 |
| — | — |
| 测试级别 | 基于结构的验证测试，模块/对象级别 |
| 驱动方式 | 驱动程序或调用软件 |
| 集成方式 | 自底向上、自顶向下、对象/类或混合 |
| 支持工具 | 编译器、SCM、SCA等 |

2. 硬件团队测试与集成

虽然本文重点关注物联网软件测试，但由于物联网设备的很多功能依赖于硬件，所以也简要介绍一下硬件集成。大多数硬件集成是自底向上的。硬件团队在实际构建“老化”电路板之前，需要对设计进行多次测试。首先设计电路板，然后多次重新设计，接着构建带有重要部件（如执行器或传感器）的原型电路板。当认为电路板可以正常工作时，会进行“冒烟测试”，运行原型汇编代码以确保电路板按预期工作。之后构建“最终”传感器和执行器，将电路板连接到传感器并通电（另一次冒烟测试），再连接执行器进行冒烟测试。此时，可能会联系软件开发团队，让系统软件测试人员将电路板 - 传感器 - 执行器连接到当前生产软件，查看会发生什么。

硬件 - 软件集成实验室需要以下关键物品：
- 示波器
- 信号发生器
- 硬件刺激器
- 硬件模拟器
- 线绕原型I/O板
- 检查设备（如相机、探头等）
- 用于记录电气、热量、湿度、时间的记录仪
- 软件配置和功能支持
- 系统的计划、进度和成本
- 团队的能力和技能

下面是硬件集成流程的mermaid流程图：

graph LR
    A[设计电路板] --> B[多次重新设计]
    B --> C[构建原型电路板]
    C --> D[冒烟测试]
    D --> E[构建最终传感器和执行器]
    E --> F[连接传感器并通电测试]
    F --> G[连接执行器并测试]
    G --> H[联系软件开发团队]

3. 硬件测试与集成的位置

硬件测试和集成应该在项目生命周期的各个阶段进行，无论是在供应商处、有一系列硬件供应商的中国，还是当硬件到达物联网测试团队时。物联网测试的最终责任由最终项目的硬件和软件测试人员承担。

4. 全硬件 - 软件 - 系统集成

建议逐步构建测试环境，公司和团队应尽早规划、迭代集成并全程进行测试。全硬件 - 软件系统集成和测试环境有多种配置，下面从简单到复杂介绍STA环境。

4.1 简单集成STA SIL

这种环境下，系统的各个部分构成设备的配置。软件管理设备的数据，通过通信线路与其他系统通信，控制执行器、读取传感器数据并与互联网通信。物联网SIL环境针对设备的实际使用情况进行测试，可能只是放在桌子上或测试夹具上，配置并不复杂。在这个例子中，测试人员会扮演“正常用户”和“黑客”的角色，在刺激和监控软件、硬件及其他系统输入输出的同时进行测试，这种测试可能是手动的，很少使用工具。这种简单的例子适用于智能家居的物联网立体声扬声器控制器、玩具和简单的独立物联网系统。

4.2 更高级的具有快速集成重新配置功能的物联网STA SIL

随着系统复杂性的增加，集成挑战成为一个重要的任务领域，需要专门的环境和支持。项目在集成现成（OTS）项目以及开发的硬件和软件时会遇到集成问题，且随着元素和接口数量的增加，问题会呈指数级增长。

图19 - 6所示的SIL环境在简单模型的基础上进行了扩展，以支持更复杂的物联网设备测试。该SIL配置使用机架来放置不同的硬件部件，拥有一个带有零插入力（ZIF）连接器的“硬件补丁面板”，允许不同版本的硬件放入机架，并且可以快速重新配置而不会损坏电线（ZIF连接器用于防止电线损坏）。ZIF补丁面板可以连接不同的物联网设备版本配置（如不同的手机版本），还可以支持不同的测试支持设备，如示波器、计时设备、模型、通信线路等。可能会有多个被测物联网SUT设备配置，这些不同的配置可以在集成测试配置中“切换”进出。由于配置的多样性，SIL能够快速更改配置，这对于快速测试是一个优势。

当然，这只是一个临时的测试SUT集成配置。在完成一些集成和测试，并且集成项目的配置稳定后，可以进行最终的实际软件和硬件集成。必须注意ZIF的硬件和软件接口是否正确。

工具（如ZIF、设备机架、示波器、信号发生器、分析仪等）对集成工作有很大的优势。虽然不是每个软件工程师或测试人员都能操作特殊的测试工具，但如果测试环境中有能够使用这些工具的合适人员，就可以节省大量的集成和测试时间。运行一个集成实验室需要一个团队，如果物联网设备很复杂，为团队提供尽可能多的支持和工具是一个很好的计划。即使需要租赁或借用集成设备和支持人员，也可能比让没有合适设备或知识的人员去追查问题更节省时间和金钱。

物联网规划最好让测试团队参与集成工作。项目中的开源软件（OSS）、OTS、软件、操作系统服务、硬件接口等越多，就越需要进行集成规划和维护。此外，配置中包含的集成元素的原型和评估副本越多，就越需要进行测试规划。我所在的集成测试团队在一个大型项目中每周开会，并且根据需要随时开会，这个例子表明通过谨慎选择选项可以快速重新规划集成。

可以在“现场”或现实世界环境中对部件进行测试，但这不如通过早期构建和原型进行持续集成（CI），进而实现持续测试（CT）和交付（CD）有利。CI会不断规划、集成、测试并重复硬件和软件配置。CI/CT/CD团队需要保持参与并灵活应变。CD的交付对象可能是测试人员、内部利益相关者（如开发团队、外部代表），甚至是“客户”，向客户交付时需要谨慎并确保客户理解相关情况。

以下是不同SIL环境的对比：
| SIL环境 | 特点 | 适用场景 |
| — | — | — |
| 简单集成STA SIL | 配置简单，手动测试为主 | 智能家居控制器、玩具等简单系统 |
| 高级物联网STA SIL | 可快速重新配置，支持多设备和测试工具 | 复杂物联网设备 |

5. 测试环境支持：模拟、建模和仿真

在测试过程中，由于调度、成本、复杂性、物流、安全等现实问题的限制，可能会出现可用性受限的情况。当一个或多个所需元素不可用，或者需要“特殊”刺激来驱动测试时，就会给集成和测试带来挑战。即使测试人员在测试环境中做得很好，由于测试环境的限制，导致软件出现故障的错误仍然可能发生。这些限制可能由多种原因造成，例如：
- IoT硬件和软件配置与测试时不同。
- 用户（包括黑客）的行为超出了软件测试计划、风险和测试模型的覆盖范围。
- IoT设备与外部源相关的输入/输出范围与测试时不同。
- 软件或系统所处的状态和条件与预期不同。
- 测试环境的可用性限制。
- 来自OTS软件的安全威胁指示，如电池寿命下降、高功率使用、意外的网络连接/断开等。

为了解决这些问题，模拟、建模和仿真技术可以在测试系统中发挥重要作用。虽然与真实环境相比，模拟和建模并不完美，但它们可以让工程师在测试进入现实世界之前解决一些问题。

5.1 模拟测试示例

图19 - 7展示了一个“测试实验室模拟”的示例，其中模拟了风作为测试人员控制的输入，输入到IoT设备中。通过外部测试计算机，可以支持测试模拟，监测诸如时间等参数，并期望输出信号（例如来自安全威胁的信号）。还可以生成测试模拟输入来选择设备上的“按钮”，并添加“记录硬件”设备来记录电力和其他生成的系统输出。外部测试计算机系统使用测试实验室模拟、测试用例和记录硬件来驱动所有这些测试。虽然这样可以为感兴趣的IoT设备生成更多测试，但仍然不是真实世界的情况。

在测试中，测试人员希望控制测试环境以避免墨菲定律的影响。墨菲定律指出“任何可能出错的事情都会出错”，真实世界充满了未测试的意外压力情况，可能会使软件或硬件进入未知状态，导致用户输入异常，以及产生影响软件的时间效应。如果不控制测试环境，可能会导致系统故障甚至失败，并且这些问题可能会重复出现。一些程序员可能会将这些问题称为“特性”或用“垃圾进/垃圾出”（GIGO）来解释，但测试人员希望消除这些情况，或者至少能够解释为什么不应该忽略这些测试，因为黑客很喜欢利用这类借口。

模拟模型可以是简单的，也可以是复杂的。简单的模拟模型通常是将“预定”的输入流输入到测试系统中；而其他模拟模型则会在闭环测试系统中利用反馈信息来驱动计算输入值，根据IoT设备的输出确定新的输入值。

以下是模拟测试环境的关键要素总结：
| 要素 | 说明 |
| — | — |
| 模拟输入 | 如模拟风、按钮操作等 |
| 监测参数 | 时间、安全威胁信号等 |
| 记录设备 | 记录电力和系统输出 |
| 模拟模型 | 简单或复杂，基于反馈或预定输入 |

5.2 模拟模型示例

图19 - 8展示了另一个模拟模型，测试人员使用计算机“提供”输入，代替风力发电机。测试人员可以设置不同的参数和条件（如风速、方向、温度、波动等），并将这些参数输入到一系列风力发电机系统中，然后将数据存储到云中。这种方法可以对风力发电机系统进行广泛的评估。

在构建这样的SIL系统时，测试团队需要能够回答以下问题：
- 如何测试SIL和支持的模拟（即测试测试系统本身）？
- 模拟是否准确反映了传感器和执行器的情况？
- SIL架构需要多少控制和保真度？
- 测试人员可以从任何IoT元素获得多少供应商信息，以及是否应该信任这些信息？

基于模拟的工具可以提供成功标准或分析能力，使工程师能够在不完全依赖人工判断的情况下判断SUT的成功与否。许多模拟会将数据输出到SUT中，并记录预期输出，然后将这些输出与测试软件生成的结果进行比较。有些模拟基于单个方程或逻辑序列，而其他工具则模拟整个系统的各个方面。

5.3 原型仿真示例

图19 - 9展示了一个IoT机器人的原型仿真示例，使用线绕电路板。该原型旨在评估玩具的概念，具有碰撞传感器以停止向前移动、电机以驱动轮子向各个方向移动，以及运行原型软件的仿真板，电路只是缠绕在传感器和执行器电机上的“电线”。系统具有Wi - Fi互联网通信通道以发送和接收数据。目标是对玩具的概念进行基本测试，同时也能获得真实世界的经验。

有一个实验室的初始模拟规划是基于“最佳猜测”，即模拟的输入和输出基于工程理解和要求。但在开发过程中，测试人员需要在现场对系统的输入和输出进行实际测量，这些实际测量结果改善了后续IoT系统版本的模拟测试模型。

以下是模拟、建模和仿真技术在测试中的应用流程mermaid流程图：

graph LR
    A[确定测试需求] --> B[选择模拟模型类型]
    B --> C[设置模拟参数和条件]
    C --> D[进行模拟测试]
    D --> E[记录预期输出]
    E --> F[与实际测试结果比较]
    F --> G[分析差异并改进]
    G --> H[重复测试或应用于实际系统]

综上所述，在IoT系统的测试与集成过程中，无论是开发团队的软件测试、硬件团队的硬件集成，还是全硬件 - 软件 - 系统的集成，以及模拟、建模和仿真等测试环境支持技术，都起着至关重要的作用。通过合理规划和利用这些环境和技术，可以提高测试效率，减少故障发生的可能性，确保IoT系统的稳定性和可靠性。同时，随着IoT系统的不断发展和复杂化，持续关注和改进测试与集成方法将是保持竞争力的关键。