通過前面文章已經(jīng)了解了 K8S 大概的運行機制，接下來看一下在測試領域中如何用 K8S 來高效的 解決分布式運行測試用例的場景。 在企業(yè)中運行 UI 自動化與學習中是不一樣的，最大的不同之處就在 于企業(yè)的場景中測試用例的量級非常的恐怖， 通常一款超過 2 年的 TO B 類型的產(chǎn)品都會擁有數(shù)以千 計的 UI 自動化測試用例。 這個時候測試的運行效率會成為最大的瓶頸。 在這個時候企業(yè)會尋求并發(fā) 執(zhí)行測試用例的能力。 一般每種語言的測試框架都會提供相應的并發(fā)測試機制， 但是這種機制通常都 是單機的并發(fā)能力，而這種并發(fā)模型都會存在單機的性能瓶頸， 無法在一臺服務器中啟動太多的瀏覽器 執(zhí)行測試。 所以在測試用例的規(guī)模達到一定量級后，尋求多機的分布式執(zhí)行測試的能力成為了必須的測 試架構(gòu)。 目前各種領域都提供了一些可用的分布式執(zhí)行能力，這其中以 Selenium 官方團隊的 Grid， 移動端的 STF 和 Cypress 的用例文件分割模式比較流行。下面來介紹一下 selenium 的 Grid 是如何在 K8S 中進行部署的。

SELENIUM GRID

Gird 的理念是將瀏覽器單獨提取出來并進行集群化管理， 在以前測試程序和瀏覽器通常是綁定在一臺 機器的，而 Grid 的出現(xiàn)把瀏覽器單獨部署成為一個集群，而測試程序通過 remote Webdriver 來代替之 前的 Webdriver 與遠程瀏覽器進行通信并執(zhí)行測試用例。 而接收測試請求的角色就是 Grid 架構(gòu)中的 Master 節(jié)點，有時候它也被稱為 Hub 節(jié)點。 作為瀏覽器集群的 Master 節(jié)點，它主要的工作是負責接 收測試程序的請求并把測試任務平均分發(fā)到在它下面注冊的多個 Node 節(jié)點上去， Node 節(jié)點作為 Gird架構(gòu)的 worker 節(jié)點，是真正啟動瀏覽器并執(zhí)行測試的地方。 所以在這套架構(gòu)下需要做的事情有以下 3 點：

• 測試程序從之前的 Webdriver 變成 remotewebdriver 以跟 Gird 的 Master 節(jié)點通信。

• 在 K8S 中 1 臺節(jié)點上部署 Grid 瀏覽器集群中的 Master 服務

• 在 K8S 中的多臺幾點上部署 Grid 瀏覽器集群中的 Node 服務

首先看一下如何在 K8S 集群中部署 Master 節(jié)點

apiVersion: extensions/v1beta1 kind: Deployment metadata: name: selenium-hub labels: name: selenium-hub spec: replicas: 1 template: metadata: labels: name: selenium-hub spec: containers: - name: selenium-hub image: selenium/hub:3.7.1-beryllium imagePullPolicy: IfNotPresent ports: - containerPort: 4444 env: - name: GRID_TIMEOUT value: '0' - name: GRID_THROW_ON_CAPABILITY_NOT_PRESENT value: 'true' - name: GRID_NEW_SESSION_WAIT_TIMEOUT value: '-1' - name: GRID_BROWSER_TIMEOUT value: '15000' - name: GRID_TIMEOUT value: '30000' - name: GRID_CLEAN_UP_CYCLE value: '30000' - name: JAVA_OPTS value: '-Xmx512m' - name: GRID_MAX_SESSION value: '30' --- apiVersion: v1 kind: Service metadata: name: selenium-hub labels: name: selenium-hub spec: type: NodePort ports: - port: 4444 targetPort: 4444 name: port0 nodePort: 30000 selector: name: selenium-hub sessionAffinity: None

上面是 Grid master 節(jié)點部署在 K8S 中的配置文件，這里又接觸到了一個新的資源對象也就是 Deployment，這個對象的作用和使用方法都很容易理解。它的目的是維持 POD 的數(shù)量，在 spec 字段 下有一個非常關鍵的字段是 replicas，代表著 Deployment 對象要維護的 POD 的數(shù)量， 如果用戶把這 個值設置為 3 那么 Deployment 會保證在 K8S 集群中一定會有這 3 個 POD 存在，如果其中任何一個 POD 出現(xiàn)故障，Deployment 都會創(chuàng)建新的 POD 來補充進去， 而創(chuàng)建什么樣的 POD 由配置文件中的 template 字段決定，它是 POD 的模板，是指導 Deployment 創(chuàng)建什么樣的 POD 的模板。 K8S 正是通 過 Deployment+Service 模式來完成通用的負載均衡+高可用的架構(gòu)設計的：Deployment 會保證 K8S 集 群中一定有多個業(yè)務 POD 處于運行狀態(tài)而 Service 在接管 POD 網(wǎng)絡后能保證流量是通過負載均衡的機 制平均分發(fā)到每個 POD 中的。 當然在目前的場景下 replicas 設置為 1 即可。 然后再看一下作為 worker 角色的 Node 節(jié)點如何在 K8S 中進行部署：

apiVersion: extensions/v1beta1 kind: Deployment metadata: name: selenium-node-chrome labels: name: selenium-node-chrome spec: replicas: 6 template: metadata: labels: name: selenium-node-chrome spec: containers: - name: selenium-node-chrome image: selenium/node-chrome-debug:3.7.1-beryllium imagePullPolicy: IfNotPresent ports: - containerPort: 5900 env: - name: HUB_PORT_4444_TCP_ADDR value: 'selenium-hub' - name: HUB_PORT_4444_TCP_PORT value: '4444' - name: NODE_MAX_INSTANCES value: '60' - name: NODE_MAX_SESSION value: '60' - name: NODE_REGISTER_CYCLE value: '5000' - name: DBUS_SESSION_BUS_ADDRESS value: '/dev/null' resources: requests: memory: '500Mi' volumeMounts: - mountPath: '/dev/shm' name: 'dshm' volumes: - name: 'dshm' hostPath: path: '/dev/shm' --- apiVersion: v1 kind: Service metadata: name: selenium-node-chrome labels: name: selenium-node-chrome spec: type: NodePort ports: - port: 5900 targetPort: 5900 name: port0 nodePort: 8900 selector: name: selenium-node-chrome sessionAffinity: None

在 Node 的配置文件中需要注意 2 點：

• 由于 Node 節(jié)點需要到 Master 節(jié)點上注冊自己的信息，所以需要讓 Node 節(jié)點知道 Master 節(jié)點 的 IP 地址。 這里是通過環(huán)境變量的形式注入到容器中的，所以需要記住這兩個固定的環(huán)境變量。 同時 K8S 為了解決服務發(fā)現(xiàn)的問題，在集群中內(nèi)部部署了 DNS 服務器，曾在 K8S 的安裝章節(jié)提 到過。 而任何 Service 在創(chuàng)建的時候都會將自己的名字也就是 name 這個字段作為域名注冊到 DNS 服務器中， 這樣在 K8S 內(nèi)部尋址方式統(tǒng)一使用域名尋址即可。 所以在 Node 的配置中指定 Master 服務的 ip 地址為 selenium-hub， 因為在創(chuàng)建 Master 服務的 Service 時候為 name 字段填 寫值正是 selenium-hub。

• 在上面的配置文件中，仍然使用 Deployment 來維護 POD 的數(shù)量，replicas 字段填寫的值是 6，也 就是每個 Node 服務注冊 60 個瀏覽器（Node 服務的 NODE_MAX_INSTANCES 和 NODE_MAX_SESSION 兩個環(huán)境變量填寫的都是 60） 一共 360 個瀏覽器。 但是這種部署方式 有一個缺點是 Deployment 并不保證這 6 個 POD 是分布在不同的節(jié)點上的，也就是說可能存在兩 個或多個 POD 是部署在同一臺節(jié)點上導致瀏覽器的分布并不均勻， 失去了分布式運行的優(yōu)勢。所 以為了解決這個問題可以換用 Daemonset 這個資源對象來代替 Deployment，這兩個資源類型很 像，目的都是在集群中維護多個 POD。Daemonset 不同的是它沒有 replicas 字段，取而代之的是 它保證 K8S 集群中每個節(jié)點上都有且只有一個 POD 存在，它十分適合本次的部署場景，能夠保證 每個節(jié)點上的瀏覽器絕對的平均分布。

部署完畢后可以通過 Master 服務暴露的端口號來訪問圖形界面：

如果能看到上面的圖就說明部署已經(jīng)成功了， 接下來只需要在測試代碼中使用 remote webdriver 連接 Master 節(jié)點即可。

WebDriverContainer webDriverContainer = new WebDriverThreadLocalContainer(); Configuration.screenshots = false; webDriverContainer.clearBrowserCache(); Configuration.browser = "chrome"; Configuration.remote = "http://k8s.testing-studio.com:30000/wd/hub"; String baseURL = "http://k8s.testing-studio.com:8999/"; com.codeborne.selenide.Selenide.open(baseURL); $(byText("Welcome Gaofei!")).should(Condition.visible);

上面我使用 Java 的 Selenide 框架來執(zhí)行自動化測試, 它封裝了很多 Webdirver 的細節(jié)所以配置上更為 簡單，只需要 Configuration.remote 指定好 Grid 的地址即可。

CYPRESS 的分布式執(zhí)行測試用例

Cypress 作為最近兩年流行起來的 UI 自動化測試框架，它在并發(fā)執(zhí)行上并沒有像 Selenium Grid 的設計 一樣去虛擬化一個瀏覽器集群， 相反的它用一種非常簡單的設計方式，就是把任務的調(diào)度交給用戶自己 來做，用戶只需要運行如下命令：

cypress run --record --key=281554e5-9eee-41bf-9f4c-e9cb405ed5a3 --ci-build-id $BUILD_TAG --parallel --spec "cypress/integration/cases/test1.js" --browser chrome

如果使用 Cypress 的數(shù)據(jù)控制 Dashboard 完成并發(fā)運行的話，那需要去官方網(wǎng)站注冊并創(chuàng)建對應的 project， 在運行的時候指定 --key 和--ci-build-id $BUILD_TAG --parallel 來完成并發(fā)能力， 只要用戶 在不同的機器上運行 cypress 命令的時候使用同樣的 key 和--ci-build-id 那么 dashboard 就會認為他們 屬于同一個測試任務將他們的測試結(jié)果整合成一個測試報告。同時想要完成 cypress 的并發(fā)測試需要將測試用例拆分成多個測試文件， 因為 Cypress 的調(diào)度粒度是控制在文件級別的， 比如用戶希望有用 10 個并發(fā)的能力那就需要將測試用例拆分成 10 個文件保存，然后分別在不同的機器上運行這 10 次 命令完成這 10 個測試文件的測試。 不得不說這種分布式測試的能力比起 Selenium Grid 來說差了至少 一個等級。 這樣需要用戶每一次更改并發(fā)數(shù)量就對測試文件進行重新拆分，如果拆分的不夠均勻還容易 造成長尾現(xiàn)象， 最痛苦的是用戶需要自己來編寫任務分發(fā)工具將測試程序調(diào)度到不同的機器上運行 Cypress 命令。 為了解決這個任務分發(fā)問題需要利用 K8S 的調(diào)度能力來完成。 常用的做法是使用 K8S 的 job 對象來將任務提交到 K8S 中運行， 由于 K8S 本身就是集群架構(gòu)，有自己的負載均衡調(diào)度 策略，所以它能夠保證 Cypress 的任務調(diào)度到不同的節(jié)點上分攤壓力?？梢岳迷?K8S 容器編排介紹 的那一章中針對 job 的配置文件

apiVersion: batch/v1 kind: Job metadata: name: cypress-test spec: template: spec: containers: - name: stable image: registry.gaofei.com/cypress_test imagePullPolicy: Always env: - name: cypress_file value: 'cypress/integration/cases/test1.js' restartPolicy: Never backoffLimit: 0 parallelism: 1 completions: 1

如上述配置文件中編寫的配置，如果希望有 10 個瀏覽器的并發(fā)度，那在拆分完測試文件后，只需要提 交 10 次 job 來運行 Cypress 的測試任務，通過環(huán)境變量來指定每一次測試任務需要執(zhí)行哪一個測試文 件。 這樣就完成了 Cypress 中最難以完成的任務分發(fā)工作了，因為 K8S 會幫將任務分發(fā)到集群上不同 的節(jié)點上去以完成任務的分布式執(zhí)行。