冒煙測試與迴歸測試

　　1.何為冒煙測試

　　冒煙測試是自由測試的一種。冒煙測試在測試中發現問題，找到了一個bug，然後開發人員會來修復這個bug。這時想知道這次修復是否真的解決了程式的bug，或者是否會對其它模組造成影響，就需要針對此問題進行專門測試，這個過程就被稱為冒煙測試。在很多情況下，做冒煙測試是開發人員在試圖解決一個問題的時候，造成了其它功能模組一系列的連鎖反應，原因可能是隻集中考慮了一開始的那個問題，而忽略其它的問題，這就可能引起了新的bug。

　　冒煙測試引入到軟體測試中，是指測試人員在正規測試一個新版本之前，先投入較少的人力和時間驗證一個軟體的主要功能，如果主要功能都沒有實現，則打回開發組重新開發。這樣做的好處是可以節省大量的時間成本和人力成本。

　　2.何為迴歸測試

　　迴歸測試是指修改了舊程式碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他程式碼產生錯誤。迴歸測試作為軟體生命週期的一個組成部分，在整個軟體測試過程中佔有很大的工作量比重，軟體開發的各個階段都會進行多次迴歸測試。在漸進和快速迭代開發中，新版本的連續釋出使迴歸測試進行的更加頻繁，而在極端程式設計方法中，更是要求每天都進行若干次迴歸測試。因此，通過選擇正確的迴歸測試策略來改進迴歸測試的效率和有效性是非常有意義的。

　　迴歸測試一般是在進行軟體的第二輪測試開始的，驗證第一輪中發現的問題是否得到修復。當然迴歸也是一個迴圈的過程，穿插在軟體測試整個生命週期裡面。如果迴歸的問題不通過，則需要開發人員修改後再次迴歸，直到通過為止。

　　3.兩者有何區別

　　冒煙測試就是完成一個新版本的開發後，對該版本最基本的功能進行測試，保證基本的功能和流程能走通。如果不通過，則打回開發那邊重新開發；如果通過測試，才會進行下一步的測試(功能測試，整合測試，系統測試等等)。冒煙測試優點是節省測試時間，防止build失敗。缺點是覆蓋率還是比較低。

　　迴歸測試我有兩層理解，一是就是當你修復一個bug後，把之前的測試用例再次應用到修復後的版本上進行測試。二是當一個新版本開發好後，而且冒煙測試通過，此時可以先用上一個版本的測試用例對新版本進行測試，看是否有bug！其實迴歸測試用的很多，比如新增加一個功能模組等等，所以自動化測試可以高效率的進行迴歸測試。

　　4.如何做好冒煙測試

　　冒煙測試必須在每次提交新的測試版本前執行,且執行規範需根據需求設計文件來要求,開發在每次接受新的開發需求時,必須按照需求文件嚴格整理出冒煙測試點,也就是基本功能點,畢竟這些功能點都是開發人員要完成的,可能會認為這個工作不重要,如果整理出了這些基本功能點,就不會導致後期版本釋出時出現功能遺漏,或者功能實現有缺陷等等問題,只有將所有的問題保留在前期的需求評審階段,才能更有效率完成使用者的需求,後期出問題的機率也就大大降低。

　　冒煙測試的規範,其實冒煙測試規範取決於人,而不在於流程,如果需求分析做的很細緻,就不可能不規範,就不會冒煙標準,更不會存在爭議的問題所在,所以這就需要開發在設計階段對需求的把握,要實現什麼樣的功能,達到什麼樣的效果,其實開發在做之前是有預想的,但是到底是否符合使用者的需求,就要看跟使用者的需求溝通和評審,所以這裡所說的準備還是由設計階段產生的冒煙測試點,然後定義實現的情況,並給出最後評審.當然不同的專案是不一樣的,但是準則是冒煙測試不通過,產品是不能提交給測試人員測試的,因為它不具備測試條件。

　　冒煙測試的執行到底該由誰來做,嚴格來說,測試人員肯定是要做冒煙測試的,因為這是測試流程中的首要階段,也是必要條件之前,測試人員執行冒煙測試不通過,就說明版本不具備測試條件,重新發回給開發人員.但是如果每次都出現這種問題,因為冒煙測試不通過而打回原形必然回耽誤大家的時間,而為了節省這個時間,提高版本釋出的效率,那就需要開發人員自己做冒煙測試,只有開發在提版本之前做一個版本自身體檢,才能讓這個版本健康的釋出出去,這樣才會有效的提高大家的工作效率,開發人員做冒煙測試是應該,因為這也是對自身工作負責任的一種態度,通過冒煙測試他們能夠檢查一次那些需求沒有實現,是否有遺漏的,就不會將原本就無效的版本發給測試,導致最後還要被髮回重審,既浪費時間,又大大降低效率。

　　5.如何做好迴歸測試

　　關於如何做好迴歸測試，大體上的人都是認為是先驗證bug，然後迴歸和本次修改相關的地方，但如何評估和此次修改相關的風險，這是一個相對重要且考驗對系統認知度的問題。在我們平時的迴歸測試中，是如何做這一點呢？

　　（1）和專案中的開發以及專案負責人溝通確認。

　　這是一個很關鍵的環節，好的開發人員在提交測試時就會註明可能影響的地方。

　　（2）關鍵點的測試。

　　就是很重要的部分，即使看著和本次修改無太直接關聯，也最好能走一下基本流程。因為這是客戶最關心的地方點，也是盈利的所在。比如測試的重點：bug修改，關聯功能，新增加功能，修改功能呢個，上一輪測試bug多的功能。（測試人員要了解開發在這一輪修改了哪些bug，要注意關注我們的bug管理工具上的變化。）

　　（3）對開發人員能力的評估。

　　好的開發人員，修改缺陷時，會修改過程中注意對其它地方的修改。但能力不足的開發人員可能考慮較少。導致修改後，引起的2次bug較多，這個時候就需要加大測試力度，可能的話要整個模組基本功能進行迴歸。

　　（4）專案初期對測試用例的維護。

　　一個專案在開始時，編寫測試用例時往往是對這個系統全面瞭解的過程，這個時候時間也較為充裕，所以寫測試用例時，儘可能標註關聯測試用例。這在大型專案裡是尤其重要的。

　　（5）變換測試人員，迴歸比較繁瑣，可以通過測試人員的輪流進行減輕一個人做迴歸的厭倦。