共计 4503 个字符，预计需要花费 12 分钟才能阅读完成。
作者 / 刘哲
编辑 / Ryan
起源 / 有道技术团队（ID: youdaotech）
引言
当咱们提到智能硬件的高效测试时，通常会思考应用自动化测试的计划，晋升产品的测试效率和品质。
因为智能硬件的应用过程中，包含了大量和用户的行为交互，这就导致在测试计划上，传统的软件自动化测试很难齐全模仿用户的残缺应用行为。
因而，咱们除了要思考借鉴和应用软件测试的思路之外，还要思考如何实现硬件测试自动化。
一、背 景
有道词典笔 2.0 是网易有道自研的学习型智能硬件。
有道词典笔搭载了有道自研的 OCR、NMT、TTS 技术，为用户提供了一扫查词、中英文互译、语音助手、触屏、离线等性能。
当咱们拿到词典笔 2.0 第一个版本的时候，首先看到的是它的 硬件外观：
从硬件层面来看——
它包含了一块可触摸的屏幕，接口方面应用了 Type-C 计划，在下方有一个摄像头，反面有喇叭能够发音，按键方面有开关机、功能键和笔的触头。
同时在设施的外部还内置蓝牙和无线模块。
这个产品如何应用呢？用户的典型应用场景是：
手持有道词典笔，向下按压笔头开启补光灯和摄像头，在文字上方滑动，实现对文字的拍照。之后图片合成，进入 OCR 模型，辨认出文字后，进入 NMT 模型，最初翻译后果展现进去，进入 TTS 服务。
所以，简略来说，它是 以扫描辨认行为为根底操作，实现若干性能的一款硬件产品。
当初咱们晓得软件方面的能力了，这时候就能够联合硬件一起来思考，有道词典笔的高效测试要怎么做。
二、让硬件动起来
咱们对一款产品做自动化测试，首先要找到用户的次要应用门路。
用户花了最多的工夫应用的行为，就是咱们须要花精力去思考如何模仿的行为。
很显著，在这里用户的扫描行为引发的查词和翻译学习后果。
那咱们就来看看，用户的实际操作是如何的。
咱们对用户扫描的场景模仿，能够分成两个局部。
一个局部是对词典笔的管制，稳固的握持，另外一部分是 对笔的挪动。
在思考实现这样的计划时，咱们思考过市面上现有的自动化计划，来实现对笔的固定和挪动。
然而碍于老本和可复制性并不适合，所以没有采纳。
让词典笔从左向右挪动起来这件事件，是整个行为的难点。
那是否能够让词典笔不动，也实现一样的扫描成果呢？
咱们决定换个思路。
咱们让 笔不动，文字从右向左挪动，从而模仿笔从左向右挪动的成果。
为了能够继续的测试，还须要文字再从左向右回来，而后再次从右向左。
当它成为一个循环的时候，就实现了继续的文字挪动。
大家看这样静止的文字像是什么？
咱们的第一反馈就是 传送带，就是工厂里见到的流水线上的挪动，所以咱们做了第一套计划。
咱们把文字固定在传送带上，而后用电机驱动传送带，实现了文字的继续挪动。
当文字能够稳固挪动之后，咱们通过 shell 去管制词典笔的扫描行为，包含了开关笔头灯、开关扫描行为等等。
而后咱们能够把设定工夫内的扫描内容传送到笔内的翻译引擎中，进入后续的翻译和发音流程。
文字动起来了，那让词典笔固定就绝对容易一些。
咱们做的第一个尝试是应用市面上曾经有的支架，把词典笔固定在支架上方，大家能够看下视频。
能够把笔夹住，间接固定在传送带上。
然而咱们也发现了一个问题，支架每次只能固定一只笔，而且稳定性并不佳。
咱们看这个视频也能看进去，始终在晃，这个成果只能说是能用。
而且咱们方才也提到了，在测试的过程当中，通常是须要让多支笔固定的。
所以咱们尝试本人做了一个支架，把 N 支笔固定在传送带上方，这样，咱们就能够实现用户扫描行为的残缺模仿了。
这是咱们对词典笔高效测试的第一次尝试，就是让硬件动了起来。
三、让计划更稳固
接下来咱们要解决的问题是，让计划更稳固。
为什么有这样的需要呢？
在很长一段时间，咱们都在应用下面提到的计划。
咱们通过这套计划实现了性能稳定性的测试，对功耗以及电池曲线等都做了上百次的验证。
然而随着咱们测试版本的减少，咱们迭代的放慢，自动化测试的需要更加频繁了。
在应用过程中，咱们看到影响文字挪动的稳定性，也就是传送带的稳定性因素是挺多的。
比如说电机老化，传动轴稳定性了，组装的精细水平，都可能会造成它文字转动时快时慢，甚至有的时候会停下来。
另外咱们的后期一次能够去测试 6 支笔，然而到了前期，咱们的测试版本的减少同时要测试的笔可能靠近 20 支。
这个计划的改良就提上了日程。
咱们还是分成文字的挪动，以及笔的撑持两个局部来改良。
文字在垂直往复运动，这个计划咱们应用的是传送带。
如果文字在程度方向往复运动呢？
咱们察看了生存中很多的物品，最初发现小朋友喜爱的钓鱼玩具是一个不错的抉择。
就是这个。
首先它的转速是恒定的，它在设计决定了影响它速度的因素，只是电机自身。
另外它的性价比比拟高，这就使得咱们能够疾速的复制和裁减测试能力。
如果咱们把文字在转盘边缘排列，而后容许静止，是不是就能够造成相似挪动的成果呢？
为此，咱们在文案上进行了肯定的设计和改良。
咱们把文字做了弧形的排版，固定在转盘上，在转盘的边缘固定测试笔，持续应用之前的自动化脚本。
这样就实现了用转盘的计划来实现扫描的行为模仿。
尽管它整体是个弧形的样子，然而得益于词典笔的算法优化，咱们理论的拼图成果还是比拟优良的，对于测试测试没有什么影响。
最初咱们去改装了它的供电形式为电源供电，这样它就能够长时间的做一个测试了。
接下来咱们要解决的就是词典笔的 撑持改良。
最开始是用硬纸来制作的繁难的支架，这仍旧是个 扩展性不佳 的计划。
随着咱们的前期的调整和改良，咱们在设计的同时帮忙下，做了一个支架的改良版，通过建模和 3D 打印的形式就把它生产进去了。
这样的话它足够精细，同时它撑持 10 支笔的测试，而且他能够疾速的复制，裁减给其余须要测试的场合。
这是咱们理论 3D 打印进去之后的产品：
这就是咱们在目前测试应用的计划，到这里咱们看到整体硬件自动化曾经比较稳定了。
四、让管制可近程
当初咱们要思考的事件，就是让管制能够近程。
咱们在硬件测试上做的计划，本来都是在公司进行的，测试的设施也都是 QA 外部团队在用。
然而今年年初的疫情扭转了咱们的工作形式，在很长一段时间里咱们都是在近程办公。
为了不便让开发人员更不便去调试，也为了让不便异地工作的共事们能够随时的进行测试，还有就是心愿咱们的测试计划的可控性更强，咱们开始在做一些可控性方面的摸索。
整体来说让管制能够近程这件事，咱们分成了 5 个指标。
首先，是咱们的测试脚本能够近程开启和敞开。
第二，是咱们须要可能管制硬件的开关，次要是转盘的开关和供电系统的管制。
比方在静止的时候就能够开启转盘，测完之后就能够敞开转盘。测试功耗之前给词典笔充电，测试开始要断开供电。
第三，是须要满足开发人员在家进行近程调试的这样一个需要。
在家办公的时候，咱们和开发不是同一个网络，甚至不是同一个城市，那开发如何疾速进入词典笔外部进行调试呢？
第四，咱们心愿整个测试过程是能够被看到的，咱们能够通过视频的监控来确定它的测试状态。
最初，因为测试自动化实现了大多数的我的项目后，咱们须要对测试过程中的数据进行跟踪，测试过程中的数据保留与展现也不可获取。
所以基于这 5 个指标，咱们设计了上面这套测试框架。
大家能够看到整个 零碎架构 如下。
首先咱们引入了一个主机或者叫控制系统，这里是用树莓派 4b 来做的。
在树莓派上咱们连贯了一个摄像机，采纳了 mjpg-streamer 的计划，开了一个 web 的监控服务，这样测试人员能够随时去察看咱们的词典测试的运行状况。
而后在树莓派的 GPIO 上，连了一个 L298n 的一个芯片，通过 python 咱们能够应用芯片对电机开关和速度进进行管制。
之后咱们又连贯了一套继电器，用来对词典笔的通断电进行管制。
为了实现内网转发穿透的能力，咱们搭建了一个 ngrok 服务，而后在测验词典笔启动它外面去，这样就能够从任何地位 ssh 到词典笔外部。
为了不便咱们去察看数据和判断后果，咱们应用了 influxdb 来保留测试中产生的数据，应用 grafana 来展现后果。
所以有了这样一套服务之后，开发产品和测试都能够实时的去用它。
这里咱们有一个简略的演示视频。
咱们外网通过 ngrok 服务近程，开启测试服务，而后开启转盘运行，这时测试开始。
测试中的视频就是通过树莓派的摄像头传输回来的。
当测试完结后，通过同样的形式，咱们能够敞开或者持续进行其余的测试。
咱们做了第三局部，让管制能够近程之后，咱们基本上实现了一套框架。这套框架把咱们用户最外围的操作，也就是扫描，变得能够自动化，能够近程管制，它能够稳固的近程管制。
五、让性能自动化
最初咱们咱们再来说说性能自动化的事件。
为了晋升局部测试用例的自动化水平，咱们还尝试做了一件事件，就是让性能自动化。
因为咱们的产品是基于 Linux 加 QT 的架构实现的，为了晋升它的测试效率，咱们心愿能够把外围软件性能自动化。
然而通过调研，市面上目前并没有足够成熟稳固的自动化测试计划适宜咱们。
咱们通常说的自动化，大略的流程是先做控件的辨认、再对控件做操作，而后对控件做校验。
在没有比拟好的计划的前提下，咱们用了一个“曲线救国”的自动化计划。
有道智云提供的 OCR 服务，能够针对图片上的文字进行辨认。
它能够提取图片上的文字，并给出对应的坐标。
所以咱们做的是：
01
用截屏加有道智云的 OCR 辨认性能，实现了对文字的定位，代替了对控件的辨认，例如“查词”，给出是否存在以及坐标地位。
02
用零碎的操作，针对下面定位的坐标去点击、滑动等，实现了相似对控件的操作，例如点击“查词”的坐标。
03
最初咱们还是用截屏，加上智云 OCR 辨认，对页面的内容进行判断，例如对查词后果的验证。
这样就实现了根本的元素操作和管制。
咱们就这样，把用户行为的自动化，设计并实现进去了。
上面的视频演示了咱们采纳该计划，全自动进行 OTA 降级测试的过程。
失常状况下，OTA 测试须要一名全职测试工作 8 小时，来实现 30 轮次降级的验证。
有了自动化的计划，这个过程实现了无人值守测试，每晚能够实现 50-100 轮次的验证，第二天测试人员只须要查看测试过程的记录即可。
六、总结
通过下面的这些步骤，咱们基本上对有道词典笔 2.0 的用户最外围操作——扫描后划词翻译，实现了软件和硬件方面的自动化。
通过硬件和软件联合的自动化计划，咱们失去的 收益微小：
>> 大幅晋升了测试效率：
单个版本须要 120+ 小时的测试数据，包含但不限于功能测试、主性能稳定性测试、随机稳定性测试、功耗测试、充放电电池曲线测试、耳机稳定性测试、耳机兼容性测试、OTA 测试等等；这些测试 85% 能够通过以上的测试框架来自动测试，咱们单个版本的测试 只须要 2 - 3 天，1- 2 人即可实现。
>> 明确了产品质量：
咱们针对每一项测试设计了不同的质量指标（例如功耗分成 12 种场景，测试时在不同场景下进行验证），得出的后果和之前版本或者竞品进行比照，从而判断咱们产品的品质好坏。一个版本会有上百个指标，而这些指标就通知了咱们产品是否能够上线，产品的品质到底如何。
>> 帮忙发现硬件生产过程中的品质问题：
某个版本在两个批次的硬件测试中，同样的测试脚本和测试计划，测试进去的数据差别显著。通过多轮次的验证，对硬件的拆解等判断，最终定位某电阻混件造成了差别，因为咱们提前发现了这个问题，尚未实现生产的产线复工，防止了更大的损失。
—— END ——
