一、自動化測試含義

在自動化測試領域內流傳著一個說法：單元測試才是自動化測試的核心，在自動化測試裡，無論框架何等完美都不可能脫離單元測試，單元測試將會是自動化測試裡最小的單位，把它看作單位一，若干個單位一組成了一個整體，它就成了自動化測試；

諸如Python的單元測試框架Unittest、Pytest；Java的單元測試框架TestNG、Junit都為自動化測試提供並承擔了決定性的支援，如何做好單位一，是一個合格的自動化測試工程師所必備的技能。

二、結構說明

• Util:工具類包:包含操作瀏覽器的常規事件、鍵盤及滑鼠事件的模擬、檔案的解析等，不區分平臺皆可使用的公共的工具類
• PageObject:頁面物件包：以每一個頁面為單位，封裝該頁面內所有需要控制的控制元件，通過頁面控制元件的定位將其封裝成物件，然後操作該物件實現自動化操作
• AppModules:公共應用模組包：在產品的業務流程中，常有中間過程，公共流程，例如登陸、例如導航，將其獨立封裝，而非在指令碼中重複編寫
• PropertyFiles:屬性檔案包：自動化框架必須實現的一點，頁面元素獨立，配置資訊獨立，從而達到更高的可維護性，頁面的變動對整體程式碼影響降到最低
• TestScripts:測試指令碼包：以TestNG作為支撐，單純的測試指令碼
• TestData:測試資料包：自動化框架必須實現的一點，測試資料獨立，根據實際測試內容的需要可以將測試資料存放在檔案裡，可以是excel、yaml、json等，而Util包裡提供解析測試資料檔案的工具類實現對的讀取寫入，在測試資料量少的情況下，則可直接使用TestNG的DataProvider實現測試資料的組織形式
• Constants:常量包：用於定義一些配置資訊如檔案路徑、SQL語句、連資料庫資訊等以供程式碼直接呼叫

      注：每一款產品都有不同的特性，例如針對我們平臺來說，它提供大量的服務及應用相關內容，這些內容並非單純的UI自動化可測的，因此我們在Util裡單獨為服務驗證提供方法用於驗證Mysql、MongoDB、Redis、ElasticSearch、PostGreSQL、Neo4j、Kafka、RabbitMQ等服務在UI自動化執行後對服務可用性進行補充驗證。

三、編碼規則及樣例

任何一家公司的自動化框架都應該有一定的規約，當自動化工程師進進出出團隊，難免變法風格及相關工作存在一定的差異。

那麼自動化團隊的編碼規約應該從哪寫方面進行規範呢？

• 命名風格規約
• 常量定義規約
• 程式碼格式規約
• 控制語句規約
• 註釋規約
• 元素定位規約
• 頁面元素封裝規約
• 自動化測試指令碼規約
• 工具類封裝規約
• 公用應用類封裝規約

 四、使用自動化測試框架的優勢

為什麼要使用自動化測試框架，實際上很多已經從事了自動化測試的人或者剛剛邁進門檻的人都會問這個問題。

明明一個檔案就能編寫用例並執行，為什麼要費那麼大力氣弄框架，為什麼要使用它？

我在從事了很多年自動化測試工作後一度非常厭倦，我們常常會吐槽的點大概就是:為什麼PO又要對頁面進行優化、為什麼前端程式碼如此的不規範、為什麼需求又變了等等

一個產品的自動化用例量可能有幾千幾萬甚至更多，一旦頁面發生變化就可能導致我們的用例因為定位不到頁面元素而執行失敗或者斷言失敗，如此我們修改自動化程式碼的代價就是不可估量的，程式碼的可維護性無法保障

同樣的道理，測試輸入，我們的測試資料也儘可能不要出現在測試程式碼中，從而方便維護和擴充套件

在一個產品內的思考：公共方法類的封裝，例如一個產品的業務邏輯會出現很多公共的且繞不過去的部分，比如登陸、比如導航，我們不可能每個用例都去編寫或複製一遍它，因此自動化框架也將這公共部分單獨封裝以供呼叫

再有一個很重要的考慮層面是，我們決定做一個新的產品，也要上自動化測試，那麼原有的自動化測試中是否有直接遷移的部分，以便我們新的團隊不用從0做起

因此我們還要合理的封裝一些通用的不依賴產品本身的API，例如滑鼠操作、鍵盤操作、瀏覽器控制、檔案解析、報告類、日誌類等等

五、好的自動化框架什麼樣

其一 必須做到頁面元素與實際測試程式碼分離

其二 必須做到測試資料與實際測試程式碼分離

其三 必須將公共方法獨立封裝不可依賴於產品

其四 必須儘可能封裝產品內的公共模組以供呼叫

自動化測試框架的目標一定是為自動化測試工程師服務的，讓他們能夠快速構建測試程式碼，並且框架必須是鬆耦合的從而使它可維護可擴充套件