我眼中的bug管理 軟件測試
作為一名測試人，必須要面對其中一個(gè)就是bug，bug有很多方面，細說(shuō)下我眼中的bug：
bug的提交：如何提交bug是很有學(xué)問(wèn)的，比如以前我就曾經(jīng)遇到過(guò)這樣的情況，一個(gè)頁(yè)面上的幾個(gè)樣式問(wèn)題提了幾個(gè)bug，遭到批判說(shuō)，可以提交一個(gè)bug，被教育說(shuō)并不是bug越多越好云云，其實(shí)我不是這樣的意思，因為之前遇到過(guò)把幾個(gè)類(lèi)似的bug提到一個(gè)里面，結果只改一處就把bug fixed了，因為bug沒(méi)有修復完整，那么我只能reopen了它，但是這樣又導致了高的reopen率，我好為難!怎樣提交bug才能把這兩個(gè)方面平衡到呢?我后來(lái)采用的方式，提了一個(gè)bug，在備注中說(shuō)明，共有*個(gè)問(wèn)題，請仔細修復后再fixed。因為現在要求每個(gè)開(kāi)發(fā)在修復bug后一定要填寫(xiě)備注，他在填寫(xiě)時(shí)必定會(huì )看到我寫(xiě)的內容，如果仍有其他情況發(fā)生，那么也就沒(méi)有辦法了，以后只能再提交多個(gè)bug來(lái)杜絕此事。
bug的嚴重程度及發(fā)現難度：因為這兩個(gè)字段可能會(huì )影響到開(kāi)發(fā)的KPI，一個(gè)季度或半年中，某個(gè)開(kāi)發(fā)同學(xué)的嚴重bug率及容易發(fā)現的bug率是多少，會(huì )多多少少影響到開(kāi)發(fā)的KPI，所以當我們選擇這些時(shí)要慎重，原則就是公平，是就是，不是就不是，不要帶有私人情感，比如我跟某某開(kāi)發(fā)關(guān)系不錯，還是不要這樣選擇了類(lèi)似的，這樣會(huì )對其他同學(xué)很不公平，而且這樣就是縱容，縱容的結果就是ta的質(zhì)量越來(lái)越爛，辛苦的還是測試。
bug的流轉：某些情況下，我們的bug并不會(huì )很順利的關(guān)閉，驗證之后沒(méi)有修復的reopen掉;提交之后開(kāi)發(fā)無(wú)法重現的，會(huì )later掉;由于一些配置等情況的可能會(huì )產(chǎn)生一些無(wú)效bug;多人測試時(shí)又可能是重復的bug;林林總總的情況，導致我們提交bug時(shí)也要非常小心，畢竟測試產(chǎn)生過(guò)多的無(wú)效bug也是一種測試技能的缺失，無(wú)法重現或很難重現的也算是測試在提交bug時(shí)未能找到規律導致的，也是要避免的;那么說(shuō)到bug流轉，最需要關(guān)注的就是流轉到later狀態(tài)的bug，本來(lái)later意味著(zhù)本次項目中不修復，以后再修復，但是很多時(shí)候會(huì )忘記掉還有這樣一個(gè)bug在，等到出了問(wèn)題才又想起來(lái)，這個(gè)是很壞的一種情況，好的做法是在項目之后及時(shí)梳理later的bug，提早安排在后續工作中修復。
bug的根因：以往提交bug，提交時(shí)描述現象就OK了，等著(zhù)驗證。但是我倒是希望不管是新手還是老手，能分析bug的根因是很重要的，從某個(gè)方面可以看出來(lái)你所對應的開(kāi)發(fā)在開(kāi)發(fā)習慣上會(huì )有哪些陋習，一般會(huì )有規律可循，再有就是尋找bug的根因對理解系統實(shí)現是非常有幫助的，或許對大部分測試同學(xué)來(lái)講可能會(huì )比較困難，我會(huì )建議大家從簡(jiǎn)單的分析入手，了解了程序結構和實(shí)現后，慢慢深入，肯定會(huì )大用幫助。我也一直會(huì )努力去這樣做。
bug的統計和分析：不管是做項目也好，季度總結也好，一個(gè)里程碑上對bug進(jìn)行統計分析是非常必要的，從幾個(gè)方面講：一是將bug歸類(lèi)，總體哪個(gè)類(lèi)型的bug比較多，bug歸類(lèi)可以從多方面(比如按功能模塊分，或者按開(kāi)發(fā)人員分，按測試人員分)，你需要考慮的角度不同就可以進(jìn)行不同的統計。二是提煉某類(lèi)bug可以找出解決此類(lèi)bug的方案，以保證后續中不再發(fā)生這樣的bug，可能更多需要從開(kāi)發(fā)的角度去做這件事情。三是找到發(fā)現某類(lèi)bug的統一解決方案，比如我寫(xiě)怎樣一個(gè)小工具可以批量找出這樣的bug等等。個(gè)人認為bug統計是可以提高后續質(zhì)量很重要的手段。
最后一點(diǎn)是我們要一直去思考的問(wèn)題：如何發(fā)現一些隱藏深的bug呢?就需要對測試技能和業(yè)務(wù)、程序實(shí)現的熟悉程度，越是在這幾方面掌握的多，越是可以通過(guò)各種手段綜合發(fā)現較深程度的bug。比如web測試，你是否關(guān)注了每次請求和返回信息?頁(yè)面反應正確時(shí)，數據庫是否正確?我們就曾發(fā)現過(guò)，頁(yè)面什么問(wèn)題都沒(méi)有，但是數據庫存儲的參數卻多了很多重復的為問(wèn)題。各類(lèi)測試方法和技術(shù)在不同領(lǐng)域的測試不盡相同，大家可根據自己的經(jīng)驗進(jìn)行總結，去外部進(jìn)行學(xué)習，多多益善。
簡(jiǎn)單的是就只如下：
1、測試人員可以利用Bug管理系統提交自己發(fā)現的bug，提交的信息一般包括測試環(huán)境(操作系統、語(yǔ)言等)、使用的測試產(chǎn)品版本號，bug類(lèi)型，bug嚴重程度，bug重現步驟，期望行為/實(shí)際行為，附加描述信息，附件，屏幕截圖或錄像。測試人員提交這些信息的目的是盡可能地幫助開(kāi)發(fā)人員重現bug以便調試;
2、測試人員可以把bug直接提交給負責相關(guān)模塊的開(kāi)發(fā)人員，也可以提交給開(kāi)發(fā)組長(cháng)由其將bug分發(fā)到相關(guān)開(kāi)發(fā)人員。
3、開(kāi)發(fā)人員收到bug系統發(fā)來(lái)的bug分配通知后，可以登錄系統查看bug詳情。在對bug進(jìn)行修改后，可以將bug重新提交回測試人員。
4、開(kāi)發(fā)人員提交的bug修改代碼，在團隊編譯系統將其編入最新版本后，自動(dòng)將改bug信息中的修改版本號更新，然后通知測試人員可獲取最新版本進(jìn)行驗證。
5、測試人員如驗證無(wú)誤，可關(guān)閉bug;否則可重新返回開(kāi)發(fā)人員修改。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
