那么需求是什么，我們要測什么，在哪些機型上測，這幾個問題我們都搞清楚了。是不是測試完成，我們就可以順利結束這個項目了呢？等等，我們好像還錯過了什么…是的那就是我們錯過了提交bug和跟蹤bug。
Bug一詞的原意是“臭蟲”或“蟲子”。但是現在，在電腦系統或程序中，如果隱藏着的一些未被發現的缺陷或問題，人們也叫它“Bug”，這是怎么回事呢？原來，第一代的計算機是由許多龐大且昂貴的真空管組成，並利用大量的電力來使真空管發光。可能正是由於計算機運行產生的光和熱，引得一只小蟲子?Bug鑽進了一支真空管內，導致整個計算機無法工作。研究人員費了半天時間，總算發現原因所在，把這只小蟲子從真空管中取出后，計算機又恢復正常。后來，Bug這個名詞就沿用下來，表示電腦系統或程序中隱藏的錯誤、缺陷、漏洞或問題。
一個項目在開發-測試中基本上是不可能不出現bug的，或因為粗心大意，或因為開發人員沒有理解需求，或因為代碼邏輯，總會出現一些bug的，而我們在進行功能測試的時候，發現一個bug了，該怎么去告訴開發人員，怎么記錄下來，又怎么解決呢？
真正在工作中，測試在提交bug的時候，是會用到bug管理工具的，用於提交bug，跟蹤bug，市面上有很多的bug管理工具，比如禪道，比如jira，有些公司也會自己開發一套bug管理工具。有些同學可能會說，有bug，那直接告訴開發，口頭說一下，讓他改就行了，為什么要搞這么麻煩，還得去使用一個工具記錄呢？
因為在實際工作中，一般往往並不會只有一個開發，一個測試，當人員增多時，不對bug進行記錄，會造成工作上的混亂，比如說現在有A,B2個測試人員，當A測試發現了一個點贊后崩潰的問題，沒有進行記錄直接告訴了開發，那么當B測試發現該問題時，又去告訴一次開發。這樣其實有效率上的問題，當bug被記錄到bug管理工具中時，不僅僅可以看到提了什么bug，還可以看到bug的狀態，開發有沒有解決？bug被解決后，bug記錄有沒有被關閉？
那么我們下面就以一個bug管理工具—禪道為例子給大家演示一下bug的流程。禪道是一個中國團隊本土做的還比較好的一個bug管理工具，在他的官網上也有在線演示版。
先選擇測試，bug，然后點擊提bug的按鈕
點擊提bug按鈕后，就進入到了提bug的詳情頁面，下面的元素我也可以拿微信舉例子簡單和大家講講重點的功能
所屬項目：
也就是你對應的項目名稱，比如微信
所屬模塊：
具體的功能模塊，比如朋友圈首頁
所屬迭代：
每個app都有自己的版本號，一般來說在設置-關於里可以找到，比如微信目前的版本號是6.5.3
影響版本：
一般來說填測試版或者線上版
當前指派：
這里填寫你要提交去解決的開發對象
截止日期：
也就是bug的修改截止日
Bug類型:
即對bug進行簡單分類，比如有代碼錯誤，界面優化，設計缺陷等待
操作系統:
如果是app測試的話，一般這里填寫Android或者iOS,用於區分不同的平台
瀏覽器:
一般用於web兼容性測試，app測試的話可不填
bug標題:
對bug進行的簡單描述，讓開發理解就好，比如微信朋友圈點贊后無反應
嚴重程度:
不同的平台可能划分的名稱不同，比如有的是以數字區分，1-4，1為最嚴重，或者是Low，High這樣進行划分。一般來說最高級，比如1級bug意味着非常嚴重，影響到進程使用，比如登錄后直接崩潰，這樣的為1級bug。2級bug意味着嚴重，一般指重要功能出了問題，比如微信朋友圈打不開。3級bug意味着普通，一般來說在測試中提的最多的缺陷就是3級bug，比如微信朋友圈無法點贊。4級bug是對應一些建議性的問題，比如你覺得點贊的紅心過大或者過小
優先級:
為建議開發處理的優先級，一般來說是越嚴重的bug越優先處理
重現步驟:
詳細描述bug產生的操作步驟，出現后的結果，和期望結果，一般來說，有截圖的話附帶截圖比較好。
那么提交完成后這個bug就已經被激活了，指派給了對應提交的開發，下面要做的，就是等待開發修復bug，當開發把bug修復完成后，他會把bug再提交給你，我們在新的版本上，對bug進行復測，如果說bug已經解決了，則關閉改bug，如果bug還存在，則又打回給開發。
那么在實際工作中是不是要bug全部修復完才能達到上線呢？如果上線時間很緊急，還有沒修復完的bug怎么辦呢?
一般來說如果還有等級是1級，2級的bug是不允許帶上線的，如果有3級bug，4級bug的話可以讓產品進行定奪，如果影響范圍不大時間又比較急的話，帶着不嚴重的bug上線也是可以接受的，只要在測試報告中注明就好。