【issue平台】漏测改进的智能跟进和挖掘方案
漏测改进的智能跟进和挖掘方案—ISSUE平台
—“小D啊，DAI平台提醒说你们项目昨天有个紧急更新单，前天有个突发单，是怎么回事啊？”
—“啊，是这样的，…………，我先去TAPD补录个BUG进行分析，并采取漏测改进措施防止以后此类问题再出现。”
—（过了一个月突然想起来）“小D啊，上次那个突发问题处理的怎么样了，改进效果如何，有没有同类问题再出现？”
—“嗯……这问题比较难搞，还没想到比较好的改进措施；同类问题有没有出现我得去查查，只是数据量非常大，查起来比较耗时。”
—“我记得XX项目好像遇到过这类问题，你去问问他们怎么处理的……”
众(ju)所(wo)周(suo)知(zhi)，程序的BUG是永远不能全部测试出来的，所以项目测试中上述场景屡见不鲜。虽然无法保证上线前100%正确，但我们可以不断对历史测漏漏测的BUG进行分析总结，避免以后再次出现同类问题，不断优化测试方案手段，逐步降低漏测和提升品质信心。因而，对付外网漏测是作为测试者非常重要的一项工作，也是推动各项测试技术不断发展的契机。
一、现状与问题
目前IEG品管中心负责的各项目在对外网bug的处理上通常会用到TAPD和DAI两套系统，如下所示：
TAPD几乎集中了项目中的所有问题，包括内网发现和外网发现的。而DAI更关注外网产生并对用户造成一定影响的问题。
但这样的处理流程在长期应用之后，我们发现它存在一定限制：
1) 不能很好地应对外网用户反馈的问题
项目在外网运营时，会有不少问题反馈来自论坛和玩家群，这种问题不一定会形成突发或者紧急更新，便不会被录入到DAI系统进行跟进。
2) 难以问题归类和漏测改进效果评估
TAPD和DAI都是以列表进行BUG收集，没有进行归类汇总的特性，并且如果该BUG进行了漏测改进，改进后是否再次出现、漏测改进方案是否有效，也很难直接从TAPD与DAI上获得，如文章开头的对话。
收集和记录BUG只是BUG管理的第一步，将BUG进行总结、改进，避免同类问题再次出现才是最终目的，于是我们建立了一套自身的BUG跟进流程，大致如下：
该流程运转了1年有余，对漏测管理和改进工作改良颇多，发酵酝酿了不少改进优化的技术方向。不过人心总是贪的，欲望总是填不满的，民众上访反映存在下面这些问题：
1) 项目当前重点问题不清晰
一些同类问题感觉玩家反馈了很多次，一些内网无法重现的问题但外网持续偶有反馈，但缺少量级统计，无法正确评估这个问题对于玩家的重要和影响程度，也在推动修复时无法用有效的反馈量来增加该问题的优先级。
2) 漏测改进闭环效果不明显
漏测BUG的改进方案敷衍了事、一次性解决、未从根本上规避的现象很多，而目前没有对这方面进行有效的监控。当同类问题再次多次出现，没有重视该类问题应该需要提取实施有效的改进方案。
3) 历史和重复问题难查询
问题记录采用Excel方式，很大程度依赖人的记忆，当人员交接、项目BUG量庞大时，会很容易出现漏测问题重复验证、重复提交等无意义工作量，或因未找到重复问题导致被记录为多条问题。
4) 项目间共性问题缺乏归类和便利查看渠道
A项目出现一个问题并且有较好的改进方案，但B项目也出现而并不知道A的方案，导致重复造轮子的工作量甚至B根本没有研究出该项改进。
用两张图来表现当时的情况：
二、平台的诞生
为了解决上面提到的各种问题，我们将考虑将外网问题反馈跟进的方式做到web平台上，期望整个流程由平台控制，问题的智能归类也让平台决策，让执行者的BUG管理流程更加清晰明了，让管理者对项目重点问题、改进进度以及所有项目大方向上的问题共性有把握。
同时，也使各个角色的职责更专注：
外包只需关注问题录入、验证与bug提交；
TM关注当前项目的问题审核，重点问题挖掘和改进实施；
Leader关注项目整体质量情况与TM改进进展；
TE/TM/Leader可以从不同项目之间获取共性问题，挖掘重点漏测改进方案进行突破；
下面列举一下平台实际使用的一些场景：
a) 测试外包：在问题验证后，通过平台进行录单。
b) 项目TM/TE：审核问题单，进行漏测改进。
查询并总结阶段性的处理结果，可以进一步识别项目的重点问题和解决思路。
c) 团队Leader：通过平台观察各项目重点问题和改进大数据，进行团队目标KPI、重点方向的识别制定和资源分配。
（示意图 (>^ω^<)）
目前该平台为我们组内的10多款端游手游进行漏测统计和改进提供了非常大的帮助。在组内应用的过程中，我们仍在持续挖掘平台的核心价值，对平台做“汇集”漏测改进方案、对漏测问题“智能推荐”改进方案、“挖掘”各项目可实施的新的改进方向等方面的优化。
三、平台核心功能实现
3.1 问题关联的实现
关联的目的在于确认录入的问题是否存在于已知的问题列表中，平台在解决这个问题上进行了以下处理：
以上，找到合适的问题以后，进行关联为同一问题。
3.2 如何提升关联识别的精度
我们将关联精度的提升拆分为下面两个步骤：
1) 分词的正确度
2) 关键词与已知问题的匹配程度
a) 分词的正确度
分词算法采用了公司的分词系统，http://nlp.oa.com/thinkerguo/seg_auth/index.php?r=site/index，该平台构建的分词逻辑如下：
使用基础词库+平台运转中不断学习的用户词库，持续扩充词库量，分词的准确性也会越来越高。
b) 关键词的选择与已知问题的匹配程度
例如：
在该问题中，需要从分词中重新组成最为简单但可以表达出意思的词组，完美的结果应该为：
“查看 敌方英雄 属性 无法查看 饰品”
要达到这个完美的结果几乎是不可能的，但可以通过逻辑达到一个比较理想的结果
处理流程如下：
其中相似度匹配算法核心在于：
基于剔除后的关键词数量决定匹配度算法
分词结果与数据库的匹配数量决定匹配程度
基于结果数量动态调整匹配程度
自动学习不断完善各项目自我特征和共通特征
四、未来展望
目前，该平台的2.0版本也正在开发中，将于不久之后面世。我们并不期望它能立即带来立竿见影的效果，现在能为项目测试人员提供一点点便利我们也乐于见到。而问题的智能分类、漏测改进方案的智能推荐和挖掘等高端功能，在更多的项目加入、平台长期的坚持运营、平台知识库的不断扩充、形成可靠的数据源之后，才会真正起到应有的作用。同时，在技术上我们也存在识别准确度的疑难杂症正在尝试攻破，比如下面三点：
1) “简称”识别，很多项目都有玩家自行产生的昵称或简称，这些词语并没有统一的写法，比如英雄联盟中的“小炮”、“炮娘”、“剑姬”、“JJ”，这会让同类问题识别产生非常大的误差，需要在外网采集大量的相关词语后进行智能分析和机器学习，将其划分为同价类；
2) “错别字”识别，玩家反馈和测试人员录入时，很可能打错字，比如“露露-璐璐”甚至“lulu”，这需要使用拼音识别的方式进行归类（目前暂不考虑五笔错别字……）；
3) 语义识别，这是智能识别的一大难题，也会导致目前同类识别出现这样的错误——“游戏的ping达到800”，“游戏很延迟”——他们没有被识别为同类问题，这方面暂时没有深入研究解决方案；
总之，我们希望该平台能成为腾讯游戏测试宝贵的经验库，为千千万倒在前浪上的测试战士们，让他们惨痛的“血的教训”起到警示后人的作用，让测试技术不断发展、游戏质量不断趋于完美。
漏测改进的智能跟进和挖掘方案—ISSUE平台
—“小D啊，DAI平台提醒说你们项目昨天有个紧急更新单，前天有个突发单，是怎么回事啊？”
—“啊，是这样的，…………，我先去TAPD补录个BUG进行分析，并采取漏测改进措施防止以后此类问题再出现。”
—（过了一个月突然想起来）“小D啊，上次那个突发问题处理的怎么样了，改进效果如何，有没有同类问题再出现？”
—“嗯……这问题比较难搞，还没想到比较好的改进措施；同类问题有没有出现我得去查查，只是数据量非常大，查起来比较耗时。”
—“我记得XX项目好像遇到过这类问题，你去问问他们怎么处理的……”
众(ju)所(wo)周(suo)知(zhi)，程序的BUG是永远不能全部测试出来的，所以项目测试中上述场景屡见不鲜。虽然无法保证上线前100%正确，但我们可以不断对历史测漏漏测的BUG进行分析总结，避免以后再次出现同类问题，不断优化测试方案手段，逐步降低漏测和提升品质信心。因而，对付外网漏测是作为测试者非常重要的一项工作，也是推动各项测试技术不断发展的契机。
一、现状与问题
目前IEG品管中心负责的各项目在对外网bug的处理上通常会用到TAPD和DAI两套系统，如下所示：
TAPD几乎集中了项目中的所有问题，包括内网发现和外网发现的。而DAI更关注外网产生并对用户造成一定影响的问题。
但这样的处理流程在长期应用之后，我们发现它存在一定限制：
1) 不能很好地应对外网用户反馈的问题
项目在外网运营时，会有不少问题反馈来自论坛和玩家群，这种问题不一定会形成突发或者紧急更新，便不会被录入到DAI系统进行跟进。
2) 难以问题归类和漏测改进效果评估
TAPD和DAI都是以列表进行BUG收集，没有进行归类汇总的特性，并且如果该BUG进行了漏测改进，改进后是否再次出现、漏测改进方案是否有效，也很难直接从TAPD与DAI上获得，如文章开头的对话。
收集和记录BUG只是BUG管理的第一步，将BUG进行总结、改进，避免同类问题再次出现才是最终目的，于是我们建立了一套自身的BUG跟进流程，大致如下：
该流程运转了1年有余，对漏测管理和改进工作改良颇多，发酵酝酿了不少改进优化的技术方向。不过人心总是贪的，欲望总是填不满的，民众上访反映存在下面这些问题：
1) 项目当前重点问题不清晰
一些同类问题感觉玩家反馈了很多次，一些内网无法重现的问题但外网持续偶有反馈，但缺少量级统计，无法正确评估这个问题对于玩家的重要和影响程度，也在推动修复时无法用有效的反馈量来增加该问题的优先级。
2) 漏测改进闭环效果不明显
漏测BUG的改进方案敷衍了事、一次性解决、未从根本上规避的现象很多，而目前没有对这方面进行有效的监控。当同类问题再次多次出现，没有重视该类问题应该需要提取实施有效的改进方案。
3) 历史和重复问题难查询
问题记录采用Excel方式，很大程度依赖人的记忆，当人员交接、项目BUG量庞大时，会很容易出现漏测问题重复验证、重复提交等无意义工作量，或因未找到重复问题导致被记录为多条问题。
4) 项目间共性问题缺乏归类和便利查看渠道
A项目出现一个问题并且有较好的改进方案，但B项目也出现而并不知道A的方案，导致重复造轮子的工作量甚至B根本没有研究出该项改进。
用两张图来表现当时的情况：
二、平台的诞生
为了解决上面提到的各种问题，我们将考虑将外网问题反馈跟进的方式做到web平台上，期望整个流程由平台控制，问题的智能归类也让平台决策，让执行者的BUG管理流程更加清晰明了，让管理者对项目重点问题、改进进度以及所有项目大方向上的问题共性有把握。
同时，也使各个角色的职责更专注：
外包只需关注问题录入、验证与bug提交；
TM关注当前项目的问题审核，重点问题挖掘和改进实施；
Leader关注项目整体质量情况与TM改进进展；
TE/TM/Leader可以从不同项目之间获取共性问题，挖掘重点漏测改进方案进行突破；
下面列举一下平台实际使用的一些场景：
a) 测试外包：在问题验证后，通过平台进行录单。
b) 项目TM/TE：审核问题单，进行漏测改进。
查询并总结阶段性的处理结果，可以进一步识别项目的重点问题和解决思路。
c) 团队Leader：通过平台观察各项目重点问题和改进大数据，进行团队目标KPI、重点方向的识别制定和资源分配。
（示意图 (>^ω^<)）
目前该平台为我们组内的10多款端游手游进行漏测统计和改进提供了非常大的帮助。在组内应用的过程中，我们仍在持续挖掘平台的核心价值，对平台做“汇集”漏测改进方案、对漏测问题“智能推荐”改进方案、“挖掘”各项目可实施的新的改进方向等方面的优化。
三、平台核心功能实现
3.1 问题关联的实现
关联的目的在于确认录入的问题是否存在于已知的问题列表中，平台在解决这个问题上进行了以下处理：
以上，找到合适的问题以后，进行关联为同一问题。
3.2 如何提升关联识别的精度
我们将关联精度的提升拆分为下面两个步骤：
1) 分词的正确度
2) 关键词与已知问题的匹配程度
a) 分词的正确度
分词算法采用了公司的分词系统，http://nlp.oa.com/thinkerguo/seg_auth/index.php?r=site/index，该平台构建的分词逻辑如下：
使用基础词库+平台运转中不断学习的用户词库，持续扩充词库量，分词的准确性也会越来越高。
b) 关键词的选择与已知问题的匹配程度
例如：
在该问题中，需要从分词中重新组成最为简单但可以表达出意思的词组，完美的结果应该为：
“查看 敌方英雄 属性 无法查看 饰品”
要达到这个完美的结果几乎是不可能的，但可以通过逻辑达到一个比较理想的结果
处理流程如下：
其中相似度匹配算法核心在于：
基于剔除后的关键词数量决定匹配度算法
分词结果与数据库的匹配数量决定匹配程度
基于结果数量动态调整匹配程度
自动学习不断完善各项目自我特征和共通特征
四、未来展望
目前，该平台的2.0版本也正在开发中，将于不久之后面世。我们并不期望它能立即带来立竿见影的效果，现在能为项目测试人员提供一点点便利我们也乐于见到。而问题的智能分类、漏测改进方案的智能推荐和挖掘等高端功能，在更多的项目加入、平台长期的坚持运营、平台知识库的不断扩充、形成可靠的数据源之后，才会真正起到应有的作用。同时，在技术上我们也存在识别准确度的疑难杂症正在尝试攻破，比如下面三点：
1) “简称”识别，很多项目都有玩家自行产生的昵称或简称，这些词语并没有统一的写法，比如英雄联盟中的“小炮”、“炮娘”、“剑姬”、“JJ”，这会让同类问题识别产生非常大的误差，需要在外网采集大量的相关词语后进行智能分析和机器学习，将其划分为同价类；
2) “错别字”识别，玩家反馈和测试人员录入时，很可能打错字，比如“露露-璐璐”甚至“lulu”，这需要使用拼音识别的方式进行归类（目前暂不考虑五笔错别字……）；
3) 语义识别，这是智能识别的一大难题，也会导致目前同类识别出现这样的错误——“游戏的ping达到800”，“游戏很延迟”——他们没有被识别为同类问题，这方面暂时没有深入研究解决方案；
总之，我们希望该平台能成为腾讯游戏测试宝贵的经验库，为千千万倒在前浪上的测试战士们，让他们惨痛的“血的教训”起到警示后人的作用，让测试技术不断发展、游戏质量不断趋于完美。