我是一名大專生，專業是軟體技術成績挺好，其實也是因為學校老師沒怎麼教真東西只是一個基礎，升本沒上去，導致java，web,c語言基本上都忘了，目前想要自學自動化測試，學到可以工作的程度，但是實在不知道該怎麼入門，怎麼學，請各位大神救救孩子吧！！！！

可以上「極客時間」看看相關課程，比如

軟體測試52講（Ebay中國的茹炳晟）

移動端自動化測試實戰（思寒）的課程

200塊錢搞定，然後剩下的就看你自己肯不肯吃苦了。

因為最近在教學過程中, 總結了同學們所犯的很多錯誤，和之前沒做過自動化測試，但是限於領導要求，或者自己想提升了，開始研究自動化測試的人類似，最近記憶比較深的低級的幾個問題是：

1、編寫一個python的類將 __init__寫成_init_苦於問題一直解決不了；

2、想新建一個包，經常將package建成folder；

3、appium腳本中啟動的activity或者包名經常寫不出來；

4、將包名命名為selenium導致無法引入對應相應庫；

5、寫個selenium腳本執行不成功拋出異常，跑來問，這個怎麼又報錯了？異常類型都提示NoSuchElementException；

這些確實很初級的問題，其實最核心的而是缺乏編程能力、缺乏問題分析能力、缺乏解決問題能力。

功能測試學的可以之後就可以考慮進階學自動化測試，但自動化測試怎麼學習呢，這裡給大家提供一個簡易的學習路線。

對於功能測試學習自動化測試我的建議如下：

一、提升編程能力

二、熟悉分層自動化測試思想：

自動化是分為三個層面的（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自動化測試的一些實踐要求，當然也是相對簡易的，複雜的就是實現平台化管理，每天測試工程師，只需要選擇具體項目、所測的測試用例集，然後執行，輸出測試報告，郵件自動發送到相關開發/測試，框架的開發維護上也能夠持續集成。

題主沒有測試基礎，就需要先入門軟體測試，了解一些基礎的技能，比如：

了解這些技能後，需要參加一些實戰項目，才能找到工作。

具體內容，下面的鏈接中都有詳細的回答，如何自學軟體測試？

隨後可以學習自動化測試~ 請看鏈接：如何學習自動化測試？

這兩個鏈接中的100G自學資料，可私信我領取~

首先先要學一門語言，一般做自動化測試用Python會多一些，然後開展按照分層自動測試思想進行自動測試的實戰。一定是自動化技術和項目進行持續結合，持續自動化，持續實戰實戰才行哦、學自動化不是只是說寫代碼好就可以了，得有測試思想，什麼做自動化測試，自動化測試能解決什麼問題，該如何運用等才行哦。

具體的自動化測試提升技能視頻如下：

https://study.163.com/course/courseMain.htm?courseId=1209508868share=2shareId=400000000533070

如果說一點基礎都沒有的話，建議先學習python基礎。完全掌握一門語言，在來了解selenium。

推薦閱讀：
相关文章