禪道系統(tǒng)_BUG流程分析

1、Bug的屬性                                                      Bug重現(xiàn)環(huán)境這個應該是我們重現(xiàn)bug的一個前提，如果沒有這個前提，我們可能會無法重現(xiàn)問題，或者跟本就無從下手。操作系統(tǒng)這個是一般軟件運行的一大前提，基本上所有的軟件都依賴于操作系統(tǒng)之上的，對于一個軟

2、件來說，要想在某個操作系統(tǒng)上運行，必須要對這個操作系統(tǒng)支持，這就需要有真對性的設計與開發(fā)。對于不同的操作系統(tǒng)，其可能存在差異（如：win xp 與 win 7）或本質的區(qū)別（如 win 7 與 CentOS linux ），所以，操作系統(tǒng)環(huán)境是重現(xiàn)問題的一個重要前提。瀏覽器對于B/S系統(tǒng)，或面向大眾的互聯(lián)網產品（網站，郵箱等），瀏覽器的兼容性也是必須測試的一個重點，對于現(xiàn)在的瀏覽器市場，各式的瀏覽器都有其用戶群，要想使產品大眾化，必須考慮這些產品的兼容性問題。不同的瀏覽器之間（IE、 

3、firefox、chrome、opera 等），甚至同一系列不同版本（ie6/ie7/ie8/ie9等）都可能存在兼容性問題，所以，對于這類應用，瀏覽器環(huán)境重現(xiàn)bug前提條件之一。 其它（這個“其它”非常重要）對于不同的系統(tǒng)發(fā)現(xiàn)重現(xiàn)問題，都會有其特定的前提，拿我測試的郵箱來說，必須要描述其是在測試線還是現(xiàn)網環(huán)境，而且還要附帶一重現(xiàn)問題的帳號等。對于c/s軟件，可能還要考慮與其它常用軟的兼容等，例如，是在安裝的某款軟件后，對本軟件的安裝和使用造成影響。這些都是重現(xiàn)問題的必須描述的環(huán)境。 問題類型根據JIRA的管理系統(tǒng)的劃分，bug 只是問題的一種，它可以用

4、于跟蹤多種不同類型的問題（其實，他只是將bug做為一子類而已）。JIRA系統(tǒng)缺省提供的問題類型（大部分的系統(tǒng)都可以自定義類型的，這樣就增加了靈活性。）Bug : 測試過程、維護過程發(fā)現(xiàn)影響系統(tǒng)運行的缺陷。（這就是一般測試人員所提交的bug）New Feature :  對系統(tǒng)提出的新功能。（單個的小需求可以，如果大的話，就相當于一個需求，放到這里是不合理的。）Task : 需要完成的一任務。（開發(fā)或測試任務指派。）Improvement : 對現(xiàn)有系統(tǒng)功能的改進。（一般產品經理或產品體驗師做的事

5、）當然，不同的公司，他們的人員定位與職責是不太相同的，按照上面的分類，JIRA就不是簡單的缺陷管理系統(tǒng)了，它涵蓋一項目（或產品）所需要處理的任務、需求與缺陷。 Bug 類型：這里縮小范圍，單指我們測試人員在測試過程中發(fā)現(xiàn)的缺陷，發(fā)現(xiàn)產品缺陷其實就是測試人員工作的主要目的。當然，你要確定一個問題的類型，也需要對項目（或產品）有比較深的理解。是代碼缺陷還是設計缺陷有時候就不太容易區(qū)分，當然，這個劃分，對于開發(fā)定位問題影響很小，但對于問題類型的統(tǒng)計就比較重要了。下面看一些常見的分類：劃分方式一：代碼錯誤設計缺陷界面優(yōu)化配置相關安裝部署性能問題標準規(guī)范測試代碼其它劃分方式二：功能類

6、（function）性能類（performance）界面類（UI）易用性類（usability）兼容性類（compatibility）其它（else）這個分類當然是可以自定義的，具我接觸的缺陷管理都是可以自定義的，既然是對問題的管理，那么你當然可以拿來做特定環(huán)境下的系統(tǒng)來使用，或我就想用這個系統(tǒng)來指派任務，那么我的自定義類型為前端任務、后端任務、測試任務、配置部署. 缺陷等級缺陷等級，這個劃分也比較靈活，有分三級或四級，也有分五級的。致命一招斃命的缺陷，使你的系統(tǒng)無法運行，有造成數據泄漏的安全性問題。嚴重可以引起易于糾正的異常情況、可能引起易于修復的故障或對產品外觀難以接受的缺陷。一

7、般指不影響產品的運轉和運行、不會成為故障起因，但對產品外觀和下道工序影響較大的缺陷 輕微輕微缺陷是指對產品外觀和下道工序可能會有輕微影響的缺陷 建議增加用戶使用體驗的建議性問題。（一般情況下，建議也為做為缺陷的一種。這個跟系統(tǒng)的類型與需求有關） 缺陷優(yōu)先級（priority）當問題處理人員在面對許多問題需要處理進，就需要問題進行優(yōu)先級排序。我們做事情的安排，操作系統(tǒng)有處理進程等都在使用著優(yōu)先級。優(yōu)先級的劃分：低>中>高>緊急延遲處理>正常排隊>優(yōu)先處理>緊急處理Bug 的嚴重程度和優(yōu)先級是含義不同但相互聯(lián)系密切的兩個概

8、念，它們從不同的側面描述了軟件缺陷對軟件質量和最終用戶的影響程序和處理方式。一般地，嚴重程序高的軟件缺陷具有較高的優(yōu)先級。嚴重程度高說明缺陷對軟件造成的危害性大，需要優(yōu)先處理，而來嚴重程序低的缺陷可能只是軟件不太盡善盡美，可以稍后處理。嚴重程度高優(yōu)先級不一定高：如果某個嚴重的軟件缺陷只在非常極端的條件下產生，則沒有必要馬上處理。如果某一個軟件缺陷，需要重新修改軟件的整體架構，可能會產生更多的潛在缺陷，而且軟件由于市場的壓力必須盡快發(fā)布，此時即使缺陷的嚴重性很高，是否需要修正，需要全盤考慮。嚴重程度優(yōu)先級不一定低如果是軟件名稱或公司名稱的拼寫錯誤，雖然說其屬于界面錯誤，嚴重程度不高，但其關系到軟

9、件和公司的市場開解，必須盡快修正。  缺陷狀態(tài)對于一個問題，其處理過程是一個周期，周期的不同階段，其所處的狀態(tài)也是不一樣的。不同狀態(tài)所對應的處理人也是不一樣的。打開 ： 表示問題被提交等待有人處理。重新指派 ： 問題被重新指派給某人處理。 處理 ： 問題在處理中，尚未完成。固定 ： 確認此問題存在，但暫時不進行處理。回歸 ： 對已經修復的問題進行回歸確認。Reopened :關閉 ： 問題的最后一個狀態(tài)。  Bug處

10、理流程                                                           下面通過一個比較完整的bug的處理流程圖，更深刻的理解bug的狀態(tài)以一個bug的生命周期。 提交（打開）缺陷在提交一個缺陷的缺陷，首先盡量描述這個缺陷的屬性。Bug重

11、現(xiàn)環(huán)境，bug類型，bug等級，bug的優(yōu)先級以及詳細的重現(xiàn)步驟，結果與期望等。當然，我們在提交一個問題之前首先應該保證，這個缺陷是沒有被提過的，以免造成重復缺陷單。如果是回歸不通過的缺陷，其狀態(tài)又會變?yōu)榇蜷_狀態(tài)。  分配（轉交）缺陷這一步不是必須的，跟項目模式有關，有些公司測試部門與開發(fā)部門獨立，那么測試人員就不確定自己測試的模塊是由哪位開發(fā)人員負責的，在這種情況下，測試人員統(tǒng)一把問題指派給項目組長或經理，由項目組長（或經理）對問題進行確認后再次分配給相應的開發(fā)人員。有些測試人員是穿插到不同研發(fā)團隊中的，所以對不同的開人發(fā)員負責的開發(fā)模塊非常清楚，這個時候就可以將問題直接

12、指派給相應的開發(fā)人員。也有一種情況，本來此問題應該由A開發(fā)人員負責，但由于A開發(fā)人員的調離或辭職，些問題為轉交給其它人員處理?！胺峙洹睆娬{是上級對下級；“轉交”強調的是平級之間。 確認缺陷當開發(fā)人員接到一個缺陷時，首先是對其進行分析與重現(xiàn)，如果對其進行分析發(fā)現(xiàn)不是缺陷（可能由于測試人員不了解需求）或無法對此問題進行重現(xiàn)，那么就需要將此問題反回給測試人員，并注明原因。如果確認為缺陷則需要對其進行處理。 推遲處理在處理問題之后，還需要進行一次判斷，是否需要推遲處理，有些需求已經確認了是問題，由于其可能在極端情況下才會出現(xiàn)，或需要對系統(tǒng)架構進行改動，或其優(yōu)先級非常低，所以暫時不需

13、要對此問題進行處理（或到下個版本進再進行修復）。 固定對于推遲處理的問題可以暫時進行固定（“固定”為QC中的叫法。）一般固定的問題需要經過項目經理與測試經理協(xié)商后才能固定。 處理缺陷開發(fā)人員在確認完一個問題需要處理時，那么就對其進行處理工作。（例如，redmine 是支持處理人時時更新問題處理進度的，如 已處理30% ，已處理80% 等，當然，對于短時間內可以修復的問題就沒必要時時的去更新處理進度。） 回歸缺陷回歸缺陷對于測試人員來說是非常重要的工作，其有三個入口兩個出口。確認非缺陷問題：對于提交的一個缺陷，開人員處理為非問

14、題或無法重現(xiàn)，然后直接轉交給測試人員回歸。測試人員再次確認，如果真如開發(fā)人員所說，則將問題關閉。如果非開發(fā)人員所說，是由于問題描述模糊或其它原因喂重現(xiàn)問題，則再次注明原因轉給開發(fā)人員。確認修復問題：對開發(fā)人員修復的問題再次進行確認，確認能過，則關閉問題。確認不通過，將問題再次打開并轉給開發(fā)人員。確認固定問題：有計劃的對固定問題進行確認，有些固定問題隨著時間的推移，版本的更新或已經不存在了，對這類問題應該及時關閉。有些固定問題依然存在且變得緊急，對于這類問題應該及時打開交給開發(fā)人員處理。 關閉缺陷對于已經修復的缺陷進行關閉，這也是一個缺陷的最后一個狀態(tài)。   注1：  文中提到了產品與項目，好多人分不清項目與產品，各自有各自的理解。我個人從用戶群上來劃分。如果面向的是特定客戶的需求，那么稱其為項目，如某醫(yī)院的醫(yī)療系統(tǒng)，某公司的管理系統(tǒng)。面向大眾用戶且長期運營的需求，稱為產品，如，某網站，某網絡游戲。如果小A讓我給他做一個網站呢