阅读： 8

91个物联网开源项目，5565个 Bug，9 次采访，194 位 IoT 开发人员验证，从这里面，我们能对物联网bug有什么了解？在本篇文章中，我们将跟随来自ICSE 2021的论文——”IoT Bugs and Development Challenges” 一探究竟。

一、背景和动机

物联网(IoT)是一个自配置、自适应和复杂的网络，通过通信协议将嵌有传感器或驱动器的智能对象与互联网相连。据高德纳公司估计，到2025年，全球将有超过754.4亿件智能设备。用户可以通过编程和远程控制来收集这些“智能家伙”的数据或控制它们的行为。

对资源受限的物理设备进行编程，处理不同的网络协议，以及在物联网系统中集成不同实体，这些都为开发此类系统增加了独特的挑战。基于上述原因，物联网中的bug比传统软件中的更加复杂。

在此之前，有一些研究者调查过物联网仓库的特性，并讨论了物联网系统的一些挑战。但是现有的bug分类研究多限于物联网中的特定子领域，如智能水产养殖系统bug、物联网设备操作系统bug、物联网系统部署过程中发现的bug等。还有一些研究并没有将物联网开发者实际情况纳入考量，另外一些研究成果并没有给出它们得出分类的构建过程。更成熟的软件领域已经从bug分类和开发者挑战的实证和定性研究中受益，但据调查发现，目前还没有针对物联网的此类研究。所以在 “IoT Bugs and Development Challenges”中，对物联网系统中的缺陷和开发人员面临的挑战进行了系统性的研究。

为了做到这一点，作者从物联网GitHub项目入手，收集了来自91个具有代表性的物联网项目中 5565 份错误报告。通过根本原因分析法(RCA，Root Cause Analysis)，根据观察到的bug、根本原因以及bug出现的位置，对323个错误报告进行了分类。由此提出了物联网系统中的首个bug分类，该分类是通过分析现实世界中的物联网缺陷构建的。同时为了补充分类和研究物联网开发者面临的挑战，还对9名在物联网不同层面具有实践经验的物联网从业者进行了半结构访谈。最后，通过由194名物联网开发者完成的在线调查验证了发现。

以下是对该篇论文的学习解读，为了方便，下文都将以第一人称的口吻进行叙述。

二、研究方法

本次工作将为以下两个问题得出结论：

• RQ1：物联网系统中的bug有哪些类别?
• RQ2：物联网开发者在实践中面临哪些挑战?

为了回答这些问题，我们进行了由两个阶段组成的实证调查。

在第一阶段(RQ1)，分析了来自开源物联网项目的323个issue和拉取请求(Pull Request)。利用这些发现整理形成了物联网系统中的首个bug分类方法。在第二阶段(RQ2)中，分两步进行，首先是对物联网开发者进行半结构化访谈，以发现新的漏洞和挑战类别，再次是对物联网开发者进行线上调查，以验证发现并获得新的见解，进行定性研究。

研究过程中的所有定量、定性数据都可以在下面这个仓库中查看：https://github.com/IoTSEstudy/IoTbugschallenges

2.1 物联网漏洞分类

2.1.1 收集bug报告

第一步是找到具有代表性的物联网项目仓库。这里使用“GitHub topic feature”来寻找物联网相关的存储库。根据GitHub官方对topic feature介绍:

( https://docs.github.com/en/github/administering-a-repository/classifying-your-repository-with-topics )，在https://github.com/topics/ 中可以通过主题查找仓库。

首先以“internet-of-things”、“IoT”等相关关键词对主题进行搜索，然后将搜索结果中排名前三的“IoT-application”、“IoT-platform”、“IoT-device”加入到目标主题列表中继续查找。

根据搜索收集到8774个使用这五个主题的仓库，排除了其中小于10颗星的仓库，最终留下了1356个项目。为了只研究有效的bug，寻找只有“closed”状态且带有“bug”、“ defect”或“error”标签的已发布的错误报告。此外，为了筛选出具有代表性的物联网仓库供研究，还根据其自述页面、发布的bug报告和网站等信息，手工分析了具有5个以上标记问题或50个以上已关闭问题的仓库。继续排除了不代表物联网系统的项目，如只有用户界面、文档或不再受支持。最终的项目列表包含了91个要分析的开源物联网仓库。

最终，从91个物联网仓库收集了5565份bug报告。

据统计这些仓库中最流行的编程语言是Python(21%)、Java(18%)、JavaScript(17%)、C(13%)和c++(13%)。其中一些使用其他编程语言，如Go、Ruby和c#。

选择的存储库在star和fork的数量上也是不同的。收集到的符合主题的存储库中有32%的star超过500，40%的star在50到500之间，28%的star在10到50之间。

2.1.2 打标签

对于数据集中的每个bug报告，都会为其创建了一个JSON对象，其中包含 bug 报告的一些基本信息，例如：标题、问题描述等。

bug指的是任何可观察到的、与系统正确功能相违背的系统意外行为。为了探bug的原因，这里使用“five whys”技术对每份错误报告进行了根本原因分析（RCA）。按照这种方法，我们会反复询问“为什么”，直到理清问题的脉络，追溯到问题的根本原因。

我们会检查开发人员之间的整个讨论，以及每个错误报告的修复提交数据(例如提交消息和代码差异)，然后按照开放式编码程序手工标记。标记的过程并不是只进行一遍，而是迭代进行的，我们会从所有错误报告中随机抽取新的实例，这样有可能会产生新的类别，持续这个过程，直到 bug 类别达到饱和再也没有新的类别出现为止。最终，我们完整标记了323份错误报告。

2.1.3 Bug 分类案例

接下来看一个对bug 分类的具体案例。下图左边描述了物联网系统的典型分层结构。这个层级结构在打标签的也有用到，对 bug 的标记中有 bug 所在位置这一项。先看左边的结构，显示的是不同的设备在网关设备的帮助下连接到智能家居管理平台上。

设备层：

底部的设备层包括通过嵌入式传感器和驱动器与物理世界交互的智能可编程设备。一些物联网设备采用小型嵌入式操作系统(如：contiki、RIOT、TinyOS)，支持各种编程语言，允许开发人员在设备OS上编写嵌入式代码，而裸金属物联网设备则直接在其硬件处理器上运行嵌入式代码。

边缘层：

这一层包含网关设备，能够处理遥测数据收集、处理和路由。网关设备可以通过各种通信协议(如MQTT、CoAP和HTTP)来处理设备&设备、设备&云端间的互操作。

Tips: 网关，顾名思义，就是可以连接上网的一个设备。智能家居设备，一般都需要连接到智能平台，依靠平台来实现自动化、APP远程控制、以及设备之间的相互联动。但是zigbee和蓝牙一样，它是一种局域网的通讯技术，并不能直接连到互联网，那么就需要一个网关，帮助它们连接上智能平台。zigbee网关既包含zigbee模块，又包含wifi模块。对下，它负责把zigbee设备添加进来。对上，它负责连接智能平台，间接的把zigbee设备接入智能平台。有些智能子设备本身就是有带wifi模块的，这些设备不需要经过网关，就可以直接连接到平台，但一般wifi设备的成本会比较高，售价比较贵。并且wifi模块比较耗电，像无线传感器这种装电池来供电的设备，不适合用wifi模块，一般都是zigbee的。https://zhuanlan.zhihu.com/p/343799100?ivk_sa=1024320u

云端：

远程物联网云服务器收集和处理所有遥测数据，并与物联网设备进行通信，实现远程控制和监控。物联网云服务器规则引擎允许用户编写物联网设备之间的自动化逻辑，以定义物联网系统的互操作行为。

下面使用一个真实的物联网漏洞案例来探究物联网系统中的漏洞及其成因还有开发者面临的挑战。这个 bug案例来源于 github 上的pytradfri 项目，这个项目提供了一个用来与IKEA Tradfri ZigBee 网关通信的 Python 包。也就是说通过使用这个包，可以使智能家居平台与宜家指定网关通信并控制宜家的灯和墙上的插座。其中一些功能包括：列出所有灯并获取灯光属性（名称、状态、色温、调光等级等）、更改灯光的属性值、控制墙壁插座等。

这里提到的智能家居平台，其实就是这个项目的拥有者 Home Assistant（家庭助理），家庭助理是一个能够跟踪和控制家庭中的所有设备，并提供自动化控制的平台。Home Assistant 有一个简单的、适合移动设备的界面来控制所有设备，且不会将任何数据存储在云端。这个项目下还有好多其他仓库，比如有：用于获取太阳能电池板预测信息的异步 Python 客户端、用于安卓 IP 网络摄像头的 Python api、用于与 Google Chromecast 通信的 Python 3 库等。

回到bug中，https://github.com/ggravlingen/pytradfri/issues/135 这个bug 是 2018年在该项目中提交的。

bug 提交者当时试图将他的宜家网关与家庭助理进行集成。他在家庭助理中运行了pytradfri，添加了一个灯泡设备(D3)后，他的灯被错误地识别为是传感器设备而不是灯泡(F1)，随后当试图关闭灯泡时Android应用程序崩溃了(F2)。最初，开发者怀疑该错误的根源是网关库与家庭助理不兼容。

然而，对边缘层故障的进一步研究发现，原来是网关误将D3识别为传感器(F3)了。因为网关主要依赖于设备响应数据的特定格式来识别设备的类型，因此还需要调查来自bug 提交者设备发出的有效负载数据 (步骤5)。

此外，由于设备电池和到网关的距离可能会影响配对过程，开发人员尝试在不同的情况下进行配对测试(步骤6)。

进行了如上排查后，根本原因被确定为G2网关设备固件中的bug，重新设置设备和网关并再次配对解决了这个问题。但令人不解的是F2仍然存在。通过Wireshark对app接收到的数据进行监控，发现F2的根本原因是Android app代码存在错误。

正如在这个例子中看到的，bug 和 bug 的原因需要在不同层级去深究，也可以看出物联网项目中的bug在追查时比传统软件中的复杂度更高。

2.2 访谈

虽然对错误报告的手工分析以及阅读开发人员的讨论已经能形成一些物联网bug分类结构，但仅限于代码级的分析或许可能会错过物联网开发人员遇到一些高级问题。为了填补这一空缺，我们还对物联网开发者进行了半结构化访谈，以获得新的bug类别，并收集他们开发过程中遇到的实际挑战，以补充最终的结果。

参与者：

要招募在物联网系统开发方面有足够经验的开发人员，还是借助了GitHub，因为它提供了一个多样化的开发人员池，还能够获知他们对不同项目的贡献。我们查找到热门开源物联网库前三名贡献者的有效电子邮件地址，作为调查候选人。我们通过邮件联系候选人并进行面谈，直到达到数据饱和（数据饱和是在定性分析时需要的一个概念），也就是选择面谈的人数并不是越大越好，只要能够有足够的数据来重复研究，进一步的数据收集是不必要的。我们依靠这个广泛应用的方法论原则来决定何时停止采访，因为它也被用于软件工程的其他定性研究中。我们采访了具有不同发展背景和经验的人，以考虑在不同人群中实验结果的可变性。

下表列出了所有9位访谈参与者在物联网发展方面的经验和专业领域。对于他们的总体发展背景，最少是3年，最高是20年(avg=13, sdv=6.4)。从从事物联网的经验来看，最少为3年，最高为17年(avg=6.4, sdv=4.6)。他们的物联网开发经验涵盖了从硬件到中间件、云计算和终端应用等物联网系统的所有领域。此外，他们的项目涵盖了智能家居和工业物联网(IIoT)等多个领域。

访谈：

由于进行访谈的目标是获取到一些新的见解，并且我们还没有bug类别的明确结构，所以我们按照半结构化的方法进行访谈。访谈开始时先询问了一些关于参与者的物联网发展背景和他们在物联网领域的专业知识。这些信息可以帮助我们在面谈的技术部分即兴提出有见地的问题。我们的策略是，从开放式问题开始，以避免参与者对我们的发现产生偏见或固有印象，然后在访谈过程中逐步转向更有组织和预先设定的问题。

在参与者同意的情况下，我们记录了所有访谈的音频和视频，以供后续分析。所有的采访都是通过Zoom远程进行的。访谈时间平均为31 ~ 70分钟，约为43分钟。我们使用了一种自动语音检测工具Descript来生成访谈的转录，然后我们对自动生成的转录进行手动更正，以防出现任何错误。

分析：

访谈的主要目的是从物联网从业人员的经验中生成理论，具体的分析步骤包括：

1、 从访谈中收集数据；

2、 逐行分析访谈笔录；

3、 识别新类别，并将类别与其子类别联系起来，同时不断将之前分析的所有数据与新类别进行比较。

对每次访谈都重复这些步骤。平均而言，从每次采访中能抽取18个标签，标签中的冲突在每次迭代后由受访者解决。

2.3 验证调查

为了确保上述过程得到的结果具有通用性、全面性和代表性，我们通过在线调查让更多物联网开发者参与进来。

调查人员来源：

我们将在线调查发送给为所收集的物联网项目至少做出三项贡献的开发者，以及社交媒体平台(如Linkedin和Facebook)和在线论坛中的物联网开发者小组。调查在2020年7月19日至8月19日期间进行。下图统计了调查参与者的背景。

调查过程：

调查分为三个部分。在第一部分中，我们收集了参与者在物联网发展方面的背景。

第二部分讨论了开发物联网系统时遇到的挑战，旨在将我们的发现与参与者的自身经验联系起来。

第三部分是基于参与者以往在物联网开发中的经验，给出关于bug类别出现的频率和严重性。

分析：

最终有194名受访者完成了调查，有效回应的回复率约为10%。

三、研究结果:物联网bug分类

3.1 bug的分类

我们使用数据集中RCA收集的所有标签，建立了物联网系统的错误分类法。

如图所示，物联网的bug可能是多方面的，并在不同的层次和位置表现出来。因此，我们首先定义了分类的面，然后，根据这些面来分析所有的错误报告，并建立了一个适应所有维度的分层分类法。

接下来，将逐个对分类法中的主要bug类别进行介绍。我们将使用特定的错误作为每个类别的例子。

所有这些错误示例都可以在数据集中找到：https://github.com/IoTSEstudy/IoTbugschallenges/blob/master/bug-categorization/323-analyzed-bugs.csv 。

3.1.1 IoT设备

这个分类涵盖了与物联网设备硬件和固件相关的bug。

设备硬件：

这个子类别中的bug与物联网设备的物理方面相关。包括布线问题、设备引脚状态问题或设备的物理传感器和执行器问题等。例如，PEDALINOMINI/34与不区分单按和双按硬件按钮有关。https://github.com/alf45tar/PedalinoMini/issues/34

这一类型的其他常见bug与设备在内存、功耗或cpu方面的限制有关。受访者P1提供了一个这样的例子，一个低电量的设备向云端上传了错误的数据。在收集的bug报告中，有很多类似的情况是由于设备电量不足导致设备出现故障。此外还有一些例子，比如内存不足(ZWAVE2MQTT/141，受访者P7)。

另一个已知物联网设备硬件问题的例子是Raspberry Pi设备的时序问题，受访者也提到了这个问题(P8)。Raspberry Pi 中缺少硬件时钟，可能存在时间滞后问题。https://blog.pisignage.com/lack-of-hardware-clock-in-raspberry-pi-scheduling-issues/

设备固件：

固件bug有三个子类。第一个与设备固件意外异常和挂起问题有关。第二个子类别包括与物联网设备配置相关的问题，特指为特定目的发送给设备的外部指令。这种类型的错误通常发生在将物联网设备引入物联网网络的早期阶段。每个设备必须配置正确，与其他硬件或软件组件兼容，并能够与网络上的其他设备通信。第三个也是最常见的子类别是固件升级问题。在各种情况下，处理设备固件的OTA更新、过时的更新或使用错误的二进制文件更新设备固件的不良做法都可能导致物联网系统故障。比如在某些情况下，陈旧的更新问题与设备配置有关，如在WTHERMOSTATBECA/54（https://github.com/klausahrenberg/WThermostatBeca/issues/54 ），设备需要在每次固件更新后重新配置WiFi凭证，否则，未来的固件更新将不是最新的。

3.1.2 兼容性

当bug只发生在特定类型的设备、通信协议或第三方组件上时，它属于兼容性类别的bug。例如，当某些设备以不同的格式表示它们的遥测数据时，就会出现一个常见的设备不兼容问题，导致其他组件无法处理它们的数据。其他常见的bug与某些传感器和开发板组合的兼容性问题有关，例如，在MONGOOSE-OS/277中，DHT温度传感器与ESP32微控制器不兼容。

不同协议的互操作性问题是另一种情况。如MAINFLUX/1079，它与HTTP和MQTT协议之间的互操作性有关。

在物联网开发中一个常见的不良做法是开发特定于协议或特定于设备的代码。例如，在DEVICE-OS/1938中，物联网平台依赖于事件组件来报告每个事件针对的协议，以便能够针对每个协议分别运行不同的功能。有时开发人员确实别无选择，为了绕过第三方设备的限制只能遵循这种容易出错的方法。例如，P2提到了一个例子，树莓派和某些类型的传感器不兼容，迫使他们的开发人员为这些设备的通信实现自定义逻辑。开发人员不得不在树莓派的默认实现和他们自己的基于传感器类型的自定义实现之间切换，这导致了许多问题。

3.1.3 与IoT设备通信

这类错误有两种类型：

设备连接：一些连接问题与设备连接到互联网所依赖的网络有关。有一个例子是当设备不能发现一个有效和可用的网络，就会失去对互联网的访问能力。P9提到一个例子，“当设备位置改变到另一个房间或另一座建筑时，设备必须重新配置以适应新的接入点。”除了网络发现，未妥善处理网络重置，或不稳定和不可靠的网络是可能出现的其他常见问题。

然而，在网络状态正常时，物联网设备偶尔也可能出现无法与网关或远程云服务器建立有效连接的情况。此外，意外的断开或关闭连接问题也是这类bug的常见表现。两位受访者(P6和P9)认为连通性错误是最严重和最具挑战性的错误。正如P9所说，“我们物联网平台最薄弱的部分是与物联网设备的通信”。

数据和消息传递：通常消息要么是通过云发送到物联网设备的命令，要么是从物联网设备那里接收的遥测数据，有些错误会导致这些消息传递失败。其他一些消息传递错误与消息的时序有关。例如，各种错误报告中提到了消息的速率和顺序。另外一些错误和通过消息传递的有效负载有关，在某些情况下，有效负载的大小或格式是失败的原因。还有一些情况是由于消息被截断或覆盖而破坏了有效负载的完整性。

3.1.4 云/边界服务

设备管理：

远程监控和控制每个IoT设备，设备应连接到云服务器或集线器设备，并在侦听用户命令时报告其状态。设备管理(DM)问题包括在此过程中导致失败的问题。

第一类DM问题发生在物联网设备初始化阶段。设备初始化(DI)问题的一种类型是，当物联网设备没有被云或边缘组件正确或唯一地识别，将会导致物联网系统的进一步故障。此外，如果物联网设备无法提供可识别的身份和对云或边缘的有效访问权限，则将不允许使用远程服务。设备注册和配置错误的一些例子包括重复的设备证书、自动配置设备的问题或从配置服务检索数据失败。DI bug的另一类是物联网设备的绑定、关联和配对问题。一位受访者(P5)提到过一个例子，其中两个开关与一个灯相关联，但由于多实例设备的标签寻址问题，只有一个开关在工作。

第二类DM问题与监控物联网设备状态的问题有关。一种设备状态是连接状态，即检查设备是否在线，也称为心跳检查。这类漏洞的一些例子是传输了错误的设备心跳，导致显示设备连接丢失，或者设备实际已经离线，但却返回了正常的心跳包，导致当设备离线时没有通知其他组件。检索设备状态(如灯泡的颜色和亮度)失败、显示状态错误或更新设备状态失败都是这类问题的一些实际案例。

自动化

此漏洞类别与物联网云或边缘平台提供的自动化服务相关，并分为触发、条件和执行问题。规则触发器定义启动规则的条件。规则条件是在触发规则时应该检查的语句。规则条件问题的例子是检索设备状态以检查规则条件的问题，因为条件通常依赖于设备的最新状态(TESLA-API/43)。规则操作执行中的问题是最后也是最突出的自动化问题。这些问题的一些例子是规则操作执行后崩溃，在处理规则中的异步行为和线程时出现问题，以及规则输出不可预测或不确定性问题。

3.1.5 通用开发

这个类别是一些常见的开发错误。包括安装、编译或构建项目的问题，以及物联网项目中的意外崩溃或性能问题。此外还包括身份验证或授权过程中的错误。特定于物联网的授权问题之一是生成或维护设备使用云或边缘服务时必须提供的证书(AZURE-IOT-SDK-C/657)。其他子类包括UI相关、可用性或外部问题。

3.2 bug特性分析

在 bug 原因方面，一般的软件编程错误(SWP)，如语法问题，语义编程错误(SEM)这些是导致缺陷的最主要根源。物联网开发人员犯的一些语义错误包括未处理好控制流、功能逻辑或返回值。然而，一些语义bug与物联网系统的自动化逻辑有关，如自动化应用程序中的逻辑故障。上图显示了错误类别和根本原因的分布。最常见的漏洞类别是一般开发问题(48%)、设备管理问题(29%)和消息传递问题(19%)。

下一个常见的根本原因是依赖错误(DEP)，即开发人员使用了错误版本的软件或固件库、工具、设备或协议。

导致硬件、连接和消息传递问题的最重要根本原因之一是时序错误(TM)。对超时或操作速率的不当处理、连接关闭时错误超时值或不处理异步行为都是与时间相关的根本原因。

一些更偏向硬件编程的故障，如中断处理，属于硬件编程错误(HWP)。

异常情况(EC)是物联网漏洞的另一个根本来源，包括处理极端情况(大数据或超出范围的数据)、未正确处理错误或未处理需求更改或第三方组件的更改。最后，其余的根本原因与内存故障(MEM)、并发故障(CON)和配置故障(CNF)相关。

bug种类之间的相关性：

在分析过程中，我们观察到某些bug类别出现的频率相对更高。

为了研究bug之间的相关性，我们使用了Lift，这是Han和Kamber引入的一个统计度量，用于计算两类bug同时出现的概率。对于每一对bug类别，Lift值大于1表示正相关，而Lift值小于1则表示负相关。下表显示了相关bug类别对应的Lift值。最相关的错误类别是[硬件、固件]、[硬件、连通性]和[固件、连通性]。这种相关性分析除了能帮助物联网开发人员进行调试外，还让我们深入了解物联网错误在实践中是如何相互交织的。

bug的频率和严重性

通过询问调查参与者，他们是否以及有多频繁地遇到每种bug类别，以及基于对物联网系统的影响和修复时间所感知的严重程度，统计得到了下面这张表。

根据统计显示，至少82%的物联网开发人员都遇到过我们分类的错误类别，这表明我们创建的bug类别在一定程度上能够代表真实世界物联网系统中的错误分类。连通性问题是最常见和最严重的漏洞类别，超过97%的物联网开发者至少遇到过一次。与设备相关的问题是继连接问题之后最严重的错误。据调查受访者称，自动化问题是最不严重的问题，然而，超过91%的物联网开发者至少面遇到过一次，根据物联网开发者的经验，兼容性问题是最不常见的错误。

关于子类别，设备初始化问题是最常见和最严重的设备管理错误，约95%的IoT开发人员已经处理过这些问题。在设备状态问题上，与连接状态相关的bug出现的频率更高，而与设备属性状态相关的bug更严重。在与设备相关的问题中，设备固件异常问题是最严重的。关于一般的开发问题，安装问题是最常见和最严重的。

四、RQ2发现

在本节中，我们将提供物联网开发者所面临挑战的调查结果。

4.1 测试和调试面临的挑战

依赖对真实设备的访问：

根据7名受访者、几个GitHub问题(device – os /1871、MY- CONTROLLER/485、TESLA-API/43)和74%的调查参与者表示，物联网开发者依靠访问设备来测试和调试他们的物联网系统，需要进行手动复位或监控设备输出等任务(P2,3,7)。但在某些情况下，设备无法直接接触到或位于难以访问的位置，因此远程调试更有必要。四名受访者认为，为了更好地进行物联网测试和调试，需要模拟解决方案。正如P5，一名中间件开发人员所言：“物联网设备供应商不提供其设备的模拟，所以我们必须得在实际硬件设备上进行逆向工程，而不是使用模拟的设备。”另外，如P5、8,9所述，目前物联网中的模拟解决方案还不够成熟，它们仅适用于有限的场景，如测试高级控制器或小单元测试，而不适合所有级别的测试，如系统测试。测试环境的访问和模拟是个问题

故障定位：

根据8名受访者、9份调查意见以及半数调查参与者的说法，由于物联网系统运营缺乏透明度，故障定位存在障碍。正如P7所提到的，“没有一个可以记录所有内容环境。”造成这种情况的一个因素是很难跟踪物联网系统中众多外部组件的执行情况。

影响故障定位的另一个因素是隐藏故障的存在。例如，P7提到“在应用程序上很难识别设备现在报告的温度是几分钟前的温度。”此外，P2,4提到了只有在设备工作了特定时间后才会出现故障的例子(P2为5分钟，P4为几个小时)，这在GitHub问题(device – OS/1926, ZWAVE2MQTT/141, VSCP/207)中也会观察到。这样的问题使得物联网的失败更加不可预测，并可能隐藏开发者的错误。

故障定位的另一个问题是缺乏工具和开发人员的支持。例如，P3通过Wireshark监听通信，对设备消息进行检测。作为一名硬件平台开发人员，P2说:“由于没有来自设备的错误或损坏的反馈，我们需要添加了一些led来跟踪设备是否正常工作。”

复现物联网bug：

除了前面提到的设备访问限制或隐藏故障等增加漏洞复现难度的因素外，一些漏洞只会在特定的设备设置或物联网系统的特定环境中发生。除非具有完全相同的设置或环境，否则物联网开发人员无法复现这些错误。例如，一个调查评论指出“在X86设备启用ASLR时，很难重现一些与内存相关的错误。”

组合爆炸：

除了传统软件中所有不断发展的组件，如库和操作系统，物联网系统中还有更多不断变化的因素。由不同标准的不同制造商生产的硬件设备、设备集成中间件和通信协议都是物联网中额外变化的因素。随着所有这些组件以特定的速度发布新版本，当开发人员想要用测试用例覆盖所有可能的组合时，组合爆炸问题就很可能会发生。举个例子，P9说“我们每次必须测试10到15个不同的设备”。此外，80%的受访者认为组合爆炸是物联网开发者面临的测试挑战，P8认为这是最严峻的测试挑战。

测试和调试边缘案例：

覆盖大规模的场景(例如太多的设备)和特殊情况(例如温度低于零度)增加了测试覆盖的障碍。有四名受访者、三名调查参与者提到了这一挑战，并在几个GitHub讨论(DEVICE-OS/1926, TEMPERATURE-MACHINE/13)中观察到这一挑战。例如，P4说:“我们应该努力编写针对并发问题的测试，因为我们的物联网系统部署在不同的城市，所以我们应该能够每秒处理140,000个HTTP请求。”此外，这个挑战是最常见的测试挑战(83%的受访者)。

不成熟的测试体系：

下图显示了过度依赖物联网开发人员进行测试的现状， 64%的参与者提到开发人员是他们物联网项目的主要测试人员。正如P6，一个拥有近7K star的热门物联网项目开发者所说:“我们没有QA团队。都依靠开发人员进行测试，无论是手动还是编写自动化测试。”但通常，软件开发人员不具备测试硬件方面的技能。拥有1.5K star的物联网平台软件开发人员P9表示，他们物联网平台的瓶颈是硬件测试，因为他们没有足够的工具、知识和硬件测试实践。

而且物联网测试高度依赖于手工执行，因为只有5%的参与者报告测试能够实现完全自动化。此外，在采访中，四名受访者提到了纯手动IoT测试方法。据受访者表示，最常用的物联网测试方法是混合策略。一位物联网开发者描述了这种方法的一个例子:“不直接与设备交互的服务会自动测试，但使用设备时就需要手动测试。”

第三方的快速变化：

所有受访者都提到了第三方变更带来的挑战。三名受访者表示，第三方在没有事先通知的情况下做出了重大更改。此外，P5和8提到了第三方系统停止支持设备或服务，导致他们的物联网系统崩溃。四位受访者(P2,4,5,8)明确表示，很难跟上设备制造商等各种第三方的快速变化。

技术、背景和需求的多样性：

物联网技术的多样性带来的挑战是访谈和调查评论中重复次数最多的挑战。此外，60%的受访者对此表示赞同。几位与会者提到，物联网开发需要多种开发技能，如硬件编程和网络协议知识。通常，开发人员不会经历这条学习曲线:“开发人员倾向于使用他们熟悉的协议。虽然有时存在更好的解决方案，但开发者并不知道或有能力使用它们。”P2、3、7、8和一些调查评论提到，很难理解某些设备制造商的低质量文档。P2、3和两个调查意见还提到，用户需求、用户背景和技能可能是非常不同的，开发一个能够支持所有用例的通用物联网系统是一项挑战。例如，P2提到他们必须在硬件上增加更多的引脚，并增加对模糊传感器的支持，以满足所有用户的需求。

4.2 其他挑战

安全：

调查结果显示，超过一半的物联网开发人员对其物联网系统中使用的第三方组件(如操作系统和库)的安全性没有信心。此外，在总共14名提到安全相关挑战的参与者中，有6人认为这是最重要的挑战。此外，66%的物联网开发者认为安全是一项复杂的任务。P7也提到了一个主要挑战，即在具有处理和存储限制的物联网设备中生成和存储访问令牌。类似地，近60%的物联网开发者认为设备限制使得安全任务具有挑战性。还有设备与物联网网关之间本地通信的安全性通常被低估，它们可能是高度不安全的。正如P9所说，“为了加快物联网系统的发展，开发者不考虑本地网络的安全”。

物联网设备的更新。

半数受访者认为，为已经发布的设备发布软件升级或安全补丁是不可避免的挑战。参与调查的6名物联网开发人员就更新挑战提出了“在已销售的设备上安装关键更新”或“在大规模部署中安装固件更新”等意见。

受限设备的编程：

63%的参与者认为设备限制使物联网发展更加困难。大多数物联网开发者都在努力以一种消耗更少处理能力和能源的方式设计和实现软件。我们的受访者也提到了不同层次的设备限制(P2,3,6,8)。

五、讨论

在实践中没有采用物联网测试解决方案：

原文参考文献中已经提出了多种物联网测试工具和方法，如设备模拟器、物联网单元测试框架等。然而，似乎没有一个被物联网开发者采用，只有9%的人提到使用第三方服务作为他们的主要测试方法。此外，尽管物联网测试自动化框架已经存在，但物联网测试仍以手动和特定的方式进行，因为我们研究中95%的物联网开发人员都执行手动测试。此外，正如P5,8所提到的，设备模拟并不支持模拟所有类型的设备。未来一个可能的方向是为每个物联网设备单独设计设备模拟器，以在测试期间绕过必须要实际硬件设备的需求。

缺乏设备级监视工具支持：

调查物联网设备的日志数据是物联网开发人员常见的调试任务。没有通用的工具可以从所有类型的设备上接收日志数据，开发人员不得不手动使用简单的方法来监控设备状态和通信状况，比如分别对每个设备进行串行打印(P2,7)或使用Wireshark (P3,7)等通用工具。而且现有跟踪设备日志的解决方案在实践中发现是低效的，受访者表示 即使一些设备提供了日志库，也需要从每个组件单独手工聚合或跟踪。”

设备的日志集中采集也是一个需要完善的方向。

碎片化和不断变化的物联网生态系统：

当今物联网发展面临的最严峻挑战之一是硬件设备的迅速淘汰。正如一些物联网专家和所描述的那样，物联网设备被更新换代和被供应商停止支持的步伐正在加快。物联网设备的更新通常会使旧设备无法使用，同时也会破坏物联网开发者的实现。在这个不断变化的物联网生态系统中，开发人员必须努力维护特定于设备或特定于协议的代码。物联网开发人员不仅要负担所有版本的设备以跟上这些变化，而且还要分配大量的开发工作，从一个版本或生态系统迁移到另一个版本或生态系统。由于这一问题针对的是物联网消费者和开发者，2019年，一些国家规定了物联网供应商在售卖设备后发布更新的最短时间。此外，受访者提出了一些解决方案，如基于契约的测试(P5)，以确保与第三方系统的持续兼容性。然而，这些方法都不能成为长期和普遍的解决方案，因为它们仍然依赖于现有的合同和法规。

六、总结

基于91个物联网开源项目、5565个 Bug、9 次采访、194 位 IoT 开发人员验证，我们了解到了物联网系统的第一个bug分类框架，通过展示常见的错误类别及其根本原因之间的相关性分析，希望这些错误能够在物联网系统开发的早期被避免或检测到。这个分类覆盖的面涉及物联网系统的各层级，那么从物联网安全的角度来看它也提供了一个攻击面的索引，爱出 bug 的地方，如果可被利用，那么极有可能成为漏洞。

另外，通过针对性的访谈形式汇总出的物联网开发人员面临的挑战，或许可以帮助研究人员和开发人员理解现实世界中物联网发展的痛点，并设计新的技术和工具。

参考链接：

论文原文 https://people.ece.ubc.ca/amesbah/resources/papers/iot-icse21.pdf 

版权声明

本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。