硬件测试的思考和改进:有道词典笔的高效测试探索
作者/ 劉哲; 編輯/ 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測試需要一名全職測試工作8小時,來完成30輪次升級的驗證。
有了自動化的方案,這個過程實現了無人值守測試,每晚可以實現50-100輪次的驗證,第二天測試人員只需要檢查測試過程的記錄即可。
六、總結
經過上面的這些步驟,我們基本上對有道詞典筆 2.0 的用戶最核心操作——掃描后劃詞翻譯,實現了軟件和硬件方面的自動化。
通過硬件和軟件結合的自動化方案,我們得到的收益巨大:
大幅提升了測試效率:
單個版本需要120+小時的測試數據,包括但不限于功能測試、主功能穩定性測試、隨機穩定性測試、功耗測試、充放電電池曲線測試、耳機穩定性測試、耳機兼容性測試、OTA 測試等等;這些測試85%可以通過以上的測試框架來自動測試,我們單個版本的測試只需要2-3天,1-2人即可完成。
明確了產品質量:
我們針對每一項測試設計了不同的質量指標(例如功耗分成12種場景,測試時在不同場景下進行驗證),得出的結果和之前版本或者競品進行對比,從而判斷我們產品的質量好壞。一個版本會有上百個指標,而這些指標就告訴了我們產品是否可以上線,產品的質量到底如何。
幫助發現硬件生產過程中的質量問題:
某個版本在兩個批次的硬件測試中,同樣的測試腳本和測試方案,測試出來的數據差異明顯。通過多輪次的驗證,對硬件的拆解等判斷,最終定位某電阻混件造成了差異,由于我們提早發現了這個問題,尚未完成生產的產線停工,避免了更大的損失。
網易有道,與你同道。有道技術團隊眾多崗位招聘中,歡迎聯系我們,投遞簡歷~
總結
以上是生活随笔為你收集整理的硬件测试的思考和改进:有道词典笔的高效测试探索的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 【数据结构】--队列之循环队列
- 下一篇: PS简单入门须知的小技巧