學習自動化測試的一些感悟

 

這個話題比較大，相信你們也都有本身的想法，我在這裏寫一些我本身的見解，請你們指教。

一、什麼叫作自動化測試工程師？
首先，要會使用自動化測試工具；
接下來，對於高手來講，要能寫一些獨立的測試腳本甚至測試工具；
更高的高手則是能把腳本和工具和實際工做緊密結合起來，解決工做中遇到的問題。

二、自動化測試工程師應該具備開發能力嗎？
經過上述內容，應該能夠看得出來，自動化測試人員必定要有開發能力，而這偏偏是測試人員目前所欠缺的。沒有開發能力的測試人員雖然也能夠作一些所謂的自動化，可是僅僅是一些皮毛，沒有辦法作到活學活用。根據某機構的調查數據，目前全部從事測試工做的人中，90%的人都沒有任何開發能力。根據目前的市場行情，若是在精通一門開發語言，可以從純手工測試轉型爲自動化測試工程師，月薪至少增長3~5k。

三、自動化測試的層級
通常來講，自動化測試分爲三個層級：單元測試、接口測試、UI測試，這三層成一個金字塔形狀分佈。最底層是單元測試，接口測試在中間，UI測試在最上層。

單元測試
單元測試無疑是最適合作自動化的，可是，大多數單元測試都是由研發人員本身完成。單元測試的代碼行覆蓋率可以達到70%，就是一個很是不錯的程度了。
單元測試框架
單元測試經常使用的框架——XUnit，好比Java的JUnit，PHP的PHPUnit，Python的unittest等等；
一個測試用例一般由三部分組成——setUp，測試邏輯，tearDown。setUp用於準備測試數據，tearDown用於清理數據；通常單元測試框架都支持裝飾器設計模式的註解，好比跳過執行，測試套件的組織，測試用例依賴管理等等。
單元測試框架能夠無縫地在UI測試和接口測試中使用，它們的基本思想都是相通的。

接口測試
接口的自動化是目前最適合測試工程師進行自動化的一層。接口不但變化小，運行速度快，受益高，還有着出現問題後可以很快定位的優勢。

UI測試
目前，大衆眼中關注的比較多的是UI的自動化測試，這是由你們的思惟慣性致使的。傳統的測試行業，測試工程師都是從UI下手，來完成全部的測試工做，因此到自動化領域，你們也理所固然的喜歡從UI層來進行自動化。作UI自動化，最重要的是要能有一個好的自動化測試框架，這裏有一些框架的基本設計思路供你們參考：
分佈式——case增長到必定程度後，如何快速的運行全部的case，這就涉及到分佈式的概念。行爲驅動——也就是常說的Cucumber，這個領域筆者沒有太多的涉足，不誤導你們；
關鍵字驅動——由『操做對象』、『操做』、『數據』關鍵字組合成測試用例，框架來把關鍵字解析爲腳本並執行。這種框架最大的優勢就是能夠提供給不懂代碼的測試人員使用，典型的表明是Robot framwork；
數據驅動——同一段代碼的業務邏輯經過更換數據輸入來生成多個測試用例，咱們只需維護測試數據就能夠維護case，這種框架思想在不少測試工具中都有實現；
關鍵字和數據混合驅動——目前最高級的框架，將上述兩種框架結合起來。
固然，這些思路不只僅能用在UI層的自動化。
對於UI自動化，我我的的建議是隻作冒煙測試用例的自動化，這樣既能夠從UI的角度來重複性的驗證主業務主流程沒有問題，又能夠下降維護成本。

四、何時最適合作自動化
首先，自動化測試歷來都不是用來發現新的bug的，它更多的是用來驗證原有功能是沒問題的，新的修改對原有代碼邏輯沒有影響。因此，當一個項目相對穩定以後，之後的項目都是基於原有代碼進行迭代，這個時候自動化的介入是很是有效的。
另外，若是某個用例須要有大量的輸入項，作手工測試比較繁瑣，咱們也能夠引入自動化的手段作局部的自動化。好比，驗證某個用戶登陸1000次是否可以登陸成功，這種狀況使用手工的方式基本是不可能的。

五、自動化測試工具推薦
功能測試：Selenium（WEB），Appunim（APP）
性能測試：Jmeter（趨勢）