關于自動化的學習，一直是大家關注的話題，那么Python學習到什么程度就可以進行自動化測試了呢？下面結合我自身的學習歷程跟大家分享一下。

初識自動化

剛開始學自動化的時候，是跟著視頻課程學習的，當時學習完用Selenium進行腳本錄制之后，就覺得自動化測試好簡單，錄制腳本后回放腳本就行了，所以學完錄制腳本之后，就沒再往下繼續學習，使用Selenium腳本錄制的功能進行腳本的錄制回放。

結果可想而知，錄制腳本時，一個鼠標懸浮事件沒有錄制上，導致元素找不到，最終整個腳本以失敗而告終。

因為隨著前臺開發技術的不斷更新換代，并不是所有的事件、操作都能使用Selenium自動錄制上，還需要我們手動處理。

定位元素

總結這次失敗的教訓，我繼續進行視頻課程的學習，學到了使用WebDriver去定位元素，之前使用Selenium錄制不到的鼠標懸浮操作，用元素定位的方式也定位到了，腳本能正常跑通。

學習完本章內容后，我使用現有的知識，寫了一個回歸測試的腳本，包含下單、新增用戶、發貨等功能，基本包含了系統的主要的功能流程。

但是在寫完這個腳本后，我發現，目前掌握的知識只能滿足于這種簡單的流程測試，就像是下單的整個流程、發貨的整個流程，并不能滿足我們多樣化下單的需求。

比如說我這次下單要買紅色L碼，下次下單要買藍色S碼，如果使用我們現有的這種腳本編寫方式，同一個功能，只是參數不同，我們需要重復寫這一段代碼，有多少用例，就要重復多少次，不僅浪費時間，而且造成了代碼的冗余，而且還有參數寫錯的風險。

如果后期某個參數名改變，我們要把所有相關的參數名都改一遍，不利于后期代碼的維護，人員成本也比較高。

自動化測試框架

接下來就進行了自動化測試框架的學習，將不同的頁面、初始化方法、功能模塊等分開來寫，引入UnitTest進行測試用例的管理等等。引入UnitTest之后，上面提到的代碼冗余的問題就得到了解決。

因為UnitTest測試框架，把功能單獨寫一個方法里，使用該方法時就進行方法的調用，如上述提到的下單的功能，先將功能寫成一個方法，然后將不同的參數值寫到測試用例集合中，每次執行測試用例，就調用下單的方法，只需更改參數，不需要重復編寫代碼，這也解決了參數名更改導致的腳本問題，只需要在下單方法里修改參數名，并不需要在每個測試用例里都修改一遍，節省了時間，也避免了修改不完全造成的遺漏。

問題定位及解決

當然我們應該還具備問題定位及解決的能力。因為在學習的過程中，我們完全是按照視頻教程上按部就班的操作的，所以基本上不會遇到什么問題。

但是在實際的工作中應用的時候，網站是千變萬化的，難免會出現這樣那樣的問題，比如說教程里只說了可以通過class進行元素的定位，但沒有說如果一個class有多個屬性名應該怎么處理，比如我們如果直接把inputstyle password這兩個元素作為元素定位的標志，實踐發現并不能定位到元素，從搜索引擎搜索才知道，這種的代表這個元素都多個class的屬性名，我們只需選擇其中一個名稱進行定位即可。

諸如此類的這種小知識一般在課程里不會提到，但是是實際的工作中確實經常遇見的，所以我們還需要具備問題解決的能力，不能只局限于教程上的知識，不然自動化測試是進行不下去的。

結語

學習到此，小編認為就可以嘗試進行自動化測試腳本的編寫工作了。

當然，這只是基礎，學習是永無止境的，想要讓自己變得更優秀，讓自己寫的腳本更好，我們要不斷的擴展自己的知識，學到這里只是起點，后面我們還有很長的路要走。

但是也不能貪多，貪多嚼不爛，只是一味的學習但不應用到實際的工作中，學習的知識很快就會忘記了，而且學習和真正應用到工作也是不一樣的，因為在工作中我們會遇到各種各樣的在學習中未提及的知識點，需要我們不斷的去充實、鞏固當前已經掌握的知識，這樣才能將知識轉化為自己的所有物，并將其靈活運用。