步骤3：基础数据整合
　　目的：按照所需处理格式，对基础数据进行重新整合，分类整理。
　　村长拿到基础数据清洗后结果，问题又来了：怎么归纳整理成修改用例的输入？归纳整理的结果是什么样的？
　　答案是：结合需求开搞。啊呸~说的容易，也不举个例子。呃，各位村民，别急，村长慢慢给你说。
　　话说从软件研发起，有传说中的需求，也是指导开发实现的文档。这个文档说明了软件实现的功能点、软件性能指标等方方面面。也是有了这么一个神圣的文档，测试同学有据可依去跟开发GG直面PK，是否完成需求的实现等等。
　　语音APP也有语音需求，如语音需求总表，详细说明了需要调用的APP，具体的每个话术、每个结果状态等等。
　　在村长的项目中，语音有几方面的话术：导航音乐电话节目等等。每个主功能上又会对应具体的话术，如“打电话给张三”“打电话给张三的联通号码”等等详细话术的要求。村长灵机一动，根据每个类型的的话术进行统计。从统计结果上看，导航类的语音请求多，详细的语料展示如下。

　　拿到统计结果，村长粗略核对了下产品详细需求，发现39类导航语音话术中，实际用户使用的只有7种。这7种语料中，“我要去我想去”+“导航到XXX”占比高，也是用户在发起路线规划的需求是高的。于此同时，可以看出用户直接说出地名占比也较高。产品层面分析：发起语音时，产品页面会有文字等方面的提示，也是这些语料占比高的原因。另一些问题：沿途查找导航过程中查询时间路况等方面，均未有用户使用。
　　分析到这里，村长在想下一步，怎么来指导用例的修改呢？是全面替换原有用例么？
　　步骤4：修改用例
　　目的：使用基础数据分析结果，来指导测试用例的编写&修改，终达到保证用户场景80%的使用。
　　上文提到了，已经得到了基础统计结果&分析结果。村民一般反馈，那直接用这些数据去修改测试用例得了，还墨迹啥。不，其实还是需要对用例区别对待。不可以全部只按照用户反馈修改，不可以不参考用户反馈修改。这句话很拗口，说白了是：需要对原有用例按照用户实际路径进行修改，并且修改优先级。在语音APP修改时，按照测程进行重新规划。
　　原来case，因为不清楚用户实际使用频次，所以所有的语料都必须全量覆盖测试。新case，修改一部分case，并且重新按照用户使用频次标注优先级，在测程中得以优化。
　　如下语音唤起导航case：原本P1-case：175条。新修改P1-case：31条。同时将原本的“回家去公司查找XX地点放大缩小地图”类case归类为P4，即统计中用户并未使用过的语料。

　　步骤5：版本发布&用户反馈总结
　　目的：修改后用例，需要在真正版本发布后，对用户反馈进行归纳整理，选出语音模块漏侧case，完善测试用例和场景。
　　村长根据分析出结果，修改后的用例，对V2.1.1版本进行语音APP集成测程重新规划，并终发布以观察效果。具体效果待后续展示。
　　四、村长实践后效果
　　村长在实际实践中，对比了V2.1.0&V2.1.1的的case量、测试耗时、漏侧等相关数据，结果如下图所示，对case量进行调整，case级别进行调整后，实际上用户反馈漏侧也没有任何变化。看来这么干是可行的。


　　图片5

　　五、村长后续的打算
　　做完语音测试用例优化后，村长想从后续几个方面去优化推广：
　　打算1：统计数据，从运营平台上自动化获取；
　　打算2：统计数据中，数据整合&数据清洗自动化处理。
　　打算3：推广到其他测试周期长应用中~
　　以上是村长在实际测试中，从用户数据逐步提取关键信息，终指导测试用例删减的故事，希望大家能够喜欢&提出建议和意见。