九命猫丶的博客

话说上回，我们完成了一部分10服务的测试用例编制，在上文的“进入编程会话”的用例中，我们需要获取level-1权限，本节我们将详细聊聊关于27服务解锁相关内容。

但是目下USB有他自己的优势，还是会继续更新下去，日后申请到设备也会尝试使用ETHERNET-to-CAN并尝试实现持续集成......ETHERNET-to-CAN ，使得公司内网所有设备均能够访问CAN总线，这样无论是持续集成还是多人开发都能带来更多便利...对于一开始为什么使用图莫斯设备尝试UDS诊断的自动化测试，原因是咱手上只有这个设备...但是其本质上作为USB TO CAN而言存在一些不便...咱也被其他同事吐槽。

现在我们的代码以及能够满足大部分UDS诊断测试场景的需求了，本节我们将一些变量放到配置文件中，以便适应不同的测试环境或不同的测试项目进行更改。

上回我们通过多线程的方式，实现了3E服务的会话维持功能，以适应某些特殊的测试场景，现在我们需要完善一个日志系统来保存我们在测试中产生的UDS诊断帧。

话说上回，我们完成了有关27服务的相关功能，现在能够在有解密算法的前提下获取任意等级的权限了。除了27还有一个特殊的服务需要特殊处理--UDS3E服务，本节我们将使用多线程的方式实现3E服务会话维持功能，以供在某些需要会话维持的测试场景使用。

话说上回，我们成功地发送了第一条UDS诊断报文 -- "10 03"，并以Str的形式获取了它的响应报文 "50 03"，但是这样的返回结果并不能够满足或这说并不方便测试用例中断言使用。本节中我们将响应报文进行处理，区分正响应及NRC，并将正响应消息根据不同服务特定的结构进行拆分，以便在编写用例中快速地取值、断言。

话说上回，我们创建了一个称之为DevManager的类用于帮助我们进行设备的初始化操作，并创建一个全局变量handle保存初始化过程中获取到的设备句柄。现在我们可以开始尝试发送一些简单的UDS指令，比如"10 03"进入扩展会话。

因为UDS诊断一般标准是统一的，或许可以考虑搭建一个平台供多个项目进行自动化测试。但是...咱手上的设备只有相对廉价的Toomos，So...拿着不太方便的USB TO CAN先简单做个Demo出来叭~