測試常見面試題

1、一、不能重現(xiàn)的bug該如何處理？bug應(yīng)該可重現(xiàn)，問題重現(xiàn)才可以讓開發(fā)快速原因定位并解決問題。在測試的過程中偶爾會碰到一些不能重現(xiàn)的問題，對于這類型的問題應(yīng)該：1、首先，測試人員應(yīng)該想辦法重現(xiàn)，如果實在不行，也應(yīng)該將bug產(chǎn)生的條件和出現(xiàn)的問題做一個記錄，建議開發(fā)根據(jù)問題的描述來進(jìn)行原因定位。當(dāng)然了，即使開發(fā)解決了問題，如果不能重現(xiàn)，也不能有效地驗證。2、根據(jù)經(jīng)驗，一般的問題的產(chǎn)生都可以找到重現(xiàn)的規(guī)律的，只是看花的時間和成本。嚴(yán)重的bug一定要想辦法找到原因，而優(yōu)先級別低的問題可以考慮成本先將bug擱置，以后重現(xiàn)的時候再讓開發(fā)解決。通常，不能很快找到規(guī)律的問題都是一些比較重要且奇怪的問題，開發(fā)

2、一般不能根據(jù)描述進(jìn)行定位，此時測試工程師應(yīng)該有很強(qiáng)的責(zé)任心和信心想辦法重現(xiàn)問題。3、關(guān)于bug的重現(xiàn)，有一點非常重要的是，一定要開發(fā)人員與測試人員很好地配合，bug的重現(xiàn)效率才會更高，測試人員千萬一個人不要悶頭悶?zāi)X地在那冥思苦想，而應(yīng)該及時把問題和看法與開發(fā)人員交流，畢竟程序是他們寫的，大家一起探討可以有效地促進(jìn)問題的解決。復(fù)雜的問題并不是一個人就可以輕易就解決的，而是一個團(tuán)隊的結(jié)晶，要懂得充分利用團(tuán)隊的力量。4、注意bug出現(xiàn)的時候的日志，通常程序日志都包含著很重要的信息，從那些信息中分析出現(xiàn)問題的條件，并嘗試重現(xiàn)。5、碰到問題時，應(yīng)該盡量將出錯信息作為關(guān)鍵字在互聯(lián)網(wǎng)搜索，有可能別人也碰到了

3、類似的問題并解決了，即使沒有人解決過相同的問題，在互聯(lián)網(wǎng)上也有很多資料，可以幫助你獲取靈感。6、必要時，寫一些簡單的測試程序來幫助重現(xiàn)問題。下面我會講一個在實際測試過程中不能重現(xiàn)的問題的解決方法與過程，可能這個問題對于剛?cè)腴T的人來說有點難理解，不要緊，你不需要看明白問題的原因和代碼，但需要學(xué)會這個復(fù)雜的問題的解決方法，并應(yīng)用到實際的測試當(dāng)中。1、問題的描述：某短信發(fā)送模塊出現(xiàn)core，但由于core信息紊亂不能定位到出錯原因且無法重現(xiàn)導(dǎo)致core的規(guī)律。2、問題重現(xiàn)過程：（1）使用gdb對core原因進(jìn)行追蹤，發(fā)現(xiàn)core信息中含有的錯誤信息為：#0oxffic5ai8in_malloc_un

4、locked（）from/lib/libc.so.1#1oxff1C57foinmalloc（）from/lib/libc.so.1（2）以這兩句core信息作為關(guān)鍵字在google上搜索，一些文章上類似問題的分析中獲取經(jīng)驗，初步推斷是由于內(nèi)存溢出而產(chǎn)生的core（3）將這些文章轉(zhuǎn)發(fā)給開發(fā)負(fù)責(zé)人，并討論可能導(dǎo)致的原因，開發(fā)從文章中獲取靈感，寫測試程序?qū)ν茢噙M(jìn)行測試（4）同時測試人員詳細(xì)分析程序運(yùn)行日志，發(fā)現(xiàn)出現(xiàn)core之前，短信編碼為平時少見的245，而短信的長度則是一個臨界值140字節(jié)（5）測試人員從程序運(yùn)行日志中得到啟發(fā)，發(fā)送一條短信編碼為245且短信長度為140字節(jié)的短信，果然出現(xiàn)了相類

5、似core（6）開發(fā)人員分析根據(jù)測試結(jié)果分析導(dǎo)致core的原因：調(diào)用sprintf打印短信內(nèi)容的時候?qū)е铝藘?nèi)存溢出，而這樣溢出會覆蓋它后面的內(nèi)存塊的內(nèi)存管理區(qū)域，在緊接著的malloc操作中就會發(fā)生段錯誤，從而導(dǎo)致了core的出現(xiàn)。這個問題的原因，因為多人的參與，得到了準(zhǔn)確的定位和解決，雖然原因是我最先發(fā)現(xiàn)的，但問題的準(zhǔn)確定位和解決并不是歸公到某個人，而是大家一起努力的結(jié)果，團(tuán)隊的結(jié)晶。二、暫時無法解決的問題在測試的過程中，開發(fā)可能會在bug回復(fù)的時候告訴你暫時無法解決該問題，這個時候作為測試的負(fù)責(zé)人，應(yīng)該怎樣處理呢？1、首先，確實問題是否真的無法解決，解決需要付出的成本有多大。2、其次，確認(rèn)

6、問題的嚴(yán)重性，如果此類問題不解決，是否會導(dǎo)致嚴(yán)重的后果。3、對于會導(dǎo)致嚴(yán)重后果的問題，一定要堅持讓開發(fā)解決，并且想辦法幫助開發(fā)解決問題。測試人員應(yīng)該主動協(xié)助開發(fā)人員找到問題的原因和解決方法，并充分利用團(tuán)隊的資源，請教對這個領(lǐng)域比較有經(jīng)驗的工程師，大家一起討論問題的解決方法。4、對于對系統(tǒng)不會造成危害的問題或雖然有微小的危害但修改成本過高而又可以人為避免，則可以將問題遺留到下一版本解決或關(guān)閉這個bug,并在bug報告中說明原因和注意事項。5、這個時候，測試人員的態(tài)度非常重要，在告訴開發(fā)這個問題一定需要解決的時候態(tài)度是溫和的堅定，并讓他意識到問題的嚴(yán)重性。試想想，如果你板著臉孔冷冰冰地丟給開發(fā)一句

7、“這個問題一定要解決！”扭頭就走，他會是怎樣的反應(yīng)呢？可以笑的時候就笑吧，大家都是工作，不要將工作的氛圍搞得太僵，大家在一個和諧的環(huán)境中工作才會保持愉悅的心情。6、發(fā)現(xiàn)問題之后測試人員可能心里會嘀咕“反正這是開發(fā)的問題就讓開發(fā)去折騰吧”，如果你一不小心這樣想了，那就偷偷的想幾秒鐘好了，這個念頭閃過之后，作為bug負(fù)責(zé)人的你怎么忍心看著開發(fā)一個人手忙腳亂呢？測試和開發(fā)其實是一個整體，在這個整體中的每個人都有責(zé)任去解決問題。三、測試工程師和開發(fā)工程師的意見不一致1、首先，客觀地比較自己的建議和開發(fā)的意見哪個更好。2、如果開發(fā)的方法的確是比較優(yōu)化，那就應(yīng)該接受開發(fā)的意見；如果經(jīng)過對比之后還是覺得自己

8、的建議更好，那就堅持自己的建議，并詳細(xì)給開發(fā)解釋你的建議，通過對比兩者之間的差別婉轉(zhuǎn)地告訴開發(fā)你的建議值得采納。3、如果雙方還是對各自的意見相持不下，可以跟項目經(jīng)理一起討論，由項目經(jīng)理衡量應(yīng)該采取哪種處理方法。不過，有時候，項目經(jīng)理也不一定站在你這邊，你可能還需要花腦筋說服項目經(jīng)理或被項目經(jīng)理說服。4、當(dāng)然，這個問題的討論前提是問題值得花時間和精力去研究討論，如果是一些比較簡單或次要的問題，就沒必要花那么長的時間去計較了，放過開發(fā)吧，也許他真的覺得這個問題沒必要這樣修改或者是他也修改到很累很煩了，這么簡單的一個問題何不讓開發(fā)輕松一下？四、開發(fā)工程師不配合工作1、先進(jìn)行一個自我檢討：我的態(tài)度有問

9、題嗎？我報的bug是否都描述清楚了？我所發(fā)現(xiàn)的問題是否有價值？如果這些問題的答案是否定的，那么自己先改正了，開發(fā)會看大到你的改變，也會調(diào)整自己的態(tài)度的。2、在一個團(tuán)隊中有一、兩個不合作的開發(fā)工程師是正常的，不可能每個人都那么配合那么好態(tài)度，也沒必要自己覺得很難受，因為問題在于他的身上，你做對了自己該做的就行了。3、不要去逃避，雙方之間換一種有效的溝通方法。比如，在MSN上交流不清楚，就換成電話或面對面，聽到你愉快的聲音或看到親切的面孔，對雙方之間的互動更加有幫助。但不要說著說著就火冒三仗，面紅耳赤了哦！如果你也是火暴的脾氣，面對面交流雙方很容易爭執(zhí)起來，那么就通過MSN或郵件來交換意見吧！總之

10、，交流的方式是很多的，選擇雙方更能有效溝通的交流渠道會達(dá)到事半功倍的效果。4、盡量避免與對方直接沖撞。人的自尊心都是很強(qiáng)的，學(xué)歷越高或能力越強(qiáng)的人，通常自尊心也是越強(qiáng)，你尊重他他才會尊重你，說得通俗點，你給了他面子、給了他臺階，他才會給你面子給你臺階。即使雙方之間發(fā)生了爭執(zhí)，也不要太過介懷，只是工作而已，大方點繼續(xù)對他真誠的微笑。5、如果他實在不配合，必要的時候，可以適當(dāng)表達(dá)你的立場，或者委婉地向他的領(lǐng)導(dǎo)反映或者將你們之間的交互郵件抄送給他的領(lǐng)導(dǎo)。這是一個有效的方法，但同時也是一個容易引發(fā)新的矛盾的方法，記住這樣做是為了有效解決問題，而不是在別人背后“打小報告”。這是在工作，對事不對人。在我的

11、team中，有一個開發(fā)的態(tài)度非常不配合，不管是對我還是其它的測試人員。五、如何處理不能迅速定位的工程故障對于一些不能迅速定位的工程故障，開發(fā)很自然寄望于測試環(huán)境能將問題重現(xiàn)，如果能夠輕易在測試環(huán)境重現(xiàn)，那肯定是一件好事，不過通常如果是一些簡單的容易出現(xiàn)的問題，在測試的時候肯定就已經(jīng)發(fā)現(xiàn)問題了；正是因為問題的復(fù)雜或者是一些測試時沒有考慮過的問題，才遺留到工程上導(dǎo)致出現(xiàn)故障。1、查看工程環(huán)境程序日志，如果沒有查詢的權(quán)限，請工程實施人員幫忙查找，分析日志查找到問題的原因或相關(guān)線索。2、如果日志的提示信息足夠，可以根據(jù)日志定位原因，則在測試環(huán)境中按照日志提示構(gòu)造條件相同的測試案例測試，嘗試在測試環(huán)境中

12、將問題重現(xiàn)。3、如果不能從日志中獲取足夠的信息，而且測試環(huán)境中也無法把問題重現(xiàn)，那么先跳出思維定勢，想想為什么會出現(xiàn)這樣的故障，可能導(dǎo)致的原因有那些，自己還有哪些測試點或異常沒有考慮到，測試環(huán)境和配置與實際的工程環(huán)境和配置有哪些差異等等。同時主動與開發(fā)負(fù)責(zé)人、工程實施人員以及有經(jīng)驗的項目經(jīng)理討論，分析可能導(dǎo)致的原因。4、請工程實施人員將工程環(huán)境的配置文件和執(zhí)行程序幫忙ftp到本地測試環(huán)境，在測試環(huán)境中使用實際工程環(huán)境的配置文件和執(zhí)行程序，并盡量模擬實際環(huán)境搭建測試環(huán)境。5、在模擬實際環(huán)境的測試環(huán)境中，根據(jù)分析的可能原因構(gòu)造測試案例測試，嘗試在測試環(huán)境中將問題重現(xiàn)。6、問題重現(xiàn)后協(xié)助開發(fā)解決問題

13、。7、驗證解決后的程序是否仍然會出現(xiàn)類似故障。8、總結(jié)出現(xiàn)故障的原因并作記錄，如果是配置的問題需要提醒工程人員在實施的時候注意，如果是測試疏忽的測試點要在測試報告中記錄并在案例庫中增加相應(yīng)的案例，如果是某些異常開發(fā)沒有考慮全面要總結(jié)類似的問題并提示所有開發(fā)注意。下面是一個非常難定位的工程故障的實例，希望這個工程故障的解決方法和態(tài)度能夠給你一些啟示。1、問題描述：在某省某短信業(yè)務(wù)高峰期，實際處理的短信比接受到的短信少，也就是在系統(tǒng)處理某環(huán)節(jié)丟失了部分短信。2、問題進(jìn)展：A、實際工程環(huán)境的日志沒有任何錯誤提示B、相關(guān)模塊的負(fù)責(zé)人進(jìn)行代碼白盒檢查，也沒辦法從代碼中看出缺陷C、測試環(huán)境沒有出現(xiàn)工程所描

14、述的故障3、問題解決：A、登錄實際的工程環(huán)境，查看所有相關(guān)的程序日志，但程序的日志都正常，不能從中得到啟示和幫助。B、根據(jù)推測可能的原因，在測試環(huán)境中試圖使用大壓力測試，但也沒出現(xiàn)工程所描述的故障。C、與開發(fā)負(fù)責(zé)人、項目經(jīng)理和工程人員討論可能導(dǎo)致故障出現(xiàn)的原因，并根據(jù)討論結(jié)果設(shè)計測試案例、測試方案。D、將工程實際環(huán)境的配置和執(zhí)行文件拿到測試環(huán)境，并模擬工程環(huán)境搭建測試環(huán)境，發(fā)現(xiàn)其中配置存放短信的配置項比實際測試環(huán)境的大兩倍。也就是：;queuesize,inbyte,20MBQueueSize=2O97i52O;maxISMGqueuelength,0meansnolimitMaxQueueL

15、en=50000E、模擬出現(xiàn)故障時的業(yè)務(wù)壓力，發(fā)現(xiàn)當(dāng)發(fā)送隊列MaxQueueLen超過了46807后，不會繼續(xù)增大，永遠(yuǎn)不會到達(dá)50000，也就是說永遠(yuǎn)不可能出現(xiàn)隊列滿的情況，模塊永遠(yuǎn)不會報隊列滿的錯誤；所以系統(tǒng)只要接收到信息就往隊列里放（只有該模塊隊列滿或者連接不上等異常出現(xiàn)的時候才會存放到短信緩存器），而該模塊共享隊列最大只能存放46807條信息，多余的信息也便丟失了。F、建議開發(fā)人員修改程序，當(dāng)短信存放超過了實際存放長度或配置長度，就提示錯誤并將短信存放到短信緩存器，確保短信在高峰期得到保障。G、給工程人員提供配置建議。共享隊列大小、隊列長度與網(wǎng)關(guān)連接個數(shù)之間的關(guān)系應(yīng)該滿足：對于共享隊列

16、大小為QueueSize=20971520，MaxIQueueLen，網(wǎng)關(guān)連接個數(shù)為之間的關(guān)系為：網(wǎng)關(guān)連接個數(shù)*MaxQueueLen<=40000。因此，若網(wǎng)關(guān)個數(shù)為1，貝UMaxQueueLen的安全大小是MaxQueueLen=40000。H、開發(fā)人員修改程序之后驗證問題：（1）、仍然保留MaxQueueLen=50000配置不變，壓力測試，當(dāng)短信發(fā)送隊列MaxQueueLen超過了46807后，系統(tǒng)能夠提示錯誤信息，并將短信緩存到短信緩存器。（2）、配置MaxQueueLen=40000，壓力測試，當(dāng)短信發(fā)送隊列MaxQueueLen=40000的時候，系統(tǒng)提示錯誤，并將短信存放

17、到短信緩存器。六、資源不足該怎么辦1、現(xiàn)有的資源是否能解決2、能否可以借用資源3、向領(lǐng)導(dǎo)反映并說明問題的嚴(yán)重性1請自我介紹一下。面試就是自我推銷的過程，同樣自我介紹應(yīng)有閃光點，應(yīng)突出自己為什么這個崗位。2說說你以前公司的測試流程。必答題。主要結(jié)合自己的項目經(jīng)驗相信講一個自己做過的項目，從立項到測試結(jié)束，當(dāng)然側(cè)重測試和自己所做的內(nèi)容。這里面試官一般都會根據(jù)你說的再提問。3你是怎樣做出自己的職業(yè)選擇或者自己的職業(yè)規(guī)劃。這題也經(jīng)常問?？梢詮淖约旱膬?yōu)點說如何適合做軟件測試，對與職業(yè)規(guī)劃，我一般說在技術(shù)上往資深測試工程師發(fā)展。4你覺得自己作為測試工程的優(yōu)勢在哪里？你認(rèn)為自己比你的同事優(yōu)秀在哪里？也經(jīng)常問

18、，可以從性格出發(fā)，講自己優(yōu)點，以及在項目中表現(xiàn)，領(lǐng)導(dǎo)的良好評價等，總之“恰當(dāng)”地往好處說，不要言過其實，讓人懷疑你的人品哦。說說自己的缺點？這個也不好回答，最好能恰當(dāng)?shù)匾昊卮鸬絻?yōu)點上。5. 一個測試中不堪回首，或者讓你很郁悶的事情。我被問到了，當(dāng)時想不起來，后來想想可以講一個項目中的失誤及后果，然后講自己如何去成功彌補(bǔ)及教訓(xùn)經(jīng)驗。我如果提前想一下就不會該說什么了。6你的好友是如何評價你的？你的項目組長是如何評價你的？這類題也經(jīng)常問。回答總要往好處說，但是你要自信地回答。7在成年后，哪些成績給你帶來最大程度的滿足？蠻不錯的題。記得我但是答的是第一次自己帶一個小項目，順利完成測試任務(wù)。8.測試時你提交的bug被研發(fā)拒絕或者他認(rèn)為不是問題，你如何處理?9. 測試與開發(fā)溝通如何提高效率和改善溝通效果？測試工程師的素質(zhì)和技能?10. 你在壓力