譯者 | 陳峻

審校 | 孫淑娟

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

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

什么是TestOps?

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

總地說(shuō)來(lái)，TestOps是DevOps的一個(gè)子集。它通過(guò)一組技術(shù)和方法，在整個(gè)DevOps管道中進(jìn)行自動(dòng)的、透明的、可訪問(wèn)與管理的測(cè)試。而且，這些測(cè)試不僅在于QA上的透明與可控。

DevOps的原生測(cè)試是怎樣的？

一個(gè)應(yīng)用程序通常由前端、后端、以及移動(dòng)版本等部分組成。每個(gè)部分都可以由一個(gè)專門的團(tuán)隊(duì)來(lái)負(fù)責(zé)開(kāi)發(fā)。而一個(gè)典型的10人團(tuán)隊(duì)往往包含如下角色：

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

那么，測(cè)試將如何在這樣的團(tuán)隊(duì)中開(kāi)展？以下是在典型DevOps中，自動(dòng)化測(cè)試人員的主要任務(wù)：

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

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

TestOps的工作流

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

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

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

TestOps的生命周期

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

M1：?jiǎn)蝹€(gè)手動(dòng)測(cè)試人員

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

1. 團(tuán)隊(duì)：有時(shí)候，該階段甚至沒(méi)有專門的QA人員，僅由某個(gè)產(chǎn)品負(fù)責(zé)人或經(jīng)理去開(kāi)展測(cè)試工作。

2. 目標(biāo)：

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

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

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

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

6. 達(dá)標(biāo)：團(tuán)隊(duì)已經(jīng)建立了一個(gè)基本的錯(cuò)誤檢測(cè)和修復(fù)流程。

M2：手動(dòng)測(cè)試團(tuán)隊(duì)

這是DevOps的預(yù)備測(cè)試階段，測(cè)試團(tuán)隊(duì)會(huì)在此階段逗留較長(zhǎng)的時(shí)間，尤其是那些不以快節(jié)奏的開(kāi)發(fā)流程為目標(biāo)的團(tuán)隊(duì)。通常，此類手動(dòng)測(cè)試會(huì)在規(guī)定的發(fā)布周期的節(jié)奏下正常開(kāi)展。

1. 團(tuán)隊(duì)：多名初、中級(jí)QA人員，由一名高級(jí)QA人員/負(fù)責(zé)人指導(dǎo)。

2. 目標(biāo)：

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

3. 指標(biāo)：

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

4. 工具：團(tuán)隊(duì)需要通過(guò)如下工具，來(lái)存儲(chǔ)和管理測(cè)試用例，生成控制報(bào)告，以及跟蹤所有手動(dòng)測(cè)試的活動(dòng)。

• TestRail，一種基于Web的測(cè)試用例管理工具。測(cè)試人員、開(kāi)發(fā)人員、以及團(tuán)隊(duì)負(fù)責(zé)人可以使用它來(lái)管理、跟蹤和組織手動(dòng)測(cè)試等工作。
• PractiTest，一種為手動(dòng)測(cè)試提供了多團(tuán)隊(duì)管理、以及報(bào)告功能的端到端工具。
• Qase.io，一種新的且迭代迅速的工具。

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

6. 達(dá)標(biāo)：團(tuán)隊(duì)精心設(shè)計(jì)好了測(cè)試用例、存儲(chǔ)、以及管理流程。

M3：高級(jí)手工測(cè)試團(tuán)隊(duì)

這是高級(jí)QA工程師團(tuán)隊(duì)的一個(gè)可選的進(jìn)化階段，旨在整個(gè)公司的測(cè)試中，建立牢固的信任關(guān)系。

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

2. 目標(biāo)：優(yōu)化監(jiān)控的效率。鑒于手動(dòng)測(cè)試很難被優(yōu)化，我們往往需要借助各種半自動(dòng)化的工具，來(lái)加快高級(jí)測(cè)試團(tuán)隊(duì)的工作效率。

3. 工具：在這個(gè)階段，工具的主要任務(wù)是通過(guò)諸如：屏幕截圖、測(cè)試場(chǎng)景的自動(dòng)點(diǎn)擊等功能，發(fā)揮團(tuán)隊(duì)的作用，并盡量減少人工操作。典型工具包括：

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

4. 指標(biāo)：

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

5. 挑戰(zhàn)：

• 開(kāi)發(fā)團(tuán)隊(duì)的自動(dòng)化測(cè)試（如：?jiǎn)卧獪y(cè)試、集成測(cè)試）和QA團(tuán)隊(duì)仍處于脫鉤的狀態(tài)。
• 測(cè)試過(guò)程中的優(yōu)化和擴(kuò)展水平，仍然會(huì)受到團(tuán)隊(duì)人數(shù)的限制。

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

A1：有了一位自動(dòng)化工程師

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

1. 團(tuán)隊(duì)：在手動(dòng)測(cè)試的團(tuán)隊(duì)中添加了一名中、高級(jí)自動(dòng)化QA工程師。

2. 目標(biāo)：

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

3. 工具：該階段需要QA和開(kāi)發(fā)團(tuán)隊(duì)之間的通力協(xié)作，以自動(dòng)化各種測(cè)試實(shí)例和可執(zhí)行的CI管道。

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

4. 指標(biāo)：

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

5. 挑戰(zhàn)：盡管我們?cè)谶@個(gè)階段首次獲得了準(zhǔn)確意義上的自動(dòng)化測(cè)試套件，但是我們反而無(wú)法精準(zhǔn)地預(yù)測(cè)產(chǎn)品從測(cè)試到發(fā)布的持續(xù)時(shí)間。

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

A2：測(cè)試自動(dòng)化團(tuán)隊(duì)

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

1. 團(tuán)隊(duì)：幾位中、高級(jí)AQA工程師與更多初級(jí)隊(duì)友一起工作。

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

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

3. 工具：該階段，我們需要能夠通過(guò)從測(cè)試中獲取洞見(jiàn)，以提供報(bào)告和可觀察性工具：

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

4. 指標(biāo)：

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

5. 挑戰(zhàn)：

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

6. 達(dá)標(biāo)：

• 一旦回歸和驗(yàn)證測(cè)試完全轉(zhuǎn)為自動(dòng)化，團(tuán)隊(duì)就有足夠的時(shí)間進(jìn)一步考慮基礎(chǔ)設(shè)施的開(kāi)發(fā)。
• 測(cè)試結(jié)果的收集和報(bào)告自動(dòng)化，是另一種需要花費(fèi)大量時(shí)間和精力的工作。

A3：高級(jí)測(cè)試自動(dòng)化團(tuán)隊(duì)

當(dāng)測(cè)試的目標(biāo)被設(shè)定為獲得對(duì)DevOps管道、以及測(cè)試基礎(chǔ)設(shè)施的完全訪問(wèn)權(quán)限后，我們就需要配備一支非常熟悉測(cè)試的高級(jí)團(tuán)隊(duì)。

1. 團(tuán)隊(duì)：10人以上的高級(jí)AQA工程師

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

3. 工具：

• 作為全棧測(cè)試的自動(dòng)化解決方案，Allure TestOps為測(cè)試團(tuán)隊(duì)提供了如下開(kāi)箱即用的基本功能：

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

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

4. 指標(biāo)：與A2階段的指標(biāo)類似，該階段的測(cè)試執(zhí)行頻率指標(biāo)需要開(kāi)發(fā)人員、運(yùn)維人員、測(cè)試人員，有時(shí)甚至是管理人員等整個(gè)團(tuán)隊(duì)，最大化測(cè)試的使用率。

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

T1：TestOps的第一步

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

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

2. 目標(biāo)：

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

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

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

4. 指標(biāo)：

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

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

6. 達(dá)標(biāo)：一旦我們習(xí)慣了掌控管道，并讓各種測(cè)試都像上了發(fā)條一樣去自動(dòng)通知、生成相應(yīng)的報(bào)告，那么我們就達(dá)標(biāo)了！

T2：成立TestOps團(tuán)隊(duì)

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

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

2. 工具：

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

3. 目標(biāo)：

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

4. 指標(biāo)：原生測(cè)試的覆蓋率和遷移的速度。

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

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

譯者介紹

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

原文標(biāo)題：??Complete Guide to TestOps??，作者：Ruslan Akhmetzianov