「2019」「RM圆桌」第二期 我们要搞测试

主要是下面的几个步骤
1)恢复现场：尽量重现bug出现时的场景
2)分析关联变量：对于比较好复现的问题，分析关联变量比较容易发现问题根源
3)控制变量（排除法）：对于一个稳定的机器人突然出现的，之前没有发生的问题，不要匆忙打开软件撸代码，先尝试换硬件，换线，换机械，换传感器，先排除是他们引起的问题，最后再怀疑软件出了问题
4)多次重现寻找规律

这里我给大家举个例子

Bug描述：机器人发射弹丸时，云台抖动，导致弹道不稳；
1）恢复现场，发现每次开启摩擦轮之前云台稳定，开启摩擦轮后，开始逐渐抖动并且加剧；
2）分析出关联变量是开启摩擦轮，而不是发射弹丸，也不是拨弹机构；
3）控制变量，换一个机器人，同样的程序，发现发射弹丸时，云台不抖动；
说明是硬件和结构引起的问题；分析云台抖动相关的变量：云台PID位置反馈，云台速度环反馈，云台PID输入角度，用jscope 调试，发现开启摩擦轮后云台PID速度环反馈数据周期性抖动，而速度环反馈是陀螺仪反馈的数据，这时保证其他环境不变，更换陀螺仪模块，发现抖动依然存在；至此可以定位问题不在软件，也不在硬件，开始从结构方向去寻找问题产生原因，检查机构是否稳固，最后发现是有一个结构件螺丝松动，摩擦轮开启后，产生共振，导致陀螺仪数据抖动，从而出现bug，最后优化结构件固定方式，解决该问题。

从哪些方面去测试一个具有完整运动功能的机器人底盘的性能好坏呢？这个问题可以归纳为有哪些测试方法，实际上就是测试用例的测试方法，下面总结了几个比较典型的测试用例的设计思路。
用例设计方法：
1.点线面：列出被测对象的所有功能点、业务流程，以及整体功能全面应用时产生的需求，设计测试用例；
2.等价类：从实际输入输出中提炼出等价的具有代表性的输入输出，根据输入测试用例；
3.边界值：对输入输出的临界值，单独考虑测试用例；
4.状态机：对状态切换过程，输出状态机，并对每一种状态设计测试用例；
5.流程图：对被测对象的工作流程，输出流程图，并从流程的角度设计测试用例；

我们可以举一些在数据分析上面用到的方法和工具

一般一个问题发生，第一件事是简单分析后找到可能的源头，确定是哪部分出了问题，大体上分机械嵌软，硬件嵌软
一般机械嵌软纠缠的问题可能不需要改代码就能解决，不过事后一般会加相关的代码来快速暴露机械问题
硬件嵌软的问题就需要比较仔细的调试才能定位，就像上面举的例子一样，前车之鉴是，在没改代码而突然出现问题的时候，先从换板子，换机械，换线路开始（穷人请自觉忽略这段）
在定位问题的过程中，很多时候是需要有数据支撑，需要寻找问题的根源，比如分析通信协议，分析IMU原始数据等，这个时候往往就需要一些辅助工具来提高获取数据的效率。以下是一些常用手段和方法

1)抓包：使用工具抓出错的数据，通过出错的数据再反查代码定位问题，常用工具有：keil断点和watch窗口，jscope（JLINK驱动自带的曲线分析工具），wireshark（网络抓包），串口助手，串口监听工具（device monitor），或者配上蓝牙串口适配器使用效果更佳

2)Log分析：如果板子有sd卡等储存器硬件接口，可将关键数据和关联的数据储存到SD卡中，便于离线分析问题，对于需要获取不方便在线调试的数据时，作用非常大。一般的log会包含以下内容
a)时间戳：系统的systick或不同任务的count，有了时间戳就可以依据时间来判断问题是否是周期发生，对进一步确定问题有较大帮助
b)系统状态标志和状态机当前状态：打印状态机便于定位问题出在哪个状态中，是全局问题还是局部问题
c)其他模块的心跳状态：分锅专用，谁写的bug谁来解
d)写一些特殊的状态输出出来，这些状态可能与系统运行无关，但对于debug非常有用，比如一些奇怪的标志位

一般选用matlab或python作为辅助分析工具，在分析数量比较大的样本，或与计算紧密相关的bug时起作用；在样本数量较小时推荐使用excel（毕竟一般电脑里都自带不需要装啰里啰嗦的软件），一般的数据处理excel也可以支持。

当然，这里要说明的一点是，Bug很难复现，复现了也说不明白怎么回事怎么办？一般对于这样的问题，推荐使用录像机（或手机相机）录视频的方法来记录问题（PS：演示时配上录像设备效果更佳），如果实在买不起手机支架什么的话，可以去找大爷翻翻监控，看看能不能找到些蛛丝马迹（你会发现过不了两天门卫大爷就认识你了）