譯者 | 陳峻
審校 | 孫淑娟
過去，在軟件開發的后期，團隊往往不得不以全局重構、甚至延遲發布的方式，來處置他們發現的嚴重錯誤。而隨著時間的推移，業界學會了通過DevOps和敏捷等方法，來加速開發的周期。不知您是否注意到，DevOps并不是一個人的戰斗，而是開發人員、運維人員、測試人員、以及業務部門之間的一組復雜的流程、技能、溝通和工具。它專注于彌合開發和運營孤島之間的溝通障礙，并通過各種自動化或虛擬化工具，實現持續開發、集成、測試、監控與反饋、以及交付和部署，來縮短新功能的面市時間。
不過，和其他新生的技術概念類似，DevOps也在持續完善中。在融入了安全性、基礎設施、以及測試之后，我們相繼看到了DevSecOps、NetOps、以及TestOps的出現。本文將重點和您討論TestOps的相關概念、工作流，以及生命周期中每個階段所涉及到的團隊、目標、指標、挑戰和工具等方面。
什么是TestOps?
通常，在分解大型發布的過程中，我們需要針對不同的框架和編程語言的代碼，進行各種類型的測試（如：Web、API、Canary等）。對此，我們需要通過持續測試的方法，來滿足各個微服務代碼的單元級與集成級測試的全覆蓋。
總地說來，TestOps是DevOps的一個子集。它通過一組技術和方法，在整個DevOps管道中進行自動的、透明的、可訪問與管理的測試。而且，這些測試不僅在于QA上的透明與可控。
DevOps的原生測試是怎樣的？
一個應用程序通常由前端、后端、以及移動版本等部分組成。每個部分都可以由一個專門的團隊來負責開發。而一個典型的10人團隊往往包含如下角色：
- 開發人員，負責編寫代碼、重構和拉取請求的管理
- 項目經理，負責開發的整體進度和敏捷流程
- QA工程師，負責發布測試和最終產品質量
- 自動化測試（AQA）工程師，其工作是將測試自動化發展至極限
- 運維人員/管理員，負責質量把關和管道維護
那么，測試將如何在這樣的團隊中開展？以下是在典型DevOps中，自動化測試人員的主要任務：
- 首先，自動化測試工程師的工作往往涵蓋了后端、前端和與原生自動化測試的各種集成。此處的“原生”意味著測試應使用與被測試代碼相同的技術棧，也允許將測試存儲在與代碼相同的存儲庫中。使用單一存儲庫的好處是，開發人員可以協助AQA工程師進行代碼的審查、以及復雜的測試開發。
- QA經理在拉取請求的階段，針對已開發出的案例審查客戶場景的合理性、以及極端案例的覆蓋率。
- 同時，AQA工程師也會從QA的角度，檢查單元和集成測試。
- 雖然諸如：Docker或Kubernetes的配置、構建腳本、以及測試環境設置等底層維護，都是由Ops人員負責的；但是包括：配置Selenium網格、瀏覽器、以及數據庫的數據管理等有關測試的基礎設施，仍然是由AQA工程師負責的。
可見，AQA工程師主要從事的是底層測試和質量檢查等工作；而QA人員則負責監督發布的整個管理過程。
TestOps的工作流
上圖展示了TestOps的管道，其具體工作流為：
- 開發人員創建一個新的功能分支，并在完成時產生一個包含了一些全新代碼、以及一堆自動化測試的拉取請求（PR）。
- AQA工程師審查PR，并在必要時添加更多的測試。例如，他們會增加包含了數十個參數與變體的全面測試。
- 之后，QA經理從業務角度開始最終的測試審查。測試主要著眼功能和用戶故事的覆蓋范圍。
- 如果測試能夠順利完成，那么分支就會被合并。如果測試出現問題，那么團隊著手予以修復，并跳轉至上述第2步。注意，每個錯誤都應當與待添加到下一次回歸運行的問題相關聯。
可見，管道上的大多數測試只有在實現了自動化后，其測試的持續時間才能夠更容易被預估。
TestOps的生命周期
如上圖所示，我將在下文向您介紹QA團隊在開展TestOps過程中，可能涉及到的每個階段的團隊、目標、指標、挑戰和工具等方面。
M1：單個手動測試人員
該階段通常是每個QA部門的起點。大多數團隊甚至不會意識到該階段的存在。不過，它確實會對QA的未來發展產生影響。
1. 團隊：有時候，該階段甚至沒有專門的QA人員，僅由某個產品負責人或經理去開展測試工作。
2. 目標：
- 創建錯誤報告的流程與模板，且報告越清晰越易于開發團隊的修復。
- 此階段創建的測試用例，可能很短且缺乏細節，不過主要目的是為了獲悉對測試持續時間的粗略估計，以便為下一階段做好準備。
3. 指標：通過密切地關注流程，在指定的流程中正確地記錄Bug的數量。
4. 工具：可使用Excel、電子郵件、Slack、以及任何其他能夠共享和跟蹤錯誤報告的工具。
5. 挑戰：當團隊較小時，將錯誤直接傳遞給開發人員，并在Slack DM（即時通訊工具）中獲得修復通知是較為容易的。但是該方法也可能會給下個階段帶來潛在的混亂。
6. 達標：團隊已經建立了一個基本的錯誤檢測和修復流程。
M2：手動測試團隊
這是DevOps的預備測試階段，測試團隊會在此階段逗留較長的時間，尤其是那些不以快節奏的開發流程為目標的團隊。通常，此類手動測試會在規定的發布周期的節奏下正常開展。
1. 團隊：多名初、中級QA人員，由一名高級QA人員/負責人指導。
2. 目標：
- 我們需要為每個測試設置一個所有者，并記錄運行的結果，以便團隊知道誰應該對測試的疏漏負責。這不是為了懲罰，而是為了實現建設性的回顧。
- 測試的透明度。文檔、無法通過（pass-failed）的比率、以及將Bug與問題跟蹤器聯系起來，都可以協助整個團隊去掌控測試的過程。
- 詳細的測試用例。作為文檔要求的一個環節，團隊里的不同成員工作在同一套測試用例上時，應為測試用例從一個所有者轉移到另一個所有者做好準備。也就是說，測試用例應該包含所有的步驟、注釋、元數據、以及環境描述等方面。
3. 指標：
- 測試用例的執行頻率。測試的運行當然是越頻繁越好。
- 測試通過率。請記住，測試的通過，可能并不表明代碼無懈可擊，而是跳過或忽略了某些深層次的錯誤。
- 測試報告的生成和使用情況。測試的結果報告不僅僅是給經理或測試團隊的負責人查閱的，也需要開發人員經常查看其中的問題和測試用例。同時，運維人員還需要據此判定手動測試套件，是否比冒煙套件和金絲雀版本更有價值。
4. 工具：團隊需要通過如下工具，來存儲和管理測試用例，生成控制報告，以及跟蹤所有手動測試的活動。
- TestRail，一種基于Web的測試用例管理工具。測試人員、開發人員、以及團隊負責人可以使用它來管理、跟蹤和組織手動測試等工作。
- PractiTest，一種為手動測試提供了多團隊管理、以及報告功能的端到端工具。
- Qase.io，一種新的且迭代迅速的工具。
5. 挑戰：通常，測試的速度，以及回歸類測試的復雜程度，都會對測試團隊的人員數量有所要求。因此，對于那些缺乏人手和經驗豐富的團隊，可能在此面臨嚴峻的挑戰。
6. 達標：團隊精心設計好了測試用例、存儲、以及管理流程。
M3：高級手工測試團隊
這是高級QA工程師團隊的一個可選的進化階段，旨在整個公司的測試中，建立牢固的信任關系。
1. 團隊：與前一階段幾乎相同。主要的區別在于團隊成員更加資深。
2. 目標：優化監控的效率。鑒于手動測試很難被優化，我們往往需要借助各種半自動化的工具，來加快高級測試團隊的工作效率。
3. 工具：在這個階段，工具的主要任務是通過諸如：屏幕截圖、測試場景的自動點擊等功能，發揮團隊的作用，并盡量減少人工操作。典型工具包括：
- Postman：一種專注于測試、而非執行過程的API測試工具。
- FakeData：一種通過生成測試數據，來節省時間，并避免手動測試表單的工具。
- LambdaTest和Responsively：一種能夠將自動化快速測試，在不同分辨率的瀏覽器上顯示結果的工具。
4. 指標：
- 需要衡量通過半自動化工具和自動化日常任務，以優化測試時間與人力成本的水平。
- 通過獲得每個測試套件運行的透明度、以及可預測性，來估計出產品的最終發布時間。
5. 挑戰：
- 開發團隊的自動化測試（如：單元測試、集成測試）和QA團隊仍處于脫鉤的狀態。
- 測試過程中的優化和擴展水平，仍然會受到團隊人數的限制。
6. 達標：團隊能夠根據業務要求，以更快的速度發布新的版本。
A1：有了一位自動化工程師
這是公司走向自動化的第一步。通常，此階段會包含：選擇測試框架、測試的執行環境、以及覆蓋率指標等基本步驟。這些都為進一步的自動化開發奠定了基礎。
1. 團隊：在手動測試的團隊中添加了一名中、高級自動化QA工程師。
2. 目標：
- 通過自動化的端到端（E2E）測試，不但涵蓋了各種基本API，而且提高了整體測試的效率。雖然對于一組UI測試，可能需要更多的時間，且效率可能低于手動設置；但是一組帶有數據生成和模擬API的自動化端到端測試，肯定會在覆蓋率和效率上勝過手動操作。
- 創建一個可被用于快速實現手動測試用例的自動化流程，并盡可能地自動生成已調優過的模板代碼。
3. 工具：該階段需要QA和開發團隊之間的通力協作，以自動化各種測試實例和可執行的CI管道。
- 自動化工程師可以選擇Selenium和Playwright之類端到端的測試工具作為測試環境。這兩種工具都是不錯的無頭瀏覽器（Headless Browser）測試框架，可以啟動手動測試用例的自動化。
- 可以選擇JetBrains或微軟的IDE產品。
4. 指標：
- 鑒于網站布局或API響應的微小變化，都可能導致自動化測試的失敗，測試團隊應事先設定有關測試穩定性和可維護性的API測試指標。
- 盡可能頻繁地在各種環境和條件下，去測試每個拉取請求的合并和發布。
- 衡量從自動化測試遷移回手動測試的比率。此類遷移往往意味著自動化的成熟度和精準度，尚有待提高與改進。
5. 挑戰：盡管我們在這個階段首次獲得了準確意義上的自動化測試套件，但是我們反而無法精準地預測產品從測試到發布的持續時間。
6. 達標：自動化測試用例的生成、工具的建立、以及流程的確立，都為快速發布與交付提供了保障。
A2：測試自動化團隊
隨著時間的推移，團隊雖然獲得了更多的自動化工程師，但是有高達60%的自動化項目會出現停滯不前的現象。此外，前面階段的原有流程也可能會給全棧測試的自動化帶來影響。
1. 團隊：幾位中、高級AQA工程師與更多初級隊友一起工作。
2. 目標：從如下方面保持軟件質量體系的穩定性：
- 原子化的自動測試既能夠彼此獨立，又可以提供本地化的結果，更容易修復Bug。也就是說，每次測試失敗都能夠提供更精確的結果，以便得到快速的修復。
- 提供一個帶有統一接口的測試套件，以便開發人員通過質量門在其分支上運行測試。
- 基于良好的文檔記錄，該階段應實現100%的回歸和驗證測試的覆蓋率，以體現自動化測試的價值。
3. 工具：該階段，我們需要能夠通過從測試中獲取洞見，以提供報告和可觀察性工具：
- 報告類工具，如Allure Report和ReportPortal等開源方案，都能夠共享結果，并控制自動化套件的執行。
- 全棧測試框架，如Katalon和Cypress。選擇全棧測試框架對于計劃保持A1-A3測試級別的團隊來說，可以在專有的供應商基礎設施中，構建出廣泛的新功能。
- 監控：雖然設置Grafana之類的實例有些繁瑣，但是它作為一個通用的開源分析和交互式可視化工具，能夠以圖表、圖形或警報的形式，為團隊提供即時的測試結果。
4. 指標：
- 運行與重新運行次數。就像論文在反復被引用的過程中，可以體現其自身價值那樣，同一個測試被不同的團隊運行，其結果是否能夠給其他團隊帶來分支合并或發布，都能夠體現測試套件的價值。
- 測試本身的用時并不重要，重要的是它能否預測代碼正式發布的時間點。
- 有時候，測試可能會在沒有明顯原因的情況下，持續通過了失敗的結果（passed-failed result），對此我們應當予以隔離、調查和修復，以認清是否由于基礎設施的問題所致。
- 無論是業務邏輯的變化，還是測試本身的原因，都可能導致失敗。因此，我們需要通過Time-to-fix，來估算能夠多快去修復此類失敗的測試。
5. 挑戰：
- 與測試相關的基礎設施往往與QA團隊“相距甚遠”，且不具有通用性。因此，這會影響到上面提到的測試的“運行與重新運行的次數”。
- 隨著測試變得更加原子化，您會發現將大型手動測試用例映射到一組原子自動化測試，會變得越來越困難。為此，團隊需要有更改手動測試的工作流程，按需使用清單進行手動測試。
6. 達標：
- 一旦回歸和驗證測試完全轉為自動化，團隊就有足夠的時間進一步考慮基礎設施的開發。
- 測試結果的收集和報告自動化，是另一種需要花費大量時間和精力的工作。
A3：高級測試自動化團隊
當測試的目標被設定為獲得對DevOps管道、以及測試基礎設施的完全訪問權限后，我們就需要配備一支非常熟悉測試的高級團隊。
1. 團隊：10人以上的高級AQA工程師
2. 目標：QA團隊需要與Ops團隊保持聯系，不但要完成測試的編寫，而且能夠對測試的基礎設施實施控制。也就是說，由Ops團隊負責硬件和腳本級別的維護，其中包括：緩存、構建腳本、以及數據庫可訪問性等低級別的部分。而QA團隊則努力控制測試環境的基本配置與微調、性能分析、依賴關系、數據和環境更新等方面。這些都是團隊集成到主要DevOps管道中所必需的。據此，獨立的自動化測試團隊可以實現對每個分支、以及版本進行快速且精確的測試。
3. 工具：
- 作為全棧測試的自動化解決方案，Allure TestOps為測試團隊提供了如下開箱即用的基本功能：
- 可以與JS、Python或Java框架，以及與Playwright或Selenium等全棧工具相集成。
- 能夠控制帶有各種自定義套件，重運行的選定測試，以及存儲運行歷史記錄的CI/CD系統。
- 能夠開展自動化的故障調查和詳細的分析。
- qTest是另一個用于敏捷測試的大型測試管理工具。它遵循了集中式的測試管理概念，有助于QA團隊與其他利益相關者輕松地進行溝通，并協助開展快速的開發任務。
4. 指標：與A2階段的指標類似，該階段的測試執行頻率指標需要開發人員、運維人員、測試人員，有時甚至是管理人員等整個團隊，最大化測試的使用率。
5. 挑戰：缺乏基礎設施的管理專業知識。如果QA團隊不去深入研究基礎架構，那么他們可能會將與Ops相關的任務（如更新Selenium或框架）推遲到最后。
T1：TestOps的第一步
該階段意味著QA團隊已經走出了測試的“泡沫”，代碼庫被整潔的原子自動化測試所覆蓋。測試已經以半自動運行的方式，融入了主要的開發管道流程。如今的重點是為與Ops的全面集成做好準備。
1. 團隊：團隊中需要有兩、三個熟悉服務器管理、以及CI/CD工具和流程等運維專業知識的測試人員。
2. 目標：
- 掌控所有測試基礎設施，包括與管理員團隊一起維護所有的模擬器、Selenium實例、以及其他測試內容。由經驗豐富的管理員著手更新測試服務器上的瀏覽器或Docker。
- 通過將測試服務器集成到主要的開發管道中，以自行解決“計劃”測試、數據庫擦除、以及Selenium配置更新等棘手且不穩定的測試。
- 以自動化的方式設置測試通知，并要求Ops團隊監控測試的執行。
3. 工具：在這個階段，我們需要如下工具來構建可擴展、且靈活的自動化測試基礎架構。
- Docker，可以輕松地創建、管理多個預設且能夠按需運行的環境。
- Jenkins，雖然不是最容易設置的系統，但它一直被龐大的開源社區、以及豐富的生態系統所推崇。
4. 指標：
- 執行測試套件的持續時間與成本。為了避免測試管道被卡在測試的質量門處，我們可以根據時間和成本兩項指標，來優化Ops團隊的工作，以確保測試預算的可控的范圍內。
5. 挑戰：與A2階段類似，我們雖然可以更好地管控測試基礎設施，但是上述指標不一定能夠被調優。這往往需要我們與Ops團隊保持密切協作關系。
6. 達標：一旦我們習慣了掌控管道，并讓各種測試都像上了發條一樣去自動通知、生成相應的報告，那么我們就達標了！
T2：成立TestOps團隊
這個階段對于彌合測試和開發人員之間鴻溝是必要的。測試人員和開發人員開始在統一的技術棧上編寫測試代碼。測試人員和運維人員通過對測試基礎設施的管理，提供了快速將新功能推向市場的管道。
1. 團隊：由原來以資深測試人員為主的團隊，轉變為具有運維和基礎設施維護經驗的SDET（Software Development Engineer Test，測試開發工程師）團隊。
2. 工具：
- GitHub/GitLab，一套基于代碼的協作工具與平臺。
- Allure TestOps，一種可以將實時文檔、自動跟蹤測試內容、以及通過率等所有測試要素，對非開發人員開放的工具。同時，其高級儀表板可供將開發人員、運維人員、以及QA團隊，開展聚合式的全棧測試分析。
3. 目標：
- 遷移到各種原生的測試工具上，即：測試與被測代碼使用相同的技術棧。例如：JEST for JS、XCtest for iOS、Kaspresso for Android、Pytest for Python、JUnit5 for Java、以及SpringTest for Spring。
- 測試人員在審查開發人員所編寫的低級別（單元）和中級別（集成）測試的過程中，使用QA的各種最佳實踐，來提高測試的質量，并從開發人員處學習更好的編程模式。
4. 指標：原生測試的覆蓋率和遷移的速度。
5. 挑戰：原生測試往往需要測試團隊比以前更多的編程技能。學習此方面技能的最佳方式，便是通過建立跨職能部門的流程與溝通渠道，與開發人員更緊密地合作。
6. 達標：將傳統的測試方式轉變為原生的測試模式。
譯者介紹
陳峻 （Julian Chen），51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗；持續以博文、專題和譯文等形式，分享前沿技術與新知；經常以線上、線下等方式，開展信息安全類培訓與授課。
原文標題：??Complete Guide to TestOps??，作者：Ruslan Akhmetzianov
