測試環境：stm32F401RCT6、RT-Thread版本: v4.1.0、RT-Thread Studio版本: 2.2.6、網絡硬件使用ec800m移植at_socket使用sal框架。

1、測試介紹
我移植的這個at驅動還不完善，頻繁發送消息時會導致網絡斷連，打開調試進行一些延時就沒問題了。但是斷連的特性反而有助于我們進行qos測試。

因為我們要測試斷網后qos消息質量的穩定性，所以 cleanSessionFlag（清除會話）必須為false
由于我們要測試中途被mqtt服務器踢掉后的效果，所以示例使用的我的mqtt服務器，您如果有興趣測試這個的話請修改配置信息為您的服務器

要測試的功能如下圖。都是發送20條消息。

2、測試發布QOS1 / QOS2消息
網絡正常情況發送，發送qos1消息
打印日志上面紅框表示RyanMqtt發布了多少條消息也就是 RyanMqttPublish 接口回復ok的次數，下面表示真正完成發布了多少條

emqx截圖，可以看到是20條。但細心的你肯定發現了發送的信息居然不是按順序來的，這是因為emqx設置訂閱的qos2主題，實際顯示將會按照qos2完成時間來進行顯示

網絡正常情況發送，發送qos2消息

模擬發送中途斷網，發送qos1消息
這里模擬的意思是：發送第5條的時候把網絡硬件進行關閉，發送第10條時啟動網絡硬件，觀察發布消息和實際消息是否對得上號

看上面日志咱們發送了12條，emqx為什么會收到13條呢？
這就是qos1的特性了，允許至少一次的重復接收，咱們斷網重新連接的時候根據qos1的特性咱們是可以重新發送的。

模擬發送中途斷網，發送qos2消息
這里模擬的意思是：發送第5條的時候把網絡硬件進行關閉，發送第10條時啟動網絡硬件，觀察發布消息和實際消息是否對得上號
這里我們就遇到了開頭說的ec800m驅動問題，qos2需要較多的網絡交互，ec800直接罷工了。
但是等它重連后我們可以發現，qos2的消息依然可以穩定保證只有一次。(之前我自己進行的測試要比這嚴謹的多，會考慮到多次斷網情況等)

模擬發送中途被踢，發送qos1消息
模擬中途被踢：發送20條，在中間的時候手動通過mqtt管理后臺把RyanMqtt客戶端踢掉
這個測試真考驗手速啊，試了4次才成功。
可以看到發送到15條的時候被mqtt服務器給踢掉了，等待重連后可以正常同步

模擬發送中途被踢，發送qos2消息
模擬中途被踢：發送20條，在中間的時候手動通過mqtt管理后臺把RyanMqtt客戶端踢掉
可以看到發送了15條，但是收到了21條！是bug嗎？其實不然，這主要是emqx服務器的策略問題，因為是主動剔除emqx服務器會清除會話上下文，導致qos2消息多接收。
所以說重大風險的環境，一定不要只依靠qos2，太多因素會導致意料之外的結果。一定要通過應用層來保證最終一致性

2、測試訂閱QOS1 / QOS2消息
為了方便觀察效果，我們使用emqx的腳本功能，給所有發送消息尾部加一個0 - 1000的隨機值。方便觀察消息接收情況。
腳本如下

網絡正常情況接收，接收qos1消息

網絡正常情況接收，接收qos2消息

模擬接收中途斷網，接收qos1消息
實驗條件：使用mqttx上位機發布10條消息，RyanMqtt收到第5條后重啟網絡硬件，看聯網后是否可以接收到消息

模擬接收中途斷網，接收qos2消息
實驗條件：使用mqttx上位機發布10條消息，RyanMqtt收到第5條后重啟網絡硬件，看聯網后是否可以接收到消息

模擬接收中途被踢，接收qos1消息
模擬接收中途被踢，接收qos2消息
實驗條件：我使用mqttx的自動發送功能，一秒發一條。發送20條消息，當發送5 - 10條后從emqx服務器剔除RyanMqtt客戶端

尷尬的發現沒法測試，上面測試發布消息剔除的時候說過emqx服務器的剔除會清除會話信息，清除后會話信息，雖然RyanMqtt依然保留著訂閱主題信息，但是emq服務器的訂閱信息不存在了。
所以不管有沒有使能clearSession，都非常推薦在連接成功回調函數中訂閱主題。