譯者 | 陳峻

審校 | 孫淑娟

過去，在軟件開發(fā)的后期，團隊往往不得不以全局重構(gòu)、甚至延遲發(fā)布的方式，來處置他們發(fā)現(xiàn)的嚴重錯誤。而隨著時間的推移，業(yè)界學會了通過DevOps和敏捷等方法，來加速開發(fā)的周期。不知您是否注意到，DevOps并不是一個人的戰(zhàn)斗，而是開發(fā)人員、運維人員、測試人員、以及業(yè)務部門之間的一組復雜的流程、技能、溝通和工具。它專注于彌合開發(fā)和運營孤島之間的溝通障礙，并通過各種自動化或虛擬化工具，實現(xiàn)持續(xù)開發(fā)、集成、測試、監(jiān)控與反饋、以及交付和部署，來縮短新功能的面市時間。

不過，和其他新生的技術(shù)概念類似，DevOps也在持續(xù)完善中。在融入了安全性、基礎設施、以及測試之后，我們相繼看到了DevSecOps、NetOps、以及TestOps的出現(xiàn)。本文將重點和您討論TestOps的相關概念、工作流，以及生命周期中每個階段所涉及到的團隊、目標、指標、挑戰(zhàn)和工具等方面。

什么是TestOps?

通常，在分解大型發(fā)布的過程中，我們需要針對不同的框架和編程語言的代碼，進行各種類型的測試（如：Web、API、Canary等）。對此，我們需要通過持續(xù)測試的方法，來滿足各個微服務代碼的單元級與集成級測試的全覆蓋。

總地說來，TestOps是DevOps的一個子集。它通過一組技術(shù)和方法，在整個DevOps管道中進行自動的、透明的、可訪問與管理的測試。而且，這些測試不僅在于QA上的透明與可控。

DevOps的原生測試是怎樣的？

一個應用程序通常由前端、后端、以及移動版本等部分組成。每個部分都可以由一個專門的團隊來負責開發(fā)。而一個典型的10人團隊往往包含如下角色：

• 開發(fā)人員，負責編寫代碼、重構(gòu)和拉取請求的管理
• 項目經(jīng)理，負責開發(fā)的整體進度和敏捷流程
• QA工程師，負責發(fā)布測試和最終產(chǎn)品質(zhì)量
• 自動化測試（AQA）工程師，其工作是將測試自動化發(fā)展至極限
• 運維人員/管理員，負責質(zhì)量把關和管道維護

那么，測試將如何在這樣的團隊中開展？以下是在典型DevOps中，自動化測試人員的主要任務：

• 首先，自動化測試工程師的工作往往涵蓋了后端、前端和與原生自動化測試的各種集成。此處的“原生”意味著測試應使用與被測試代碼相同的技術(shù)棧，也允許將測試存儲在與代碼相同的存儲庫中。使用單一存儲庫的好處是，開發(fā)人員可以協(xié)助AQA工程師進行代碼的審查、以及復雜的測試開發(fā)。
• QA經(jīng)理在拉取請求的階段，針對已開發(fā)出的案例審查客戶場景的合理性、以及極端案例的覆蓋率。
• 同時，AQA工程師也會從QA的角度，檢查單元和集成測試。
• 雖然諸如：Docker或Kubernetes的配置、構(gòu)建腳本、以及測試環(huán)境設置等底層維護，都是由Ops人員負責的；但是包括：配置Selenium網(wǎng)格、瀏覽器、以及數(shù)據(jù)庫的數(shù)據(jù)管理等有關測試的基礎設施，仍然是由AQA工程師負責的。

可見，AQA工程師主要從事的是底層測試和質(zhì)量檢查等工作；而QA人員則負責監(jiān)督發(fā)布的整個管理過程。

TestOps的工作流

上圖展示了TestOps的管道，其具體工作流為：

• 開發(fā)人員創(chuàng)建一個新的功能分支，并在完成時產(chǎn)生一個包含了一些全新代碼、以及一堆自動化測試的拉取請求（PR）。
• AQA工程師審查PR，并在必要時添加更多的測試。例如，他們會增加包含了數(shù)十個參數(shù)與變體的全面測試。
• 之后，QA經(jīng)理從業(yè)務角度開始最終的測試審查。測試主要著眼功能和用戶故事的覆蓋范圍。
• 如果測試能夠順利完成，那么分支就會被合并。如果測試出現(xiàn)問題，那么團隊著手予以修復，并跳轉(zhuǎn)至上述第2步。注意，每個錯誤都應當與待添加到下一次回歸運行的問題相關聯(lián)。

可見，管道上的大多數(shù)測試只有在實現(xiàn)了自動化后，其測試的持續(xù)時間才能夠更容易被預估。

TestOps的生命周期

如上圖所示，我將在下文向您介紹QA團隊在開展TestOps過程中，可能涉及到的每個階段的團隊、目標、指標、挑戰(zhàn)和工具等方面。

M1：單個手動測試人員

該階段通常是每個QA部門的起點。大多數(shù)團隊甚至不會意識到該階段的存在。不過，它確實會對QA的未來發(fā)展產(chǎn)生影響。

1. 團隊：有時候，該階段甚至沒有專門的QA人員，僅由某個產(chǎn)品負責人或經(jīng)理去開展測試工作。

2. 目標：

• 創(chuàng)建錯誤報告的流程與模板，且報告越清晰越易于開發(fā)團隊的修復。
• 此階段創(chuàng)建的測試用例，可能很短且缺乏細節(jié)，不過主要目的是為了獲悉對測試持續(xù)時間的粗略估計，以便為下一階段做好準備。

3. 指標：通過密切地關注流程，在指定的流程中正確地記錄Bug的數(shù)量。

4. 工具：可使用Excel、電子郵件、Slack、以及任何其他能夠共享和跟蹤錯誤報告的工具。

5. 挑戰(zhàn)：當團隊較小時，將錯誤直接傳遞給開發(fā)人員，并在Slack DM（即時通訊工具）中獲得修復通知是較為容易的。但是該方法也可能會給下個階段帶來潛在的混亂。

6. 達標：團隊已經(jīng)建立了一個基本的錯誤檢測和修復流程。

M2：手動測試團隊

這是DevOps的預備測試階段，測試團隊會在此階段逗留較長的時間，尤其是那些不以快節(jié)奏的開發(fā)流程為目標的團隊。通常，此類手動測試會在規(guī)定的發(fā)布周期的節(jié)奏下正常開展。

1. 團隊：多名初、中級QA人員，由一名高級QA人員/負責人指導。

2. 目標：

• 我們需要為每個測試設置一個所有者，并記錄運行的結(jié)果，以便團隊知道誰應該對測試的疏漏負責。這不是為了懲罰，而是為了實現(xiàn)建設性的回顧。
• 測試的透明度。文檔、無法通過（pass-failed）的比率、以及將Bug與問題跟蹤器聯(lián)系起來，都可以協(xié)助整個團隊去掌控測試的過程。
• 詳細的測試用例。作為文檔要求的一個環(huán)節(jié)，團隊里的不同成員工作在同一套測試用例上時，應為測試用例從一個所有者轉(zhuǎn)移到另一個所有者做好準備。也就是說，測試用例應該包含所有的步驟、注釋、元數(shù)據(jù)、以及環(huán)境描述等方面。

3. 指標：

• 測試用例的執(zhí)行頻率。測試的運行當然是越頻繁越好。
• 測試通過率。請記住，測試的通過，可能并不表明代碼無懈可擊，而是跳過或忽略了某些深層次的錯誤。
• 測試報告的生成和使用情況。測試的結(jié)果報告不僅僅是給經(jīng)理或測試團隊的負責人查閱的，也需要開發(fā)人員經(jīng)常查看其中的問題和測試用例。同時，運維人員還需要據(jù)此判定手動測試套件，是否比冒煙套件和金絲雀版本更有價值。

4. 工具：團隊需要通過如下工具，來存儲和管理測試用例，生成控制報告，以及跟蹤所有手動測試的活動。

• TestRail，一種基于Web的測試用例管理工具。測試人員、開發(fā)人員、以及團隊負責人可以使用它來管理、跟蹤和組織手動測試等工作。
• PractiTest，一種為手動測試提供了多團隊管理、以及報告功能的端到端工具。
• Qase.io，一種新的且迭代迅速的工具。

5. 挑戰(zhàn)：通常，測試的速度，以及回歸類測試的復雜程度，都會對測試團隊的人員數(shù)量有所要求。因此，對于那些缺乏人手和經(jīng)驗豐富的團隊，可能在此面臨嚴峻的挑戰(zhàn)。

6. 達標：團隊精心設計好了測試用例、存儲、以及管理流程。

M3：高級手工測試團隊

這是高級QA工程師團隊的一個可選的進化階段，旨在整個公司的測試中，建立牢固的信任關系。

1. 團隊：與前一階段幾乎相同。主要的區(qū)別在于團隊成員更加資深。

2. 目標：優(yōu)化監(jiān)控的效率。鑒于手動測試很難被優(yōu)化，我們往往需要借助各種半自動化的工具，來加快高級測試團隊的工作效率。

3. 工具：在這個階段，工具的主要任務是通過諸如：屏幕截圖、測試場景的自動點擊等功能，發(fā)揮團隊的作用，并盡量減少人工操作。典型工具包括：

• Postman：一種專注于測試、而非執(zhí)行過程的API測試工具。
• FakeData：一種通過生成測試數(shù)據(jù)，來節(jié)省時間，并避免手動測試表單的工具。
• LambdaTest和Responsively：一種能夠?qū)⒆詣踊焖贉y試，在不同分辨率的瀏覽器上顯示結(jié)果的工具。

4. 指標：

• 需要衡量通過半自動化工具和自動化日常任務，以優(yōu)化測試時間與人力成本的水平。
• 通過獲得每個測試套件運行的透明度、以及可預測性，來估計出產(chǎn)品的最終發(fā)布時間。

5. 挑戰(zhàn)：

• 開發(fā)團隊的自動化測試（如：單元測試、集成測試）和QA團隊仍處于脫鉤的狀態(tài)。
• 測試過程中的優(yōu)化和擴展水平，仍然會受到團隊人數(shù)的限制。

6. 達標：團隊能夠根據(jù)業(yè)務要求，以更快的速度發(fā)布新的版本。

A1：有了一位自動化工程師

這是公司走向自動化的第一步。通常，此階段會包含：選擇測試框架、測試的執(zhí)行環(huán)境、以及覆蓋率指標等基本步驟。這些都為進一步的自動化開發(fā)奠定了基礎。

1. 團隊：在手動測試的團隊中添加了一名中、高級自動化QA工程師。

2. 目標：

• 通過自動化的端到端（E2E）測試，不但涵蓋了各種基本API，而且提高了整體測試的效率。雖然對于一組UI測試，可能需要更多的時間，且效率可能低于手動設置；但是一組帶有數(shù)據(jù)生成和模擬API的自動化端到端測試，肯定會在覆蓋率和效率上勝過手動操作。
• 創(chuàng)建一個可被用于快速實現(xiàn)手動測試用例的自動化流程，并盡可能地自動生成已調(diào)優(yōu)過的模板代碼。

3. 工具：該階段需要QA和開發(fā)團隊之間的通力協(xié)作，以自動化各種測試實例和可執(zhí)行的CI管道。

• 自動化工程師可以選擇Selenium和Playwright之類端到端的測試工具作為測試環(huán)境。這兩種工具都是不錯的無頭瀏覽器（Headless Browser）測試框架，可以啟動手動測試用例的自動化。
• 可以選擇JetBrains或微軟的IDE產(chǎn)品。

4. 指標：

• 鑒于網(wǎng)站布局或API響應的微小變化，都可能導致自動化測試的失敗，測試團隊應事先設定有關測試穩(wěn)定性和可維護性的API測試指標。
• 盡可能頻繁地在各種環(huán)境和條件下，去測試每個拉取請求的合并和發(fā)布。
• 衡量從自動化測試遷移回手動測試的比率。此類遷移往往意味著自動化的成熟度和精準度，尚有待提高與改進。

5. 挑戰(zhàn)：盡管我們在這個階段首次獲得了準確意義上的自動化測試套件，但是我們反而無法精準地預測產(chǎn)品從測試到發(fā)布的持續(xù)時間。

6. 達標：自動化測試用例的生成、工具的建立、以及流程的確立，都為快速發(fā)布與交付提供了保障。

A2：測試自動化團隊

隨著時間的推移，團隊雖然獲得了更多的自動化工程師，但是有高達60%的自動化項目會出現(xiàn)停滯不前的現(xiàn)象。此外，前面階段的原有流程也可能會給全棧測試的自動化帶來影響。

1. 團隊：幾位中、高級AQA工程師與更多初級隊友一起工作。

2. 目標：從如下方面保持軟件質(zhì)量體系的穩(wěn)定性：

• 原子化的自動測試既能夠彼此獨立，又可以提供本地化的結(jié)果，更容易修復Bug。也就是說，每次測試失敗都能夠提供更精確的結(jié)果，以便得到快速的修復。
• 提供一個帶有統(tǒng)一接口的測試套件，以便開發(fā)人員通過質(zhì)量門在其分支上運行測試。
• 基于良好的文檔記錄，該階段應實現(xiàn)100%的回歸和驗證測試的覆蓋率，以體現(xiàn)自動化測試的價值。

3. 工具：該階段，我們需要能夠通過從測試中獲取洞見，以提供報告和可觀察性工具：

• 報告類工具，如Allure Report和ReportPortal等開源方案，都能夠共享結(jié)果，并控制自動化套件的執(zhí)行。
• 全棧測試框架，如Katalon和Cypress。選擇全棧測試框架對于計劃保持A1-A3測試級別的團隊來說，可以在專有的供應商基礎設施中，構(gòu)建出廣泛的新功能。
• 監(jiān)控：雖然設置Grafana之類的實例有些繁瑣，但是它作為一個通用的開源分析和交互式可視化工具，能夠以圖表、圖形或警報的形式，為團隊提供即時的測試結(jié)果。

4. 指標：

• 運行與重新運行次數(shù)。就像論文在反復被引用的過程中，可以體現(xiàn)其自身價值那樣，同一個測試被不同的團隊運行，其結(jié)果是否能夠給其他團隊帶來分支合并或發(fā)布，都能夠體現(xiàn)測試套件的價值。
• 測試本身的用時并不重要，重要的是它能否預測代碼正式發(fā)布的時間點。
• 有時候，測試可能會在沒有明顯原因的情況下，持續(xù)通過了失敗的結(jié)果（passed-failed result），對此我們應當予以隔離、調(diào)查和修復，以認清是否由于基礎設施的問題所致。
• 無論是業(yè)務邏輯的變化，還是測試本身的原因，都可能導致失敗。因此，我們需要通過Time-to-fix，來估算能夠多快去修復此類失敗的測試。

5. 挑戰(zhàn)：

• 與測試相關的基礎設施往往與QA團隊“相距甚遠”，且不具有通用性。因此，這會影響到上面提到的測試的“運行與重新運行的次數(shù)”。
• 隨著測試變得更加原子化，您會發(fā)現(xiàn)將大型手動測試用例映射到一組原子自動化測試，會變得越來越困難。為此，團隊需要有更改手動測試的工作流程，按需使用清單進行手動測試。

6. 達標：

• 一旦回歸和驗證測試完全轉(zhuǎn)為自動化，團隊就有足夠的時間進一步考慮基礎設施的開發(fā)。
• 測試結(jié)果的收集和報告自動化，是另一種需要花費大量時間和精力的工作。

A3：高級測試自動化團隊

當測試的目標被設定為獲得對DevOps管道、以及測試基礎設施的完全訪問權(quán)限后，我們就需要配備一支非常熟悉測試的高級團隊。

1. 團隊：10人以上的高級AQA工程師

2. 目標：QA團隊需要與Ops團隊保持聯(lián)系，不但要完成測試的編寫，而且能夠?qū)y試的基礎設施實施控制。也就是說，由Ops團隊負責硬件和腳本級別的維護，其中包括：緩存、構(gòu)建腳本、以及數(shù)據(jù)庫可訪問性等低級別的部分。而QA團隊則努力控制測試環(huán)境的基本配置與微調(diào)、性能分析、依賴關系、數(shù)據(jù)和環(huán)境更新等方面。這些都是團隊集成到主要DevOps管道中所必需的。據(jù)此，獨立的自動化測試團隊可以實現(xiàn)對每個分支、以及版本進行快速且精確的測試。

3. 工具：

• 作為全棧測試的自動化解決方案，Allure TestOps為測試團隊提供了如下開箱即用的基本功能：

1. 可以與JS、Python或Java框架，以及與Playwright或Selenium等全棧工具相集成。
2. 能夠控制帶有各種自定義套件，重運行的選定測試，以及存儲運行歷史記錄的CI/CD系統(tǒng)。
3. 能夠開展自動化的故障調(diào)查和詳細的分析。

• qTest是另一個用于敏捷測試的大型測試管理工具。它遵循了集中式的測試管理概念，有助于QA團隊與其他利益相關者輕松地進行溝通，并協(xié)助開展快速的開發(fā)任務。

4. 指標：與A2階段的指標類似，該階段的測試執(zhí)行頻率指標需要開發(fā)人員、運維人員、測試人員，有時甚至是管理人員等整個團隊，最大化測試的使用率。

5. 挑戰(zhàn)：缺乏基礎設施的管理專業(yè)知識。如果QA團隊不去深入研究基礎架構(gòu)，那么他們可能會將與Ops相關的任務（如更新Selenium或框架）推遲到最后。

T1：TestOps的第一步

該階段意味著QA團隊已經(jīng)走出了測試的“泡沫”，代碼庫被整潔的原子自動化測試所覆蓋。測試已經(jīng)以半自動運行的方式，融入了主要的開發(fā)管道流程。如今的重點是為與Ops的全面集成做好準備。

1. 團隊：團隊中需要有兩、三個熟悉服務器管理、以及CI/CD工具和流程等運維專業(yè)知識的測試人員。

2. 目標：

• 掌控所有測試基礎設施，包括與管理員團隊一起維護所有的模擬器、Selenium實例、以及其他測試內(nèi)容。由經(jīng)驗豐富的管理員著手更新測試服務器上的瀏覽器或Docker。
• 通過將測試服務器集成到主要的開發(fā)管道中，以自行解決“計劃”測試、數(shù)據(jù)庫擦除、以及Selenium配置更新等棘手且不穩(wěn)定的測試。
• 以自動化的方式設置測試通知，并要求Ops團隊監(jiān)控測試的執(zhí)行。

3. 工具：在這個階段，我們需要如下工具來構(gòu)建可擴展、且靈活的自動化測試基礎架構(gòu)。

• Docker，可以輕松地創(chuàng)建、管理多個預設且能夠按需運行的環(huán)境。
• Jenkins，雖然不是最容易設置的系統(tǒng)，但它一直被龐大的開源社區(qū)、以及豐富的生態(tài)系統(tǒng)所推崇。

4. 指標：

• 執(zhí)行測試套件的持續(xù)時間與成本。為了避免測試管道被卡在測試的質(zhì)量門處，我們可以根據(jù)時間和成本兩項指標，來優(yōu)化Ops團隊的工作，以確保測試預算的可控的范圍內(nèi)。

5. 挑戰(zhàn)：與A2階段類似，我們雖然可以更好地管控測試基礎設施，但是上述指標不一定能夠被調(diào)優(yōu)。這往往需要我們與Ops團隊保持密切協(xié)作關系。

6. 達標：一旦我們習慣了掌控管道，并讓各種測試都像上了發(fā)條一樣去自動通知、生成相應的報告，那么我們就達標了！

T2：成立TestOps團隊

這個階段對于彌合測試和開發(fā)人員之間鴻溝是必要的。測試人員和開發(fā)人員開始在統(tǒng)一的技術(shù)棧上編寫測試代碼。測試人員和運維人員通過對測試基礎設施的管理，提供了快速將新功能推向市場的管道。

1. 團隊：由原來以資深測試人員為主的團隊，轉(zhuǎn)變?yōu)榫哂羞\維和基礎設施維護經(jīng)驗的SDET（Software Development Engineer Test，測試開發(fā)工程師）團隊。

2. 工具：

• GitHub/GitLab，一套基于代碼的協(xié)作工具與平臺。
• Allure TestOps，一種可以將實時文檔、自動跟蹤測試內(nèi)容、以及通過率等所有測試要素，對非開發(fā)人員開放的工具。同時，其高級儀表板可供將開發(fā)人員、運維人員、以及QA團隊，開展聚合式的全棧測試分析。

3. 目標：

• 遷移到各種原生的測試工具上，即：測試與被測代碼使用相同的技術(shù)棧。例如：JEST for JS、XCtest for iOS、Kaspresso for Android、Pytest for Python、JUnit5 for Java、以及SpringTest for Spring。
• 測試人員在審查開發(fā)人員所編寫的低級別（單元）和中級別（集成）測試的過程中，使用QA的各種最佳實踐，來提高測試的質(zhì)量，并從開發(fā)人員處學習更好的編程模式。

4. 指標：原生測試的覆蓋率和遷移的速度。

5. 挑戰(zhàn)：原生測試往往需要測試團隊比以前更多的編程技能。學習此方面技能的最佳方式，便是通過建立跨職能部門的流程與溝通渠道，與開發(fā)人員更緊密地合作。

6. 達標：將傳統(tǒng)的測試方式轉(zhuǎn)變?yōu)樵臏y試模式。

譯者介紹

陳峻 （Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項目實施經(jīng)驗，善于對內(nèi)外部資源與風險實施管控，專注傳播網(wǎng)絡與信息安全知識與經(jīng)驗；持續(xù)以博文、專題和譯文等形式，分享前沿技術(shù)與新知；經(jīng)常以線上、線下等方式，開展信息安全類培訓與授課。

原文標題：??Complete Guide to TestOps??，作者：Ruslan Akhmetzianov