這張圖大概可以分為四部分，按照橫線切分，實際上是一行行測試程式碼。按照豎切，可分為物件，操作，值（資料）。下面分別對這四部分內容討論。

1、物件

物件是…，這部分的變化是由開發編寫程式碼是決定的。測試同學基本上對其影響力微乎其微。但如果要做自動化測試時，就需要考慮一個問題，如何保證物件不變化或者變化較小，如何保證讓物件的變化對測試影響變得更小，或者讓物件的變化時能夠第一時間告知測試，使得在第一時間能夠發現並修改。要做到這一點有兩個方案可參考。

1.1 和開發同學約定物件變更流程和規範

當一個需求需要快速上線時，對產品、開發同學來說，修改介面是最為簡單可行的方案，但對UI自動化測試來說確是災難。如何建立一套物件約束機制就顯得尤為重要。下面是當時做飛信UI自動化測試時和開發約定的幾條規範。

1）每個元素必須有ID和Name，ID和Name必須按照規範進行命名。

2）每一個物件和元素都必須按照約定格式編寫。

3）每一個編譯合格安裝包，都能夠自動化生成約定業務物件庫，並能夠自動校驗物件變化對指令碼的影響。

通過上面的約定，可以做到UI介面變化時，快速生成新的物件庫，並且能夠在第一時間確認UI的變化對測試指令碼的影響範圍，並快速維護。

1.2 基於框架物件的封裝

物件進行封裝抽象，以保證物件發生變化時對測試指令碼的影響最小。比如PageObject設計模式。

Page Object模式是自動化測試框架的一種測試設計模式，是指UI介面上用於與使用者進行互動的物件。將每一個頁面設計為一個Class，其中包含頁面中需要測試的元素（按鈕，輸入框，標題 等），這樣在測試頁面中可以通過呼叫頁面類來獲取頁面元素，這樣巧妙的避免了當頁面元素id或者位置變化時，需要改測試頁面程式碼的情況。 當頁面元素id變化時，只需要更改測試頁Class中頁面的屬性即可。通過對介面元素的封裝減少冗餘程式碼，提高測試用例的可維護性。

2、操作

一個物件確定後，其物件基本保持不變，所以在測試框架中能圍繞進行改進和操作的空間非常小。

比如：一個物件確定其型別是button後，其操作不外乎點選，雙擊，text等屬性。

3、資料（值）

在自動化測試原理圖中，資料是測試同學唯一可以掌控的地方，這也恰恰說明資料能力是測試核心能力之一，測試本身是不可遍歷不可窮盡，如何在眾多的測試資料中找到合適的測試資料，並能夠恰好滿足業務測試的覆蓋是測試核心的能力。所以自動化測試是測試的一種能力拓展和有效補充。

在自動化測試中如何組織資料是件很複雜的事情。需要考慮業務特性，技術能力，工作流程等等因素。

從資料週期和功能的角度思考，一般可分為全域性資料，如環境地址；依賴資料，業務串聯需要的上下游關鍵資料，如：賬號，訂單號；業務資料，為完成某項業務測試必須的資料，如京東金融小金庫轉賬所需要的各種入引數據。

從業務特性的角度思考，在介面測試中，其測試物件是入參和出參，變化較小，真正變化較多的是各種引數，所以大多數使用資料驅動的自動化框架。

在京東金融App測試中，業務資料變化相對較少，恰恰是介面元素變化較多，所以大多使用關鍵字驅動的PO設計模式，封裝和抽象物件的變化。

4、指令碼

測試指令碼對自動化從業人員來說在熟悉不過，有上圖可以看到，一行程式碼由物件，物件的操作和資料共同組成。一個業務指令碼由一行或者多行程式碼組成。一個指令碼可能是一個步驟或者一個測試用例。是測試程式碼組織中最基本的組成單元。下篇詳細介紹指令碼的組織方式相關的問題。

上面是我收集的一些視訊資源，在這個過程中幫到了我很多。如果你不想再體驗一次自學時找不到資料，沒人解答問題，堅持幾天便放棄的感受的話，可以加入我們扣扣群【313782132 】，裡面有各種軟體測試資源和技術討論。

當然還有面試，面試一般分為技術面和hr面，形式的話很少有群面，少部分企業可能會有一個交叉面，不過總的來說，技術面基本就是考察你的專業技術水平的，hr面的話主要是看這個人的綜合素質以及家庭情況符不符合公司要求，一般來講，技術的話只要通過了技術面hr面基本上是沒有問題（也有少數企業hr面會刷很多人）
我們主要來說技術面，技術面的話主要是考察專業技術知識和水平，上面也是我整理好的精選面試題。

趕快進來學習瞭解與交流吧，我是一包傷心的辣條。