小明入职已有两年，期间测试能力已不知不觉成长许多，得到了Leader大熊的高度认可。回首这两年间，小明对“Bug总结流程”印象最为深刻，他对这个流程的认识在不断改变着：从最初的好奇，逐步变为反感，最终因为收益良多，重新走向认同。今天我们来介绍下这个流程。
两年前的某天，大熊在思考一件事情：如何能够帮助组员快速提高测试技能？
以往的管理经验告诉他，只是安排一些讲座培训无济于事，如果没有实际的实例与测试理论知识贯通，这就如同学校里照本宣科一般无法学以致用；同时没有实际的示例，很多异常测试点总是遭到组员的质疑(例如:有同学就会质疑网络返回超时这种情况不用测试吧)。
“理论”、“实践”、“说服力”、“知行合一”，这些名词在大熊的脑中不断地闪现，最终一根线将这些词汇串联在了一起：基于线上漏测问题的Bug总结流程。
Bug总结思想
对线上漏测的问题进行收集
对每一个漏测的问题详细分析Bug机理以及漏测的原因
基于以上的原因思考如何进行改进，避免漏测问题发生
将改进方案实施
重复以上的步骤，通过正向循环推动测试团队的质量改进不断优化
Bug总结流程：
为了便于流程的运转和操作，大熊在Cynthia系统上建立了总结流程和表单：
举例说明：
某天，小明测试的搜狗手机输入法项目在上线后，出现了许多线上统计数据不正确的问题。小明收到这个问题反馈后，第一时间跟进和处理问题，确认问题存在，同时配合开发等人一同追查问题原因，后该问题经过追查，原因是覆盖安装所致，开发随后根据该问题进行了问题修正。
流程演练：
1.大熊收到这个问题后，会让小明将此问题录入Cynthia的总结表单
2.小明根据跟进了解的信息，在Cynthia上分别填写：
a.问题原因(包括开发原因和测试原因)
开发原因：
用户在客户端操作之后的pingback不会立即写进这个文件, 会在几种情况下(输入法崩溃,退出,关机,进入设置界面)保存文件. 文件保存位置/data/data/com.sohu.inputmethod.sogou/files/shared_prefs /com.sohu.inputmethod.sogou_preferences.xml。旧版本按照旧格式保存文件，开 发在代码中没有考虑兼容旧格式的pingback，所以第一次读取旧版本已经保存的文件时, 会因为格式不兼容而读错位, 又由于错位, 某些本应以字符串方式解析的pingback错误地以整数方式解析, 导致解析过程中断(具体来说, 130为止会中断), 结果就是, 130以前的读错位, 130以后的丢失，所以会影响全部的pingback。新旧格式存储见附件。
测试原因：
1)测试对pingback模板的开发实现了解不够全面深入，导致pingback模块有修改时，还停留在黑盒测试层面；
2)测试设计考虑不足，输入法覆盖安装的case漏测。
b.问题分类(该问题属于什么类型)
示例中的问题由于没有进行开发改动的实现了解，所以问题类型判定为“用例设计不足->设计层面了解不足”和"测试经验，测试发散度不足"
c.开发解决方案
先判断第一位是否为空，如果不为空（旧格式），将旧格式映射到新格式上，再按照新格式读取；如果为空，直接按照新格式读取
d.测试改进方案(根据问题原因来推导如何进行改进，避免类似问题重复发生)
1）从V8.8版本开始，测试组对每个模块都要绘制开发实现流程图，以进一步深入了解开发实现；
2）在上线前测试checklist中特增加覆盖安装的case，从流程上保证测试质量；
3）在流程上，对代码优化或代码重构等技术需求进行改动内容调研，并产出【影响范围】评估报告。
4）整理pingback测试点形成文档，每次测pingback时都按照该文档进行。若pingback有改动，在此基础上添加测试点。
3.大熊对小明填写的表单各项内容进行审核，各个字段的内容了解深入、填写无误后，大熊置为审核通过，该表单会处于改进方案实施中。
4.后续大熊会督促小明的改进方案实施，如：小明整理pingback测试点文档。
5.当以上改进方案实施完毕后，小明将此表单置为改进完毕交由大熊审核关闭。
正是通过以上流程，小明在这两年期间积累了非常多的经验，测试能力稳步提高，逐渐成为了团队的顶梁柱。
“反省是一面镜子，它能将我们的错误清清楚楚地照出来，使我们有改正的机会。——海涅”
