「2019」「RM圆桌」第二期 我们要搞测试
RM圆桌
11735
0
118
2019-01-09
圆桌时间：2019年1月11日（周五） 19:00-20:00
圆桌嘉宾：@易小川（论坛昵称：民间科学家）
温馨提示：
在直播期间，大家可以直接移步至论坛活动版块，https://bbs.robomaster.com/forum-technology-1.html，直播墙会自动实时更新内容。
在前20分钟内，为主持人嘉宾对话时间，这段时间内嘉宾是不会回答其他参与者的问题的，大家可以在后面40分钟的自由问答时间内提问。
参与本期活动的网友，我们将挑选出三位优秀提问者，奖励3510电机。
================================切割线=========================
1、什么是测试工作？为什么参加RoboMaster比赛需要做测试工作？
a)简单贴切的说，就是验证机器人功能是否正常，是否稳定；复杂的说，就是保证系统稳定性的一种手段，是研发的一个重要环节；
b)RoboMaster坑比较大，机器人系统复杂，各种逻辑组合较多，需要从不同角度去验证和测试，才能保证机器人功能稳定。
b)RoboMaster坑比较大，机器人系统复杂，各种逻辑组合较多，需要从不同角度去验证和测试，才能保证机器人功能稳定。
2、不做测试，会有什么后果呢？
举个例子，给ofo小黄车开锁之前，如果不检查胎压是否正常，捏刹车是否有反应，转动踏板，链条还在不在链盘上，那么你这1块钱可能就交给开锁体验费了。
3、感觉并不清楚测试和研发的差别，那做测试和做研发有什么区别？
a) 思维角度不同：研发注重功能的实现，测试注重功能的使用；举个例子，做好拨弹机构，研发放进去10颗刚从组委会买到的新弹丸，全部拨出来，研发就说，我已经完成拨弹机构啦，但测试这个时候往往会从场地里收集一箩筐脏不拉几的弹丸，分分钟噎死拨弹机构；
b) 知识广度不同：研发注重知识点的深入理解，测试注重知识的广度，对于问题定位需要考虑多方面的影响。
c) 权责关系不同：研发主要对需求负责，测试主要对用户负责；
4、那有什么好的测试方法分享下？
回答这个问题前，先简单说一下测试流程，可以简单分为：
理解需求，设计用例，执行用例，报告分析问题，几个环节
从流程中可以看出，测试方法是在用例设计环节体现的，因此可以给大家讲一下测试用例的设计方法
理解需求，设计用例，执行用例，报告分析问题，几个环节
从流程中可以看出，测试方法是在用例设计环节体现的，因此可以给大家讲一下测试用例的设计方法
5、什么是用例？
可以简单思考一下，我们去执行测试时，会想到一个功能点，然后按照一定步骤去验证功能，并且把结果与心里的预期（需求）去比较，把这个过程变成文字，写出来，就是一条测试用例了，简单的说用例就分为，测试条件，测试步骤，预期结果；
6、那测试组的工作如何和别的组配合？研发前期、研发中期和研发后期？
这个问题实际上可以理解为在各个阶段测试如何介入项目；
a)前期，需求期；
i.从用户角度的去思考需求是否合理，是否完备；
ii.与研发约法3章：问题记录同步方式，固件管理方式，研发的测试诉求；
iii.制定测试计划；
iv.梳理初版测试用例；
a)前期，需求期；
i.从用户角度的去思考需求是否合理，是否完备；
ii.与研发约法3章：问题记录同步方式，固件管理方式，研发的测试诉求；
iii.制定测试计划；
iv.梳理初版测试用例；
b)中期：研发期
i.按阶段执行测试，定期反馈分析问题；
i.按阶段执行测试，定期反馈分析问题；
c)后期：稳定期；
拉研发参与测试，稳定性测试，性能测试，测试总结；
拉研发参与测试，稳定性测试，性能测试，测试总结；
7、听说你准备了一个比较详细的测试流程？
这里是我们RM的测试流程，这个已经被优化过了，大家可以直接使用。
8、我们如何通过测试去定位BUG？
BUG定位方法是一门学问，首先，要有几个理念。
理念1：比赛没有玄学，机器人也不会紧张，真正导致出bug的往往是因为测试环境和实际应用环境不一致
举例1：机器人刚开电的时候刷RFID卡距离正常，但每次底盘上电后RFID刷卡距离急剧缩短，看似很诡异，一旦找到复现规律，就方便定位问题，最终发现是因为底盘上电时，电机启动电流较大，而且在RFID安装的位置有电机的电源线和中心板，干扰了RFID模块的运行
总结1：测试一定要尽可能模拟真实环境
举例2：英雄机器人启动失败，有时启动出现取弹机构的控制电机疯转抬起机构，在没有改代码的情况下出现概率从1%逐渐上升到50%（大概2周的时间越来越高），嵌软组小伙伴debug发现启动时偶尔那一路can回出现奇怪的数据导致电机接收到错误数据抬起，后查明是因为板子的一个电容虚焊导致can芯片初始供电不稳定，一旦供电稳定则成功启动通讯正常，如不稳定can就会输出奇怪的数据，重新焊了一遍与can芯片相关的元件后恢复正常启动
总结2：看似玄学的问题，都是有原因的
举例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的，这辈子都不可能的，只能靠甩给机械才能维持生活这样子）
找bug比较简单，定位才难，就像你在家看跳水比赛一样：看似简单，实际上需要很多知识和经验。
举例3：系统性问题
英雄的云台出现零点附近的突然换向，在经验不足的队员看来就是嵌入式的问题，如果嵌入式队员也是经验不多的队员，就会被甩锅，在嵌入式debug时会发现在靠近中间位置时，电机突然会脱离系统旋转一定角度，是因为机械D型槽顶丝松动导致。
举例4：步兵的云台出现开启摩擦轮时云台会抖动，不开摩擦轮一切正常，debug发现在摩擦轮开启时云台会受一个周期性的力矩，这个力矩是两个摩擦轮的转速差异导致的。而该力矩的频率与云台结构的固有频率相近导致共振，并被IMU放大，导致云台宏观上周期震动，对IMU的计算结果使用低通滤波解决。（就像天线上挂块人肉就能解决信号不好的问题）
举例5（可以分一分）：步兵在换了新结构后云台日常震动，看着很难受，在确定两级PID代码都没有问题的时候开启debug模式，对位置环使用不同频率的正玄波进行测试，在查看50hz附近的结果的过程中发现IMU传感器周期性发生突变的现象。最终发现是因为新结构中轴承与云台间连接不紧密导致微小震动，震动传到了固连在云台上的IMU模块造成了IMU角速度突变导致的控制不收敛现象。（本可以拍一拍就解决的问题非要这么麻烦）
总结：一个问题并不是一个点引起的，会涉及多个错误的叠加，比如机械-机械的错误叠加（嵌软是不可能出bug的，这辈子都不可能的，只能靠甩给机械才能维持生活这样子）
9、修复BUG的重点是重现BUG，你有什么重现BUG的秘籍？
主要是下面的几个步骤
1)恢复现场：尽量重现bug出现时的场景
2)分析关联变量：对于比较好复现的问题，分析关联变量比较容易发现问题根源
3)控制变量（排除法）：对于一个稳定的机器人突然出现的，之前没有发生的问题，不要匆忙打开软件撸代码，先尝试换硬件，换线，换机械，换传感器，先排除是他们引起的问题，最后再怀疑软件出了问题
4)多次重现寻找规律
1)恢复现场：尽量重现bug出现时的场景
2)分析关联变量：对于比较好复现的问题，分析关联变量比较容易发现问题根源
3)控制变量（排除法）：对于一个稳定的机器人突然出现的，之前没有发生的问题，不要匆忙打开软件撸代码，先尝试换硬件，换线，换机械，换传感器，先排除是他们引起的问题，最后再怀疑软件出了问题
4)多次重现寻找规律
这里我给大家举个例子。
Bug描述：机器人发射弹丸时，云台抖动，导致弹道不稳；
1）恢复现场，发现每次开启摩擦轮之前云台稳定，开启摩擦轮后，开始逐渐抖动并且加剧；
2）分析出关联变量：是开启摩擦轮，而不是发射弹丸，也不是拨弹机构；
3）控制变量，换一个机器人，同样的程序，发现发射弹丸时，云台不抖动；
说明是硬件和结构引起的问题；分析云台抖动相关的变量：云台PID位置反馈，云台速度环反馈，云台PID输入角度，用jscope 调试，发现开启摩擦轮后云台PID速度环反馈数据周期性抖动，而速度环反馈是陀螺仪反馈的数据，这时保证其他环境不变，更换陀螺仪模块，发现抖动依然存在；至此可以定位问题不在软件，也不在硬件，开始从结构方向去寻找问题产生原因，检查机构是否稳固，最后发现是有一个结构件螺丝松动，摩擦轮开启后，产生共振，导致陀螺仪数据抖动，从而出现bug，最后优化结构件固定方式，解决该问题。
1）恢复现场，发现每次开启摩擦轮之前云台稳定，开启摩擦轮后，开始逐渐抖动并且加剧；
2）分析出关联变量：是开启摩擦轮，而不是发射弹丸，也不是拨弹机构；
3）控制变量，换一个机器人，同样的程序，发现发射弹丸时，云台不抖动；
说明是硬件和结构引起的问题；分析云台抖动相关的变量：云台PID位置反馈，云台速度环反馈，云台PID输入角度，用jscope 调试，发现开启摩擦轮后云台PID速度环反馈数据周期性抖动，而速度环反馈是陀螺仪反馈的数据，这时保证其他环境不变，更换陀螺仪模块，发现抖动依然存在；至此可以定位问题不在软件，也不在硬件，开始从结构方向去寻找问题产生原因，检查机构是否稳固，最后发现是有一个结构件螺丝松动，摩擦轮开启后，产生共振，导致陀螺仪数据抖动，从而出现bug，最后优化结构件固定方式，解决该问题。
10、从哪些方面去测试一个具有完整运动功能的机器人底盘的性能好坏呢？
这个问题可以归纳为有哪些测试方法，实际上就是测试用例的测试方法，下面总结了几个比较典型的测试用例的设计思路。
用例设计方法：
1.点线面：列出被测对象的所有功能点、业务流程，以及整体功能全面应用时产生的需求，设计测试用例；
2.等价类：从实际输入输出中提炼出等价的具有代表性的输入输出，根据输入测试用例；
3.边界值：对输入输出的临界值，单独考虑测试用例；
4.状态机：对状态切换过程，输出状态机，并对每一种状态设计测试用例；
5.流程图：对被测对象的工作流程，输出流程图，并从流程的角度设计测试用例；
用例设计方法：
1.点线面：列出被测对象的所有功能点、业务流程，以及整体功能全面应用时产生的需求，设计测试用例；
2.等价类：从实际输入输出中提炼出等价的具有代表性的输入输出，根据输入测试用例；
3.边界值：对输入输出的临界值，单独考虑测试用例；
4.状态机：对状态切换过程，输出状态机，并对每一种状态设计测试用例；
5.流程图：对被测对象的工作流程，输出流程图，并从流程的角度设计测试用例；
11、我们定位BUG会借助哪些工具呢？
我们可以举一些在数据分析上面用到的方法和工具。一般一个问题发生，第一件事是简单分析后找到可能的源头，确定是哪部分出了问题，大体上分机械嵌软，硬件嵌软
一般机械嵌软纠缠的问题可能不需要改代码就能解决，不过事后一般会加相关的代码来快速暴露机械问题
硬件嵌软的问题就需要比较仔细的调试才能定位，就像上面举的例子一样，前车之鉴是，在没改代码而突然出现问题的时候，先从换板子，换机械，换线路开始（穷人请自觉忽略这段）
在定位问题的过程中，很多时候是需要有数据支撑，需要寻找问题的根源，比如分析通信协议，分析IMU原始数据等，这个时候往往就需要一些辅助工具来提高获取数据的效率。以下是一些常用手段和方法：
一般机械嵌软纠缠的问题可能不需要改代码就能解决，不过事后一般会加相关的代码来快速暴露机械问题
硬件嵌软的问题就需要比较仔细的调试才能定位，就像上面举的例子一样，前车之鉴是，在没改代码而突然出现问题的时候，先从换板子，换机械，换线路开始（穷人请自觉忽略这段）
在定位问题的过程中，很多时候是需要有数据支撑，需要寻找问题的根源，比如分析通信协议，分析IMU原始数据等，这个时候往往就需要一些辅助工具来提高获取数据的效率。以下是一些常用手段和方法：
1) 抓包：使用工具抓出错的数据，通过出错的数据再反查代码定位问题，常用工具有：keil断点和watch窗口，jscope（JLINK驱动自带的曲线分析工具），wireshark（网络抓包），串口助手，串口监听工具（device monitor），或者配上蓝牙串口适配器使用效果更佳。
2) Log分析：如果板子有sd卡等储存器硬件接口，可将关键数据和关联的数据储存到SD卡中，便于离线分析问题，对于需要获取不方便在线调试的数据时，作用非常大。一般的log会包含以下内容
a)时间戳：系统的systick或不同任务的count，有了时间戳就可以依据时间来判断问题是否是周期发生，对进一步确定问题有较大帮助
b)系统状态标志和状态机当前状态：打印状态机便于定位问题出在哪个状态中，是全局问题还是局部问题
c)其他模块的心跳状态：分锅专用，谁写的bug谁来解
d)写一些特殊的状态输出出来，这些状态可能与系统运行无关，但对于debug非常有用，比如一些奇怪的标志位。
a)时间戳：系统的systick或不同任务的count，有了时间戳就可以依据时间来判断问题是否是周期发生，对进一步确定问题有较大帮助
b)系统状态标志和状态机当前状态：打印状态机便于定位问题出在哪个状态中，是全局问题还是局部问题
c)其他模块的心跳状态：分锅专用，谁写的bug谁来解
d)写一些特殊的状态输出出来，这些状态可能与系统运行无关，但对于debug非常有用，比如一些奇怪的标志位。
12、那我们的数据怎么处理呢？
一般选用matlab或python作为辅助分析工具，在分析数量比较大的样本，或与计算紧密相关的bug时起作用；在样本数量较小时推荐使用excel（毕竟一般电脑里都自带不需要装啰里啰嗦的软件），一般的数据处理excel也可以支持。
一般选用matlab或python作为辅助分析工具，在分析数量比较大的样本，或与计算紧密相关的bug时起作用；在样本数量较小时推荐使用excel（毕竟一般电脑里都自带不需要装啰里啰嗦的软件），一般的数据处理excel也可以支持。
13、当然，这里要说明的一点是，Bug很难复现，复现了也说不明白怎么回事怎么办？
一般对于这样的问题，推荐使用录像机（或手机相机）录视频的方法来记录问题（PS：演示时配上录像设备效果更佳），如果实在买不起手机支架什么的话，可以去找大爷翻翻监控，看看能不能找到些蛛丝马迹（你会发现过不了两天门卫大爷就认识你了）
14、刚刚有人问测试可以由哪些专业的？
测控，软件，计算机，电子，自动化相关专业都可以。简单来说就是跟测试对象相关的专业都可以
15、测试中哪个环节更重要？
测试流程中最关键的环节就是测试用例的设计，因为测试执行都是按照事先设计好的用例来执行的，用例的覆盖度保证了测试的覆盖度，所以该环节需要增加多次的评审；另外测试执行是最花时间的环节，对于产品来说，这个环节持续的时间一般是研发周期的2倍以上。
测试流程中最关键的环节就是测试用例的设计，因为测试执行都是按照事先设计好的用例来执行的，用例的覆盖度保证了测试的覆盖度，所以该环节需要增加多次的评审；另外测试执行是最花时间的环节，对于产品来说，这个环节持续的时间一般是研发周期的2倍以上。
16、还没到时间啊,测试算法方面流程是怎么样的？如鲁棒性之类的
算法方面测试流程也是相通了，流程基本不变，不过算法可以采用白盒测试，就是对算法的逻辑进行遍历，一般都可以自己搭建自动化测试平台，思考全面的输入和输出，以及一些异常输入，来逐一验证结果。
算法方面测试流程也是相通了，流程基本不变，不过算法可以采用白盒测试，就是对算法的逻辑进行遍历，一般都可以自己搭建自动化测试平台，思考全面的输入和输出，以及一些异常输入，来逐一验证结果。
17、我想问一下，测试的话涉及的变量比较多，就比如说弹丸发射这一个，同样的电控参数，但是不同的测试时间测，不准确率有非常大的差异，这个怎么分析？
这个就是一个从测试去反推需求的问题了，首先要考虑你的需求是不是要求在任何时间段，任何环境都保持弹丸发射准确，如果需求没问题，而测试出不同环境，准确度不同，那测试主要职责就是暴露出问题，剩下的就是反馈给研发，与研发同学一起定位问题。
这个就是一个从测试去反推需求的问题了，首先要考虑你的需求是不是要求在任何时间段，任何环境都保持弹丸发射准确，如果需求没问题，而测试出不同环境，准确度不同，那测试主要职责就是暴露出问题，剩下的就是反馈给研发，与研发同学一起定位问题。
18、请问有什么上位机软件可以调云台的PID的呢？我们现在云台的PID调得不是很好。
云台的PID，一般可以用无线串口，用串口示波器进行调试；如果有线方式可以用jscope输出波形进行调试
19、测试中的数据分析要怎么做比较好？（重复）
数据分析，可以推荐一些常用的工具。一般选用matlab或python作为辅助分析工具，在分析数量比较大的样本，或与计算紧密相关的bug时起作用；在样本数量较小时推荐使用excel（毕竟一般电脑里都自带不需要装啰里啰嗦的软件），一般的数据处理excel也可以支持。
20、测试阶段，如何让机械的步兵祭天？
这个问题问得好，测试的最后阶段，就要考虑极端环境的测试，如果步兵的应用场景有大量撞击，越野的工况，那么结构定版测试阶段就需要覆盖这些暴力测试，既然是暴力测试，那么机械祭天的概率就会非常大。不过提醒一下，还是要考虑性价比，以及应用场景是否有大量的暴力使用，没时间没钱也用不到就少做暴力测试了。
这个问题问得好，测试的最后阶段，就要考虑极端环境的测试，如果步兵的应用场景有大量撞击，越野的工况，那么结构定版测试阶段就需要覆盖这些暴力测试，既然是暴力测试，那么机械祭天的概率就会非常大。不过提醒一下，还是要考虑性价比，以及应用场景是否有大量的暴力使用，没时间没钱也用不到就少做暴力测试了。
21、比赛现场那么紧张，出现问题怎么做最科学？
辛辛苦苦从家里面把机器人抱过来，放在启动区就不行了？想要避免这样的尴尬情况，除了在家里把机器人哄好之外，还需要在到达比赛现场的时候进行一些必要的测试
推荐各位战队队员在家里面装车检查的时候把检查的项目工工整整的记下来，总结出一份机器人自检表，拿到现场也可以用来检查的，推荐检查以下事项：
a)机械方面：检查一下螺丝在旅途中是不是丢了少了松了，可以对关键的螺丝在拧紧后用记号笔划线做好记号，一旦松动，就可以立即发现；还要注意机器人的卡簧还在么，避震还在么，轮子还在么，麦轮的小胶轮还在么，每个小胶轮还能动么，云台是不是歪了，云台顶丝是否有松动，板子是不是都掉出来了，拨弹轮顶丝是否紧固等等。
b)硬件方面：检查一下板子上电是不是冒烟了，板载的状态指示灯还能亮么，各个模块的通讯还正常么，can电阻还匹配么，在箱子里是不是还找到额外的小电容小电阻了，没有打胶的杜邦线是不是都掉出来了等等。
c)软件方面：当上面机械和硬件检查好了之后，上电查看初始化是不是还正常，各个机构还是不是可控，之前写好的登岛打大符流程会不会因为水土不服就罢工了（笑话，怎么会）。
辛辛苦苦从家里面把机器人抱过来，放在启动区就不行了？想要避免这样的尴尬情况，除了在家里把机器人哄好之外，还需要在到达比赛现场的时候进行一些必要的测试
推荐各位战队队员在家里面装车检查的时候把检查的项目工工整整的记下来，总结出一份机器人自检表，拿到现场也可以用来检查的，推荐检查以下事项：
a)机械方面：检查一下螺丝在旅途中是不是丢了少了松了，可以对关键的螺丝在拧紧后用记号笔划线做好记号，一旦松动，就可以立即发现；还要注意机器人的卡簧还在么，避震还在么，轮子还在么，麦轮的小胶轮还在么，每个小胶轮还能动么，云台是不是歪了，云台顶丝是否有松动，板子是不是都掉出来了，拨弹轮顶丝是否紧固等等。
b)硬件方面：检查一下板子上电是不是冒烟了，板载的状态指示灯还能亮么，各个模块的通讯还正常么，can电阻还匹配么，在箱子里是不是还找到额外的小电容小电阻了，没有打胶的杜邦线是不是都掉出来了等等。
c)软件方面：当上面机械和硬件检查好了之后，上电查看初始化是不是还正常，各个机构还是不是可控，之前写好的登岛打大符流程会不会因为水土不服就罢工了（笑话，怎么会）。
22、说到这里突然想说一下测试工具的事情。
列举能提高测试效率的工具如下：
1)测试用例管理工具 ones testcase等；
2)测试缺陷管理工具：JIRA，禅道等
3)测试提测平台：邮箱等；
这些管理工具都可以对bug进行很好的跟踪。多个项目的测试用例，可以在相应的平台管理，对测试过程还可以顺便做详细的记录，方便追溯；这样机器人的质量和稳定性又可以达到一个新的高度了
列举能提高测试效率的工具如下：
1)测试用例管理工具 ones testcase等；
2)测试缺陷管理工具：JIRA，禅道等
3)测试提测平台：邮箱等；
这些管理工具都可以对bug进行很好的跟踪。多个项目的测试用例，可以在相应的平台管理，对测试过程还可以顺便做详细的记录，方便追溯；这样机器人的质量和稳定性又可以达到一个新的高度了
23、最后用自动化测试内容结束今天的话题：
比赛的开发任务量如此巨大，在某些需要大量测试的场合，我们当然不希望再找队员日日夜夜反复测同一个项目，这时候就要制作一些辅助测试的自动化小工具，比如自动打大符？机器人站在那里，面对大符，就可以打一晚上，当你第二天走进实验室的时候，发现它还在打大符的时候你肯定很开心是吧，为了达到这么一个伟大的目标，你需要设计一个脚本，把机器人和大符连接起来做一个闭环，再弄一个消息记录和通知系统用来告诉你它什么时候停了，机器人是不是已经累到吐血等等，当然还需要一套自动装填机器人，自动捡子弹机器人，调好之后再对这套自动化打大符系统进行稳定性测试（扶我起来，我没死）。总之，一套自动化无敌智能设备可以帮我们从大量的测试中节省人力了。
当然话说回来，要搭建一个稳定的解决上面问题的系统，难度不亚于一个新的比赛，所以这个时候就需要评估自动化的资源成本，在现有资源条件下，去做一些自动化的测试。
经过上面几个步骤，相信每个队伍的机器人都可以稳定高效打大符了，接着就又到大家喜闻乐见的改规则环节了。
比赛的开发任务量如此巨大，在某些需要大量测试的场合，我们当然不希望再找队员日日夜夜反复测同一个项目，这时候就要制作一些辅助测试的自动化小工具，比如自动打大符？机器人站在那里，面对大符，就可以打一晚上，当你第二天走进实验室的时候，发现它还在打大符的时候你肯定很开心是吧，为了达到这么一个伟大的目标，你需要设计一个脚本，把机器人和大符连接起来做一个闭环，再弄一个消息记录和通知系统用来告诉你它什么时候停了，机器人是不是已经累到吐血等等，当然还需要一套自动装填机器人，自动捡子弹机器人，调好之后再对这套自动化打大符系统进行稳定性测试（扶我起来，我没死）。总之，一套自动化无敌智能设备可以帮我们从大量的测试中节省人力了。
当然话说回来，要搭建一个稳定的解决上面问题的系统，难度不亚于一个新的比赛，所以这个时候就需要评估自动化的资源成本，在现有资源条件下，去做一些自动化的测试。
经过上面几个步骤，相信每个队伍的机器人都可以稳定高效打大符了，接着就又到大家喜闻乐见的改规则环节了。
24、一般的暴力测试都是在测试些什么，比如测试耐撞性或者一些其他的？
就是极端环境，不仅仅是撞击，比如数据通讯的时候也是极端环境：可以给它多于正常数值几十倍的信息；比如视觉方面可以给它极端的视觉环境和激光干扰之类的
就是极端环境，不仅仅是撞击，比如数据通讯的时候也是极端环境：可以给它多于正常数值几十倍的信息；比如视觉方面可以给它极端的视觉环境和激光干扰之类的
关联专栏
RoboMaster 课程沙龙
文章标签
请问这篇文章对你有用吗？
「2019」「RM圆桌」第二期 我们要搞测试