首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >DIY自动化测试【智能音箱】

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

原创
作者头像
Apan
修改2018-06-29 11:58:15
2.6K0
修改2018-06-29 11:58:15
举报
文章被收录于专栏:自动化测试自动化测试

导语 说到自动化测试,有些同学可能觉得有门槛。本文介绍智能音箱测试中,全员均可自由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分钟每条,执行接近无

大部分用例长期反复利用

人为失误率

较大

长期稳定性

无法进行

可自动执行

欢迎大家提供宝贵意见!

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

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

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

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

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一 整体设计思路
  • 二 功能自动化
    • 2.1 设计思路
      • 2.2 问题优化
        • 2.2.2 提升日志可靠性(输出)
        • 2.2.4 用例设计上的优化
    • 三 效果对比
    相关产品与服务
    腾讯云小微
    腾讯云小微,是一套腾讯云的智能服务系统,也是一个智能服务开放平台,接入小微的硬件可以快速具备听觉和视觉感知能力,帮助智能硬件厂商实现语音人机互动和音视频服务能力。
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档