談冒煙測試

        冒煙測試，剛進公司就接觸到了。只是剛開始一直沒有體會到冒煙的含義和精髓，一直覺得是冒煙測試就是把待測產品的主要功能測試一下就好了。後面回想一下，不是那麼回事的。
        冒煙測試源自硬件行業，對一個硬件或者硬件組件改動後，直接給設備加電，看看設備會不會冒煙，沒冒煙，就表示待測組件是經過了測試。
        在軟件開發過程當中，一直有高內聚、低耦合這樣的說法，各個功能模塊之間的耦合仍是存在的，所以一個功能的改動，仍是會影響到其餘功能模塊。                                                                                                               所以在開發人員修復了先前測試中發現的bug後，想知道這個bug的修復是否會影響到其餘功能模塊，須要作的就是冒煙測試。                                                                                                                                                  搞清楚冒煙測試的起源，冒煙測試的目的後，不難想到，冒煙測試是這樣的一種測試，不要求覆蓋面有多廣，但至少要保證覆蓋待測產品的絕大部分功能；不要求每一個功能都測的很詳細，但至少要保證被修復了的bug所屬的功能和系統其餘骨幹功能都是可用的（即這個版本能拿去作系統功能測試了）。
        而要作到覆蓋骨幹功能和bug所屬功能，卻不是簡簡單單在頁面中點幾下就好了的。任何一個項目或者產品，骨幹功能都有它的使用場景。冒煙測試就是要保證這些骨幹功能的使用場景都能跑通，若是沒跑通，後續的系統測試就不必了。
        其實作冒煙測試以前，都已經作了一個簡單的安裝部署測試了（你不安裝部署，哪裏來東西測呢）。按我本身的理解，其實這塊也能夠放入冒煙測試範疇的。想一想看，安裝部署是否是很相似電路板加電，讓電路板開始工做呢？然後面的骨幹使用場景測試，只是在這個基礎上作的後續工做。若是安裝部署後，待測產品跑到一半就down掉了，後面的骨幹功能的使用場景還測個屁呀。
        使用場景的是否能跑通的測試，不須要測一些異常的狀況，保證基本功能覆蓋到就好了。一般，冒煙測試是交給開發人員去作的。只有確認了功能可用後，交給測試人員去作纔有意義。剛開始進公司時，小組裏面有我的不作冒煙，只把他修改了的部分簡單測了下，就交給我這邊去測試。結果就是我測試到一半，發現有個很重要的功能用不了。這個時候，測試只要停止了。時間久了，你們對產品質量和測試工做有了必定認識（最主要是你們不急急忙忙地加班了，^__^ ），對我也有了必定的承認，所以作事也愈來愈正規了。如今咱們小組的作法是，小組裏面每一個人扮演產品使用場景中的一個角色，而後你們一齊分工去完成每一個場景裏面各自角色要完成的任務，在這個過程當中，觀察待測項目是否正常。
        後面須要冒煙上的優化作些什麼呢，我想更多的仍是從自動化上去着手，版本構建自動化，自動化冒煙測試等等。