智能座舱测试——数据驱动开发的语音测试方案

背景

本文章只涉及思路,不涉及具体技术实现

不知不觉已经做语音云端测试已经有段日子了,从刚开始关注语音识别到后面关注技能话术,到现在的用户话术的分析并进行话术泛化的扩展,语音也在不断地改善和优化,但是最终还是要结合用户体验的话,我们还要关注的部分更多,比如包括但不限于下面几点:

  • 识别正确性
  • 识别流畅度
  • 语义正确性
  • 语义响应速度
  • 数据的兼容性
  • 服务的稳定性
  • 服务的并发量
  • 技能的使用占比
  • 技能的高频话术

基于以上,为了更好的用户体验,需要依赖一定的数据支撑,所以需要分析生产环境的数据信息来提取我们的服务情况,进而找到需要优化的方向,需要制定一套测试方案来满足以上需求。也就是接下来要提到的DDD(数据驱动开发)的测试方案。

面向对象

数据驱动测试所面向的部分主要分为两类服务:

  • 识别服务
  • 技能服务

数据准备

既然是数据驱动,需要什么样的数据呢?需要什么样的数据就先看一下我们要关注的内容而定。接下来针对在背景部分提到的几点一个个的分析所需要的数据内容。

  • 识别正确性

目的:针对用户语音交互识别的正确率和特定名词识别的正确性
数据:用户的话术和话术对应的音频文件,歌曲,歌名之类的数据集的识别
描述:可以通过服务器拉取脱敏后的用户话术和音频文件,也可以通过语音合成方式进行特定方言,语速,语调的音频合成

  • 识别流畅度

目的:验证识别文字上屏的间隔,不应该超过400ms(具体根据识别引擎的反馈模式而定)
数据:识别结果反馈给终端的间隔时间
描述:识别反馈间隔是用户体验识别是否流畅的重要数据指标,通过分析实时日志和自动化方式主动发送音频流,统计识别反馈时间差

  • 语义正确性

目的:在验证针对相同意图的不同说法,是否能够进入到对应的技能并返回正确的语义或者内容
数据:用户的说法和技能应该返回的语义或者内容结果,需要内容支撑的数据集(音乐名,歌手,POI点等)
描述:不仅要验证能够进入到正确的技能中,还要验证在技能中能够做到正确的操作,且需要支持用户的不同的泛化说法

  • 语义响应速度

目的:验证服务端对请求文本的理解所消耗的时间,该数据也是影响用户体验的重要数据
数据:服务端收到文本请求到响应发送给终端的时间间隔
描述:生产环境日志中的识别结束到结果发给终端的时间间隔,也可以同通过自动化方式发送文本请求并统计请求和响应之间的间隔

  • 数据的兼容性

目的:验证基于内容的技能对数据内容的提取的正确性
数据:歌名,歌手,节目,POI
描述:通过爬虫技术获取需要的数据并通过自动化方式进行验证

  • 服务的稳定性

目的:实时监控服务的业务运行,服务器资源占用和异常告警
数据:服务器资源信息,技能处理的成功率
描述:分析生产环境日志信息和模拟用户主动发送请求并验证响应信息

  • 服务的并发量

目的:实时监控并测试用户并发量并参考数据进行扩容或缩容(尤其是小长假前后)
数据:服务的实时的并发数据(识别并发,语义并发)
描述:通过分析生产环境的实时数据,根据不同项目区分每个项目的并发数

  • 技能的使用占比技能的高频话术

目的:明确用户常用技能和用户的常用话术,作为冒烟测试话术
数据:技能数据和话术数据
描述:通过分析生产环境数据

技术需求

根据数据准备中所提到的信息,把所需要的技术分为以下几部分:

  • 数据爬虫

python
requests

  • 数据分析

python
pandas

  • 测试验证

java
junit
python
pytest
allure

  • 数据存储

mongodb
minio

  • 服务监控

grafana
influxdb

  • 基础设施服务

docker
jenkins
loki
grafana
minIO
Influxdb
mongodb

测试任务

数据已经梳理好了,接下来是该如何使用这些数据,就要结合我们的研发模式,通过研发模式来决定我们的测试模式。

  • 冒烟测试
    主要针对版本发布的测试验证工作,依赖于高频技能和高频话术的用例数据,进行版本发布测试。
    冒烟测试工作不仅包含了文本请求还包含了语音识别,只是语音识别的版本发布不频繁,频率不会那么高
  • 泛化测试
    针对通过生产日志提取出来的用户有效话术统一加入到测试数据中,并作为全量的测试用例集。保证用户说的话术且有明确意图的要95%的覆盖率。
  • 数据集闭环测试
    通过参数化测试,引入爬取的数据集中的数据,并验证数据的提取是否符合预期,针对部分技能可以通过终端设备的操作,自动上传数据并完成数据集的自学习,针对不能正确提取的数据,通过结合终端操作上传数据,再次使用即可正确提取,从而形成数据集的闭环。
  • 稳定性测试
    通过7*24h任务,模拟用户和服务端交互并统计时间,正确率等信息,针对异常情况进行飞书告警通知
  • 服务监控
    通过实时分析生产日志并收集技能的正确率占比,并发量,资源占用等信息,针对不同的数据设定相应的阈值,超过设定阈值,触发飞书告警。

测试基础设施

研发的数字化转型离不开持续测试,持续测试离不开测试服务的支撑,自动化基础设施的相关文章可参考另一篇博客自动化测试基础设施——介绍

附录

附上之前整理的思维导图
在这里插入图片描述

  • 1
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值