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