DIY自动化测试【智能音箱】

导语 说到自动化测试,有些同学可能觉得有门槛。本文介绍智能音箱测试中,全员均可自由DIY自动化用例的一种方式。

    笔者从事智能音箱系统测试,这是一款基于android系统的智能语音助手产品。基本功能特性和测试方法都已稳定,目前多产品快速迭代,涉及的场景较多且数据量大,例如不同场景下的灯效多达四五十种,每一种灯效又包含十多项参数,靠人工检查成本较高(时间、人力等),繁琐又易出错,且无法做长期稳定性测试,适合采用自动化来对更新的版本做基础验证。

一 整体设计思路

整个自动化测试分成三部分,流程如下:

完整流程

脚本用python实现。

    1:检测RDM版本并升级设备,这里用socket与服务器建立连接,当版本构建完成后,按约定把版本号及版本路径传回,若版本号大于当前版本号,下载版本、解压并升级;

    2:升级重启后,按照测试用例进行测试;

    3:测试完成后,利用TOF邮箱服务把报告汇总发给预设的相关人员;

对于大部分同学来说,可以注释掉第1和第3的操作函数:

脚本修改

只执行功能自动化测试,如下重点描述。

二 功能自动化

2.1 设计思路

整个设计主要基于如下几项思考:

脚本与用例分离:参与此项目的测试同学大多无编程基础,要让大家都能玩转自动化,一个重要的原则是脚本与用例分离。测试人员只需要关注和维护用例,若有功能变更(例如唤醒词、TTS、灯效等),只需同步修改用例中对应部分的内容。

确定测试场景并抽离实测设备:音箱是一种人机交互设备,操作场景主要是下发语音指令和按键操作,需要借助辅助设备来模拟人的角色,同时音箱也有配套的APP,因此用手机做为辅助设备,满足大部分测试场景。把手机和音箱的SN号抽离出来,音箱代号“A”,手机代号“B”,设计用例时区分音箱和手机,实际测试时再配置被测音箱和手机SN,自动化脚本负责将逻辑的“A/B”通过ADB分别定向下发到具体的设备,同时可支持多脚本并发运行。

明确的输入输出:对智能音箱的操作主要有两类:按键和语音,同时,一个确定的操作均对应一个清晰的输出。输入可以用adb下发,输出主要分灯效、音效、TTS、媒体源及各种状态,这些信息在日志中都是确定的。

灵活选择测试用例:测试人员多且每人负责不同的模块。需支持所有人共用一份用例。每条用例需有flag标识是否执行,测试人员只需配置自己负责的模块用例;同时,也支持一个用例的循环压测;

结果方便统计与保存:每一个用例有明确的测试结果,“OK”或“NG”,并列出失败原因。基于excel强大的数据筛选整理能力以及python对excel的完善支持,excel是无二选择。

环境搭建如下:

组网环境

对应用例设计如下:

用例设计

“Enable/Command/Check Point”这三列为必填项,其他项不填也不影响测试结果,为了用例可读性及完整性,最好各列均补充。各字段含义如下:

"Enable":是否测试此用例,可选“Y/N/F”,“Y”表示用例被执行,“N”表示用例不被执行,“F”为flag,可以在脚本中定义某些配置;

“Test Number”:用例编号,每个用例都有唯一的一个编号用以标志,当测试不通过时,会根据编号和时间生成对应日志;

“Test Level”:用例优先级,分“A/B/C”三个级别,当测试策略为“详细测试”时,选择三个级别用例全部执行,当测试策略为“基本功能验证”时,只执行“A/B”用例,当测试策略为回归测试时,只执行“A”级别的用例;

“Test Name”:自定义测试标题;

“Test Step”:详细列举测试执行步骤;

“Command”:各步骤中操作对应的测试命令,用“A/B”来区分“音箱/手机”;

“Command Check”:执行命令后检查命令是否下发成功;

“Check Point”:用例检查点,例如键值、灯效、音效等,分行陈列,用“dmesg”或“logcat”区分是在哪个系统中查看日志;如果结果有多种可能,用“|”分开;

“Test Result”:测试结果,如果全满足“Check Point”则标注“OK”,否则"NG",对于“NG”的用例,记录日志;

“Error Info”:如果用例执行失败,会把“Check Point”中不满足的条件列举出来。

脚本可配置测试循环次数,大体流程如下:

用例执行流程

2.2 问题优化

    上面这个流程有诸多的问题及考虑不周的地方,列举一些优化项。

2.2.1 提高识别率(输入)

    受测试环境及场景影响,语音指令的识别率比较低,影响测试结果的准确性。从两方面进行了优化,第一,下发配置后添加检查,通过日志检查配置有没有下发成功,如果音箱没有识别到准确的指令,重新下发一遍(不超过三次);第二,降低环境噪音,一方面屏蔽室录音,提升音源的准确度,另一方面降低音箱自身音量,提升唤醒灵敏度。优化后因为未识别而导致结果失败的用例减少了约80%,但无法杜绝。

    智能音箱的语音交互流程如下,ASR(Automatic Speech Recognition)识别语音后,经NLU(Nature Language Understanding)处理,以文字反馈给音箱中控。用文本来代替语音,是跳过ASR识别的另一种思路。(ASR及NLU另有专项测试)

语义处理流程

    提了一个测试需求给开发GG,完美的解决了这个难题。不仅完全杜绝了误识别问题,也极大提升了测试效率,每条涉及语音的用例至少优化了十秒钟,更新唤醒词、重新录制音频这些复杂的流程也都完全不是事了。有个小缺陷:和少数涉及语音输入的用例会有冲突,例如留言功能,还是得用之前的录音方式。流程对比如下:

文本代替语音

2.2.2 提升日志可靠性(输出)

    通过上面这些方法,“输入”能确保执行到位。输出主要是查看日志。系统层面的日志记录在内核中,通过dmesg或cat proc/kmsg查看;应用日志通过logcat查看。logcat中也包含有灯效,但不全面,所以灯效统一用dmesg。在excel的“Check Point”中,通过区分“dmesg”及“logcat”在对应日志系统中check。

    测试中随机出现日志丢失问题。进一步查找发现LOGCAT是以环形缓冲区存储数据流,分为main,events,radio,system四个环形结构,其中每个buffer大小是256kb。同步打印日志是没有问题的,当加大buffer大小,例如4M后,日志丢失的问题也消失,确定就是由于buffer引起。在每条用例执行的时候,删除日志,并修改日志保存的方式,利用管道将操作日志同步输出至电脑。应用日志保存在main中,完整的方式为adb logcat -v time -b main。

2.2.3 测试结果随时保存

    如果用例跑到最后才保存测试结果,可能会由于异常或中途中断而白跑。修改为每跑一条用例就保存excel表格。同时,对于测试fail的用例,红色标出,并完整记录logcat及dmesg供后续分析。由于每一条用例可能执行多次,执行失败的日志以列名、时间、用例编号来唯一标识,方便查阅。

测试结果

2.2.4 用例设计上的优化

遵循几个原则:

  1. 各个用例之间要尽量解耦,避免因为一个用例执行失败或未执行而影响另一个用例或整个用例的测试结果;
  2. 各个用例的预期应该完整且明确,例如播放音乐过程中设置闹钟后唤醒设备,灯效应包含唤醒灯效、语义处理灯效、TTS灯效,领域状态包含音乐暂停、闹钟设置、TTS唤醒打断、音乐重新播放;
  3. 纯按键用例无需“Command Check”,涉及语音输入的用例建议填写,写关键字就可以。

优化后的流程如下:

优化后的流程

三 效果对比

对比项

人工

自动化

备注

执行用例时间

120条用例/人天

50分钟

可利用晚上进行

人力成本

生成用例10分钟每条,执行4分钟每条

生成用例10分钟每条,执行接近无

大部分用例长期反复利用

人为失误率

较大

长期稳定性

无法进行

可自动执行

欢迎大家提供宝贵意见!

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java社区

十个Java实战开发中必备的小策略

为什么开发要用GIT呢?因为要给自己一颗后悔药吃。只要经常commit,文件就可以随时回退到某个时刻的内容,再也不担心别人改了自己的文件,自己误删了文件,特别是...

2857
来自专栏韩伟的专栏

经典软件架构模式(三)

REST模式 让我们回到服务器端开发。一直以来,互联网服务就以数据互通为最重要的业务特性。我们来看看一个微博系统的案例。 ? 【此案例并非完全真实情况,有一定提...

2887
来自专栏极客猴

这个 Github 仓库因你而精彩

我于今年 6 月份创建自己微信读者群。群组人数从一开始零星几人到现在的两百多号人。群里面的小伙伴都非常好学,经常来群里面讨论技术问题。我自己从中学到很多知识,也...

822
来自专栏Linyb极客之路

面对峰值响应冲击,解决高并发的三大策略

在写这篇博客的前2天,听说某系统在25人的用户量下就宕机了,实在让人震惊,所以捋了下互联网交易系统我们可以采取哪些技术来解决互联网平台下大数据量高并发的问题。

923
来自专栏编程一生

美团点评智能支付核心交易系统的可用性实践

每个系统都有它最核心的指标。比如在收单领域:进件系统第一重要的是保证入件准确,第二重要的是保证上单效率。清结算系统第一重要的是保证准确打款,第二重要的是保证及时...

1573
来自专栏Coding01

我是这么制作「coding01 日报」的

「coding01 日报」为大家每日推送不错的技术帖子,欢迎大家查阅。今天这篇文章的内容是,如何利用 「Workflow」搜集素材和制作每天日报的雏形。

901
来自专栏资深Tester

怎样才能提交一个让开发人员拍手叫好的bug单

1493
来自专栏美团技术团队

美团点评智能支付核心交易系统的可用性实践

1707
来自专栏张善友的专栏

关于MongoDB你需要知道的几件事

Henrique Lobo Weissmann是一位来自于巴西的软件开发者,他是itexto公司的联合创始人,这是一家咨询公司。近日,Henrique在博客上撰...

1649
来自专栏包子铺里聊IT

深入浅出系统设计面试——Design Twitter Timeline

如何 design 一个 Twitter 类型的系统,尤其是其中的 timeline/tweets 的部分,这是很多朋友都会在面试中遇到的问题,包子君今天与大家...

6097

扫码关注云+社区