PO設計模式詳解

 

一、傳統模式

• 重用性低：登錄功能重復

• 可維護性差：數據和代碼混合

• 可讀性差：元素定位方法雜亂（id、xpath、css混雜）

• 可讀性差：不易識別操作的含義（特別是css和xpath語法）

• 可維護性差：如果某個元素的屬性改了，你要更改多次

 

二、PO模型

• Page Object Model 頁面對象模型

• PO是自動化測試項目開發實踐的最佳設計模式之一

 

設計准則

地址：https://github.com/SeleniumHQ/selenium/wiki/PageObjects

 

1. The pulic methods represent the services that the page offers

   1. 使用公共方法來代表頁面提供的服務

   2. 基類（基礎服務：頁面的基礎的服務：點擊元素，輸入內容）

   3. 頁面類：登錄、添加商品

    

2. Try not to expose the internals of the page

   1. 不要暴露頁面的內部細節（比如元素 ，元素的定位方法等），隔離了測試用例和業務和頁面對象

    

3. Generally don't make assertions

   1. PO本身通常（絕）不應進行判斷或斷言. 判斷和斷言是測試的一部分, 應始終在測試的代碼內, 而不是在PO中. PO用來包含頁面的表示形式, 以及頁面通過方法提供的服務, 但是與PO無關的測試代碼不應包含在其中

    

4. Methods return other PageObjects

   1. 方法返回其他的頁面對象，進行頁面的關聯

   2. 登錄->首頁，首頁->添加商品，推薦正向返回

    

5. Need not represent an entire page

   1. PO不一定需要代表整個頁面，定義你所需要實現的業務的部分即可，所以在我們的測試中有的頁面對象可以非常簡單（用什么寫什么）. PO設計模式可用於表示頁面上的組件. 如果自動化測試中的頁面包含多個組件, 則每個組件都有單獨的頁面對象, 則可以提高可維護性.

    

6. Different results for the same action are modelled as different methods

   1. 相同的操作（但可能是不同的數據）帶來的不同的結果可以封裝成不同的方法。

補充：

1. 實例化PO時, 應進行一次驗證, 即驗證頁面以及頁面上可能的關鍵元素是否已正確加載. 在上面的示例中, SignInPage和HomePage的構造函數均檢查預期的頁面是否可用並准備接受測試請求（selenium官網提到的）

2. 上述只是一個經驗總結，非強制

 

分層模型：

• 表現層：頁面中可見的元素，都屬於表現層（元素定位的編寫）

• 操作層：對頁面可見元素的操作。點擊、輸入文本、獲取文本等（基類）

• 業務層：上面2層的組合，並聯合到一起形成某個業務動作，在頁面中對若干元素操作后所實現的功能。（頁面類的方法，也可以是多個頁面的組合）

• 測試用例就是組合了1個或多個頁面的方法，操作對應的元素，完成的測試。測試用例本身不在PO內

• 非PO結構和PO結構對比

 

 

• PO架構圖

• 項目結構