【轉】如何對待測試中不能重現的BUG

如何對待測試中不能重現的BUG

作者:謝金花

在測試過程中,我們總會遇到一些偶然發生的、不能重現的BUG,或者在測試人員那裏可以重現,但是在開發人員處卻不能重現的BUG。而且偶然發生的“無法重現”的BUG多半是“計劃外”的。無論站在開發人員還是測試人員的角度,都不願意遇到不能重現的BUG,因爲這意味着要花更多的時間去查找原因和修改BUG,甚至短期內無法修復,需等待以後再次出現或許才能解決。

一、一般情況下,BUG不能重現的原因主要有以下幾點:

(1)環境不一致

這是BUG不能重現的主要原因之一。在開發人員認爲這是無效的BUG裏面,估計至少有80%的BUG是因爲環境不一致的原因造成的。這既包括開發環境和測試環境的不一致,也包括開發環境和系統的實際運行環境不一致。

BUG產生是有一定原因的,它的重現也需要一定的環境。如果沒有相應的環境,那麼你可能很難重現這個BUG。

從廣義上來說,保證或影響系軟件的任何因素都是環境。例如,硬件的配置、軟件的設置、網絡的帶寬、網速等。通常,環境中的軟件因素有:系統的Build、 Application Server的類型和Version、Operation System 的語言和Version、瀏覽器的語言和Version等。

就拿我們某一項目來說:在V1.0.5版本的系統測試中,發現某一模塊功能出現問題,將這個問題提交到開發人員處,結果開發人員無法重現這個問題,且在開發人員處,該模塊功能正常,查找了原因很久,發現可能是版本升級導致,於是將版本回滾到之前的版本,功能恢復正常。

諸如此類由於環境不一致的原因導致的不能重現的BUG,大部分是在開發人員那不能重現,小部分是在測試人員處偶然出現,找不到規律。所以,這就要求我們測試與開發的環境要分開,測試要有自己的獨立環境,且測試環境要保持乾淨、無毒。

(2)瀏覽器的不當設置

對於Web測試來說,瀏覽器的設置又是對重現BUG起着重要的作用。下面的幾個圖片說明了瀏覽器的幾個關鍵設置:



  

圖1:Internet臨時文件的設置


 
圖2:“高級”選項的設置

說明:在“高級”選項中,對測試起重要作用的是“禁止腳步調試”(不選擇,即前面不要有勾)和“顯示每個腳本錯誤的通知”(選擇它,即前面要出現勾)。

這些設置對重現有關腳本錯誤的BUG起着重要的作用。根據這些腳本錯誤的通知,開發人員可以快速發現代碼中的錯誤,並及時修復它。

下面講解某一項目中由於瀏覽器設置引起的bug不能重現的例子:

有次版本發佈之後,從領導那邊反饋回來一個bug。根據以往流程,我們首先對這個BUG進行驗證,可是無論如何都重現不了該BUG,於是找到項目經理,讓他重現下該BUG,仍舊不能重現。最後項目經理找到領導,瞭解其操作過程,才發現其瀏覽器字體設置爲“微軟雅黑”,而我們的瀏覽器字體爲默認字體。最後將字體修改爲“微軟雅黑”後該BUG才重現。

(3)內存泄露

某些系統長期運行後出現運行速度慢、反應遲鈍等現象,其中一個主要的原因就是內存泄露。有的開發人員沒有養成及時回收內存的習慣,結果系統在不斷地申請內存空間,卻沒有一點內存釋放。這類錯誤在短期內不會出現,但當系統長期運行時就會出現,並且由此會引發一系列的問題。此類問題只有經過長時間的運行測試, 纔可能會被發現。

這個問題在我們某一項目中也存在過,由於該項目是採用Java語言開發的,Java可以自動回收內存,這就導致了開發人員對及時回收內存問題的忽略,使用時出現內存泄露。

(4)函數接口類型不匹配

此類錯誤難以重現,並且難以發現它的真正原因,一般只有在查看源代碼後才能發現。某些類型的數據會被系統自動轉換,一般也不會出現錯誤;但有些數據被截斷或被強制轉換成另外一種數據類型時,會出現一些潛在的錯誤。在集成測試時此類錯誤最有可能發生。

二、出現不可重現的BUG時,我們應當本着以下原則,實現BUG的重現工作:

(1)重現的人員: 缺陷的重現工作,最好由測試人員去完成,一方面,測試人員的文字描述其實很難包括所有的現象信息,讓開發人員重現的難度很大,另一方面,測試人員的重現更有說服力和更快捷。

(2)重現的次數:每個難重現的缺陷,由發現該缺陷的測試人員連續重複測試300次,如果還不能重現,將缺陷狀態改爲closed;

(3)延長測試時間,努力找到規律。如果市場緊急,由公司級領導特批,相當於高層領導評估風險,就可以先發布軟件,但測試和整改繼續,留待問題解決後下一版本軟件升級;

(4)若確實無法重現,轉交項目經理做延遲處理,繼續跟蹤,若保留一個月都無法重現的,可先關閉,以後重現時再Reopen;

三、遇到無法重現的BUG時,我們應該做到如下幾點:

(1)一定要提交

把不可重現的BUG記錄下來,以後再遇到的時候可能就會了解發生的原因。同時盡力去查找出錯的原因,比如有什麼特別的操作,或者一些操作環境等。而且程序員對程序比測試人員熟悉的多,因爲測試人員看到的只是程序的外部,無法深入程序內部,也許你提交了,即使無法重新,程序員也會了解問題所在。無法重現的問題再次出現後,也可以直接叫程序員來看看問題。

但是針對一些比較嚴重的、隨機發生無法重現的bug,測試人員提交上去後,有可能會出現以下三個情形:a.開發人員試圖重現,重現不出,Reject回來;b.開發人員找不到規律,所以不去解決,問題一直處於Open狀態;c.開發人員因爲問題難以解決,所以直接Resolved回來,覺得反正是偶發的,先改成解決狀態再說。

(2)儘量詳細的描述缺陷

儘可能的詳細記錄BUG產生的相關信息;如重現頻率,發生情況並有截圖,操作步驟,軟件的版本,發生錯誤時的各種變量、內存、存儲器等存儲的數據內容,軟件出錯時的軟硬件環境等。

(3)由開發人員進行人工代碼走查和工具靜態檢查

無法重現的代碼找對系統最熟悉的開發人員重新Review代碼,最好是多人一起查。查代碼還找不出來,就要檢查操作系統、應用服務器及其環境是否有問題,是否有兼容性問題。或者採用靜態檢查工具(如pclint,splint等工具)檢查代碼,消除所有的error與warning。

(4)查看是否正確設置瀏覽器的選項

對於瀏覽器設置不正確引起的BUG,設置好瀏覽器選項,就能使BUG重現。

總之,在遇到某些嚴重的、卻又無法重現的Bug,應積極回憶BUG的症狀和所有的環境因素,一絲一毫的細節都不要錯過。並與開發人員、DBA、系統設計人員、項目經理等一起分析那些環境因素,根據以往的經驗分析影響此Bug重現的重要因素,並在相同的環境上安裝同樣的系統進行測試,以驗證所做的猜測。而對於某些無法重現、但嚴重程度不是很高的Bug,可以暫時只作記錄、而不必花費大量的人力和物力去分析。如果下次又出現了,那麼根據發生的頻率再去分析是否需要跟蹤此Bug。如果需要跟蹤它,那麼在它又出現後一定要立刻對當時的環境進行截圖,如錯誤信息、界面、日誌等。這樣也利於開發人員定位、分析它,從而準確、快速地修復它。如果條件允許,測試人員應立即保護現有環境,並邀請相關的開發人員和系統分析人員一起研討產生此問題的原因和解決方法。

 

轉自:http://express.ruanko.com/ruanko-express_34/technologyexchange8.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章