尝试写一个系列文章，关于串口自动化测试。
这是第一个测试场景，传统的串口调试和串口自动化测试均有介绍。
场景描述
在设备研发过程中，某个串口模块依赖一个另一个串口模块，比如说模块A依赖模块B，如下图所示，模块A在某些操作下会发出串口命令给模块B，并接收模块B 给出的回复做出后续反应：
这种依赖的问题会导致原本的需求目的是要验证模块A，但由于所依赖的模块B不稳定或者未开发完成，导致工作无法正常开展。
解决方式
那作为测试工程师，面对这样的情形，我们该怎么办呢？解决这类问题的核心的思路：引入依赖串口模块替身，更通俗的叫法，引入Mock服务。
Mock是什么
可能还有些读者之前并没有接触过Mock，不清楚Mock是个啥。Mock简单来理解，就是模拟，在测试过程中，对于一些很难构造或者获取的对象，用一个虚拟的对象来创建以便测试。而这个虚拟的对象就是mock对象。
Mock对象就是真实对象在调试期间的代替品。
对于上面的问题，可以通过引入Mock服务来进行解决。将模块B用Mock替代，对模块A进行测试。
串口测试的工具介绍
常见的串口调试工具
目前市面上有不少串口调试工具，功能大同小异，但都不能说是实现了自动化测试，而且串口调试工具进行少量数据传输，并且，对于有时间精度要求的测试（比如模块B需要在500ms内给模块A返回回复内容）很难把控。
比如下图的串口调试工具，可以MOCK模块B，在收到模块A发出的串口命令后自动进行回复，但是，当收到的命令少时还好，收到的命令多的情况下，要根据发来的命令做出不同的回复，人工操作很难做到准时精确。而且人工操作存在误差，当有命令需要得到快速回复，响应速度没有那么快。
串口自动化测试工具: 串口测试机器人（utpSerial）
串口测试机器人支持模拟模块B，自动配置对模块A的回复。当收到模块A发来的串口命令时，会自动进行回复。并且支持在这个过程中所有收发命令的检查。
下面是串口机器人配置自动回复的命令，无需编程，直接插入，然后根据实际的测试逻辑填写当收到模块A的命令“cmdA”时需要自动做出的回复“cmdB”，并且可以对回复的时间进行设置。
通过事先以测试用例的形式配置好所有命令的回复，就可以实现对模块A的自动化测试。
同时串口测试机器人还提供了很多其他的命令，方便快捷的进行串口命令检查，查看等操作。下面选取其中两条命令作为展示。
命令一：检查
检查模块B收到的模块A发来的消息是否符合预期。比如在正常的情况下，模块A发来的第三条命令应该是cmdxx，用下面的命令就可以进行检查确认，如果命令发送正常，则检查命令执行成功；如命令发送错误，则检查命令执行失败，并会明确在测试结果处写明失败原因（实际收到的命令是什么）
命令二：查看
自动化测试最担心的是测试数据是否是真实正确的，人工测试时，可以实时进行查看，测试人员会“放心”。而用自动化测试工具，测试过程无需人工干预，对于测试过程中的命令究竟是什么，可能会“不放心”。苏州宏控串口测试机器人提供查看命令，用户可以查看实际测试过程中，模块A发来的什么命令，什么时候发生的，模块B给这个命令做出了怎样的回复，回复时间是什么，这些测试数据统统会留存。
更多的命令，可以通过苏州宏控串口测试机器人来进行探索和体验。
