王幸福，攜程酒店研發部高級測試經理，負責無線自動化測試相關工作。在測試框架和平臺研發、移動測試、DevOps等領域有著豐富的經驗。
如今很多大型網際網路公司、創新型企業都在積極地進行DevOps實踐和落地。為什麼DevOps如此受青睞? 我們該如何實施DevOps？DevOps中Dev代表開發，Ops代表運維，那麼在這個嶄新的流程體系中，QA又該如何找到自己的位置？帶著這些疑問和困惑，我們希望在本文中都能進行探索和解答。
以往在軟體開發的世界裡，以月甚至以年為周期進行發布是一種常態。但隨著近些年由雲、移動網際網路、AI、社交技術以及區域鏈等技術推動的業務變革呈現爆炸式的發展。在這種大背景下，即使是大型的網際網路公司也隨時面臨著業務上被淘汰的危險，持續的業務創新，快速的上線，卓越的用戶體驗以及快速的獲得反饋才是企業制勝的法寶。
業務在高速變革，那麼技術怎麼樣呢？技術的變革比之業務，有過之而無不及。應用架構從以往的服務集中到如今盛行的微服務，IT架構從物理機、虛擬機到如今的容器化、雲服務，開發技術棧無論是前端還是後端也都呈現百花齊放的姿態。
無論是業務變革還是技術變革，最終都會對企業的開發流程造成影響，並進而推動其進行變革。從早期的瀑布式開發，到敏捷開發，再到如今的DevOps，其產生的背景無一不都有著業務和技術變革的影子。
為什麼當前我們需要DevOps，甚至很多大型的網際網路公司也在進行DevOps轉型，其中最關鍵是因為其核心思想能夠滿足當前業務和技術變革的需要，那就是「快速的交付價值，靈活的響應變化」。「快速的交付價值」意味著能先人一步佔領市場，「靈活的響應變化」亦意味著減少變化帶來的不利因素，使企業立於不敗之地。
業務和技術變革推動流程變革
攜程在很久以前就已經開始進行持續交付的建設，應用部署全部實現了容器化, 並實現了一套自動化程度較高的持續集成發布系統-Ctrip CD（後面簡稱CD），CD發布流程如下圖所示：
攜程發布流程圖
開發人員在功能開發完成並提交代碼後, 可以自己操作或通知測試進行環境部署。進行環境部署的人員可以在CD中創建發布版本，然後由CD自動進行代碼編譯，代碼掃描，安全掃描，測試環境部署等操作。測試人員完成測試後進行測試結果的反饋。如果測試通過繼續通過CD進行UAT環境的部署，進行驗證測試。測試通過後，發布生產環境。
從上面流程圖可以看出，整個發布過程自動化程度還是較高的，相關人員只要在CD中操作新建版本，關注發布狀態就可以了。但我們仔細分析這個過程還是能發現不少問題：
1）持續集成的反饋鏈路過長。我們往往希望在開發人員每次提交代碼時就進行代碼編譯，代碼掃描，單元測試等過程，而不是在功能開發完成後進行。
2）人工介入依然過多。雖然在CD中可以完成大部分的編譯，發布，部署等繁複且人工易出錯的工作，但是否可以省略人工創建版本，測試環境手動測試，進而每次提交代碼都觸發一系列的操作，發布到UAT環境，甚至是生產環境（對於業務簡單，單元測試和接口測試的應用）。
3）CD發布系統解決了編譯，部署，環境治理等大部分OPS相關的工作，但卻沒有考慮到如何把開發，測試以及發布後的監控等活動整合起來。
上面提到的這些問題，也是攜程希望引入Auto DevOps的原因之一。DevOps所提倡的「持續集成，持續測試，持續交付，持續部署」可以很好地解決這些問題，使整個研發效率提升。
攜程DevOps是基於GitLab CI/CD為主幹實現的，並針對攜程內部的情況進行了二次開發，實現auto devops的能力。本文關注的重點是在DevOps過程中的測試實踐，所以在此就不贅述攜程DevOps的實現細節，僅列出攜程DevOps的主幹流程。
攜程DevOps流程及測試流程圖
DevOps雖然從字面意義上看更著重於開發與運維的融合，但事實上卻並非如此。DevOps可以看成是開發、運維和QA三者的交集，所以DevOps實施成功的關鍵在於各個階段都不能有短板。DevOps通過自動化來實現「持續交付」的流程，那麼自動化的手段中自然也包括測試的自動化。其倡導的「持續測試」也需要我們儘可能多的使用自動化手段來快速的發現和反饋問題，從而保障交付產品的質量。
我認為「持續測試」並不僅僅是頻度上的持續，還包括開發過程上的持續。我們希望在開發過程的各個階段都可以有測試的介入，「測試左移」和「測試右移」的思想也由此而來。那麼在攜程DevOps流程中，我們根據自身的情況分三個階段來進行測試的介入。
第一階段開發提交代碼時，觸發靜態掃描（Sonar，Infer，代碼風險掃描等），安全掃描，單元測試。如果這些測試不通過，將通知開發進行修復。
第二階段開發提交代碼後，經過編譯並部署到測試環境時，觸發接口測試、熔斷測試、比對測試、性能測試等。
第三階段測試環境測試通過後，發布到生產的鏡像環境，在此環境進行流量回放測試，並進行發布前的驗證確認工作，驗證通過後可以進行生產發布。同時進行生產環境各項指標的監控工作。
在整個過程中, 我們也會收集DevOps指標數據，日誌，性能，測試數據，進行測試分析，通過算法進行風險評估，從而為提高測試決策質量，效率提升提供依據。
俗話說「無規矩不成方圓」, 流程的制定只是搭了個架子。在這個架子下，我們還需要制定一系列流程標準來充實它，這也是相對比較困難的部分。因為制定的這些標準需要取得整個部門甚至整個公司的認可，並作為規範來嚴格的執行，這勢必對現有的流程和規範造成很大的影響，推廣難度還是比較大的。所以如有必要，甚至可以成立質量委員會來統一制定這些標準，並密切監控實施的過程，遇到問題和困難可以一起想辦法解決。
那麼通常的標準有哪些呢？歸納下來，這些標準包括：
提測標準：靜態掃描結果，單元測試通過率，覆蓋率，接口測試結果…
測試規範：探索測試，用例執行，接口測試分析，性能測試…
發布規範：風險分析，發布檢查項…
監控規範：業務，性能，日誌數據收集，預警的條件….
有了流程和標準，我們就夯實了實施DevOps的基礎。接下來需要一個平臺來實踐這些流程和標準，可以選擇Gitlab CI/CD，也可以選擇Jenkins，亦或者Gitlab與Jenkins結合。我們選擇了自建平臺，理由如下：
1）無論是Gitlab還是Jenkins都需要進行較複雜的配置文件設置，對於開發和測試人員都有一定的學習成本，所以我們希望通過可視化配置的方式來簡化配置過程，這樣既能提高配置的效率，也能減少推廣的難度。
2）攜程酒店測試使用的工具和平臺很多都是內部研發的，市面上的DevOps平臺整合這些工具和平臺並沒有現成的方案可用。
3）我們希望DevOps測試過程並不僅僅是給測試看的，我們希望開發，測試，產品都可以從這個平臺中看到自己需要的東西。
4）DevOps最理想的狀態是可以直接自動發布到生產。可目前現實的情況卻很少有應用可以做到，那麼我們希望提供儘可能多的評估和反饋數據來縮短發布確認的過程。
Moss平臺
在實施DevOps過程中會涉及到很多的工具，我們把這些工具形象的稱為工具鏈，而合理的整合工具鏈中的工具也是DevOps是否成功的關鍵因素之一。在測試各個階段常用的測試手段通常包括靜態代碼掃描，單元測試，接口測試，UI自動化測試，流量回放等等。而這些測試手段在業界都有比較成熟的開源框架，比如SonarQube、Junit、Selenim、Appnium…. . 攜程酒店測試根據自身情況，結合這些開源框架開發了一系列的平臺和工具。
攜程酒店DevOps測試工具鏈
靜態掃描作為一種近乎零成本的測試手段，可以在早期發現代碼中存在的代碼缺陷，安全漏洞等問題。在靜態掃描領域，SonarQube已經深耕多年，在這方面已經近乎成為標配。攜程通過對原有SonarQube代碼規範庫中的規範進行篩選和擴展，形成了自己代碼規範庫。我們還有基於開源框架開發的安全掃描工具Cobra和Buffalo。在我們的DevOps流程中，開發人員在提交代碼後就會觸發Sonar，Infer，Cobra，Buffalo等一系列的靜態掃描手段進行代碼檢測。
單元測試隨著敏捷開發的盛行而引起了大家的重視，雖然目前在國內對單元測試的重視程度依然欠缺，但從眾多大型的開源項目可以看出單元測試確實在軟體的開發質量保障方面有著積極的作用。我們為了整合單元測試的編寫，執行和結果而開發了UTP單元測試平臺。該平臺由Junit擴展庫UtpJunit，IDEA插件UtpGenerator以及Utp站點組成。該平臺實現了BDD驅動，代碼分析，在線WebIDE，單元測試執行，覆蓋率統計，報告展示，持續集成等功能。
集成測試階段主要進行接口測試，資料庫測試，Job測試等等。無論是RPC，SOA還是目前流行的微服務，都是在強調對外提供服務的能力。而這種能力主要通過提供對外接口來實現，這也決定了接口測試的重要性。我們為此構建了CAS平臺，CAS平臺是一個同時支持有碼和無碼接口自動化測試的平臺。
CAS自動化測試平臺
測試過程中一個比較難以解決的困難是測試數據問題。為了保障接口測試和UI自動化測試數據的可用性，我們開發了MOCK系統，用於測試人員配置和管理測試數據。
系統測試階段是測試人員介入比較多的階段，也是測試人員比較熱衷做自動化測試的階段。因此這個階段的自動化測試框架也比較的多。常用的Web自動化框架有Selenim，Jest，Jasmine…，常用的APP自動化測試框架有Appnium，Airtest，Clabash，UIAutomator…. 而這些自動化測試框架是百花齊放，各有所長，要根據自身團隊的實際情況慎重選擇適合自己的框架。
在Web自動化測試方面，我們選擇了Selenium框架作為基礎進行二次開發，而在APP自動化測試方面，我們構建了自己內部的測試雲平臺- ATL(APP Test Lab)，該平臺支持設備管理，也同時支持Appnium和Airtest的用例管理，執行和報告查看。
ATL自動化測試平臺
線上監控作為」測試右移」的重要手段之一，正越來越引起很多公司的重視。通常在伺服器，網絡，框架，性能等方面，OPS會有眾多的監控和預警機制。但在業務，功能等一些特定指標上卻無法兼顧到，那麼我們就需要自己去監控和預警，這些監控大致可以分為資料庫數據監控，埋點監控，接口監控，UI監控等。
攜程酒店測試監控平臺
除了以上的工具和平臺，我們還有一些經常使用的工具和平臺，限於篇幅，不在這裡一一介紹。而這麼多的工具和平臺，以往都是測試人員在各個平臺切換使用，容易混亂，效率也低，工具之間無法產生化學反應。我們需要通過DevOps把這些工具整合起來，形成工具鏈，這也就是我們經常提到的pipeline.
Moss平臺的pipeline整合了眾多的工具和平臺
DevOps的精益思想需要數據支持來減少不必要的浪費，DevOps是否成功得到實施需要數據來反饋各項指標數據，公司的領導需要知道當前團隊代碼問題，覆蓋率情況，Bug等數據… 等等這些都需要數據。
這些數據來源在哪裡? 自然來自DevOps所整合的各個平臺和工具。所以我們需要一個DevOps數據中心來收集和分析這些數據，並把數據以可視化的方式展示給相關的人員，讓相關人員可以看到自己需要的數據。
DevOps數據中心架構示意圖
Moss平臺的DevOps數據中心通過收集器從各個工具鏈平臺中拉取數據存放到MongoDB中。Neo4j是一款NOSQL圖形資料庫，用於存放人與人，人與應用，應用與應用之前的關係和數據，為以後聚合團隊數據，數據關聯提供支持。
同時DevOps數據中心還提供了可視化數據編輯功能，可以讓用戶以可視化配置的方式來配置數據的可視化看板。而且秉承著一切數據都是可以被搜索的理念, 我們提供一個搜尋引擎讓用戶搜索到自己想要的數據，並以可視化的形式展示出來。
應用看板，技術價值流看板
測試在歷經了瀑布式開發，敏捷開發階段後，其測試體系的基礎並沒有受到太多的衝擊和改變，但在「來勢洶洶」的DevOps浪潮中, 我認為測試的根基已經受到了一定的動搖，過去那種固有的測試思維已經難以適應當下測試的需要。作為測試人，如果不想被時代淘汰，就需要主動去適應這種轉變，去積極挖掘測試在DevOps體系中的價值。
在實施DevOps的過程中，我們也遇到了很多的困難和挑戰，同時也收穫了很多的經驗和教訓。總結下來主要有這麼幾點：
高度自動化，儘可能減少人為幹預
需要快速且準確的反饋問題
要制定DevOps流程中可行的規範
關注DevOps指標，優化流程和提高效率
目前, 我們實施的DevOps還處於初期階段，很多方面尚未完全達到預期。在不久的將來我們還有很多的工作需要去做：
註：微信公眾號後臺回復「devops」，可下載講師分享PPT。