相比于之前的全手工測試，現在的測試無疑自動化的多，回首看頗有封建社會過渡到資本主義社會之感。已經“自動化”了好幾個月了，一直想總結總結這種由鳥槍更換成的大炮到底給我們測試帶來多少生產力的提高，它適用什么場景，它對于測試的最終目的有多少幫助，又會帶來多大的影響？
其實說起來聽可笑的，我對于自動化測試起初還是挺抵觸的，總覺得自動化了之后會有一些很“隱藏”的缺陷會被放掉，而且針對小作坊式的軟件生產，不需要對每個軟件模塊都進行全方位測試。往往將前后端一集成，發(fā)布一個包，部署給環(huán)境，測試就好了，沒有那么多的要求。可是當軟件進入批量和大規(guī)模之后，各個模塊之間的接口通信就變得異常重要，每個環(huán)節(jié)首先必須保證自己是沒有問題的才能集成進環(huán)境，還有軟件開發(fā)都是這樣，先后臺再前端，往往到了項目后期，才集成UI聯調，此時后端的功能和接口都必須已經測試過保證沒有大問題的情況下進行的；再者軟件后臺的程序都屬于項目前期開發(fā)，更多的不確定和更多的缺陷等著測試人員去發(fā)掘。在這種情況下手工測試的缺點就暴露出來，一是不能及時提供有效的頁面給予手工測試，二是不停的代碼變更讓手工測試已經很難滿足復用的需要，這時候的自動化就猶顯重要。
啰嗦了一堆，其實就是想說自動化在軟件進入規(guī)模化生產之后測試人員的必經之路，可以大大的提升測試效率和節(jié)省測試時間，讓這個軟件過程在最短的時間內完成。
前面提到了自動化測試適用的測試過程，現在結合幾個月測試過程簡單的談談自動化的優(yōu)缺點，共享資源。
自動化適用的用例程度最好的就是參數值校驗的用例了，對于自動化腳本來說，無論是腳本語言還是高級語言都可以采用一個模板，就是一個套子，每次使用的時候只需要更換傳遞的參數即可。這種測試，同樣基于最基本的等價類邊界值的用例劃分，測試設計的基本思想，自動化同樣適用。
其實對于參數值用例校驗本身，其集成在功能模塊測試之中，每個用例都最原始功能模塊的一部分，軟件的程序就是這樣，我們測試每個功能模塊是否有缺陷也就是靠傳遞參數查看其返回是否達到期望結果。PS：不能向拆開汽車或者X光檢查身體那樣…………
自動化測試無法比手工測試發(fā)揮更好的地方就是執(zhí)行用戶級用例的時候，具體到執(zhí)行的時候就是界面測試和用戶場景測試，其實這兩種測試有交集的，都已直接和用戶打交道為主，因為是人，所以自動化即使執(zhí)行通過不代表易用性等等方面達到要求，還是要具體使用情況。
自動化測試適用前期沒有頁面、需要驗證程序功能模塊的情況，不但能夠盡早的發(fā)現問題，而且自動化本身的復用性也讓后期的回歸測試和冒煙測試變得效率十足。對于測試前端頁面和用戶體驗性測試，不建議使用，因為自動化腳本編寫和調試本身就很耗時，保證腳本的正確性也需要費些周折，測試腳本執(zhí)行完成后還需要測易用性測試，時間上需要花費的更多。