軟件測試到底要不要追究BUG發生的原因呢？ 軟件測試
軟件測試到底要不要追究BUG發生的原因呢？這個問題的爭議很多，有人認為尋找BUG的原因是開發的事情，軟件測試只要能發現BUG就夠了；還有人認為軟件測試可以盡自己所能盡可能的去尋找BUG的原因。到底哪個觀點正確？我個人認為這個問題是仁者見仁，智者見智，站在一個產品不同的層面看，會有不同的看法。這里所談到的觀點，也僅代表個人看法。
要搞清楚這個問題，先要明確幾個定義，首先要明確什么是QA？簡單從字面上理解是 Quality Assure（質量保證），CMM對QA的要求主要有下面幾點：保障制度體系；促使過程改進；指導項目實施；增加透明度；評審項目活動；審核工作產品；協助問題解決；提供決策參考；進行缺陷預防；實現質量目標。其次什么是軟件測試，軟件測試是根據軟件開發各個階段的規格說明和程序的內部結構而精心設計一批測試用例（即輸入數據及其預期結果），并利用這些測試用例去執行程序，以發現程序錯誤的過程。
而軟件測試人員就是這一過程的執行者。
從上面的定義可以看到，QA重點關注的不僅僅是質量，而是整個軟件過程，保證的首先是過程和體系，也就是說只有規范了過程和體系，才有可能做出好的產品。而軟件測試就是通過自己的活動，來給QA人員提供盡可能的有效的信息和數據，使他們能夠發現過程上的異�；蛘咧贫壬系牟煌字��？梢娷浖䴗y試的任務不僅僅是測試，還要把項目的異常情況向QA報告，所以只能報出BUG是不夠的。
其實QA和軟件測試的目的都是一樣的，就是盡可能的使發布出去的產品更加符合用戶的需要，盡可能的沒有bug。不同之處只是一個關注的是整個軟件過程，一個只是關注最終的質量。所以為了搞清楚軟件測試要不要追究 BUG發生的原因，先要明確的是弄清楚BUG發生的原因對整個軟件過程有什么好處，或者說對最終的質量有什么好處？
對于開發來說，一般是能夠重現這個BUG就夠了，這樣對于那些發生幾率在100％的bug來說，軟件測試人員只要詳細清晰的描述出bug發生的步驟，寫明bug的發生條件，執行這些操作的用戶的角色以及權限，使用的操作系統和瀏覽器，然后寫清楚實際結果和期望結果，基本上就差不多了，開發根據這些描述能夠知道是如何出現的問題，并且知道應該改成什么樣。到時候軟件測試人員（可能不是原來報BUG的那個人了）進行回歸測試時根據BUG的描述，也可以很清楚的知道這個BUG是否真的改好了。但是如果一個BUG的發生幾率不是100％，或者說在某些特定的條件下的發生幾率是100％，但是一般情況下都不存在。測試人員可能只是偶然發現這個問題，卻會認為是100％出現，報BUG時也就沒有指明這個問題出現的條件，開發看到這種BUG，根本無法重現，再打給測試人員，如此反復幾次，雖然最終問題得以解決，但是對于整個項目來說，卻是浪費了很多的時間。如果在發現問題時。能夠多試幾下，或者換個環境試試，可能就會找到發生幾率不是 100％的原因，比如非法數據，特殊字符，特殊用戶權限，特殊日期，或者在系統中還有其他自己不知道的參數的影響，或者是操作系統的問題，又或者是瀏覽器的設置問題，還有可能是瀏覽器的版本問題等等，尋找這些原因的過程，是一個自我提高的過程，也是積累自己測試經驗的過程，同時也是證明測試角色重要的過程，是證明測試人員價值的過程。
當然目前國內的軟件公司中測試人員的水平還不是很高，想看懂開發的代碼并且進行測試難度還比較大，所以我也不主張去看著開發的代碼進行測試，只需要在測試的時候，多考慮一下，尤其是出現問題的時候，多想想這個問題為什么會發生，會影響到系統中其他什么地方，還會有其他哪些地方有可能存在這樣的問題，這樣等到開發修改好之后，提交測試進行回歸檢測時也可以做到有的放矢，尤其是在回歸測試時間很短的情況下，如何進行有效的回歸測試，并且保證不漏掉重大隱患，我想和開發水平固然有關，但是關系最大的還是測試人員對系統的熟悉程度，以及是否具有軟件開發的思想。
追究bug的原因，不是一朝一夕的事，需要長期的摸索和總結，開始會很煩，可能還會很郁悶，但是慢慢的你會發現其中的樂趣，想一想當你報給開發一個 Bug的時候，隨著bug的報告還有一個詳盡的發生這個bug的條件數據，以及測試平臺等數據，開發根據這些很容易重現這個問題，會對測試人員的專業度有很大的認可，那時我想自己心里的成就感不是幾句話可以說完的了！
文章來源于領測軟件測試網 http://www.kjueaiud.com/
