DevOps 中的測試實踐

腾讯WeTest發表於2020-12-15

dev

萬物皆可 pipeline，流程自動化解放生產力。在 DevOps 的 pipeline 中，我們發現測試環節也需要一套流水線化的能力，來保證研發流程的大批 pipeline 穩定高品質交付。

下面介紹下 DevOps 中如何構建高水平全面的測試能力。

文化、流程、組織結構、技術發生變革，對測試提出新要求

· DevOps 文化對測試帶來的新要求（文化）

為適應市場的快速變化，要求企業的產品快速迭代，柔性應對使用者需求，滋生了 DevOps。

《持續交付 2.0》中，作者將 DevOps 簡化概括為 2 個環：價值探索和快速驗證。

價值探索是快速發現和識別外部客戶的真實需求，為其創造價值點。"快速驗證環"要求企業在找到業務問題制定業務目標後，快速實現和落地價值點。

測試屬於"快速驗證環"，過程中要求開發/測試/運維的角色緊密配合，高效高質地落地驗證新特性。

· 在 DevOps 中構建測試工作的難點（流程）

在 DevOps 趨勢下，測試部門從原先的大量集中測試，變成了高頻快速測試。

原先大部分企業採用純手工測試的方式，從根本上無法適應 DevOps 的高頻快節奏需求。滋生了對自動化測試的訴求。

· 頭部企業測試部門的現狀（組織架構）

· 人力外包比重高：

金融/通訊/航空等大型企業的外包人力與正式人力之比，往往超過 5:1，人員流動性高，素質參差不齊。對工具和系統的穩定性和使用門檻提出要求。

· 從集中到分散又迴歸集中：

企業初期業務較為單一，測試需求歸攏到統一的測試部門。

隨著企業業務的擴充，為了快速滿足各個業務的測試訴求，將測試人員直接放到各個業務組，實現業務內快速開發測試釋出。

業務量更加龐大後，避免分散研發使各個業務組重複陷入低階別的研發活動，產生技術豎井，為實現技術資產的繼承積累，研發流程從分散開發趨向於基於中心化的基礎設施開展，也就是現在常說的"中臺"概念。測試工作也因此產生變化。除了測試各個業務的具體功能本身，也需要對基礎設施本身的質量，以及各模組專項能力做統一的測試，確保整體的健康度維持在一個可控的標準。因此，又產生了集中化的測試需求。

文化、流程、組織架構，以及新技術（容器技術等）多重力量，助推測試的敏捷化。

基於 DevOps 對測試提出的新要求，市面上也越來越多自動化測試的工具，開發者面對大量工具系統，往往需要經驗和時間成本去篩選：

問題一：在哪些環節加入測試？各個環節適用什麼型別的測試來保障該環節質量？

問題二：在人員結構和組織架構等約束條件下，各環節選取什麼樣的測試方法和工具？

下面咱們一一來分析這些問題。

問題一、測試可以滲透到哪些環節

在 DevOps 文化中，強調打破不同職能之間的隔閡，對於測試部門而言，意味著測試活動的"左移"和"右移"，從需求分析到產品上線，各個環節把控質量。在一些偏研發和偏運維的環節，測試人員可以幫助建立整套質量評體系和工具組，來保障上下游的整體質量。

例如在開發編碼環節，主要是單元測試和 code review。對於大部分企業而言，這個工作主要是研發人員在做。測試需要做的事，推動這個環節的質量意識，幫助開發同學搞定單元測試和 code review 的工具和結果記錄，做到有跡可循。

測試時間提前：測試不再等開發結束後再測試，而是將測試時間穿插在開發階段，減少測試時段的長度

單元測試提前：開發每完成一個模組的編碼，先對本模組進行單元測試，業務邏輯比較清楚，不需要重新回顧，效率較高

單元測試有據可依：測試在開發進行單元測試前提供每個模組的用例設計，供開發參考，使得單元測試更全面

單元測試 review:每個模組單元測試完成後，測試進行單元測試 review，使得單元測試更全面，程式碼質量更高；同時發現程式碼或單元測試的問題開發及時修改，不需要打包，縮短提測試時間

開發與測試密切合作：每一模組都需要開發和測試密切合作、共同完成，測試和開發的合作更加密切，開發的測試水平提升更快，測試閱讀程式碼的能力也會進步很快

測試工作量和測試周期減少：由於單元測試很充分，所以每個 job 的測試可以省去，只做整合 | 聯調測試，大大減少了測試工作量和測試時間，從而縮短整個專案週期

問題二、在人員結構和組織架構等約束條件下，各環節選取什麼樣的測試方法和工具？

· 測試管理

管理工具的目標是提升效率和協同性。市面上已經有非常多成熟的管理工具。如果是業務比較複雜的超巨企業，測試部門更關注的是對於不同測試管理系統的適配性。

舉兩個例子，以下兩張圖，分別是技術積累做的非常不錯的兩家企業測試部門的流程，差異比較明顯。

這種實際環境下，對測試管理平臺靈活性的要求就很高。

· 工作流程靈活可配置

· 可整合現有管理系統

· 過程/結果的視覺化

目前我們平臺支援按工作流來組織測試計劃，並分配任務，專案進度、人力分配視覺化跟蹤。

測試本身也是一條流水線，支援使用者向右無線擴充套件測試環節；每個測試環節支援向下無線擴充套件"測試任務項。

同時，平臺支援 jira/tapd 等管理系統的整合，需求和缺陷打通。指令碼方面支援打通 git 和 svn，直接同步指令碼到 WeTest 測試平臺。

· UI 測試

UI 測試是門檻最低，最常見的一種測試型別。一般在功能驗收，以及專項測試階段比較常用。UI 測試有 web 端和移動端。web 端的測試主要以 selenium 框架為主。市面上也有比較通用的錄製回放工具。移動端的 UI 自動化測試由於裝置型號多而雜，給測試部門帶來更大的挑戰，近幾年出現的移動端測試框架也越來越多。

之前提到組織架構裡外包比重較高，因此，UI 自動化測試工具的使用門檻一定要低。業界有較多的指令碼錄製回放工具。在實際操作過程中，往往會發現這些工具有以下弱點

· 元素識別困難

金融行業的亂序密碼盤和防截圖安全控制，把很多用例擋在門外。實際上大多數亂序密碼盤的問題都是可解決的。

· 指令碼回放成功率低

魯棒性低：順序流的指令碼，回放時只要有 1 個步驟未按預置流程走下去，就會卡住，後面的指令碼就白搞了。

適配性低：錄製的指令碼在不同的裝置上，由於解析度和尺寸的不同，導致無法回放。這就對工具的識別方式提出了更高的要求，不能是簡單的座標識別。

· 易用性差，影響效率

很多指令碼錄製工具為了提升識別效率，採用影像 + 控制元件雙重識別。影像識別過程往往需要使用者框選出需要識別的區域。大大降低了錄製指令碼的效率。也提升了工具使用的門檻。我們期望一種無感知的錄製工具。使用者在手工測試過程中順便把指令碼錄製了。

這些點，我們自研的小工具 UITrace 都解決了。目前這款工具也是 WeTest 用於交付相容測試任務的主要工具。

除工具問題外，由於移動端 UI 測試涉及到大量裝置的運維管理，在穩定運營的基礎上，有效降低運維成本，提升運維效率，是進行日常 UI 測試的前提。對於硬體的運維，WeTest 在管理上萬臺裝置的過程中，總結出 43 條運維規則，自動識別和秒速處理"開發者模式誤觸關閉""記憶體佔滿""熄屏鎖屏"等問題。保證機房 7x24 小時穩定執行，實現 1 個運維人員可管理上千臺裝置的效果。