標簽（空格分隔）： GUI自動化策略
帶你看看實際的大型全球化電商網站的 GUI 自動化測試如何開展。這場實戰，我將從以下兩個方面展開
- 試策略如何設計？這一點，我會根據親身經歷的實際項目，和你探討 GUI 測試的分層測試策略。測試用例腳本如何組織？需要注意的是，對於這個問題，我不是要和你討論測試用例的管理，而是要討論測試用腳本的管理。比如，當需要組裝上層的端到端（E2E）測試時，如何才能最大程度地重用已有的頁面對象以及業務流程（business flow）。
大型全球化電商網站的前端模塊划分
由於大型全球化電商網站的業務極其龐大，所以前端架構也要按照不同的業務模塊來划分，比如用戶管理模塊、商戶訂單管理模塊、商戶商品管理模塊等等。
當然由於這些前端模塊都會使用項目自己封裝的組件庫，比如自定義開發的列表組件、登錄組件、信用卡組件等，我們通常會把自定義開發的這些所有組件都放在一個“公共組件庫”中，為前端模塊提供依賴
所以，從代碼庫（Repository）的角度來看，各個前端模塊都有各自獨立的代碼庫，除此之外還會有一個公共組件的代碼庫。
大型全球化電商網站的 GUI 自動化測試策略設計
了解了大型全球化電商網站前端模塊的划分后，我們再來看看它的 GUI 自動化測試策略是如何設計的。總體來看，對大型網站來講，GUI 自動化測試往往應該做得比較輕量級，而不應該把大量的功能測試，以及功能的組合測試放在 GUI 自動化測試中,GUI 測試通常只覆蓋最核心且直接影響主營業務流程的 E2E 場景。
但同時，GUI 的驗證一定不是在系統全部完成后才真正開展的，也應該是分階段、分層次來設計制定測試策略的，那么接下來我也將會按照自底向上的順序分層次介紹 GUI 自動化的測試策略。
首先，要從前端組件的級別來保證質量，也就是需要對那些自定義開發的組件進行完整全面的測試。
公共組件庫會被很多上層的前端模塊依賴，它的質量將直接影響這些上層模塊的質量，所以我們往往會對這些公共組件進行嚴格的單元測試。最常用的方案是：基於 Jest 開展單元測試，並考量 JavaScript 的代碼覆蓋率指標。
Jest 是由 Facebook 發布的，是一個基於 Jasmine 的開源 JavaScript 單元測試框架，是目前主流的 JavaScript 單元測試方案。
完成單元測試后，往往還會基於被測控件構建專用的測試頁面，在頁面層面再次驗證控件相關的功能和狀態。這部分測試工作也需要采用自動化的形式實現，具體的做法是：
先構建一個空頁面，並加入被測控件，由此可以構建出一個包含被測控件的測試頁面，這個頁面往往被稱為 Dummy Page；
從黑盒的角度出發，在這個測試頁面上通過手工和自動化的方式操作被測控件，並驗證其功能的正確性。
對於自動化的部分，需要基於 GUI 自動化測試框架開發對應的測試用例。這些測試用例，往往采用和 GUI E2E 一樣的測試框架，也是從黑盒的角度來對被測控件做功能驗證。
其次，每一個前端模塊，都會構建自己的頁面對象庫，並且在此基礎上封裝開發自己的業務流程腳本。這些業務流程的腳本，可以組裝成每個前端模塊的測試用例.
以用戶管理模塊為例，測試用例的組裝過程如下：
- 首先，把用戶管理模塊中涉及到的所有頁面，比如登錄頁面、用戶注冊頁面等，按照頁面對象模型的要求寫成 Page 類；
然后，利用這些 Page 類封裝業務流程腳本，比如用戶登錄流程，用戶注冊流程等；最后，在 GUI 測試用例腳本中，調用封裝好的業務流程腳本構成該模塊的 GUI 測試用例。
在這個階段，測試用例需要完整覆蓋該模塊的所有業務邏輯以及相關的功能測試點，但是並不會實現所有測試用例的自動化。
自動化測試用例的原則，通常是：優先選取業務關鍵路徑以及 Happy Path 作為自動化測試的范圍。在資源充裕的情況下，我們希望這個階段的自動化率可以達到 70%-80%。 所以，前端模塊的質量保證主要依賴這部分測試。
- 還記得之前有提到過，“GUI 的自動化測試往往只覆蓋最核心且直接影響主營業務流程的 E2E 場景“，並且”GUI 測試遵循“手工測試為主，自動化為輔”的策略，而這里又建議說理想的自動化率應該達到 70%~80%，是不是有點前后矛盾的感覺。
- 其實，這是兩個層面的測試，這里 70%-80% 的 GUI 自動化覆蓋率是針對模塊級別的要求；而“自動化測試為輔，手工為主，以及只覆蓋核心業務場景”針對的是系統級別的 E2E 測試。這里容易引起混淆的點是模塊測試和系統級別 E2E 測試都是屬於 GUI 自動化測試的范疇。
- 最后，組合各個前端模塊，並站在終端用戶的視角，以黑盒的方式使用網站的端到端（E2E）測試。 這部分的測試主要分為兩大部分：
- 一部分是，通過探索式測試的方法手工執行測試，目標是盡可能多地發現新問題；另一部分是，通過 GUI 自動化測試執行基本業務功能的回歸測試，保證網站核心業務相關的所有功能的正確性。
- 雖然這部分端到端 GUI 測試用例的絕對數量不多，往往是幾百個的規模，但是對於保證最終網站的質量卻起着非常關鍵的作用。
可以這樣說，如果這些端到端的 GUI 自動化測試用例 100% 通過，那么上線后基本業務功能的質量就不會有大問題。所以，這部分測試工作的重要性不言而喻。
應該由誰來開發這部分端到端的 GUI 自動化測試用例呢？
- 每個前端模塊都會有對應的 Scrum 團隊，他們會負責開發該模塊的頁面對象模型、業務流程腳本以及測試用例。而端到端的 GUI 自動化測試不隸屬於任何一個 Scrum 團隊。這種情況下，最好的做法就是：成立一個專門的測試團隊，負責這種系統級別的 GUI 測試。這樣的團隊，往往被稱為 E2E 測試團隊。很顯然，如果由 E2E 團隊從無到有地開發這部分 GUI 自動化測試的腳本，效率低下。而且，這部分測試會涉及很多前端模塊，當各個前端模塊的需求、業務流程以及頁面實現有任何變動時，E2E 團隊都很難做到及時更新。所以，解決這個問題的最佳實踐就是：E2E 團隊應該盡可能地利用各個模塊已有的頁面對象和業務流程腳本，組裝端到端的 GUI 測試。
- 這樣一方面最大程度地減少了重復工作，另一方面可以把各個模塊的變更及時反映到端到端的 GUI 測試中，因為端到端的 GUI 測試用例是直接調用各個模塊的頁面對象和業務流程腳本，而這些頁面對象和業務流程腳本都是由每個模塊自己的 Scrum 團隊維護的。而為了能夠在端到端的 GUI 自動化測試中，復用各個模塊的頁面對象和業務流程腳本，我們就必須考慮的問題，也就是我今天要和你探討的第二個話題：GUI 自動化測試腳本應該如何組織？
大型全球化電商網站的 GUI 自動化測試腳本管理
也就是說，將各個模塊的頁面對象和業務流程腳本放在各自的代碼庫中，並引入頁面對象和業務流程腳本的版本管理機制，通常采用頁面對象和業務流程腳本的版本號和開發版本號保持一致的方案。比如模塊 A 的版本號是 V1.0.0，那么對應的頁面對象庫和業務流程腳本的版本號也應該是 V1.0.0。在端到端的 GUI 自動化測試腳本中，引用各個模塊正確的頁面對象和業務流程腳本的版本號，測試用例代碼就可以直接調用模塊的頁面對象和業務流程腳本了。
- 具體在測試項目中，模塊版本的依賴往往是用 POM 來配置的，如圖 2 展示了一個典型測試項目的 POM 文件中的版本依賴關系，其中引用了兩個模塊，appcommon 模塊對應的就是上文提到的“公共組件庫”，而 app.buy 對應的就是具體依賴的前端模塊。
由於這只是一個示例，所以我只保留了兩個依賴模塊，實際的端到端 GUI 測試項目往往會包含大量的模塊依賴。
在這種管理機制下，E2E 團隊不需要重復開發任何的頁面對象和業務流程腳本，而且可以始終保證與各個模塊的最新實現同步，同時端到端的 GUI 測試用例腳本也會比較穩定，不會因為各個模塊的改動而頻繁地修改。這樣一來，E2E 團隊就會有更多的時間和精力去設計並執行探索式測試，發現更多的潛在缺陷，形成良性循環。
總結：
我從實戰的角度，介紹了大型全球化電商網站 GUI 測試的策略設計以及測試腳本管理的問題：首先，要從前端組件的級別來保證質量，也就是需要對那些自定義開發的組件進行完整全面的測試。通常前端組件會基於 Jest 做比較嚴格的單元測試。其次，每一個前端模塊，都會構建自己的頁面對象庫，並且在此基礎上封裝開發自己的業務流程腳本。這些業務流程的腳本，可以組裝成每個前端模塊的測試用例。最后，把各個前端模塊組合在一起之后，站在終端用戶的視角以黑盒的方式使用網站的端到端的測試。端到端的測試應該盡可能多地重用各個模塊的頁面對象庫和業務流程腳本來完成。而為了能夠在端到端的 GUI 自動化測試中，復用各個模塊的頁面對象和業務流程腳本，我建議的方案是：對各個前端業務模塊的頁面對象庫和業務流程腳本，實施版本化管理機制