軟體測驗回顧(5)

Web GUI自動化測驗

• 軟體測驗回顧(5)
  • 11章：傳統產品和互聯網產品的測驗策略
    • 傳統產品和互聯網產品的區別
    • 傳統產品測驗策略
    • 互聯網產品的測驗策略
  • 12章：GUI自動化原理
    • GUI自動化原理
  • 13章：資料驅動+頁面物件(PageObject)模型
    • 資料驅動
    • 頁面物件(PageObject)模型
  • 14章：自動化更好描述業務
    • 1.把握封裝的函式粒度
    • 2.銜接好2個操作函式之間的頁面
    • 3.業務抽象流程
  • 15章：GUI自動化中的測驗資料
    • 1.基于API呼叫創建測驗資料
    • 2.基于資料庫操作創建測驗資料
    • 3.綜合運用API呼叫和資料庫操作創建測驗資料
      • 實時創建資料：On-the-fly
      • 事先創建測驗資料：Out-of-box
      • On-the-fly和Out-of-box的互補
  • 16章：自動化GUI自動化測驗
    • 1. 頁面物件自動生成
    • 2.GUI測驗資料自動生成
    • 3.無頭瀏覽器
  • 17章：GUI自動化的穩定性
    • 非預計的彈出對話框
      • 解決方法
    • 頁面控制元件屬性的細微變化
      • 解決方法
    • 被測系統的A/B測驗
    • 隨機的頁面延遲造成控制元件識別失敗
    • 解決方法
    • 測驗資料問題
  • 18章：GUI自動化的測驗報告
    • 開源GUI測驗框架的測驗報告實作思路
  • 19章：大型專案中設計GUI自動化測驗策略
    • 1.大型全球化電商網站的GUI自動化測驗策略設計
    • 2.大型全球化電商網站的GUI自動化測驗腳本管理

11章：傳統產品和互聯網產品的測驗策略

傳統產品和互聯網產品的區別

互聯網產品：

• 上線周期短，以“天”甚至是以“小時”為單位
• 要求全回歸測驗的執行時間不能超過4小時，

傳統產品：

• 上線周期長，以“月”甚至是以“年”為單位

傳統產品測驗策略

單元測驗 + API測驗 + GUI測驗

采用GUI自動化測驗技術，用例的維護和執行代價依然很大

互聯網產品的測驗策略

GUI測驗 + API測驗

互聯網產品的GUI測驗通常采用“手工為主，自動化為輔”的測驗策略，

測驗重點放在API測驗

• API測驗用例的開發與除錯效率比GUI測驗要高得多
  • 通常就是準備測驗資料，發起request，驗證response這幾個標準步驟，
• API測驗用例的執行穩定性遠遠高于GUI測驗，
• 執行時間往往要比GUI測驗短很多
• 對微服務的測驗，本質上就是對不同的Web Service的測驗，也就是API測驗，
• API介面的改動一般比較少，即使有改動，絕大多數情況下也需要保證后向兼容性（Backward Compatibility）

重量級API測驗，輕量級GUI測驗，輕量級單元測驗

互聯網產品的全面單元測驗只會應用在那些相對穩定和最核心的模塊和服務上，而應用層或者上層業務服務很少會大規模開展單元測驗

12章：GUI自動化原理

GUI自動化原理

主要是知道gui的自動化原理

Selenium 2.0，又稱Selenium WebDriver，它利用的原理是：使用瀏覽器原生的WebDriver實作頁面操作

Selenium WebDriver是典型的Server-Client模式，Server端就是Remote Server，以下是Selenium 2.0作業原理的決議

1. 當使用Selenium2.0啟動瀏覽器Web Browser時，后臺會同時啟動基于WebDriver Wire協議的Web Service作為Selenium的Remote Server，并將其與瀏覽器系結，系結完成后，Remote Server就開始監聽Client端的操作請求，
2. 執行測驗時，測驗用例會作為Client端，將需要執行的頁面操作請求以Http Request的方式發送給Remote Server，該HTTP Request的body，是以WebDriver Wire協議規定的JSON格式來描述需要瀏覽器執行的具體操作，
3. Remote Server接收到請求后，會對請求進行決議，并將決議結果發給WebDriver，由WebDriver實際執行瀏覽器的操作，
4. WebDriver可以看做是直接操作瀏覽器的原生組件（Native Component），所以搭建測驗環境時，通常都需要先下載瀏覽器對應的WebDriver，

13章：資料驅動+頁面物件(PageObject)模型

資料驅動

在寫自動化用例時候，不可以進行硬編碼、還需要多代碼進行復用，解決方案就是把測驗資料和測驗腳本分離，也就是說測驗腳本只有一份，其中需要輸入資料的地方會用變數來代替，

這個存放測驗輸入資料的檔案，通常是表格的形式，也就是最常見的CSV檔案，

然后，在測驗腳本中通過data provider去CSV檔案中讀取一行資料，賦值給相應的變數，執行測驗用例，接著再去CSV檔案中讀取下一行資料，讀取完所有的資料后，測驗結束，CSV檔案中有幾行資料，測驗用例就會被執行幾次，

這也就是典型的資料驅動（Data-driven）測驗了，

• 資料驅動很好地解決了大量重復腳本的問題，實作了“測驗腳本和資料的解耦”
• 資料驅動測驗的資料檔案中不僅可以包含測驗輸入資料，還可以包含測驗驗證結果資料，甚至可以包含測驗邏輯分支的控制變數
• 資料驅動測驗的思想不僅適用于GUI測驗，還可以用于API測驗、介面測驗、單元測驗等，

頁面物件(PageObject)模型

頁面物件模型的核心理念是，以頁面（Web Page 或者Native App Page）為單位來封裝頁面上的控制元件以及控制元件的部分操作，而測驗用例，更確切地說是操作函式，基于頁面封裝物件來完成具體的界面操作，最典型的模式是“XXXPage.YYYComponent.ZZZOperation”，

就是利用模塊化思想，把一些通用的操作集合打包成一個個名字有意義的函式，然后GUI自動化腳本直接去呼叫這些操作函式來構成整個測驗用例，這樣GUI自動化測驗腳本就從原本的“流水賬”過渡到了“可重用腳本片段”，

• 解決了腳本可讀性差的問題，腳本的邏輯層次也更清晰了；
• 解決了通用步驟會在大量測驗腳本中重復出現的問題，當某個步驟的操作或者界面控制元件發生變化時，只要一次性修改相關的操作函式就可以了，而不需要去每個測驗用例中逐個修改，

個人理解就是對 某一個頁面作為一個類，頁面里面的操作就是 函式，剩下把細節全部封裝在函式內，在呼叫是使用時候，就不會對細節造成困擾，也提高了可讀性，類似：關鍵字測驗

14章：自動化更好描述業務

1.把握封裝的函式粒度

很大程度上取決于專案的實際情況，以及測驗用例步驟的設計，并沒有一個放之四海而皆準的絕對標準，

往往以完成一個業務流程（business flow）為主線，抽象出其中的“高內聚低耦合”的操作步驟集合，操作函式就由這些操作步驟集合構成，

2.銜接好2個操作函式之間的頁面

前序操作函式完成后的最后一個頁面，必須是后續操作函式的第一個頁面，

如果連續的兩個操作函式之間無法用頁面銜接，那就需要在兩個操作函式之間加入額外的頁面跳轉代碼，或者是在操作函式內部加入特定的頁面跳轉代碼，

3.業務抽象流程

業務流程抽象是，基于操作函式的更接近于實際業務的更高層次的抽象方式，基于業務流程抽象實作的測驗用例往往靈活性會非常好，你可以很方便地組裝出各種測驗用例

業務流程的核心思想是，從業務的維度來指導測驗業務流程的封裝，由于業務流程封裝通常很貼近實際業務，所以特別適用于組裝面向終端用戶的端到端（E2E）的系統功能測驗用例，尤其適用于業務功能非常多，并且存在各種組合的E2E測驗場景，

15章：GUI自動化中的測驗資料

GUI測驗中兩種常見的資料型別：

• 測驗時輸入資料，
• 事先準備好的測驗資料，

在實際專案中，對于創建資料的技術手段而言，最佳的選擇是利用API來創建資料，只有當API不能滿足資料創建的需求時，才會使用資料庫操作的手段，

實際上，往往很多測驗資料的創建是基于API和資料庫操作兩者的結合來完成，即先通過API創建基本的資料，然后呼叫資料庫操作來修改資料，以達到對測驗資料的特定要求，

而對于創建資料的時機，在實際專案中，往往是On-the-fly和Out-of-box結合在一起使用，

對于相對穩定的測驗資料，比如商品型別、圖書型別等，往往采用Out-of-box的方式以提高效率；而對于那些只能一次性使用的測驗資料，比如商品、訂單、優惠券等，往往采用On-the-fly的方式以保證不存在臟資料問題，

1.基于API呼叫創建測驗資料

由于API通常都有安全相關的token機制來保護，所以實際專案中，通常會把對這些API的呼叫以代碼的形式封裝為測驗資料工具（Test Data Utility），

測驗資料的準確性直接由產品API保證，缺點是并不是所有的測驗資料都有相關的API來支持，

基于API呼叫方式的執行效率，即使采用了并發機制也不會十分理想

2.基于資料庫操作創建測驗資料

很多資料的創建和修改直接在產品代碼內完成，而且并沒有對外暴露供測驗使用的介面，

這種情況下，需要通過直接操作資料庫的方式來產生測驗資料，

同樣地，我們可以把創建和修改資料的相關SQL陳述句封裝成測驗資料工具，以方便測驗用例的使用，

創建或修改一條測驗資料往往會涉及很多業務表，任何的遺漏都會造成測驗資料的不準確，從而導致有些測驗因為資料問題而無法進行，

兩個思路來幫你解決這個問題：

• 手工方式，
  • 查閱設計檔案和產品代碼，找到相關的SQL陳述句集合，
  • 直接找開發人員索要相關的SQL陳述句集合，
• 自動方式
  • 先在只有一個活躍用戶的情況下，通過GUI界面操作完成資料的創建、修改，然后利用資料庫監控工具獲取這段時間內所有的業務表修改記錄，以此為依據開發SQL陳述句集，

假定產品功能正確，否則就會出現“一錯到底”的尷尬局面，

好處:

• 可以創建和修改API不支持的測驗資料，
• 并且由于是直接資料庫操作，執行效率會遠遠高于API呼叫方法，

壞處：

• 經常出現因為SQL陳述句更新不及時而導致測驗資料錯誤的問題
• 資料不準確往往只是區域錯誤，因此這類問題往往比較隱蔽，只有在特定的測驗場景下才會暴露，

在實際工程專案中，需要引入測驗資料工具的版本管理，并通過開發流程來保證SQL的變更能夠及時通知到測驗資料工具團隊，

3.綜合運用API呼叫和資料庫操作創建測驗資料

實時創建資料：On-the-fly

GUI測驗腳本中，在開始執行界面操作前，我們往往會通過呼叫測驗資料工具實時創建測驗資料，也就是On-the-fly方式，

• 在用例執行程序中實時創建資料，導致測驗的執行時間比較長，
• 業務資料的連帶關系，導致測驗資料的創建效率非常低，
• 更糟糕的情況是，實時創建測驗資料的方式對測驗環境的依賴性很強

事先創建測驗資料：Out-of-box

Out-of-box的含義是開箱即用，也就是說，已經在被測系統中預先創建好了充足的、典型的測驗資料，這些資料通常是在搭建測驗環境時通過資料庫腳本“預埋”在系統中的，后續的測驗用例可以直接使用

• 測驗用例中需要硬編碼（hardcode）測驗資料，額外引入了測驗資料和用例之間的依賴
• 只能被一次性使用的測驗資料不適合Out-of-box的方式，
• “預埋”的測驗資料的可靠性遠不如實時創建的資料，

On-the-fly和Out-of-box的互補

在實際的大型測驗專案中，我們往往會采用兩者相結合的方式，從測驗資料本身的特點入手，選取不同的測驗資料創建方式，

• 對于相對穩定、很少有修改的資料，建議采用Out-of-box的方式，比如商品類目、廠商品牌、部分標準的賣家和買家賬號等，
• 對于一次性使用、經常需要修改、狀態經常變化的資料，建議使用On-the-fly的方式，
• 用On-the-fly方式創建測驗資料時，上游資料的創建可以采用Out-of-box方式，以提高測驗資料創建的效率，
  • 以訂單資料為例，訂單的創建可以采用On-the-fly方式，而與訂單相關聯的賣家、買家和商品資訊可以使用Out-of-box方式創建，

16章：自動化GUI自動化測驗

• 頁面物件自動生成
• GUI測驗資料自動生成
• 無頭瀏覽器

1. 頁面物件自動生成

頁面物件自動生成技術，它非常適用于需要維護大量頁面物件的中大型GUI自動化測驗專案，

基本思路是，你不用再手工維護Page Class了，只需要提供Web的URL，它就會自動幫你生成這個頁面上所有控制元件的定位資訊，并自動生成Page Class，，需要注意的是，那些依賴于資料的動態頁面物件也會被包含在自動生成的Page Class里，而這種動態頁面物件通常不應該包含在Page Class里，所以，往往需要以手工的方式洗掉，

很多商用自動化工具，比如UFT，已經支持頁面物件自動生成功能了，同時還能夠對Page Class進行版本管理，目前國內應用還不算多、免費的Katalon Studio，已經提供了類似的頁面物件庫管理功能，

2.GUI測驗資料自動生成

由機器自動生成測驗用例的輸入資料，

• 根據GUI輸入資料型別，以及對應的自定義規則庫自動生成測驗輸入資料，
  • GUI界面上有一個“書名”輸入框，它的資料型別是string，基于資料型別就可以自動生成諸如 Null、SQL注入、超長字串、非英語字符等測驗資料，
    同時，根據自定義規則庫，還可以根據具體規則生成各種測驗資料，這個自定義規則庫里面的規則，
• 對于需要組合多個測驗輸入資料的場景，測驗資料自動生成可以自動完成多個測驗資料的笛卡爾積組合，然后再以人工的方式剔除掉非法的資料組合，
  • 先手動選擇部分輸入資料進行笛卡爾積，并洗掉不合法的部分；然后，在此基礎上，再人為添加更多業務上有意義的輸入資料組合，
    • 輸入資料有A、B、C、D、E、F六個引數，你可以先選取最典型的幾個引數生成笛卡爾積，假設這里選取A、B和C；然后，在生成的笛卡爾積中洗掉業務上不合法的組合；最后，再結合D、E和F的一些典型取值，構成更多的測驗輸入資料組合，

3.無頭瀏覽器

Headless Browser，是一種沒有界面的瀏覽器，

其實是一個特殊的瀏覽器，你可以把它簡單地想象成是運行在記憶體中的瀏覽器，它擁有完整的瀏覽器內核，包括JavaScript決議引擎、渲染引擎等，

與普通瀏覽器最大的不同是，無頭瀏覽器執行程序中看不到運行的界面，但是你依然可以用GUI測驗框架的截圖功能截取它執行中的頁面，

• 測驗執行速度更快，
  • 無頭瀏覽器無需加載CSS以及渲染頁面
• 減少對測驗執行的干擾，
  • 不可預期的彈出框，對瀏覽器測驗的干擾，
• 簡化測驗執行環境的搭建，
  • GUI測驗可以直接運行在無界面的服務器上，
• 在單機環境實作測驗的并發執行

它最大的缺點是，不能完全模擬真實的用戶行為，而且由于沒有實際完成頁面的渲染，所以不太適用于需要對于頁面布局進行驗證的場景，同時，業界也一直缺乏理想的無頭瀏覽器方案，

Puppeteer是由Google開發的，所以它可以很好地支持Headless Chrome以及后續Chrome的版本更新，

selenium + xpath的組合很方便，可以解決大部分的元素識別，chrome瀏覽器右鍵拷貝 xpath，很方便，

無頭瀏覽器目前應用的比較少，多是用來做爬蟲，說實話老師的這些工具我是一個都沒用過

17章：GUI自動化的穩定性

GUI自動化測驗穩定性，最典型的表現形式就是，同樣的測驗用例在同樣的環境上，時而測驗通過，時而測驗失敗

要提高GUI測驗穩定性，首先你需要知道到底是什么原因引起的不穩定，你必須找出盡可能多的不穩定因素，然后找到每一類不穩定因素對應的解決方案，

造成GUI測驗不穩定的因素：

• 非預計的彈出對話框；
• 頁面控制元件屬性的細微變化
• 被測系統的A/B測驗；
• 隨機的頁面延遲造成控制元件識別失敗；
• 測驗資料問題，

非預計的彈出對話框

• GUI自動化測驗用例執行程序中，作業系統彈出的非預計對話框
  • （作業系統突然彈出殺毒軟體更新請求、病毒告警資訊、系統更新請求等對話框，）
• 被測軟體本身也有可能在非預期的時間彈出預期的對話框
  • 你在網站上進行操作時，很可能會隨機彈出“用戶調查”對話框，

解決方法

• 當自動化腳本發現控制元件無法正常定位，或者無法操作時，GUI自動化框架自動進入“例外場景恢復模式”，
• 在“例外場景恢復模式”下，GUI自動化框架依次檢查各種可能出現的對話框，一旦確認了對話框的型別，立即執行預定義的操作（比如，單擊“確定”按鈕，關閉這個對話框），接著重試剛才失敗的步驟，

頁面控制元件屬性的細微變化

登錄”按鈕的ID從“Button_Login_001”變成了“Button_Login_888”，就會因為ID值的變化，定位不到它了，自動化測驗用例自然就會失敗，

解決方法

采用“組合屬性”定位控制元件會更精準，而且成功率會更高，如果能在此基礎上加入“模糊匹配”技術，可以進一步提高控制元件的識別率，

• “模糊匹配”是指，通過特定的相似度演算法，控制元件屬性發生細微變化時，這個控制元件依舊可以被準確定位，
  • 開源的GUI自動化測驗框架，目前還沒有現成的框架直接支持模糊匹配，通常需要你進行二次開發
    • 實作思路是：實作自己的物件識別控制層，也就是在原本的物件識別基礎上額外封裝一層，在這個額外封裝的層中加上模糊匹配的實作邏輯，

通常，我不建議把模糊匹配邏輯以硬編碼的方式寫在代碼里，而是引入規則引擎，將具體的規則通過組態檔的方式與代碼邏輯解耦，

有幸經歷過這樣的場景，不過我們的方案簡單粗暴，就是和前端開發約定規則，例如我們是統一使用id進行定位了，也就是說前端開發不可以隨意的更改id，(因為我不是互聯網公司，web不經常變化，可以適用約定規則這個路線)

被測系統的A/B測驗

A/B測驗，是互聯網產品常用的一種測驗方法，它為Web或App的界面或流程提供兩個不同的版本，然后讓用戶隨機訪問其中一個版本，并收集兩個版本的用戶體驗資料和業務資料，最后分析評估出最好的版本用于正式發布，

A/B 測驗通常會發布到實際生產環境，所以就會造成生產環境中GUI自動化測驗的不穩定，

這種問題的解決思路是，在測驗腳本內部對不同的被測版本做分支處理，腳本需要能夠區分A和B兩個的不同版本，并做出相應的處理，

隨機的頁面延遲造成控制元件識別失敗

解決方法

一個屢試不爽的辦法就是，加入重試（retry）機制，當某一步GUI操作失敗時，框架會自動發起重試，重試可以是步驟級別的，也可以是頁面級別的，甚至是業務流程級別的，

開源GUI測驗框架，重試機制往往不是自帶的功能，需要自己二次開發來實作，

對于那些會修改一次性使用資料的場景，切忌不要盲目啟用頁面級別和業務流程級別的重試，

我們是靠經驗的加等待時間，后來發現selenium 有一個函式可以設定一個最大超時時間，在這個時間之前都會等待，一旦超時時間內滿足了繼續執行的條件，也可以立刻執行，既保證了用例操作的預期性，也解決了延遲的不可控的問題

測驗資料問題

測驗用例所依賴的資料被其他用例修改了；再比如，測驗程序中發生錯誤后自動進行了重試操作，但是資料狀態已經在第一次執行中被修改了，

不穩定的自動化是相當耗心血的作業，能徹底把人搞瘋，維護者還不出作業量，所以盡可能讓gui自動化穩定，多處理，保持一個高的穩定率

18章：GUI自動化的測驗報告

理想中的GUI測驗報告應該是由一系列按時間順序排列的螢屏截圖組成，并且這些截圖上可以高亮顯示所操作的元素，同時按照執行順序配有相關操作步驟的詳細描述，

開源GUI測驗框架的測驗報告實作思路

• 需要自己去實作截圖以及高亮顯示操作元素的功能，
  • 利用Selenium WebDriver的screenshot函式在一些特定的時機（比如，頁面發生跳轉時，在頁面上操作某個控制元件時，或者是測驗失敗時，等等）完成界面截圖功能，
  • 擴展Selenium原本的操作函式；
  • 在相關的Hook操作中呼叫screenshot函式，

擴展Selenium原本的操作函式實作截圖以及高亮顯示操作元素的功能

• 首先，用Javascript代碼高亮顯示被操作的元素，
  • 高亮的實作方式就是利用JavaScript在物件的邊框上渲染一個5-8個像素的邊緣；
  • 然后，呼叫screenshot函式完成點擊前的截圖；
  • 最后，呼叫Selenium原生的click函式完成真正的點擊操作，

在相關的Hook操作中呼叫screenshot函式實作截圖以及高亮顯示操作元素的功能

截圖的測驗報告的具體資料結構其實是個大的json檔案，json中的每個節點元素記錄了時間戳，測驗用例輸出的log，截圖檔案的保存路徑等資訊，所以就可以很方便的在報告中同步顯示對應的log資訊，

操作步驟截圖功能，Windows7 系統開始，自帶一個「問題步驟記錄器」，直接在運行框輸入 psr.exe 就可以調起，開啟監控后，所有操作步驟的說明和截圖都會保存成 MHTML 檔案，結束時會打包到一個壓縮包中,沒用過的推薦試一下，

19章：大型專案中設計GUI自動化測驗策略

前提：大型全球化電商網站的前端模塊劃分

各個前端模塊都有各自獨立的代碼庫，除此之外還會有一個公共組件的代碼庫，

1.大型全球化電商網站的GUI自動化測驗策略設計

GUI測驗通常只覆寫最核心且直接影響主營業務流程的E2E場景，也應該是分階段、分層次來設計制定測驗策略的

1. 首先，要從前端組件的級別來保證質量，也就是需要對那些自定義開發的組件進行完整全面的測驗
   1. 最常用的方案是：基于Jest開展單元測驗，并考量JavaScript的代碼覆寫率指標，
   2. 在頁面層面再次驗證控制元件相關的功能和狀態，
      1. 先構建一個空頁面，并加入被測控制元件，由此可以構建出一個包含被測控制元件的測驗頁面，這個頁面往往被稱為Dummy Page；
      2. 從黑盒的角度出發，在這個測驗頁面上通過手工和自動化的方式操作被測控制元件，并驗證其功能的正確性，
2. 每一個前端模塊，都會構建自己的頁面物件庫，并且在此基礎上封裝開發自己的業務流程腳本，這些業務流程的腳本，可以組裝成每個前端模塊的測驗用例，

以用戶管理模塊為例，測驗用例的組裝程序如下：

• 首先，把用戶管理模塊中涉及到的所有頁面，比如登錄頁面、用戶注冊頁面等，按照頁面物件模型的要求寫成Page類；

• 然后，利用這些Page類封裝業務流程腳本，比如用戶登錄流程，用戶注冊流程等；

• 最后，在GUI測驗用例腳本中，呼叫封裝好的業務流程腳本構成該模塊的GUI測驗用例，

  在這個階段，測驗用例需要完整覆寫該模塊的所有業務邏輯以及相關的功能測驗點，但是并不會實作所有測驗用例的自動化，

  自動化測驗用例的原則，通常是：優先選取業務關鍵路徑以及Happy Path作為自動化測驗的范圍，在資源充裕的情況下，我們希望這個階段的自動化率可以達到70%-80%， 所以，前端模塊的質量保證主要依賴這部分測驗，

3. 最后，組合各個前端模塊，并站在終端用戶的視角，以黑盒的方式使用網站的端到端（E2E）測驗，
   1. 探索式測驗的方法手工執行測驗
   2. GUI自動化測驗執行基本業務功能的回歸測驗(往往是幾百個的規模，但是對于保證最終網站的質量卻起著非常關鍵的作用，)

負責這種系統級別的GUI測驗，往往被稱為E2E測驗團隊，E2E團隊應該盡可能地利用各個模塊已有的頁面物件和業務流程腳本，組裝端到端的GUI測驗，

2.大型全球化電商網站的GUI自動化測驗腳本管理

將各個模塊的頁面物件和業務流程腳本放在各自的代碼庫中，并引入頁面物件和業務流程腳本的版本管理機制，通常采用頁面物件和業務流程腳本的版本號和開發版本號保持一致的方案，

比如模塊A的版本號是V1.0.0，那么對應的頁面物件庫和業務流程腳本的版本號也應該是V1.0.0，在端到端的GUI自動化測驗腳本中，參考各個模塊正確的頁面物件和業務流程腳本的版本號，測驗用例代碼就可以直接呼叫模塊的頁面物件和業務流程腳本了，

在這種管理機制下，E2E團隊不需要重復開發任何的頁面物件和業務流程腳本，而且可以始終保證與各個模塊的最新實作同步，同時端到端的GUI測驗用例腳本也會比較穩定，不會因為各個模塊的改動而頻繁地修改，

標籤：其他

上一篇：軟體測驗工程師(Linux命令大全)零基礎小白學習_入門到精通01

下一篇：軟體測驗回顧(8)-性能測驗