在前面的话
　　车联ROM系统是搭载腾讯TAS智能车载系统。系统搭载在路畅华阳合作伙伴硬件平台上，实现了车机联网，实现了智能语音、网络音乐、实时路况、在线升级等特有功能，并且延伸了腾讯的社交基因，微信和QQ社交能力在乘驾上得以延伸。
　　村长下面讲的故事，是围绕车联ROM中智能语音APP展开，请各位看官了解~

　　一、村长为啥干这事儿
　　村长是一名腾讯移动客户端测试工程师。跟其他的测试同学一样，从需求、计划、用例设计评审、执行、报告、发布按部班的进行了自己本职的工作，比如说，车联ROM中语音APP的测试。但是有村长回头看自己的语音APP的测试用例，发现测试用例越来越多，测试回归验证时间周期不断加长，同时，仍旧有用户反馈的漏侧等各种问题。
　　她不禁思考：测试用例真的“足够好”么？真的可以反应真实用户的使用场景么？回归测试时真的需要去运行如此多的测试用例么？
　　有了这样的疑问和困惑，她去查找很多资料，突然一次例会上交流让她有了新灵感：产品同学对于新功能都会加上埋点以看到用户对新功能的使用反馈，进而对产品设计进行调整。
　　测试：为何不从用户使用角度来对用例进行划分优化呢？
　　二、村长想怎么干
　　在腾讯，倡导的理念是“一切以用户的价值为依归”。那么在以用户价值为导向的理念下，产品、运营都是从用户使用角度出发，为何测试不能也从用户数据上做文章呢？
　　下一个问题？这个文章怎么做？怎么指导测试用例？那需要从用户数据入手，抓住用户主要使用场景，进而优化测试策略，终又通过版本发布反向验证方式的可行性。
　　基础思路：基础数据提取——基础数据清洗——基础数据整合——用例修改——版本发布&用户反馈总结

　　
测试用例优化思路

　　三、村长实际操作
　　说干干，说着村长撸袖子挽裤腿的去干活了。
　　步骤1：基础数据提取
　　村长先着手查看运营数据。看到运营数据后，村长脸上写了大大的“蒙圈”。运营数据那么多，具体要从哪些数据里来提取所需信息呢？下面先看看用户数据基本有哪些：


　　图片3

　　结合项目特点：村长选取了所有事件&点击流作为分析基础数据；
　　为什么选取这两个基础数据：
　　1. 抓住主要工作流，这里是主要是用户输入流，保证80%以上的场景可覆盖；
　　2. 其他20%事件可以作为补充用例，可以分不同版本&情况来覆盖；
　　终语音APP选取出来的数据字段是这样的，包含了日期、id、用户名、版本号、用户语音识别文本、语音调用应用类型等等。
　　基础数据ready，怎么分析呢？
　　步骤2：基础数据清洗
　　目的：清除无用数据，为下一步数据整合提供输入；
　　村长拿到基础数据后，哭的心都有了，数据不但多，而且杂，中间夹杂了不少无效数据，也是“脏数据”。这些数据肯定不能直接整合使用的。那么哪些是不需要的“脏数据”？怎么清洗“脏数据”呢？
　　通过观察，语音APP中上报字段中，先去除关键字段为空的数据，表现为下面几个字段：
　　1.SessionID为NULL;
　　2. SpeechID为NULL;
　　3. Speechtext为NULL;
　　在拿到的数据样本中，工具语音会话4499次，脏数据共占比941次，其中840次是操作了语音但是实际并未声音输入，可能是用户误操作的行为。同时意外发现埋点上报一个BUG，即sessionID=NULL&speechID =NULL，但是speechtext非空（QA中彩蛋，发现这个BUG后，村长默默的乐了）。


　　捕获3

　　终，剩余的3558次语音会话，是有效样本数据。Binggo~~有了阶段性成果~继续加油