写在前面
本人2017年加入国内新能源车龙头，负责车载语音对话系统的测试工作，和团队构建起一套适合业务迭代的测试方法。最近有些欲望把这个过程中的心得体验分享给有缘人。
说一个前提，也是一个经典解释：测试工作就是质量和成本博弈的结果，所有任何测试都需要考虑性价比。
有一个限制，不清楚会不会涉及到信息泄漏，不能绘制流程图和系统架构图，望各位理解。
系统组成
我了解的车载对话系统通用的解决方案为车机端的服务和APP族（包括语音识别服务，ASR下同），车机操作系统，车机网关和车联网云端网关，云端对话系统，自然语言理解（NLU，下同）模型，运营系统，大数据服务，其他垂直类应用服务（例如负责地图和导航GIS、媒体搜索）等。
/*
下面是插入的内容
规则：可以简单认为是正则匹配，例如“(|查询)*天气”可以匹配到“查询北京天气”“查询天津天气”“哈尔滨天气”等。但随着功能越来越多，规则会更加复杂，也可能产生规则之间的冲突。
模型的产生流程为：
- 需求分析
- 模型体系设计
- 收集数据（语料）
- 标注，审核
- 迭代2～4，理论上迭代越久有效数据量越大，后续生成模型效果越好
- 使用标注好的数据，通过机器学习，训练模型
- 系统集成
- 测试
- 通过验收上线
可以看到，模型的迭代周期从逻辑上就很长，但是由于模型可以完成类似“收集1w数据，对10w乃至更多同类型但不同的输入能达到99%的准确率”的效果，性价比还是比配置规则高。所以大家都会优先考虑用模型代替规则。
*/
对话系统作为AI类复杂系统，各模块迭代频率不尽相同，对测试的要求也不尽相同。下面就从两个维度进行以下简单的分析。
测试分类
一般性工程类测试关注功能实现和性能指标，可以认为解决“对不对”的问题。
NLU、ASR等算法类更关注的是效果指标，可以认为解决“好不好”的问题。对这个点举个例子方便理解
- query=查询北京空气质量，一般NLU模型会对这个query做一些意图和主要元素的分析，分成domain=weather（天气），intent=query_index（查询指数），slot=[北京-location，空气质量-index]，其中“查询”是否被识别一般认为对结果影响不大。
- 一个“正确”的算法结果，是domain、intent、slot全部正确，而部分错误，比如“北京”没有识别出来，则不能完成“查询北京空气质量”的工作，可以认为“不正确”。但是算法关心的并不只是这一个query的问题，我们不能用“少量”query的处理结果去判断算法的“对与错”“好或者不好”。
- 如果我们的“需求”中对查询空气质量的定义可以限定为，1、查询国内不低于县级行政单位的空气质量，2、当查询的区域属于某县/市行政单位的空气质量，3、不支持非直辖市省级及以上对象，4、不支持国外区域的查询，且明确了有限个句式（类似于[NULL|查询][location][空气|空气质量]）则我们可以通过穷举和边界值方法构造测试数据集合，虽然这个测试集合数量很大，但毕竟是有限集合，可以通过测试脚本穷举完成测试工作。
- 一般ASR的效果测试，我们分成句准、字准和端到端意图正确率的方式来统计测试结果。
由于车载对话系统需要考虑网络和车机算力有限等问题，一般会将车机端算法模块做成云端算法的一个精简版，相对低频迭代，而云端支持随时上线新功能，更新频率相对更高。
各模块重点关注
根据系统构成和测试分类，我们可以推导出不同模块测试工作的侧重点。
- 云端服务：通过接口提供给前端APP及服务调用。云端工程类。
- NLU模型：向云端服务提供接口服务，一般分成多个，例如有功能类模型、话术分类模型、问答类模型、多轮对话模型等。云端算法类。
- 在线ASR服务：语音识别。云端算法类。
- 车机端App：负责对话调度和界面展现。终端工程类。
- 车机端ASR服务：包括唤醒和语音识别。主要是算法类。
- 对话系统整体：关注端到端的功能实现和效果等所有内容。
在我的意识里，云端可以约等于高频迭代。高频的迭代意味着开发更新频率高，测试频率也高。云端接口更稳定，对自动化测试维护成本较低、友好。而终端/前端工程，更容易受到设计、产品等项目角色的影响，自动化测试维护成本高，不易完美实现。
未完待续...
