一、引言

OTA 技术的英文全称为 Over the Air Technology，翻译过来就是空中下载技术。物联网行业中 OTA 技术主要用于升级设备的固件，OTA 功能是一个很基础的功能，这个功能非常重要，一个最简单的 OTA 升级流程是：服务端配置 OTA 升级包—设备上报版本号—服务端下发升级包—设备进行升级，这个流程中服务端需要适配多种设备，而且设备升级中存在各种各样的场景，整体功能非常复杂 ，整体测试需要注意的点非常多，本人最近完成了一次 OTA 服务端重构级别需求的测试，通过这个需求整体梳理了 OTA 需求的测试点，供大家参考。

二、测试前准备

测试前需要准备数据，需要不同的固件包，注册不同的虚拟设备，PS：服务端和设备之间的交互，部分设备使用 https 协议通信，可以使用 postman 接口工具来模拟通信，但是很多设备使用 MQTT 协议进行通信，MQTT 协议是一个轻量级的协议，适合功耗性能较低的物联网设备，可以使用 MQTT 可视化工具进行模拟通信，比如 MQTT（https://mqttx.app/zh）

三、功能测试点

我在进行功能测试时，发现一个问题，就是 OTA 这个功能是一个基础功能，整个功能有非常多的模块，每个模块有不同的测试点，整体测试需要注意的点非常多，上手测试的时候不知道从何开始，如果不仔细梳理 OTA 的测试点，非常容易漏测，为了避免漏测，经过不断的梳理，我总结了下面这些测试点，进行测试用例设计的时候可以给大家以参考，如下：

1.固件包的管理：
开启 OTA 升级的第一步是配置 OTA 升级固件包：
①.固件添加：开启 OTA 升级前需要配置固件升级包，对固件包的增删改查需要检验数据库，大多数情况，为了保证下载速度，固件包会传到 CDN 中，存在数据库中往往是一个链接，需要单独访问下存到数据库中的链接，看看是否可以下载下来，另外通过请求获取下此下载地址，验证下是否可以正常进行固件下载，并要核实固件内容大小和相关信息等。
②.固件的编辑： 固件添加完成之后，部分字段应该可以编辑，部分字段不能编辑。比如固件版本号，md5(用于校验固件包是否完整)，需要对照接口文档一个字段一个字段校对。
③.固件的删除：固件是否删除需要判断该固件是否被使用，如果还有对这个固件的升级没有关闭，固件是不能删除的；固件删除成功后，另外还要查验对应固件信息在数据库表中的删除逻辑是否符合预期。

2.各种升级的策略的覆盖
①.升级的策略可能有多种，不同的升级策略有不同的升级配置，需要对照接口文档检查。
②.按设备数量维度：灰度升级，指定设备升级，全量升级
③.固件版本维度：指定版本，全部版本
④.升级不同的方式：app 触发升级，静默升级
⑤.升级时间： 定时升级，延时升级，立刻升级
⑥.黑名单，白名单
⑦.流程维度： 正式升级，测试升级

3.升级流程（重点）：
在升级过程中，设备和服务端的交互中，主要是设备上报当前固件版本，服务端下发升级配置，接受升级日志。这个流程关乎 OTA 升级的成功与否，在测试中是重点，需要格外关注，下面是一些测试用例，供大家参考。
①.升级成功：设备命中配置的升级，服务端下发升级配置，设备直接升级成功，上报升级后的版本号。
②.升级失败：备命中配置的升级，服务端下发升级配置，设备直接升级失败，上报升级后的版本号。
③.多固件：有的设备有多个固件（比如固件 a 和 b），需要覆盖 a 单独升级，b 单独升级，a 和 b 一起升级…这些场景。
④.升级超时：下发升级配置后，设备一直不上报升级进度，经过 x 分钟后（服务端的配置），升级超时。
⑤.设备上报异常版本：服务端下发升级配置后，设备升级完毕，上报版本既不是旧版本，也不是目标版本，而是数据库未记录的版本。
⑥.失败重试： 配置服务端升级策略，升级失败后，重复下发多次升级配置。
⑦.成功后卡刷（本地 SD 卡覆盖安装固件）重试：卡刷后检查版本，是否可以升级成功
⑧.回退版本：卡刷高版本后，检查升级，预期收不到升级消息
⑨.黑名单设备：已配置黑名单的设备检查不到升级配置
⑩.还有各种异常操作：比如设备升级中，删除升级&固件等

4.数据一致性
为了保证性能，升级过程中的固件、版本号，设备状态大概率都会加入缓存，存储方面缓存和数据库
①.如果有多级缓存，多级缓存间数据需要一致
②.缓存和数据库一致
③.上面各种场景下的缓存和数据库保持一致

5.兼容性
①.不同类型的设备 ：常电设备，低功耗设备，比如低功耗设备，往往需要先发送唤醒消息，再发送升级消息
②.新旧版本的接口性能测试
③.首先分析对服务端压力大的场景：夜间配置一个 OTA 升级，开放升级后，大部分的设备开始陆陆续续的升级，升级成功后的设备停止，升级失败的设备再次升级。整个流量并发数量根据设备的常连接数来定，并发持续时间很长。具体压测指标可以和开发&产品商定。
④.指标：常见的压测指标有：QPS , 并发数，响应时间，CPU 利用率，内存，磁盘 IO，接口错误率等。不同的系统&需求，关注的指标不一样。OTA 功能的主要特点是：大规模放量经常发生在晚上（晚上用户请求少，而且不是频繁写入读取的业务场景，对 CPU 和磁盘 IO 压力不大），而且每次 OTA 放量经常使用静默升级的方式由设备发起请求（对响应时间不敏感），OTA 升级场景对并发数（支持同一时间升级的设备数）和接口错误率（接口错误直接导致升级失败）非常关注，可以说：OTA 功能不追求多快，但是追求稳。
⑤.升级步骤：首先确认升级流程，整个过程一般都会调用这些接口（使用 MQTT 的设备，可以使用脚本，或者调用内部接口来实现）：上报版本号，检查升级，确认升级，上报升级结果。为了真实模拟升级过程，可以使用这些接口拼成一个业务场景，使用 JMETER 进行压力测试，如下图：

⑥.执行 JEMETER 压测脚本，分析压测报告。
⑦.PS ：我在压测中遇到的问题：
Ⅰ.各种配置如数据库连接池 需要放大
Ⅱ.批量升级场景下，发生了数据库交叉死锁的问题，表现为部分设备升级失败，查看日志，发现有对应的报错。

四、接口自动化测试（Python）

1.http 接口可以使用 Python 的 request 库进行测试

2.MQTT 协议可以使用库： paho-mqtt 进行自动化测试（或者直接调用内部接口）
首先安装库 pip install paho-mqtt，使用 client.Client() 方法实例化对象，使用 connect 方法进行连接，使用 publish 方法发送 topic 消息，使用 on_message 方法制定回调函数&接受消息，可以自己根据业务封装好基础方法，用于构建 MQTT 接受，发送消息的业务场景。

一个小的 demo 代码如下图所示：

3.自动化的场景：
①.模拟不同设备进行升级（常电设备，低功耗设备）
②.模拟升级的通过结果（升级成功，升级失败，升级超时）
③.模拟不同的升级方式： app 升级，静默升级
PS : 需要梳理下自家平台的业务，了解那种升级方式，那种设备的占比多少，按照占比从高到低的覆盖场景，自动化主要可以用于回归，提升我们测试的效率。对于一个常用的需求还是很有必要的。

4.自动化的校验点
①.接口或者 MQTT 的返回
②.数据库的具体字段，比如设备、升级、固件包的状态
③.对应缓存 key 的值

五、总结

OTA 功能比较基础，比较复杂，整体测试 OTA 功能需要从功能，性能，兼容，等角度思考测试点，上面写的只是一些服务端的共性的测试点，读者在接手真正的需求时，还需要总结自己业务特殊的逻辑，这样可以减少漏测，更好的保证质量。