軟件測試中怎么判斷是不是bug，該不該提交

如何對進行缺陷管理那？

一般來說，明顯的錯誤（如程序不能繼續運行，出現明顯的錯誤提示框，數據存儲錯誤等）大家都知道肯定是bug，經常有疑問的是對于期望結果模糊，GUI（界面，操作模式等）不友好，對比其他的軟件的問題。
        由于工作的原因，參與了項目的一些開發過程，發現其實如果從開發的角度看看問題，就更容易下定提交bug的決心的。根據bug的來源，以下是我的一些總結：
1。由于代碼引起的bug
        所有的程序都會有bug,而且所有的程序員都會制造bug.這個道理如同bug是不可能被完全消滅一樣.對于一般的開發人員，經常出現的問題是由于沒有良好的編程習慣和技術能力。每個人從新手到高手都是有個階段的，成長的過程總是充滿錯誤的。開發人員多少會在修改bug的過程中成長。有些可能他們認為無法實現的操作是有可能實現的。所以這種情況要提交bug，即使不能修復，開發人員也會在bug里填寫理由，這樣對測試人員和開發人員都是有利的。
        那么對于高級的開發人員，低級錯誤的發生概率相對來說少很多，大多的bug是由于功能定義不清晰,完善或是架構，語言的局限引起的。有些嚴重的問題大家可以一起商量解決的.

2。項目時間緊迫造成的bug
        基本上每個項目都有加班的時候，開發人員在緊迫的時間里能做的就是盡可能的完成功能需要要求的功能，主要的功能。然后有時間再去通過修復bug來完善代碼。所以測試人員也不要詫異為什么會有那么多的bug，要作的就是盡可能的提交你所發現的bug。
        在我參與的開發中，項目經理經常會詢問開發人員的進度，如果他發現你已經實現了某一個模塊功能需求的功能后不是馬上開始下一個模塊的開發，而在花時間在竭力地憑著自己的猜想去完善模塊時，項目經理一定會要求你把模塊提交給測試人員測試，并馬上開始下一個模塊的開發

3。項目定義模糊造成的問題
        有些項目在開始編碼時可能只是一個大概的項目定義，甚至連具體功能的定義都不是很清楚.有時客戶對產品的最終結果都不清晰，需要一個有形的東西讓自己不斷的開發出自己的需求。那么這時開發人員大多都是根據自己的經驗或常識來實現代碼。
        還有就是大多數地需求和設計文檔不是面面俱到,只是描述了主要的業務定義.對于一些非主流或異常的處理并沒有詳細的定義.很多情況下程序在負面的操作時就會出現錯誤.
        測試人員可能就會發現很多不合理或和其他軟件不同造成的用戶界面的問題，或者有時更會發現負責代碼實現的開發人員誤解了需求定義人員對功能的解釋，甚至從從源頭上需求定義人員對功能就存在誤解。

        雖然有很多原因會引發bug,但是不管什么原因測試人員都要提交自己認為是問題的問題,即使后來發現bug是由于某種局限造成的，但對于自己乃至整個項目組都是一個財富。
        只是在bug提交的時候要切記中立客觀,對事不對人.即便開發人員拒絕修改bug,都應該不卑不亢的詢問原因.如果還有問題就讓你們的上級決定,他們會本著對項目考慮的原則從大局上把握好問題的.[Page]

        以上的我在開發過程中的一些總結。工作這么長時間，角色也不斷在轉變，發現自己剛進測試這一行業的有些想法是錯誤的。而且體會最深的就是在從別人的角度多去思考問題，這樣有些問題根本就不是問題。 
        開發和測試的關系永遠都應該是水乳交融的，互相促進的。建議大家在出現問題的時候多想想為什么會出現從這樣的問題，問題最終是如何解決的，這樣才不失為經驗積累的好方法。

原文轉自：http://www.kjueaiud.com