這個話題比較大，相信大家也都有自己的想法，我在這里寫一些我自己的看法，請大家指教。
什么叫做自動化測試工程師
首先，會使用自動化測試工具的測試人員不能夠稱之為完全的自動化測試人員，這類測試人員被稱為『工具小子』(Script Kid)。這個階段還是處于自動化測試的一個比較低級的階段，因為這些工具都不是測試人員開發(fā)的。
對于高手來說，要能寫一些獨立的測試腳本甚至測試工具。
更高的高手則是能腳本和工具和實際工作緊密結合起來，解決工作中遇到的問題。
自動化測試工程師應該具有開發(fā)能力嗎
通過上述內容，應該可以看得出來，自動化測試人員一定要有開發(fā)能力，而這恰恰是測試人員目前所欠缺的。沒有開發(fā)能力的測試人員雖然也可以做一些所謂的自動化，但是僅僅是一些皮毛，沒有辦法做到活學活用。根據(jù)某機構的調查數(shù)據(jù)，目前所有從事測試工作的人中，90%的人都沒有任何開發(fā)能力。根據(jù)目前的市場行情，如果在精通一門開發(fā)語言，能夠從純手工測試轉型為自動化測試工程師，月薪至少增加3~5k。
自動化測試的層級
一般來說，自動化測試分為三個層級：單元測試、接口測試和UI測試，這三層成一個金字塔形狀分布。最底層是單元測試，接口測試在中間，UI測試在最上層。下面通過一個表格來對比著三層測試。
| 層級 | 所處位置 | 受益 | 測試對象 | 運行速度 | 定位問題難度 | 維護成本 |
| 單元測試 | 底層 | 70% | 類或者方法 | 極快 | 十分容易 | 低 |
| 接口測試 | 中間 | 20% | 服務接口 | 快 | 一般 | 低 |
| UI測試 | 上層 | 10% | UI | 慢 | 較難 | 非常高 |
從表格中我們可以看到，最適合做自動化的是單元測試層，而UI層則不是十分適合進行自動化。
測試人員應該怎么辦
單元測試
單元測試無疑是最適合做自動化的，但是，大多數(shù)單元測試都是由研發(fā)人員自己完成。單元測試的代碼行覆蓋率能夠達到70%，就是一個非常不錯的程度了。測試人員不做單元測試，但是可以嘗試推動研發(fā)人員來編寫單元測試用例。
單元測試框架
- 單元測試常用的框架——XUnit，比如Java的JUnit，PHP的PHPUnit，Python的unittest等等；
- 一個測試用例通常由三部分組成——setUp，測試邏輯，tearDown。setUp用于準備測試數(shù)據(jù)，tearDown用于清理數(shù)據(jù)；
- 一般單元測試框架都支持裝飾器設計模式的注解，比如跳過執(zhí)行，測試套件的組織，測試用例依賴管理等等
單元測試框架可以無縫地在UI測試和接口測試中使用，它們的基本思想都是相通的。
UI測試
目前，大眾眼中關注的比較多的是UI的自動化測試，這是由大家的思維慣性導致的。傳統(tǒng)的測試行業(yè)，測試工程師都是從UI下手，來完成所有的測試工作，所以到自動化領域，大家也理所當然的喜歡從UI層來進行自動化。做UI自動化，最重要的是要能有一個好的自動化測試框架，這里有一些框架的基本設計思路供大家參考：
- 分布式——case增加到一定程度后，如何快速的運行所有的case，這就涉及到分布式的概念。對于Selenium，官方提供了一個Grid，感興趣的同學可以研究一下；
- 行為驅動——也就是常說的Cucumber，這個領域筆者沒有太多的涉足，不誤導大家
- 關鍵字驅動——由『操作對象』、『操作』、『數(shù)據(jù)』關鍵字組合成測試用例，框架來把關鍵字解析為腳本并執(zhí)行。這種框架最大的優(yōu)點就是可以提供給不懂代碼的測試人員使用，典型的代表是Robot framwork
- 數(shù)據(jù)驅動——同一段代碼的業(yè)務邏輯通過更換數(shù)據(jù)輸入來生成多個測試用例，我們只需維護測試數(shù)據(jù)就可以維護case，這種框架思想在很多測試工具中都有實現(xiàn)
- 關鍵字和數(shù)據(jù)混合驅動——目前最高級的框架，將上述兩種框架結合起來
當然，這些思路不僅僅能用在UI層的自動化。
對于UI自動化，我個人的建議是只做冒煙測試用例的自動化，這樣既可以從UI的角度來重復性的驗證主業(yè)務主流程沒有問題，又可以降低維護成本。
接口測試
接口的自動化是目前最適合測試工程師進行自動化的一層。接口不但變化小，運行速度快，受益高，還有著出現(xiàn)問題后能夠很快定位的優(yōu)點。
什么時候最適合做自動化
首先，自動化測試從來都不是用來發(fā)現(xiàn)新的bug的，它更多的是用來驗證原有功能是沒問題的，新的修改對原有代碼邏輯沒有影響。所以，當一個項目相對穩(wěn)定之后，以后的項目都是基于原有代碼進行迭代，這個時候自動化的介入是非常有效的。
另外，如果某個用例需要有大量的輸入項，做手工測試比較繁瑣，我們也可以引入自動化的手段做局部的自動化。比如，驗證某個用戶登錄1000次是否能夠登錄成功，這種情況使用手工的方式基本是不可能的。
總結
服務端灰盒測試是一個很好的自動化測試的方向，從功能測試向服務端自動化測試轉型，需要自己學習充足的編程知識，有一定的變成能力。同時還需要了解HTTP協(xié)議（或RPC協(xié)議）、設計模式、Linux、DB、前端開發(fā)、算法、架構等知識，需要很多積累。如果你不知道怎么做，先寫10000行代碼！
作為一名自動化測試工程師，你合格嘛？
聽說長得好看的都在做
軟件測試，測試界從不缺大神，比如張南（
Google測試經(jīng)理）、Lisa Crispin和 Janet Gregory等等這些。在軟件測試變的越來越重要的今天，
自動化測試也在嶄露頭角。
那么，作為想在自動化測試方面大展宏圖以及已經(jīng)成文自動化測試工程師的你，那么以下的知識你究竟掌握了多少呢。
自動化測試框架及開發(fā)技術掌握
熟練掌握自動化測試框架的原理，和理論知識，以及在自動化測試框架基礎上，完成對
測試用例設計。自動化測試，不僅僅需要掌握UI界面測試，對一些開發(fā)知識：如JAVA/C++等開發(fā)語言，
數(shù)據(jù)庫知識掌握，代碼結構等等技能往往會給自己的
工作添彩。
測試用例維護
手工測試相較于自動化測試來說，針對大型項目，維護不方便。而對于，自動化測試來說，UI測試的難點就在于一旦有了變化，利用TestWriter可以對測試用例進行維護，一般來說，測試用例的維護量很大時，在維護上便有難度。
自動化測試工具的使用
業(yè)界流行的自動化測試工具有
Selenium，UFT，TestWriter等，了解工具的特性并且掌握方法，結合項目對測試工具進行選擇。自動化測試一般通過簡單的方法，便可以實現(xiàn)簡單自動化測試，比如：1.通過制腳本，錄制/回放 2.驅動腳本執(zhí)行手寫腳本。同時對測試用例、計劃進行管理。
自動化測試實踐
作為一名合格的自動化測試工程師，對測試員以及團隊是否起到幫助，這是相當重要的一個素質。針對測試人員自動化測試方向，給予推薦建設性的建議。明確的分析開發(fā)測試的成本，在工作中，對手工測試和自動化測試做出合適的選擇。
本站僅提供存儲服務，所有內容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權內容，請
點擊舉報。
