分层测试在AI系统测试中的实践（1）（云端之约完整测试版）

写在前面

本人2017年加入国内新能源车龙头，负责车载语音对话系统的测试工作，和团队构建起一套适合业务迭代的测试方法。最近有些*把这个过程中的心得体验分享给有缘人。

说一个前提，也是一个经典解释：测试工作就是质量和成本博弈的结果，所有任何测试都需要考虑性价比。

有一个限制，不清楚会不会涉及到信息泄漏，不能绘制流程图和系统架构图，望各位理解。

系统组成

我了解的车载对话系统通用的解决方案为车机端的服务和APP族（包括语音识别服务，ASR下同），车机操作系统，车机网关和车联网云端网关，云端对话系统，自然语言理解（NLU，下同）模型，运营系统，大数据服务，其他垂直类应用服务（例如负责地图和导航GIS、媒体搜索）等。

下面是插入的内容

规则：可以简单认为是正则匹配，例如“(|查询)*天气”可以匹配到“查询北京天气”“查询天津天气”“哈尔滨天气”等。但随着功能越来越多，规则会更加复杂，也可能产生规则之间的冲突。

模型的产生流程为：

可以看到，模型的迭代周期从逻辑上就很长，但是由于模型可以完成类似“收集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][空气|空气质量]）则我们可以通过穷举和边界值方法构造测试数据集合，虽然这个测试集合数量很大，但毕竟是有限集合，可以通过测试脚本穷举完成测试工作。