本文章轉載于搜狗測試
小明入職已有兩年，期間測試能力已不知不覺成長許多，得到了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.當以上改進方案實施完畢后，小明將此表單置為改進完畢交由大熊審核關閉。
正是通過以上流程，小明在這兩年期間積累了非常多的經驗，測試能力穩步提高，逐漸成為了團隊的頂梁柱。
