IoT 产品自动化测试方案思考

在如今，IoT 产品越来越流行，无聊是产品的品类数量，还是用户数量亦或是参与布局的公司都越来越多。而我恰好也是这个行业大潮中的从业人员之一。作为一个测试，自然也想着如何能更好更高效地测试产品。自动化测试就是其中的一个方面。

IoT 测试与传统互联网产品测试的区别

所谓 IoT 即 Internet of Things，可以看出他是着眼在万物互联上面的，这是与传统互联产品最大的区别。对于测试来说最大的不同之处在于传统互联网产品大多都是 online 的，也就是可以通过代码可以获取它的状态、动作等，但是 IoT 产品例如空气净化器，想要对他进行配网却需要手动按按键触发。

对于现阶段的 IoT 产品来说，相较于传统的 Things 来说区别在于连接网络，也就是多了通讯模块。那么可以将 IoT 产品抽象成这样的模型：通讯模块作为桥梁连接云端和机器本身，机器本身通过主控板与通讯模块连接通讯。例如产品的配网绑定也就是用户通过按按键像信号传递到主控板，主控板与通讯模块进行通讯，通讯模块进入配网状态，从而进行配网。用户在手机上操作控制机器，也就是云端下发指令到通讯模块，通讯模块再按照特定的通讯方式与主控板进行通讯，然后控制机器执行特定的动作。

到这里对于 IoT 产品的自动化测试方案也就有了头绪

IoT 产品自动化测试

首先在产品开发前主控板与通讯模块都会有一套预先定义好的通讯协议，双方约定帧头，帧尾，帧类型，校验等等。然后交由不同的团队与人员进行开发。那么只要保证通讯模块和主控板之间的通讯是正常的，是可靠的，IoT 产品的测试就被划为了两部分，一部分是机器本身，和传统的产品测试一样没有大的变化。一部分是更偏向互联网方面的 APP，后台等方面的测试。本篇主要探索后者的测试。

首先可以可以写一套脚本模拟主控板，用于和通讯模块进行收发通讯。将通讯模块单独连接在电脑上，然后通过串口与这套脚本通讯。例如通讯模块连接在 COM1，而主控板模拟脚本接在 COM2。在 APP 上发送“开机”指令，下发到通讯模块以后，通讯模块往 COM2 下发指令，主控板模拟脚本接收到对应的帧以后，按照约定好的通讯协议模拟机器做出对应的应答帧，然后通过串口发回到通讯模块 。通讯模块就会收到对应的应答帧，应答帧以后上报到云端然后完成整条链路。

同样的如果是机器本身有动作，例如配网，可以用模拟脚本发送指令到通讯模块，通讯模块收到对应的帧以后解析进入配网状态即可。这样在测试时就免去了按按键这一步，由一套按照通讯模块与主控板之间通讯协议开发的脚本来代替机器本身即可。

模拟器的优缺点

而这套脚本的编写可以按照团队成员的实际情况还有测试的情况来编写，我司叫做主控板模拟器。我司初期由 C# 编写，还加了图形化界面，现在改用 python 编写，还增加了局域网通信收发指令。

优点

在上面点击开机就会发送开机指令到通讯模块，通讯模块发送开机指令，这套脚本的图形化界面上开机图标就会亮起，既可用于自动化测试也可以用户代替机器进行手工测试。也免去了一些情况模拟的烦恼。

例如模拟机器故障以后 APP 上是否会有消息推送。在传统测试中需要将机器改成故障状态，然后测试，费时费力。再比如需要测试净水器水质差的情况，不再需要往净水器中接入水质较差的水然后测试，只需要在模拟器上将水质数据改得比较差然后发送到通讯模块，即可模拟机器检测到水质较差然后发送到通讯模块的情况。

缺点

当然没有什么是十全十美的，使用这套方案的前提就是保证主控板与通讯模块之间的通讯都是可靠的。使用这套方案不能完全代替整机进行测试，只是测试了 IoT 部分。最终版本或者特定的迭代版本还是需要真是机器进行测试的。但是在开发初期的测试开发联调，后续迭代开发测试，回归测试均具有极大的便利性。

总结

简单来说这套方案就是使用脚本来模拟真实机器执行动作已经上报状态，然后就可以隔离机器和 IoT 部分的测试了。而 IoT 部分的测试可以例如 Pytest + Appium(airtest) + PO 设计模式来进行的。这个在后续文章中的分享。