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

可以简单思考一下，我们去执行测试时，会想到一个功能点，然后按照一定步骤去验证功能，并且把结果与心里的预期（需求）去比较，把这个过程变成文字，写出来，就是一条测试用例了，简单的说用例就分为，测试条件，测试步骤，预期结果；

好吧，你可以这么理解

这个问题实际上可以理解为在各个阶段测试如何介入项目；
a)前期，需求期；
i.从用户角度的去思考需求是否合理，是否完备；
ii.与研发约法3章：问题记录同步方式，固件管理方式，研发的测试诉求；
iii.制定测试计划；
iv.梳理初版测试用例；
b)中期：研发期
i.按阶段执行测试，定期反馈分析问题；
c)后期：稳定期；
拉研发参与测试，稳定性测试，性能测试，测试总结；

我要把RM组委会几年沉淀下的测试流程发给大家，大家可以在帖子里查看

嗯，我发现我的图格式有点儿问题，一会儿发给大家，先下一个问题

BUG定位方法是一门学问

首先，要有几个理念。

理念1：比赛没有玄学，机器人也不会紧张，真正导致出bug的往往是因为测试环境和实际应用环境不一致
举例1：机器人刚开电的时候刷RFID卡距离正常，但每次底盘上电后RFID刷卡距离急剧缩短，看似很诡异，一旦找到复现规律，就方便定位问题，最终发现是因为底盘上电时，电机启动电流较大，而且在RFID安装的位置有电机的电源线和中心板，干扰了RFID模块的运行
总结1：测试一定要尽可能模拟真实环境
举例2：英雄机器人启动失败，有时启动出现取弹机构的控制电机疯转抬起机构，在没有改代码的情况下出现概率从1%逐渐上升到50%（大概2周的时间越来越高），嵌软组小伙伴debug发现启动时偶尔那一路can回出现奇怪的数据导致电机接收到错误数据抬起，后查明是因为板子的一个电容虚焊导致can芯片初始供电不稳定，一旦供电稳定则成功启动通讯正常，如不稳定can就会输出奇怪的数据，重新焊了一遍与can芯片相关的元件后恢复正常启动
总结2：看似玄学的问题，都是有原因的

理念2：一个简单评价工程师的方法：定位bug的能力
找bug比较简单，定位才难，就像你在家看跳水比赛一样：看似简单，实际上需要很多知识和经验。
举例3：系统性问题
英雄的云台出现零点附近的突然换向，在经验不足的队员看来就是嵌入式的问题，如果嵌入式队员也是经验不多的队员，就会被甩锅，在嵌入式debug时会发现在靠近中间位置时，电机突然会脱离系统旋转一定角度，是因为机械D型槽顶丝松动导致。
举例4：步兵的云台出现开启摩擦轮时云台会抖动，不开摩擦轮一切正常，debug发现在摩擦轮开启时云台会受一个周期性的力矩，这个力矩是两个摩擦轮的转速差异导致的。而该力矩的频率与云台结构的固有频率相近导致共振，并被IMU放大，导致云台宏观上周期震动，对IMU的计算结果使用低通滤波解决。（就像天线上挂块人肉就能解决信号不好的问题）
举例5（可以分一分）：步兵在换了新结构后云台日常震动，看着很难受，在确定两级PID代码都没有问题的时候开启debug模式，对位置环使用不同频率的正玄波进行测试，在查看50hz附近的结果的过程中发现IMU传感器周期性发生突变的现象。最终发现是因为新结构中轴承与云台间连接不紧密导致微小震动，震动传到了固连在云台上的IMU模块造成了IMU角速度突变导致的控制不收敛现象。（本可以拍一拍就解决的问题非要这么麻烦）
总结：一个问题并不是一个点引起的，会涉及多个错误的叠加，比如机械-机械的错误叠加（嵌软是不可能出bug的，这辈子都不可能的，只能靠甩给机械才能维持生活这样子）

这里是我们RM的测试流程，这个已经被优化过了，大家可以直接使用。

登录/注册后可看帖子