冒煙測試一般基於Nightly build，構建服務器首先從CVS服務器上，下載最新的源代碼，然后編譯單元測試，運行單元測試通過后，編譯可執行文件，可執行文件若可運行，並能執行最基本的功能，則認為通過了冒煙測試，這時，構建服務器會把程序打包成安裝文件，然后上傳到內部網站，第二天一早，測試人員來了以后，會收到構建服務器發來的郵件提示昨晚是否構建成功。若構建成功，則測試人員進行相關的功能測試。所有這些功能的完成，一般是靠編寫腳本完成的，目前比較常用的腳本有 TCL，Perl，Python及功能弱弱的批處理。用這些可以完成系統的每日構建。
簡單的說，就是先保證系統能跑的起來，不至於讓測試工作做到一半突然出現錯誤導致業務中斷。目的就是先通過最基本的測試，如果最基本的測試都有問題，就直接打回開發部了，減少測試部門時間的浪費
記得有一次面試中面試官問了我一個問題,談談什么是冒煙測試,我當時就傻了,估計人家從這個問題中就得出結論,我還是個新手,也許測試還沒入門呢!不過只有跌倒過一次,才不會再次在原來的地方跌倒,不然那樣就太糟糕了.就因為這樣我回去好好翻了翻資料,把冒煙測試理清楚了,原來如此!
冒煙測試,嚴格來說就是一個基本功能點的驗證測試,可能是我在上家公司的產品質量不怎么樣的緣故吧,我們做得比較多的是冒煙測試,每次只要開發人員一提交測試版本到測試部門,我們會嚴格按照冒煙測試的流程和標准來執行,一旦基本功能點不通過,我們將不予受理測試任務,並可以保留對開發人員的上訴意見,雖然我們每次執行的不是很嚴格,但每次總會做這么一個過程.不是為了針對誰,而且版本測試必須要有這樣一個冒煙測試的過程來約束開發人員,讓他們潔身自好,真正負責任的去做產品,幫助開發人員提高自身的質量意識,從而可以更有效的提高產品的質量,和版本發布速度.也許說,效率是要靠團隊來推動的.
下面我想具體說說冒煙測試如何執行,並且如何規范標准,還有就是該由誰來做?
冒煙測試必須在每次提交新的測試版本前執行,且執行規范需根據需求設計文檔來要求,開發在每次接受新的開發需求時,必須按照需求文檔嚴格整理出冒煙測試點,也就是基本功能點,畢竟這些功能點都是開發人員要完成的,可能會認為這個工作不重要,如果整理出了這些基本功能點,就不會導致后期版本發布時出現功能遺漏,或者功能實現有缺陷等等問題,只有將所有的問題保留在前期的需求評審階段,才能更有效率完成用戶的需求,后期出問題的幾率也就大大降低.
冒煙測試的規范,其實冒煙測試規范取決於人,而不在於流程,如果需求分析做的很細致,就不可能不規范,就不會冒煙標准,更不會存在爭議的問題所在,所以這就需要開發在設計階段對需求的把握,要實現什么樣的功能,達到什么樣的效果,其實開發在做之前是有預想的,但是到底是否符合用戶的需求,就要看跟用戶的需求溝通和評審,所以這里所說的准備還是由設計階段產生的冒煙測試點,然后定義實現的情況,並給出最后評審.當然不同的項目是不一樣的,但是准則是冒煙測試不通過,產品是不能提交給測試人員測試的,因為它不具備測試條件.
冒煙測試的執行到底該由誰來做,我們以前公司也經常碰到這樣的矛盾,其實開發人員不願意做測試是事實,但是提高產品的質量最后還是由開發人員自己來完成,這一點測試人員也無能為力,但如何才能讓他們體會到這一點呢.那就需要通過嚴格的考核標准來推動,有壓力才有動力,這個准則任何時候都是有效果的.其實嚴格來說,測試人員肯定是要做冒煙測試的,因為這是測試流程中的首要階段,也是必要條件之前,測試人員執行冒煙測試不通過,就說明版本不具備測試條件,重新發回給開發人員.但是如果每次都出現這種問題,因為冒煙測試不通過而打回原形必然回耽誤大家的時間,而為了節省這個時間,提高版本發布的效率,那就需要開發人員自己做冒煙測試,只有開發在提版本之前做一個版本自身體檢,才能讓這個版本健康的發布出去,這樣才會有效的提高大家的工作效率,開發人員做冒煙測試是應該,因為這也是對自身工作負責任的一種態度,通過冒煙測試他們能夠檢查一次那些需求沒有實現,是有遺漏的,就不會將原本就無效的版本發給測試,導致最后還要被發回重申,既浪費時間,又大大降低效率,何必呢?
所以說任何一個理論的誕生都是有它的依據和道理的,雖然麻煩一點,但是效率提高了很多,何樂而不為呢!