自動化冒煙測試腳本應當遵循的原則 ZT

自動化冒煙測試腳本應當遵循的原則：

1、覆寫主要功能；

冒煙測試不是系統測試或內建測試，是以不需要面面俱到，重點放在保證主要功能或主要業務路徑執行正常；

2、易用性；

既然是自動化測試腳本，那麼最好的狀況是隻輸入一個指令可以就搞定，不要再讓執行人員做各種配置；為了達到這個目的，可能會導緻一定的備援，但是值得，這會降低在冒煙測試階段的成本。此外，測試結果要清晰明了，成功多少用例，失敗多少用例，用例失敗的原因，以及出現的異常資訊，最好都可以一目了然。

3、引入工程的概念；

獨立的測試腳本，如果沒有統一的調用管理，則不可能滿足易用性的需求；是以，應當引入工程的概念，使用類似TestSuite的概念以管理測試腳本的執行；

4、測試腳本要獨立；

也就是經常說到的“高内聚，低耦合”的思想，每個測試腳本要盡可能的獨立，執行過程不需要依賴其它測試腳本（lib除外）。此外，每個測試腳本（用例函數）覆寫的測試點要盡可能的單一，不要将多個測試點放到同一個腳本（用例函數）中執行；這樣的好處是在功能變更後，修改相應的測試腳本時，對其它測試點的測試執行沒有影響，同時，也可以保證在執行冒煙測試過程中，不會因某一個用例沒有通過，而導緻之後的用例無法繼續執行；

5、測試腳本要簡單

測試腳本編碼要盡可能的簡單，如果說測試腳本寫的很複雜，那麼就需要先測試自己的測試腳本的正确性了，否則，無法保證當冒煙測試過程出現問題後就肯定是被測産品的問題。而對測試腳本的測試是要耗費多餘的成本的，不太現實，是以測試腳本要盡可能的簡單，從複雜程度上避免測試腳本出現bug。

6、維護必要的文檔

一整套的自動化冒煙測試腳本本身也是一個産品，尤其當其以工程的方式管理時，是以必要的文檔是必不可少的，要有簡單的設計、架構文檔，更新日志。如果沒有這些文檔的話，發生測試人員變更時，新的測試工程師就慘了，隻有兩條路可選，一是一點一點的看測試代碼以搞清測試腳本是如何執行的；二是重新做一個新的測試腳本架構出來；這兩種方式成本好像都很高啊。

7、測試結果收集

每一次的測試結果都要留存，對比一段時間内的測試結果，可以知道産品那些功能點品質不穩定，如果同一個測試點在一段時間内經常不能夠測試通過，那麼這一部分的代碼十分有必要進行review，及可能存在更大的隐患。