譯者：陳峻

過去，在軟件開發的後期，團隊往往不得不以全局重構、甚至延遲發佈的方式，來處置他們發現的嚴重錯誤。而隨著時間的推移，業界學會了通過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. 目標：優化監控的效率。鑑於手動測試很難被優化，我們往往需要藉助各種半自動化的工具，來加快高級測試團隊的工作效率。

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. 達標：將傳統的測試方式轉變為原生的測試模式。