軟件測試工作中的常見難題及對策

　　軟件測試工作中的常見難題及對策

　　一、不能重現的bug該如何處理?

　　bug應該可重現，問題重現才可以讓開發快速原因定位并解決問題。在測試的過程中偶爾會碰到一些不能重現的問題，對于這類型的問題應該：

　　1、首先，測試人員應該想辦法重現，如果實在不行，也應該將bug產生的條件和出現的問題做一個記錄，建議開發根據問題的描述來進行原因定位。當然了，即使開發解決了問題，如果不能重現，也不能有效地驗證。

　　2、根據經驗，一般的問題的產生都可以找到重現的規律的，只是看花的時間和成本。嚴重的bug一定要想辦法找到原因，而優先級別低的問題可以考慮成本先將bug擱置，以后重現的時候再讓開發解決。通常，不能很快找到規律的問題都是一些比較重要且奇怪的問題，開發一般不能根據描述進行定位，此時測試工程師應該有很強的責任心和信心想辦法重現問題。

　　3、關于bug的重現，有一點非常重要的是，一定要開發人員與測試人員很好地配合，bug的重現效率才會更高，測試人員千萬一個人不要悶頭悶腦地在那冥思苦想，而應該及時把問題和看法與開發人員交流，畢竟程序是他們寫的，大家一起探討可以有效地促進問題的解決。復雜的問題并不是一個人就可以輕易就解決的，而是一個團隊的結晶，要懂得充分利用團隊的力量。

　　4、注意bug出現的時候的日志，通常程序日志都包含著很重要的信息，從那些信息中分析出現問題的條件，并嘗試重現。

　　5、碰到問題時，應該盡量將出錯信息作為關鍵字在互聯網搜索，有可能別人也碰到了類似的問題并解決了，即使沒有人解決過相同的問題，在互聯網上也有很多資料，可以幫助你獲取靈感。

　　6、必要時，寫一些簡單的測試程序來幫助重現問題。

　　下面我會講一個在實際測試過程中不能重現的問題的解決方法與過程，可能這個問題對于剛入門的人來說有點難理解，不要緊，你不需要看明白問題的原因和代碼，但需要學會這個復雜的問題的解決方法，并應用到實際的測試當中。

　　1、問題的描述：某短信發送模塊出現core，但由于core信息紊亂不能定位到出錯原因且無法重現導致core的規律。

　　2、問題重現過程：

　　(1)使用gdb對core原因進行追蹤，發現core信息中含有的錯誤信息為：#0 0xff1c5a18 in _malloc_unlocked () from /lib/libc.so.1

　　#1 0xff1c57f0 in malloc () from /lib/libc.so.1

　　(2)以這兩句core信息作為關鍵字在google上搜索，一些文章上類似問題的分析中獲取經驗，初步推斷是由于內存溢出而產生的core

　　(3)將這些文章轉發給開發負責人，并討論可能導致的原因，開發從文章中獲取靈感，寫測試程序對推斷進行測試

　　(4)同時測試人員詳細分析程序運行日志，發現出現core之前，短信編碼為平時少見的245，而短信的長度則是一個臨界值140字節

　　(5)測試人員從程序運行日志中得到啟發，發送一條短信編碼為245且短信長度為140字節的短信，果然出現了相類似core

　　(6)開發人員分析根據測試結果分析導致core的原因： 調用sprintf打印短信內容的時候導致了內存溢出，而這樣溢出會覆蓋它后面的內存塊的內存管理區域，在緊接著的malloc操作中就會發生段錯誤，從而導致了core的出現。

　　這個問題的原因，因為多人的參與，得到了準確的定位和解決，雖然原因是我最先發現的，但問題的準確定位和解決并不是歸公到某個人，而是大家一起努力的結果，團隊的結晶。

　　二、暫時無法解決的問題

　　在測試的過程中，開發可能會在bug回復的時候告訴你暫時無法解決該問題，這個時候作為測試的負責人，應該怎樣處理呢?

　　1、首先，確實問題是否真的無法解決，解決需要付出的成本有多大。

　　2、其次，確認問題的嚴重性，如果此類問題不解決，是否會導致嚴重的后果。

　　3、對于會導致嚴重后果的問題，一定要堅持讓開發解決，并且想辦法幫助開發解決問題。測試人員應該主動協助開發人員找到問題的原因和解決方法，并充分利用團隊的資源，請教對這個領域比較有經驗的工程師，大家一起討論問題的解決方法。

　　4、對于對系統不會造成危害的問題或雖然有微小的危害但修改成本過高而又可以人為避免，則可以將問題遺留到下一版本解決或關閉這個bug，并在bug報告中說明原因和注意事項。

　　5、這個時候，測試人員的態度非常重要，在告訴開發這個問題一定需要解決的時候態度是溫和的堅定，并讓他意識到問題的嚴重性。試想想，如果你板著臉孔冷冰冰地丟給開發一句“這個問題一定要解決!”扭頭就走，他會是怎樣的反應呢?可以笑的時候就笑吧，大家都是工作，不要將工作的氛圍搞得太僵，大家在一個和諧的環境中工作才會保持愉悅的心情。

　　6、發現問題之后測試人員可能心里會嘀咕“反正這是開發的問題就讓開發去折騰吧”，如果你一不小心這樣想了，那就偷偷的想幾秒鐘好了，這個念頭閃過之后，作為bug負責人的你怎么忍心看著開發一個人手忙腳亂呢?測試和開發其實是一個整體，在這個整體中的每個人都有責任去解決問題。

　　三、測試工程師和開發工程師的意見不一致

　　1、首先，客觀地比較自己的建議和開發的意見哪個更好。

　　2、如果開發的方法的確是比較優化，那就應該接受開發的意見;如果經過對比之后還是覺得自己的建議更好，那就堅持自己的建議，并詳細給開發解釋你的建議，通過對比兩者之間的差別婉轉地告訴開發你的建議值得采納。

　　3、如果雙方還是對各自的意見相持不下，可以跟項目經理一起討論，由項目經理衡量應該采取哪種處理方法。不過，有時候，項目經理也不一定站在你這邊，你可能還需要花腦筋說服項目經理或被項目經理說服。

　　4、當然，這個問題的討論前提是問題值得花時間和精力去研究討論，如果是一些比較簡單或次要的問題，就沒必要花那么長的時間去計較了，放過開發吧，也許他真的覺得這個問題沒必要這樣修改或者是他也修改到很累很煩了，這么簡單的一個問題何不讓開發輕松一下?

　　四、開發工程師不配合工作

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