淺談軟件測試中的Bug 軟件測試
引言
現在軟件開發公司越來越重視產品質量，很多軟件公司紛紛成立了自已的測試團隊，測試在軟件開發的周期中顯得越來越重要。軟件測試是為發現錯誤而運行一個程序或者系統的過程。軟件測試的主要目的是發現軟件中的錯誤或缺陷。這里軟件中的一個錯誤或缺陷就是一個Bug。軟件測試的過程就是不斷的尋找Bug，然后排除Bug。微軟的研發管理中，它的Bug管理系統是居于核心地位的。測試人員只要發現問題就立即新建一個Bug予以跟蹤并指派給相關的開發小組長，開發人員會根據Bug的詳細信息找到問題所在，修改程序解這個Bug并把Bug返回給當初的測試人員。閱讀每個Bug，你可以詳細的看到大家解決這個問題的完整思路。一般情況下，在分析、設計、實現階段的復審和測試工作能夠發現和避免80%的Bug，而系統測試又能找出其余Bug中的15%，最后的5%的Bug可能只有在用戶的大范圍、長時間使用后才會曝露出來。因為測試只能夠保證盡可能多地發現錯誤，無法保證能夠發現所有的錯誤。 一、軟件Bug涵義Bug一詞的原意是“臭蟲”或“蟲子”。但是現在，在電腦系統或程序中，如果隱藏著的一些未被發現的缺陷或問題，人們也叫它“Bug”，這是怎么回事呢？
原來，第一代的計算機是由許多龐大且昂貴的真空管組成，并利用大量的電力來使真空管發光�？赡苷怯捎谟嬎銠C運行產生的光和熱，引得一只小蟲子Bug 鉆進了一支真空管內，導致整個計算機無法工作。研究人員費了半天時間，總算發現原因所在，把這只小蟲子從真空管中取出后，計算機又恢復正常。后來，Bug這個名詞就沿用下來，表示電腦系統或程序中隱藏的錯誤、缺陷、漏洞或問題。
與Bug相對應，人們將發現Bug并加以糾正的過程叫做“Debug”，意即“捉蟲子”或“殺蟲子”。遺憾的是，在中文里面，至今仍沒有與“Bug”準確對應的詞匯，于是只能直接引用“Bug”一詞。雖然也有人使用“臭蟲”一詞替代“Bug”，但容易產生歧義，所以推廣不開。
后來就直接用bug 在現在很多的軟件測試中 都用Bug來說明那些問題。
二、Bug產生的原因
測試遺漏
測試的設計主要體現在測試用例的設計，以及通過測試策略將這些測試用例同測試計劃，測試執行，還有測試結果數據的收集整理結合在一起執行，由于測試人員水平的高低，測試工具使用的熟練程度，以及對所測試對象的理解深度等原因，測試設計很難完善，主要表現在測試用例設計的不全面，存在遺漏，或者測試方案的不周密，以及可能的測試人員執行時產生的偏差等等，這些測試方面的遺漏和偏差都可能導致軟件問題沒有及時發現，造成測試的遺漏。
．設計及修改原因
軟件需求或者設計方案經常被更改，特別是變更沒有導入一套成熟的變更管理體系的情況下，每次變更無疑于埋下大量的地雷，這些都為BUG提供滋生的環境。另外后期修改維護中對BUG未做準確的分析定位，修改方案未審核，或者修改過程中程序員出現“頭痛治頭，腳痛治腳”，“補了東邊漏了西邊”等不良修改過程中引發出新的問題，也是導致BUG被擴大的原因。
．BUG的概率性及偶然性
有些BUG的出現呈現概率的特性，它需要反常數量，頻率，或者資源的方式下執行系統才能被查找，即通常所說的壓力測試。
．BUG的潛伏性及階段性
有時候，BUG實際存在但由于觸發它的條件不滿足從而呈現潛伏狀態只能在某個階段才能被發現，單元測試，集成測試，系統測試等階段測試重點關注的對象就不同，如集成測試可以發現單元測試通過后的模塊之間接口上的錯誤。特別象嵌入式系統中多進程以及多任務處理問題、系統容錯性問題、內存問題等等，這些情況下表現出的潛伏性更加復雜多變，導致發現這些BUG需要一個特別長的周期或者需要某一特定測試環境能被有效搭建的情況下才能查找出。
．BUG的隱蔽性和周期性
該BUG實際存在但由于其他BUG的存在導致它所在的代碼沒有得到執行，因而無法暴露該BUG，這種情況在以黑盒測試為主的測試中表現尤為突出，只有通過周期性的BUG修復及測試才能發現該類BUG。
三、軟件測試中對待BUG的態度 在軟件測試過程中，我們需要根據各種度量數據從不同角度來對被測軟件的質量進行分析評估，找出軟件的質量薄弱點、評價軟件發布的風險、預估軟件測試結束的時間等等，這些分析評估涉及到各種角度、不同指標，也有一些從工程中總結的分析模型。量化評估，最重要的一點是經驗，同時需要大量統計工作作為鋪墊。 下面我主要從bug統計來說一下我的經驗。 1。hoih項目數和摘出bug數預測 一般來說我們可以根據軟件代碼行數來粗略估計一個產品可能包含的bug數目和需要的測試項目�，F在有些公司流行每千行bug數的標準來制定測試計劃，這個標準是通過以往測試經驗總結出來的，一般來說，同類的產品，尤其是同一個開發流程的產品，這些數值不應該相差太多，如果相差一個數量級以上，我們幾乎可以說，要么是QA出問題了，要么是開發出問題了。 2。測試bug分級 使用bugzilla或者Jira之類的缺陷管理系統何以很容易的實現bug分級，一般至少有Fatal, Major, Minor, cosmatic這幾種，還有一種特殊的叫做blocker，意思是這個bug會影響測試進度。產品發布前，可以根據實際情況，定一個界限級別，比如要求新出Major為0，并且所有已有的Major全部close。 3。測試bug收斂 量化評估必不可少的是bug收斂，這個要通過統計每日新出bug并跟蹤已有bug制作收斂曲線來實現。收斂曲線的形狀發散表明目前產品極其不穩定，收斂曲線開始收斂表示目前產品趨于穩定，完全收斂之后可以認為是發布的時機。 4。測試bug分布 bug分布是決定下面測試重點的一個重要的參考數據。首先還是需要統計，找出所有已有的不同級別的bug在各個模塊的分布，假如ABC三個模塊，A模塊占了bug的60%，C模塊占了bug的8%那么，我們可以得出這樣的結論，軟件的不穩定瓶頸在于A模塊，是一個薄弱點，需要開發人員集中力量對應。但是C模塊也是一個可疑模塊，因為出現bug率太低，如果不是開發的太好就是測試方法不當。 5。測試bug的周期 一個bug的生命歷程是一個完整的輪回，從他出生(open)開始，到調查(Accept)到修復(Fix)，再到確認(Verify)是最簡單的路線，這個周期越短，說明項目進展越順利反之則意味著項目進度目前有很大的阻礙。 6。降級bug數 降級bug的多少對于軟件質量評估也是一個重要參考標準，降級bug也就是由于修正一個bug又作了一個新bug，降級bug數目過多意味著現在的產品在越修越壞。 一個新的QA團隊，在2，3，4，5，6步驟可能會有所迷惑，不知道閾值應該怎樣選但如果每次都堅持這樣做，很多次之后2，3，4，5，6會給這個團隊大量的經驗積累，完全可以做到看著統計圖估計出一個產品處于什么狀態，需要加強哪些方面等等。
文章來源于領測軟件測試網 http://www.kjueaiud.com/