一十一

發表於 2018-03-14 16:40:22

摘要：

TestOps模型旨在將整個團隊的註意力集中在質量上，因此TestOps確實需要無縫且可靠。 一個簡單的例子是任何測試框架必須足夠可靠，以至於很少有停機或連接問題。 無論何時，如果評估失敗，或者延遲發布版本的反饋，都會對系統的有用性產生不好的印象。 這使TestOps團隊的心態變得至關重要。

TestOps工具

對於TestOps團隊來說，最重要的活動就是準確提供產品團隊測試和接收反饋所需的工具。 對於敏捷產品團隊和微服務的出現，出現了對新型測試基礎架構的需求，而不是傳統模型，其中測試環境取決於整個應用程序堆棧的可用性。

最重要的是，新組建的TestOps團隊需要規劃一個工作流程。

對於DevOps，構建系統是所有團隊創建發布工件並執行較低級別測試的核心應用程序。 在功能測試工作流程方面，考慮到這些測試的長期運行並且通常很脆弱，從而阻礙了在失敗測試中完成構建是一個問題，考慮到這一點，功能測試作為構建系統的後期過程被啟動，並且因此 要求TestOps構建一個基礎架構，不僅要從DevOps系統中提示它，而且要盡可能與其集成，以便為團隊提供透明的工作流程。

圖2 - 新測試和部署工作流程，同步DevOps和TestOps工具

要充分認識到這一無縫工作流程的價值，團隊必須指定他們想要測試的內容以及何時進行測試 一個規範必須存在，TestOps可以以編程方式理解消除由人為幹涉來配置測試所引起的延遲，其中包含如下詳細信息：

• 定義運行測試的時間 - 每次提交，或者每當指定的標識符（在這種情況下，Github標簽/版本存在）及其子集

• 給定的版本/模塊/功能的測試邊界

• 測試計劃中都包含哪些技術

• 需要什麽測試運行器命令

• 這些測試將使用哪種服務模板 - 基本上需要執行這些測試的資源和環境，例如服務器，Docker鏡像等等

然後TestOps可以將這些要求轉化為在構建完成後立即開始測試，測試可以在沒有人為幹預的情況下開始，此時QA的任務是審查測試結果。

大多數團隊的功能都不足以孤立地工作，很多都依賴於外部服務。能夠確保對測試和任何消費者的變更的信心是一個挑戰，特別是當這些消費者通常不在同一位置或代碼庫時。 TestOps應該提供一種機制來配置其他模塊測試可以在後期構建中使用，以確保一致性，並在沒有人工幹預的情況下徹底根除下遊消費者的任何中斷變化。 該配置最好放置在與其他測試配置相同的位置，即前面部分中提到的測試規範。 這個規範是消除風險的另一個項目，因為產品團隊在大多數情況下應該最清楚他們所做的更改與哪些應用程序/平臺交互的部分。

TestOps文化

在DevOps和TestOps之間基礎設施的兩個方面，剩下的部分是文化上的變化，以確保所有產品團隊都能看到這個系統的好處，他們都投資於追求質量。最終的理想之處是能夠在沒有質量保證幹預的情況下發布軟件，因為整個團隊都在測試覆蓋率和質量方面投入了大量資金，DevOps / TestOps工具允許對發布狀態作出快速準確的反饋。

評估

• 由於測試和發布工具的變化，我們已經擺脫了不規則的發布時間表，我們平均每周發布兩次。 我們現在每周都會連續四次發布產品。

• 將構建自動部署到測試環境會減少從構建完成到測試的平均時間，從構建完成和測試開始到平均延遲為零，平均延遲1天，測試從構建完成後立即開始。 這使得測試版本平均提前1天準備發布。

• 測試和發布管理工具的這些優勢和其他效率提升，我們減少了交付到生產的平均時間，從平均一周到一個工作日

• Docker容器立即可用於運行測試，測試問題可以實現即時反饋

• 自開始這項工作以來，我們成本降低了20％

找到TestOps適合測試場景，而不會妨礙開發工作流程。 通過TestOps保障交付質量，確保團隊有權隨意發布，同時保持我們產品的質量水平 客戶期望。

	TestOps中文社區公眾號
	微信 : wonter
	QQ群 : 632418478

站在DevOps肩膀上的TestOps（二）