1、覆蓋主要功能；
冒煙測試不是系統測試或集成測試，所以不需要面面俱到，重點放在保證主要功能或主要業務路徑執行正常；
2、易用性；
既然是自動化測試腳本，那么最好的狀況是只輸入一個命令可以就搞定，不要再讓執行人員做各種配置；為了達到這個目的，可能會導致一定的冗余，但是值得，這會降低在冒煙測試階段的成本。此外，測試結果要清晰明了，成功多少用例，失敗多少用例，用例失敗的原因，以及出現的異常信息，最好都可以一目了然。
3、引入工程的概念；
獨立的測試腳本，如果沒有統一的調用管理，則不可能滿足易用性的需求；所以，應當引入工程的概念，使用類似TestSuite的概念以管理測試腳本的執行；
4、測試腳本要獨立；
也就是經常說到的“高內聚，低耦合”的思想，每個測試腳本要盡可能的獨立，執行過程不需要依賴其它測試腳本（lib除外）。此外，每個測試腳本（用例函數）覆蓋的測試點要盡可能的單一，不要將多個測試點放到同一個腳本（用例函數）中執行；這樣的好處是在功能變更后，修改相應的測試腳本時，對其它測試點的測試執行沒有影響，同時，也可以保證在執行冒煙測試過程中，不會因某一個用例沒有通過，而導致之后的用例無法繼續執行；
5、測試腳本要簡單
測試腳本編碼要盡可能的簡單，如果說測試腳本寫的很復雜，那么就需要先測試自己的測試腳本的正確性了，否則，無法保證當冒煙測試過程出現問題后就肯定是被測產品的問題。而對測試腳本的測試是要耗費多余的成本的，不太現實，因此測試腳本要盡可能的簡單，從復雜程度上避免測試腳本出現bug。
6、維護必要的文檔
一整套的自動化冒煙測試腳本本身也是一個產品，尤其當其以工程的方式管理時，所以必要的文檔是必不可少的，要有簡單的設計、架構文檔，更新日志。如果沒有這些文檔的話，發生測試人員變更時，新的測試工程師就慘了，只有兩條路可選，一是一點一點的看測試代碼以搞清測試腳本是如何執行的；二是重新做一個新的測試腳本框架出來；這兩種方式成本好像都很高啊。
7、測試結果收集
每一次的測試結果都要留存，對比一段時間內的測試結果，可以知道產品那些功能點質量不穩定，如果同一個測試點在一段時間內經常不能夠測試通過，那么這一部分的代碼十分有必要進行review，及可能存在更大的隱患。
上面說的原則不只適用于冒煙測試，其實對自動化的回歸測試腳本開發也同樣適用。
相信有人會說，為什么一個自動化測試還要搞得這么麻煩，還整出些原則來。其實，作為一名測試管理者來說，一方面要考慮提高測試質量，另一方面也要考慮測試成本，像冒煙測試和回歸測試這樣重復性較強的工作，若沒有一個高效合理的自動化測試框架來執行，單靠手工來完成，成本是相當高的，尤其是對一些發布較頻繁的產品；同理，如果自動化測試框架不是很合理，執行過程總是需要過多的人工參與，成本同樣會很高。測試成本若是降下來了，那么我們就有更多的人力去做其它的事情，生產力就提上去了^_^。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
