協作是持續測試的關鍵推動力

 

新一輪保護主義的興起

在今年瑞士達沃斯世界經濟論壇上，中心主題是新一輪保護主義的興起及其對世界經濟的負面影響。德國聯邦總理Angela Merkel發出警告，明確說明在這個全球互聯和快速發展的世界中，繁榮和增長的最重要先決條件是合作。

協作以及DevOps、敏捷和持續測試的世界

合作正在成為商業最重要的方面，而不僅僅是在政治和經濟環境中。協作也是技術領域領導者的取得成功的關鍵因素——使用敏捷方法為客戶更快地交付軟體和價值。

通過敏捷方法，我們開始將舊有的階段門控軟體交付模式轉變為以團隊和價值為中心的方法，減少交付/批量大小，並自動化手動互動以降低交易成本，同時提高交付成果的質量和交付速度（見圖1）。通常，昂貴的手動互動包括兩個方面——一方面是安裝、部署和配置應用程式，另一方面是驗證應用程式功能——從開發、測試到生產（持續測試）。我們提供更多、更小的軟體包，並持續測試我們提供的軟體包。

 

圖1：

左側：用於開發、測試和運營的傳統分層團隊模式——這通常會導致出現孤島、由於移交導致的處理時間延長、交付延遲和大批量。

右側：敏捷團隊模式——最大限度地減少移交，允許資訊共享並改善跨階段協作。

底部：業務流程示例（價值流）——基於元件的團隊通常只關注一個元件，其中更成熟的敏捷團隊是基於功能的，負責組合元件和價值流。

團隊內部、團隊之間以及跨階段的協作

有三種類型的協作被證明可以讓企業走向成功，它們反映了企業在持續測試戰略中所經歷的典型的成熟度步驟：團隊內部協作、團隊間協作以及跨階段協作。

I：團隊內部的協作

驗收測試驅動、行為驅動和測試驅動開發都被證明是質量和效率的重要驅動因素。所有可能的初始情況、條件和預期結果都會暴露出來，通過對整個過程進行思考，整個團隊可以真正瞭解某個使用者故事的預期結果。

理想情況下，敏捷團隊的測試（參見圖2）遵循的是結對程式設計的模式。像結對程式設計師互相評審程式碼一樣，在協作測試中，開發人員和測試人員在各自的使用者故事上並行工作，相互支援，在第一天就能提供測試工件，這就是所謂的「測試自助服務模型「。一旦開發人員開始編譯程式碼，測試驅動程式就也跟著啟動了。根據檢查和平衡原則，這種方法設定了很高的質量標準，並且還可以釋放掉一些開發者資源。

 

圖2：敏捷團隊是跨職能的，測試人員是團隊的一部分。敏捷團隊可以自我組織，自我管理，並在每個sprint中提供經過充分測試的工作增量。敏捷團隊基於願景、架構和使用者體驗指南運作。這種團隊運作模式最小化了交接，實現資訊共享，並改善了跨階段協作。

像配對程式設計一樣設定測試套件和環境

隨著敏捷團隊趨於成熟，他們通過基於模型和麪向物件的測試方法提升了效率。就像標準的開發正規化已演變為物件導向的原則一樣，基於模型的測試是一個進化步驟，讓我們能夠將業務層從技術層中抽離出來。通過這種方式，我們可以向每個團隊成員——技術人員或非技術人員——提供最佳檢視，讓具有不同技能的人員能夠為測試專案的成功共同出力。

使用測試工件作為協作工具

測試工件（參見圖3）用於表示引導應用程式測試所需的資訊——例如，UI表單及其欄位、介面定義或檔案格式——以無冗餘和可重用的方式，可以顯著減少在建立和維護方面的工作量，讓這些模型成為整個業務流程中不可或缺的一部分。

這些測試工件不僅限於UI或API測試驅動程式，它們還包括：

• 測試資料管理例程，用於生成合成測試資料，搜尋現有測試資料或快照並遮蔽資料。
• 測試設計儲存庫，包含：
  • 所需的測試變體，併爲每個測試變體驗證其輸入資料、條件和預期結果；
  • 非功能性測試驅動程式和引數，例如響應時間、預期最大負載能力或各種網路條件；
  • 每個變體的業務風險——瞭解每個測試用例的含義，並對其進行多個級聯測試，如冒煙測試、sanity測試或迴歸測試。

 

圖3：測試工件包含一個測試用例儲存庫，按每個測試用例附帶的風險進行優先順序排序。儲存庫定義輸入引數、條件和預期結果——與測試資料管理相結合——提供測試執行的記錄，建立合成測試資料或快照，並遮蔽應用程式資料庫。儲存庫由基於模型和麪向物件的測試工件組成，用於進行UI測試、API測試或其他非UI測試驅動程式，如檔案測試觸發器資料庫，非功能測試驅動程式，如負載或網路模擬條件。服務虛擬化用於模擬應用程式依賴項，並使用相同的測試資料儲存庫。

將進度測試（Progression Test）轉換為迴歸測試

我們常常看到敏捷團隊使用某種測試工具為新功能建立進度測試，另一方面，開發團隊卻在建立迴歸測試——這些工作是冗餘的，會導致額外的工作量和延遲。通過基於模型的方法，每個最初用於驗證新功能的進度測試用例都可以被重用，並轉換為完整的迴歸測試組合（見圖4）。

通過將進度測試轉換為迴歸測試，我們可以達到新的測試準確度，而這些是黑盒測試永遠無法提供的。

這種方法的另一個優勢是，敏捷團隊是知識的中心，並且能夠以最少的工作量和最好的知識來實時地建立、維護和版本化測試工件。這種方法可以提高測試的準確性，這種準確性是黑盒測試永遠無法提供的。

 

圖4：爲了實現高效準確的測試策略，需要在增量交付後的下一個sprint中重複使用進度測試工件（在sprint期間驗證新功能），將其作為迴歸測試（驗證完整的現有系統功能）

團隊真的需要專門的測試人員嗎？

你是否仍然在猶豫要不要在你的團隊中設定專門的測試員角色？大約200年前，刑事司法系統引入了權力分立和制衡制度。因為檢察官、辯護人和法官不再屬於同一角色，所以我們再也看不到任何讓人匪夷所思的女巫審判。專門的測試人員可以消除開發人員的盲目性——回想一下結對程式設計是如何消除錯誤的。

II：跨團隊協作

我的幾何老師告訴我說，「兩個平行線在無窮遠處交叉！」。在我十七歲的時候，他的這番話打破了我對科學的信心，當時我正嘗試著如何繪製中心透視球的陰影。但有趣的是，對我來說，似乎在軟體科學中它卻恰恰相反：兩個並行的團隊——服務提供者和服務使用者——在完成一到兩個sprint後，他們會在相同的介面描述上出現融合。在某種程度上，你永遠不會相信他們可以理解同一種（定義）語言。

解決方案：合約測試在發生偏差之前證明介面的相容性

元件通過介面進行互動，這些介面是團隊協作的關鍵因素。我們應該通過合約測試讓每個團隊從一開始在不依賴其他相關元件的情況下就對他們的元件進行正確性驗證，而不是等待以後通過整合測試來證明存在任何偏差（參見圖5）。

合約測試將每個元件與其依賴項分離開來，並將服務客戶端和服務消費者之間的介面定義解釋為「合約」。通過這些合約，我們針對服務提供者建立API測試驅動程式，併爲服務使用者建立映象的服務虛擬化測試。通過這種方法，這些合約測試可以確保在任何時候都能夠匹配介面互動。

 

圖5：(1)「合約」是服務客戶端和服務提供者之間介面定義的同義詞。通過早期的介面定義，(2)可以為敏捷團隊的測試建立和提供API測試驅動程式及服務虛擬化工件。合約測試是高效系統整合測試的基礎。

服務虛擬化支援完全沙盒化的業務流程測試

服務虛擬化是一種模擬技術，可讓你在不使用待測試應用程式（AUT）的依賴系統元件的情況下執行測試。服務虛擬化可確保你的測試在每次執行時都會得到相應的依賴行為和資料（參見圖6）。

在驗證了AUT的模式和請求資料之後，就可以儲存、重用或修改資料，用於後續的服務虛擬化。你可以嵌入字串、數學或外部函式，讓測試場景變得更加真實。此外，你可以利用動態模式匹配系統來提供不同的響應方案、結構或模擬故障。服務虛擬化支援完全沙盒化的業務流程測試——在軟體生命週期中實現全面和早期的質量反饋。[另請參閱 測試驅動的服務虛擬化 ]。

 

圖6：服務虛擬化（「沙盒測試」）允許採購訂單服務團隊每天檢索完整的整合測試結果，包括完整的業務場景。待測試的應用程式（採購訂單服務）通過測試驅動的方式進行封裝，其中使用了測試驅動程式和用於模擬依賴項的服務虛擬化工件，它們都使用相同的測試資料儲存庫。

合約測試（反向API）是協作的關鍵

在服務提供者方面，API是快速解決 Gordian Knot 質量的關鍵。通過將服務虛擬化方案轉換為API測試驅動程式，它就像同一個硬幣的兩面：服務使用者的服務虛擬化和服務提供者的API測試驅動程式。

我們還突破了敏捷團隊的障礙——讓服務提供者和服務客戶端​​團隊能夠在早期開發階段執行和覆蓋模擬整合測試，而這些通常只能在後續的整合測試環境中實現。

服務虛擬化例程是測試工件

合約測試被視為測試工件，以與UI測試相同的方式進行建立、維護和版本化，可以讓現場、離岸甚至外部供應商執行（模擬）整合測試。

API先行

API先行——首先關注API測試不僅是這種更有效的設定和降低維護成本的願望的產物，它也主要來自我們在團隊之間實現漸進式合約測試。

這些步驟與一級方程式模擬器中使用的步驟基本相同。他們模擬了數百個元件的配置和互動（你是否知道F1團隊只允許使用最多25 Teraflops進行模擬？），並且在識別出合適的設定後，賽車手就會在真實賽車道上使用真實的賽車以超狗200英里的時速進行快速驗證並做出精確調整。或者用在飛行員訓練計劃中呢？你認為他們在第一次飛行時會讓新手撞到真正的A380嗎？可能代價有點太高了。

III：跨階段協作

隨著公司的第一批團隊轉向敏捷，重複的模式顯示出保護主義的再次興起。

「有超過50％的組織在實施DevOps」(8)，我們可以看到一個類似且重複的模式——只要有一些團隊甚至整個業務線轉型，就會遇到我們所熟知的問題：保護主義。

我們如何防止保護主義越過團隊邊界並形成壁壘？這個不是開發、測試、運營和業務之間的問題，而是敏捷團隊和業務線之間的問題。那麼，我們該如何將協作融入到整個公司的持續測試戰略實施的過程中，讓CEO和董事會成員不會面臨大規模產品計劃的大規模延遲？

一旦敏捷團隊數量開始增加，就會形成敏捷團隊的組合：部落、敏捷釋出培訓或業務線——你可能已將在應用 Spotify 模型或在使用 可伸縮敏捷框架 （參見圖7），但分階段測試的機制仍然存在。它假設你的測試過程已經很成熟，並且在團隊中進行了全面的質量驗證，然後通過了合約測試的覆蓋。

 

圖7：左邊——可伸縮敏捷框架(2)。右邊——Spotify模型(3)。

企業敏捷框架描述了成功將Agile擴充套件到企業所需的層次和結構、如何對敏捷團隊進行分組、如何跨團隊交付軟體以及如何構建和管理團隊組合（「敏捷釋出列車」、「部落」） 。

儘管如此，我們仍然需要在測試階段執行有效的測試——以排除未知或未識別的行為——特別是對於存在高業務風險的場景。在第一階段，通常需要驗證元件的互動，在第二階段，需要進行完整的端到端用例和最終業務驗收測試。

現在想象一下，如果你要為這些測試階段重新建立測試工件（通常由專門的實施團隊建立），除了需要敏捷團隊成員的努力之外，還需要額外的資源、時間，而且還會造成延遲。爲了不重建另一面牆，可以使用一個簡單但可以改變遊戲規則的方法：

測試工件是可交付成果

測試工件是可交付成果。變更發生得越晚，通常會導致越脆弱的測試自動化，但測試工件的可重用性保證了知識的轉移和協作。

持續測試需要在敏捷團隊和開發（系統）團隊之間取得平衡。

在一些企業中，在實現了從分層到敏捷團隊結構的轉變之後，敏捷團隊可能需要對應用程式從開發到進入生產環境的整個過程負責，但大多數團隊都有單獨的開發（系統）團隊來部署、維護和測試所有應用程式的組合。

可伸縮敏捷框架聲稱它「需要敏捷團隊和開發（系統）團隊之間的平衡」，這就要求這些團隊緊密協作，共享知識和測試工件。

 

圖8：最佳速度（和努力）是敏捷團隊和開發（系統）團隊之間的共同（測試）責任。

持續管道如何運作？

工件、版本控制系統和釋出自動化這三個要素與持續測試平臺相結合，形成了一個持續交付管道。它將應用程式安裝、配置和部署到各個測試和生產環境，觀察決策規則、質量閾值、應用程式依賴項，並在必要時執行回滾方案。它根據應用程式和部署的版本觸發執行每個測試階段的測試用例。

 

圖9：測試階段（從左到右）：(1)Dev：通常，在本地機器上進行，同構結對程式設計的方式進行測試。(2)QA——通過CI觸發構建和測試，僅關注團隊的元件（沙盒測試）。(3)敏捷團隊元件組成的整合測試（部落、業務、敏捷釋出培訓）。

(4)E2E-測試總體解決方案（部落/業務線組合/解決方案培訓的組合）。

應用程式釋出自動化工具是持續交付的基礎——在每個測試階段和生產環境中安裝、部署和配置應用程式，基於底層元件版本控制，防止程式碼重新編譯的工件，單獨觸發每個階段的測試執行，根據預定義的決策標準進入下一階段，並在必要時執行回滾方案。

由於這些階段最初是在團隊中動態建立的（建立、版本化和維護），因此測試工件最適合用於滿足速度和質量方面的要求。

將測試自動化提升爲真正的驗證流程，而不是下游的變更活動

系統測試通常具有不同的方向，在關注業務流程的同時，仍然可以將測試工件（如UI測試驅動程式、介面測試、測試資料例程和測試儲存庫）應用在端到端測試上。

基於模型的一次性端到端測試案例由來自各個團隊的各個部分組成。由敏捷團隊稍後做出的底層元件及其測試驅動程式的變更將被繼承併合併到端到端測試流程中。基於模型的測試可以實現全價值流的垂直測試，為每個測試階段使用正確的版本，並將自動化測試執行提升爲真正的驗證流程，而不是下游的變更活動。

 

圖10：通常，專門的系統團隊在企業層面驗證應用程式的功能。當測試工件從團隊移交給業務部門，再到系統團隊時，可以獲得最理想的速度、工作量和質量。

功能開關或生產環境測試等方法是否會改變執行關鍵端到端業務案例測試的方式？生產環境測試通常用於低風險場景，提供給小客戶群，使用綠藍部署，並在發生錯誤時自動回滾。功能開關呢？在客戶可能獲得其他客戶的信用卡資料檢視之前，仍然可以對關鍵流程（例如購物車支付流程的變更）進行有效的測試。

你是否仍然認為，敏捷團隊應該是完全自組織的（並且只專注於他們自己的元件）？永遠不要忘記W. Edwards Deming說過的話：

「系統必須是可管理的。它不會自我管理。如果放縱它們，元件就會變得自私，成為帶有競爭性的獨立利益中心，從而破壞整個系統。通過元件之間的合作來實現組織的目標纔是祕密所在。「

結論——過去、現在和未來

在過去的二十年中，專注於驗證完整端到端業務流程的集中式測試中心的日子很不好過。在外部、近岸或內部的50多個不同的供應商之間存在著十分緊張的局面，主要問題如下：延遲交付，劣質的輸入、未遵循開發者驗收測試協議、過晚才進行質量檢查、在維護不良的測試環境中進行質量檢查或者用在質量檢查上的時間太短。這是一個功能失調的表現。

我們現在看到鐘擺擺向市場的最左邊，現在他們期望開發人員能夠解決所有的質量問題。

超越團隊邊界

通常情況下需要做出折中——需要敏捷團隊和開發團隊之間從文化、流程以及測試工件的移交方面取得平衡和協作。

根據上面提到的三個階段，團隊最初只關注他們的元件，一旦企業在敏捷轉型中發展成熟，就需要進行整體思考。

要將敏捷擴充套件到整個企業，需要的不僅僅是每個敏捷團隊的自我組織——它要求團隊將跨團隊協作視為敏捷正規化的關鍵部分。通過讓傳統上獨立的團隊參與到其中，可以很好地實現「超越團隊邊界的思考」，這些測試活動是在各種連續測試階段進行的，而不僅僅是在開發階段。通過讓每個團隊中自由選擇工具，測試只有在選定的工具既能實現團隊目標又能在後續的測試階段被各種不同的角色無縫整合和使用時才能發揮作用。

附錄

1. 標題：來源：683014141/Shutterstock.com；世界經濟論壇
2. 圖7：© The 可伸縮敏捷框架
3. 圖7：© Spotify
4. 圖8：共同責任
5. W.Edwards Deming：可伸縮敏捷框架——原則#2 應用系統思考
6. 基於模型的測試自動化
7. 圖9：應用程式釋出自動化
8. Forrester：2018——企業DevOps年

關於作者

Alexander Mohr 正在為Tricentis開發並提供圍繞企業持續測試的戰略、最佳實踐和思想領導力，為敏捷轉型、CI/CT/CD設定路線圖，並在整個轉型過程中監督企業。Alexander擁有超過19年的IT經驗，於2000年初開始作為信用卡公司的開發人員，建立了一個發行和收購系統。在接下來的15年中，Alexander擔任過開發人員、產品經理、業務分析師、測試經理、架構師和專案經理等多種角色，在中型企業和企業級公司的瀑布式和敏捷專案中積累了很多經驗，知道哪些事情可以做，哪些事情不可以做。

檢視英文原文： How to Achieve Collaboration as a Key Driver for Continuous Testing