總結對自動化測試的見解

一.爲何要搞自動化

1.作迴歸測試，減小手工量：這樣就避免了測試人員重複的勞動，也可讓咱們有更多的精力去作更有意義的事情，也可讓咱們減小一些乏味的感受。

2.測試手工測試沒法實現或是較難實現的功能：好比說模擬一千萬條http併發請求，若是是手工測試，這個是實現不了的。

3.爲了方便工做，編寫一個小工具：

好比說我在作某些操做時，想實時從後臺日誌中獲取我想要的信息，可是後臺日誌信息太多，不少都不是我想要的。

這樣爲了方便我查看日誌，能夠寫一個小工具，實時從日誌提取我想要的內容。

 

二.何時適合搞自動化測試

1. 敏捷項目：項目走敏捷模式的話，因爲迭代週期過短，測試沒法對以往功能所有迴歸，因此必然要用自動化測試來作迴歸測試。

2. 系統週期比較長的時候。

若是系統週期過短，那麼花費了很長時間寫好的自動化測試可能只被使用了很短期或有限次數，那麼這樣就不值得了。

3. 項目比較穩定，需求不會變動的太迅速的時候。

需求變動的太快，會致使自動化測試總是失敗。自動化維護成本過高，甚至因爲太忙，測試人員沒有時間去維護，致使以前寫的自動化用例一直閒置，浪費時間。

 

三.自動化測試的成本

1.時間成本

A.培訓成本：若是在一個項目中想實施自動化，前期確定須要給你們作相關的培訓(基礎理論，編程語言)

B.編寫成本

C.維護成本:

維護自動化測試環境一直正常可用

新增功能或修改bug後，可能致使某些舊功能自動化測試不能正常運行(好比出新的bug或是前端自動化測試時，某個元素的路徑發生了改變等等)

 

2.金錢成本：有些不是開源的自動化測試工具仍是挺貴的，好比說QTP

 

四.怎樣選擇自動化測試框架(工具)

測試框架就是把一些經常使用的方法進行了封裝，方便咱們使用，且減小代碼的重複。

你能夠選擇本身寫測試框架，也能夠選擇一些經常使用的自動化測試框架。

接口測試比較常見的有：robot framework,fitnesse等等

單元測試：junit，testng，Nunit等等

前端頁面測試：selenium, Watir等等

固然不少時候咱們也能夠根據須要結合多種測試框架使用

 

那麼咱們在選擇使用哪一種自動化測試框架的時候通常考慮哪些因素呢？

1.支持的編碼語言。

2.支持的運行環境。linux仍是windows？

3.比較成熟，比較流行的框架。

要選擇成熟的版本，若是不是使用最新的函數，仍是使用穩定的版本比選擇最新的版本好。那麼這個框架可能自己的bug會比較少。咱們是在使用這個框架，天然不想由於它自己的bug干擾咱們的測試結果。

其次是用的人多的話，你使用中遇到問題，在網上查資料解決也比較容易。

 

五.自動化測試的缺點

1.不能徹底代替手工測試：

有的狀況自動化是沒法實現的(好比斷網斷電)，或是編寫自動化的成本過高；

自動化腳本不靈活，有些手工測試顯而易見的問題，容易被忽略，由於不在腳本的測試範圍；

還有就是自動化測試很難發現新的bug。

因此說自動化測試仍是沒法徹底代替手工測試，咱們能夠用它來輔助測試，看新增功能後或bug修改後，原有的功能是否能正常運行。

2.編寫和維護成本高

 

六.測試人員在自動化測試過程當中容易陷入的誤區

1.盲目追求自動化測試的覆蓋率，而忽略了自動化測試的實際意義。

有些功能手工測試很簡單，可是要實現自動化測試難度比較大，費時多，性價比低；有些功能可能只是一個暫時的功能，就沒有必要寫自動化。

2.爲了實現自動化而去寫自動化，而不考慮這是否真的對咱們的系統測試有幫助，或是沒有考慮到咱們項目是否真的適合作自動化。

3. 有自動化測試再也不須要手工測試

4.自動化測試僅僅只能作迴歸測試：其實自動化測試不僅是能夠作迴歸測試，也能夠來處理數據(好比說剛纔說的模擬一千萬條http併發請求)，或是作一些小工具來輔助平常工做

 

另外：其實我以爲作好自動化測試的關鍵不是說你技術有多牛，而是你的自動化測試用例是否覆蓋了那些測試的重點。因此我以爲作好自動化最關鍵的仍是你自動化測試用例的設計。