腳本編寫完成之后，自然是使用。腳本在前期的使用是功能測試和數據準備，在項目穩定之后的最大價值就是回歸測試。我將腳本分為了三個級別：基本流程測試腳本，用于每次出新built安裝后做smoke test；關鍵功能測試腳本，每次出新built后對所有重要功能進行回歸測試，確保改動不會對原有功能的造成影響；全面回歸測試腳本，一般每周跑三次或者是系統經過比較大的修改后作回歸測試。自動測試腳本在回歸測試中發揮了出色的作用，特別是系統在上線前夕，為了適應客戶的需求，功能不斷修改，對于原有的功能，自然不可能都手工測試，腳本在這個時候的意義特別大。
同事或朋友經常問我，自動化測試應該在什么時候介入？如果系統的功能需求和接口定義都很清晰，系統開發完成并且基本功能手工測試成功后，就可以開始編寫自動化測試腳本了，一方面可以利用腳本做功能測試和bug驗證，另一方面也可以用來做回歸測試。但如果系統的變化比較大或接口的定義不夠清晰，最好還是先手工測試，待功能比較穩定之后再寫腳本，因為如果功能的變化太大，維護腳本的付出可能遠遠小于腳本可以帶來的效益。
當然，并不是所有的系統都適合做自動測試，如果只是一些短期的項目，或者是腳本不會被重復利用，就沒有做自動化測試的必要，成本會遠遠大于收益，也就沒有做自動化測試的必要了。反之，如果是產品的測試或長期的項目或是自動化測試腳本會被反復使用，自動化測試就顯得很有必要了，做完一套腳本之后就會反復被使用，當然可以節省很多成本，也可以提供測試的效率。
這個架構，自己付出了很多心思，付出所得到的回報找到了自動測試的感覺，底氣不足變成了胸有成竹。項目組的其它團隊也看到了自動化測試的好處并打算參考我們的架構實現自動化測試，再做設計，揚長避短、一氣呵成。
敲完這些文字，也就意味著我的自動化測試工作暫告一段落，下周開始，因為項目的需要，將會開始我的另一個全新的角色。這個架構，絕對不是完美的，肯定還存在可以改進的空間，希望接替我自動化測試工作的同事，也能像繡花一樣用心去完善它。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
