萬物皆可pipeline，流程自動化解放生產力。在DevOps的pipeline中，我們發現測試環節也需要一套流水線化的能力，來保證研發流程的大批pipeline穩定高品質交付。
下面介紹下DevOps中如何構建高水平全面的測試能力。
1. 文化、流程、組織結構、技術發生變革，對測試提出新要求
· 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個運維人員可管理上千台設備的效果。
· 接口測試
接口測試是一項性價比很高的測試活動，接口相較於UI，變化不大，較為穩定。接口測試主要關注以下幾點。能把這些點都做足，基本上可以cover90%以上的需求。
· 適配性：支持的協議/報文格式范圍更全面（例如近幾年興起的dubbo/grpc/trpc，以及經典的http/https，WeTest平台均可支持）
· 兼顧易用性和管理能力：既要像postman一樣實時調試，又可以支持用例管理，測試任務，報告管理的管理功能，便於復用和進行歷史追溯。目前WeTest平台可以滿足需求
· mock能力：可按需求定制mock規則
· 自動生成用例組織測試的能力：提供了fuzz 安全測試：支持隨機填充、SQL注入、XSS攻擊、OS命令注入等攻擊模擬腳本的自動生成和執行。
· 預處理腳本coding能力：靈活地進行邏輯控制
· 上下游鏈路整合：支持鏈路性的接口測試，而不僅僅測試單個接口。前序接口輸出作為后續接口參數輸入
· 壓力測試
若出現服務器宕機，業務會陷入癱瘓；若延遲較高，用戶感受也會受明顯影響，造成口碑下滑。服務器壓力測試，主要關注以下幾點：
· 並發量：並發量大且穩定是基礎要素，是做壓力測試的前提條件。目前WeTest並發量可達百萬級別。
· 模擬真實場景：WeTest支持通過接口傳參構建上下文鏈路場景，模擬真實環境下的各個接口並發量。
· 兼容各類腳本：jmeter/fiddle等主流腳本框架
· 支持coding模式，多種協議和語言，便於靈活地構建測試場景。
· 監控維度科學、全面：覆蓋TPS、響應時間、收發包量等種基礎性能指標及進程級服務器等14項數據，見下方WeTest壓測報告截圖。
· 其他
除了解決上述工具和系統的問題，我們在流水線上要有設置質量紅線的意識
質量紅線不僅被用來保證轉測/發布的質量，還被用來保證Git工作流的代碼質量。避免低質量代碼進入進入下一個環節，浪費下游測試資源，舉例如下
微信MR過程觸發WeTest門禁
騰訊WeTest平台服務於質量領域超過10年，擁有豐富的多行業（包括金融、游戲等）測試經驗。2019年正式推出私有化部署解決方案，致力於服務對私密性、安全性有更高要求的企業，幫助企業打造屬於自己的質量中台。
歡迎訪問頁面，查看解決方案介紹：https://wetest.qq.com/solution/private?from=others_content_private