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.當以上改進方案實施完畢後，小明將此表單置爲改進完畢交由大熊審覈關閉。

 

正是經過以上流程，小明在這兩年期間積累了很是多的經驗，測試能力穩步提升，逐漸成爲了團隊的頂樑柱。

 

「檢討是一面鏡子，它能將咱們的錯誤清清楚楚地照出來，使咱們有改正的機會。——海涅」