Bug总结流程

小明入职已有两年，期间测试能力已不知不觉成长许多，获得了Leader大熊的高度承认。回首这两年间，小明对“Bug总结流程”印象最为深入，他对这个流程的认识在不断改变着：从最初的好奇，逐步变为反感，最终由于收益良多，从新走向认同。今天咱们来介绍下这个流程。

 

 

 两年前的某天，大熊在思考一件事情：如何可以帮助组员快速提升测试技能？

 

以往的管理经验告诉他，只是安排一些讲座培训无济于事，若是没有实际的实例与测试理论知识贯通，这就如同窗校里照本宣科通常没法学以至用；同时没有实际的示例，不少异常测试点老是遭到组员的质疑(例如:有同窗就会质疑网络返回超时这种状况不用测试吧)。

 

“理论”、“实践”、“说服力”、“知行合一”，这些名词在大熊的脑中不断地闪现，最终一根线将这些词汇串联在了一块儿：基于线上漏测问题的Bug总结流程。

 

 

 

Bug总结思想

1. 对线上漏测的问题进行收集

2. 对每个漏测的问题详细分析Bug机理以及漏测的缘由

3. 基于以上的缘由思考如何进行改进，避免漏测问题发生

4. 将改进方案实施

5. 重复以上的步骤，经过正向循环推进测试团队的质量改进不断优化

   

    

 

 

 

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.当以上改进方案实施完毕后，小明将此表单置为改进完毕交由大熊审核关闭。

 

正是经过以上流程，小明在这两年期间积累了很是多的经验，测试能力稳步提升，逐渐成为了团队的顶梁柱。

 

“检讨是一面镜子，它能将咱们的错误清清楚楚地照出来，使咱们有改正的机会。——海涅”