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

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

發(fā)表于：2023-01-20來源：未知：Smilings點(diǎn)擊數(shù)：標(biāo)簽：

軟件測試工作中的常見難題及對策首先，測試人員應(yīng)該想辦法重現(xiàn)，如果實(shí)在不行，也應(yīng)該將bug產(chǎn)生的條件和出現(xiàn)的問題做一個(gè)記錄，建議開發(fā)根據(jù)問題的描述來進(jìn)行原因定位。當(dāng)然了，即使開發(fā)解決了問題，如果不能重現(xiàn)，也不能有效地驗(yàn)證。

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

一、不能重現(xiàn)的（bug）該如何處理?

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

1、首先，（測試人員）應(yīng)該想辦法重現(xiàn)，如果實(shí)在不行，也應(yīng)該將bug產(chǎn)生的條件和出現(xiàn)的問題做一個(gè)記錄，建議（開發(fā)）根據(jù)問題的描述來進(jìn)行原因定位。當(dāng)然了，即使（開發(fā)）解決了問題，如果不能重現(xiàn)，也不能有效地驗(yàn)證。

2、根據(jù)經(jīng)驗(yàn)，一般的問題的產(chǎn)生都可以找到重現(xiàn)的規(guī)律的，只是看花的時(shí)間和成本。嚴(yán)重的bug一定要想辦法找到原因，而優(yōu)先級別低的問題可以考慮成本先將bug擱置，以后重現(xiàn)的時(shí)候再讓開發(fā)解決。通常，不能很快找到規(guī)律的問題都是一些比較重要且奇怪的問題，開發(fā)一般不能根據(jù)描述進(jìn)行定位，此時(shí)測試工程師應(yīng)該有很強(qiáng)的責(zé)任心和信心想辦法重現(xiàn)問題。

3、關(guān)于bug的重現(xiàn)，有一點(diǎn)非常重要的是，一定要開發(fā)人員與測試人員很好地配合，bug的重現(xiàn)效率才會更高，測試人員千萬一個(gè)人不要悶頭悶?zāi)X地在那冥思苦想，而應(yīng)該及時(shí)把問題和看法與開發(fā)人員交流，畢竟程序是他們寫的，大家一起探討可以有效地促進(jìn)問題的解決。復(fù)雜的問題并不是一個(gè)人就可以輕易就解決的，而是一個(gè)團(tuán)隊(duì)的結(jié)晶，要懂得充分利用團(tuán)隊(duì)的力量。

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

5、碰到問題時(shí)，應(yīng)該盡量將出錯(cuò)信息作為關(guān)鍵字在互聯(lián)網(wǎng)搜索，有可能別人也碰到了類似的問題并解決了，即使沒有人解決過相同的問題，在互聯(lián)網(wǎng)上也有很多（資料），可以幫助你獲取靈感。

6、必要時(shí)，寫一些簡單的測試程序來幫助重現(xiàn)問題。

下面我會講一個(gè)在實(shí)際測試過程中不能重現(xiàn)的問題的解決方法與過程，可能這個(gè)問題對于剛?cè)腴T的人來說有點(diǎn)難理解，不要緊，你不需要看明白問題的原因和代碼，但需要學(xué)會這個(gè)復(fù)雜的問題的解決方法，并應(yīng)用到實(shí)際的測試當(dāng)中。

1、問題的描述：某短信發(fā)送模塊出現(xiàn)core，但由于core信息紊亂不能定位到出錯(cuò)原因且無法重現(xiàn)導(dǎo)致core的規(guī)律。

2、問題重現(xiàn)過程：

(1)使用gdb對core原因進(jìn)行追蹤，發(fā)現(xiàn)core信息中含有的錯(cuò)誤信息為：#00xff1c5a18in_malloc_unlocked()from/lib/libc.so.1

#10xff1c57f0inmalloc()from/lib/libc.so.1

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

(3)將這些文章轉(zhuǎn)發(fā)給開發(fā)負(fù)責(zé)人，并討論可能導(dǎo)致的原因，開發(fā)從文章中獲取靈感，寫測試程序?qū)ν茢噙M(jìn)行測試

(4)同時(shí)測試人員詳細(xì)分析程序運(yùn)行日志，發(fā)現(xiàn)出現(xiàn)core之前，短信編碼為平時(shí)少見的245，而短信的長度則是一個(gè)臨界值140字節(jié)

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

(6)開發(fā)人員分析根據(jù)測試結(jié)果分析導(dǎo)致core的原因：調(diào)用sprintf打印短信內(nèi)容的時(shí)候?qū)е铝藘?nèi)存溢出，而這樣溢出會覆蓋它后面的內(nèi)存塊的內(nèi)存管理區(qū)域，在緊接著的malloc操作中就會發(fā)生段錯(cuò)誤，從而導(dǎo)致了core的出現(xiàn)。

這個(gè)問題的原因，因?yàn)槎嗳说膮⑴c，得到了準(zhǔn)確的定位和解決，雖然原因是我最先發(fā)現(xiàn)的，但問題的準(zhǔn)確定位和解決并不是歸公到某個(gè)人，而是大家一起努力的結(jié)果，團(tuán)隊(duì)的結(jié)晶。

二、暫時(shí)無法解決的問題

在測試的過程中，開發(fā)可能會在bug回復(fù)的時(shí)候告訴你暫時(shí)無法解決該問題，這個(gè)時(shí)候作為測試的負(fù)責(zé)人，應(yīng)該怎樣處理呢?

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

2、其次，確認(rèn)問題的嚴(yán)重性，如果此類問題不解決，是否會導(dǎo)致嚴(yán)重的后果。

3、對于會導(dǎo)致嚴(yán)重后果的問題，一定要堅(jiān)持讓開發(fā)解決，并且想辦法幫助開發(fā)解決問題。測試人員應(yīng)該主動(dòng)協(xié)助開發(fā)人員找到問題的原因和解決方法，并充分利用團(tuán)隊(duì)的資源，請教對這個(gè)領(lǐng)域比較有經(jīng)驗(yàn)的（工程師），大家一起討論問題的解決方法。

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

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

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

三、（測試工程師）和開發(fā)工程師的意見不一致

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

2、如果開發(fā)的方法的確是比較優(yōu)化，那就應(yīng)該接受開發(fā)的意見;如果經(jīng)過對比之后還是覺得自己的建議更好，那就堅(jiān)持自己的建議，并詳細(xì)給開發(fā)解釋你的建議，通過對比兩者之間的差別婉轉(zhuǎn)地告訴開發(fā)你的建議值得采納。

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

4、當(dāng)然，這個(gè)問題