测试语音遥控器语音聊天的坑

　　测试完扫描连接，接下来就要测试语音遥控了。语音这块的测试几个要点就是：

1. VAD 自动判停
2. 页面的显示
3. 拾音状态识别率
4. 多轮对话
5. 返回的数据是否正常
6. 技能是否完善
7. 自定义技能可行性
8. 数据存储
9. 语音播报
10. 友好的交互体验
11. 权限处理
12. 第三方应用干扰
13. 处于后台，锁屏的状态

　　这些都是我测试的经验，可能还有需要完善的部分，先后顺序不是很重要，重要的是这些内容都要测试到位

　　1.VAD 的自动判停

　　这是所有的语音产品都要首先测试的，我们的应用集成的阿里的 SDK。目前市场是比较好的语音助手相信大家都可能多多少少都体验过。比如苹果的 Siri，Google 的 Google Assistant，小爱同学，天猫精灵等等，这些都是语音助手。VAD 自动判停就是语音端点检测的目标是要判定语音开始和结束的位置，一般定义在语音识别领域。通俗的讲就是你在说话的时候，它会根据周围的声音在进行判断你是否已经完成说话。因为每个人的讲话的语速和节奏是差异非常大的，所以这块内容的测试还是非常磨人的。VAD 自动判停对于整个语音流程的体验来说至关重要，否则判断的失败，也将会严重影响识别结果和语义理解。VAD判停的时间，长了影响交互体验，短了难以适配复杂场景，还是以符合人类交流的习惯为最佳。

　　我在测试的过程中发现 iOS 端的 VAD 自动判停的体验效果真的是太差了，而相比之下 Android 的体验要好上很多。比如以下场景：播放一首 XXX 的歌曲。可能你已经说了播放一首，但是突然没有想起来是哪个歌星的名字，你停下来了，他可能就会自动判停了，已经结束了拾音。这种体验对于用户来说是十分不友好的，这意味着他要重新发起语音，重新说一遍。要在吵闹，安静等等的情况下去测试。我们的开发人员在周围没有任何声音的情况下，做了一个差不多7秒时间的自动结束拾音的操作。我觉得这个时间是可以忍受的。

　　2.页面的显示　

　　语音助手是根据你说的话，然后转换成文字，再返回数据的。需要特别注意，当文字超出屏幕之后，是否会自动弹出显示。这个细节非常小，但是我们开发总是会出这方面的问题，测试也经常会遗漏。特别是在有设备参与的情况下。比如：当你用设备上的按键进行切换上一曲，下一曲的时候，他会返回数据：接下来为你播放 XXX 的 XXX。但是这行文字是不会自己弹出显示在屏幕上的，需要你手动向上滑动才会显示。整个界面都需要核对，拾音按钮，在拾音状态下的显示。界面返回回来的数据显示，比如古诗。大家都知道古诗里面经常会出现一些生僻字，这个时候，界面可能就会显示不正常，会出现乱码什么。如图：

　　UI 界面还是需要细心核对的，特别是数据返回回来呈现的状态。

　　3.拾音状态

　　点击拾音按钮，应该开始拾音，仔细核对这方面的细节，最主要的是识别率高不高。初期的产品体验不会很好，因为识别率极其差。之后做了热词优化会好很多。有时候出现识别率不好的情况，可能和网络有关系。

　　4.多轮对话　　

　　语音助手一定会出现多轮对话的场景，需要特别注意的是，多轮对话的过程中，自动拾音的状态是否有提示音。比如以下场景：我 [帮我定一个闹钟] ，语音助手[好的，闹钟需要定到几点呢？]这个时候语音助手会自动打开拾音状态开始拾音，确认当前拾音按钮的状态，确认是否有提示音响起，提示用户继续当前的对话。

　　5.返回的数据是否正确

　　当你让语音助手播放歌曲，需要去测试返回的数据是否是正确的。

　　6.技能是否完善

　　这个技能是根据产品定义出来的，目前我们的技能有音乐播放、天气查询、儿歌、闹钟、日程提醒、股票查询、广播电台、历史上的今天、笑话、诗词、算数

、星座运势、智能聊天、声音、打电话。我们要根据每个技能，提出针对性的提问去测试，技能是否完善，返回的数据是否正常。

　　7.自定义技能可行性

　　目前打电话是我们的自定义技能，测试打电话真的要很多场景，要不然你就会有遗漏的 bug。

　　测试场景：播报电话号码、播报联系人名称、多个联系人选择、联系人存在/不存在等等。要测试自定义技能的完善性。

　　8.数据储存

　　这个也是比较重要的，每次语音对话之后，界面上会有很多对话的内容，那当我们退出应用的时候，这个时候我们没有选择杀死应用，只是进入到了后台。我们再次点击进入页面，之前的聊天记录应该还是在的，包括上一曲/下一曲都会用到数据储存。还有扫描连接的设备储存。

　　9.语音播报

　　语音助手这种应用可能会涉及到两个拾音通道，一个是从手机端去拾音，另一个则是从设备端去拾音，这就意味着，他的语音播报也会有两个通道。当设备连接了 A2DP 的时候，音频应该是从设备端播放出来的。我测试到过，在设备端播放一段时间音乐之后，会有短暂的时间声音会从手机端播放出来，这是因为开发人员在处理播放通道的时候逻辑没有处理好导致的。我们的逻辑是，当连接了设备的时候，我们从设备端去拾音，也从设备端去播放音乐。特别要注意的是提示音，我们的项目在测试的过程中，提示音会莫名其妙的消失掉。

　　10.友好的交互体验

　　友好的交互体验真的很重要，比如手机没有网络状态的情况下，没有合理的提示，估计会分分钟卸载应用。语音助手需要非常友好的交互体验，因为一般使用这类产品的用户很少会去手动操作，当语音没有识别到的时候，应该进行友好的交互提示。一个应用，友好的交互体验，占了成功的一半。

　　11.权限处理

　　权限这块的内容是一个应用很重要的内容，这关乎到你的应用能不能正常的上架。比如天气，电话，语音，会用到访问地址，访问通讯录，访问麦克风等权限。权限友好的提示也是很重要的哦。

　　12.第三方应用干扰

　　这个最主要测试的就是播放音乐了，当你用语音助手在播放音乐的时候，他请求到的音乐资源是在线找的，然后打开第三方应用，比如打开网易云音乐播放音乐，语音助手里面的音乐就应该暂停掉，不能出现重音的情况。

　　13.处于后台、锁屏的状态

　　退出应用之后，是否能够正常的通过设备重新去调起应用，在后台的情况下和锁屏的情况下。是否能够正常播放音乐，正常拾音，正常返回数据等等。

　　好啦，以上就是我在这个项目中踩的坑，要是有相同的经历觉得有补充的请回复我。