因為最近在群里有一些同學，之前沒做過自動化測試，但是限於領導要求，或者自己想提升了，開始研究自動化測試，最近記憶比較深的低級的幾個問題是：
1、編寫一個python的類將 __init__寫成_init_苦於問題一直解決不了；
2、想新建一個包，經常將package建成folder；
3、appium腳本中啟動的activity或者包名經常寫不出來；
4、將包名命名為selenium導致無法引入對應相應庫；
5、寫個selenium腳本執行不成功拋出異常，跑來問，這個怎么又報錯了？異常類型都提示NoSuchElementException；
這些確實很初級的問題，其實最核心的而是缺乏編程能力、缺乏問題分析能力、缺乏解決問題能力。
對於功能測試學習自動化測試我的建議如下：
一、提升編程能力：
編程能力是一切的基礎，所以基礎先打堅固，對於python或者java的學習，可以看我自動化專欄里邊的文章，也可以看我的論壇，里邊有比較清楚的分類。
二、熟悉分層自動化測試思想：
自動化是分為三個層面的（UI層自動化、接口自動化、單元測試），不是每個層面的自動化都是遙不可及的，以下標示一下這三個層面的難易程度（也叫這個為自動化金字塔）：
三個層面的自動化測試
基本上可以肯定的是，單元測試是成本最低的，也是最容易推廣，見效最大的，但是很多公司不會投入這塊，原因是因為現在大部分公司都是人才短缺，特別是成熟的研發人員。你說投入到項目實際開發工作的人員都嫌不夠，怎么可能抽出相關人力去做單元測試。而以目前大部分公司的測試團隊人員構成來說，能做單元測試的基本沒有（有也被抽去做開發了），這也是大家一致認為單元測試屬於開發職責的原因（除了他們自己沒人能做了）。
單元測試如果做不了，那么接口（API或Service）自動化測試能做不？這個只要有一定的技術基礎還是能做的，至少有一部分測試人員是能夠做接口測試的（話說性能測試就屬於一種接口自動化），如果能自主開發或直接引進一套像樣的接口自動化工具或框架（工具上來說，市面上也不少），那么就可以開展這部分的工作，我相信大部分公司能做好的自動化測試，應該也是基於這一層的（所以我們建議有條件的話，自動化測試可以先在這一層面展開，當然前提是真有那么多接口或服務需要測試）。接口自動化測試框架應該具有以下功能，根據復雜度和各自需求而定：
1、校驗
這個很好了解，如果沒有校驗，單純的執行接口的話，那就談不上測試了。所以支持對返回值校驗是一個必須的功能。
2、數據隔離
數據隔離就是指具體的請求接口、參數、校驗等數據做到與代碼相隔離，便於維護，一旦需要調整接口用例、新增接口用例時可很快速的找到位置，隔離的另一個好處就是可復用，框架可以推廣給其他團隊，使用者可以使用相同的代碼，只需要根據要求填寫各自用例即可測試起來。
3、數據傳遞
做到數據隔離可維護后，數據傳遞是另外一個更重要的需求。
數據傳遞是指接口用例之間可以做到向下傳參，例如我們通過創建訂單接口創建一個訂單，該接口會返回一個訂單號，接下來我們要進行調用查詢訂單的接口，從返回的數據中與創建訂單用例中的數據進行校驗，此時第二個接口的請求數據是需要從第一個接口用例中的返回中提取的。這樣的例子比比皆是，所以支持數據傳遞是又一個必不可少的功能。
4、動態函數
實際用例場景中我們可能會有隨機生成一個手機號、字符串加密等需求，在數據與代碼隔離之后，此時我們就需要代碼可以支持做到識別對應關鍵字時可以執行對應的函數進行填充。例如在數據中填寫nowTime()時，具體執行時會被替換成當前時間，填寫random(5)時，會被替換成一個五位的隨機數等等。
5、可配置
有時，我們的需求是用例不單單只能在一個環境上執行，可能需要同一份接口用例可以在QA、預發、線上等多個環境都可以執行。所以框架需要做到可配置，便於切換，調用不同的配置文件可以在不同的環境執行。
6、日志
日志包含執行的具體執行接口、請求方式、請求參數、返回值、校驗接口、請求時間、耗時等關鍵信息，日志的好處一來是可以便於在新增用例有問題時快速定位出哪里填寫有問題，二來是發現bug時方便向開發反饋提供數據，開發可以從觸發時間以及參數等信息快速定位到問題所在。
7、可視化報告
用例執行后，就是到了向團隊展示結果的時候了，一個可視化的報告可以便於團隊成員了解到每次自動化接口用例執行的成功數、失敗數等數據。
8、用例驅動
（1）用例的驅動模式，涉及到怎么存放測試數據，怎么描述用例，又如何復用；
（2）考慮到效率的話還要支持並發；
（3）當然測試報告不能光記錄成功和失敗，還有用例執行耗時、接口調用耗時、場景的通過率等各項數值的統計。
說完單元測試、接口測試的自動化，我們現在來說說UI層自動化測試，這也是一直很火並且也是自動化概念先入為主的一塊，畢竟市面上有不少成熟的自動化工具，如QTP、Selenium等。這塊自動化一定是會有測試團隊參與的，就算自動化框架是由開發來完成，那么具體測試工作也是由Tester全程參與的。UI層自動化測試真的不容易推行，無論有多么完善的自動化框架，在這一塊維護的成本也是非常高的，特別是懂開發的人不懂測試，懂測試的人不懂開發，這一矛盾現象所帶來的內部消耗就不少，再加上項目需求和UI層都在頻繁變動，而且Web UI技術越來越復雜和多元化（UI層自動化需要基於對象識別技術），這些都導致很多公司不願意投入這一塊。即使這樣，做為一個有上進心的測試人員，我們也是需要多想想這一塊，畢竟這是離我們測試最近的一塊“技術沃土”了（之一）。
現在我們來重點來談下Web UI自動化測試（目前的系統大都通過Web UI來展示），一般成熟一點的自動化工具方案大體是這樣：
1. 開發語言：Python或Java；
2. 開源測試框架：Selenium WebDriver；
3. Web元素定位：Xpath + cssSelector + findElement或findElements方法。
具體實施細節來講重點是針對Web UI自動化測試的特點，將各層包裝，分而治之的思想，各自相互獨立，職責定義清楚，下面簡要說明下：
1、測試用例業務流操作實現及測試數據分離管理；
2、頁面元素定位及頁面元素的操作分離；
3、可視化的日志查詢系統；
4、跨瀏覽器支持如：IE,Firefox,Chrome；
5、可視化的的測試報告，可以具體查詢到日志/截圖等；
6、實現了通過Excel的數據驅動管理；
7、郵件發送管理，可以自定義具體時間及接受者等。
以上是一般Web UI自動化測試的一些實踐要求，當然也是相對簡易的，復雜的就是實現平台化管理，每天測試工程師，只需要選擇具體項目、所測的測試用例集，然后執行，輸出測試報告，郵件自動發送到相關開發/測試，框架的開發維護上也能夠持續集成。
那么對於每一層一般都有那些技術方案呢？
UI層：
1、python+selenium+unittest、python+appium+unittest；
2、java+selenium+testng、java+appium+testng；
接口層：
python+requests；java+httpclient或者restassured
底層：
玩靜態代碼掃描吧，java方向有findbugs、pmd、checkstyle、fireline、godeyes、infer
oc方向oclint、infer
web方向：csslint、jslint等
這些過程似乎不是那么快速高效，但是效果會很好，如想快速入門，報培訓班是不錯的選擇，但還得靠自己多花時間，多學習，多總結。