软件版本升级，修复bug适配IPC设备
这周主要是针对升级后的VM的测试套进行适配，说来惭愧，5天就调试了5个bug，没有做太多的事情。刚开始让我跑一台设备后适配脚本这个事情时，我是不情愿的，主要是对旧测试套代码编辑工具没有用过，另外之前也没有写过关于VM的脚本导致了业务的不熟悉，改起来肯定会又慢又难，迫于无奈也只好妥协。最后还好把适配都完成了。
写一写这个事情的小结吧：
- 对于不想做但是又不得不做的事情，那就全力去做好吧
- 适配设备软件版本的改bug，一定是要改那些跑出bug频率很高的脚本；就拿这次来说，要多跑几台设备，至少3台吧，可以相互做参考，另外最好使用不同款的设备，这样的结果具有代表性
- 为了避免设备不稳定导致脚本概现地跑出一些错误，将跑出问题的重新跑一遍，如果第二遍能跑过就说明不是设备软件本身的问题，就不用适配
- 适配升级版本的软件，一定要知道这个版本和上一个版本之间的差别在哪里，出了问题第一考虑是否是改动导致的，再排查其他问题，这样的效率会高很多。比如接口变更，字段关键字的变更、某个关键的默认值的修改
- 调试代码，要参考debug日志，看设备日志和脚本调试日志，这样才有效。不然一个bug可能只是表面解决了没有报错，但是没有深入到根源，没有找到根本报错的原因，只有找到根本原因才能算是真正的修复bug
- 不把代码中的一些数据写死，常用的数值统一用常量表示，尤其是一些数据可能随着版本变更。比如常用的等待时间，这个时间可能与设备某些业务相关，不能随手写一个具体的等待数值，可能导致以后维护代码的人摸不着头脑
- 兼容性要考虑。这里举工作中的例子：设备在跑串口部分的case之前有一个恢复默认的操作，我将所有需要测试的选项共4项都恢复默认了，没有考虑有的设备不支持这4项，比如有的就只支持3项，强制恢复不存在的第4种自然会报错，所以根据IPC能力集判断存在时再恢复；另外当初调试的设备默认的配置是“双向透明通道”，有的设备默认配置却是“云台”，所以以后遇到操作前后顺序影响结果的case需要格外小心。写脚本可能只用了一台设备调试，代码完成后需要跑多台进行验证。
这个月继续看《编写高质量代码》，一边带着做笔记，进度也有50%以上了，继续努力，争取这个月看完。现在每天晚上看一些其他书籍，比如《红楼梦》，大半年才看了一半，吸引力没有其他书强烈了，慢慢读吧。
关于跑步，上个月我的膝盖有些疼，应该是持续跑步的原因，没有很好地休息，现在改成间接性跑了，每天晚上都跑确实对膝盖的伤害比较大， 多做一做俯卧撑和仰卧起坐也是不错的。
