DevOps 未來，測試究竟有什麼樣的可能

Hello 大家好，第一次在 TesterHome 發帖，這個帖子主要是從 DevOps 對測試所帶來的變化層面的思考，希望能拋磚引玉，一起探討下未來測試究竟有什麼樣的可能。

測試同學在 DevOps 裡如何定位？

有人說 DevOps 其實是 DevTestOps 的縮寫，那麼測試同學在 DevOps 裡如何定位呢？實施 DevOps，需要極小的交付顆粒度，極快的交付速度。為什麼要這樣做，首先小顆粒度的上線，能最大程度的保證線上系統的穩定性。有研究表明，線上的故障 70% 以上都是變更引起的，越小的交付顆粒度，變更的程度就越小。

變更小帶來的優點就是容易測試、容易定位問題、容易回滾、影響範圍小、牽涉開發人員的精力小。這麼一來，DevOps 裡可能沒有傳統意義上的專職測試人員了，作為測試人員不要悲觀，其實也沒有傳統意義上的專職開發人員和專職運維人員了，所有人都是為了從開發到上線整個過程而負責，甚至要對更為前置的需求假設以及更為後置的價值驗證的過程負責，所有人的角色不在是固守一畝三分地，而是在更廣闊的的空間進行耕耘協同。

每個人都要讓自己的工作變得有價值、有效率、有質量

開發人員不僅僅再只是實現需求，將程式碼交付給測試同學進行部署和測試，而是要保證自己實現的程式碼是有價值的、有效率的、有質量的。開發人員不僅要高效率的程式碼實現，保證程式碼是高質量可交付給使用者的，更要讓自己實現的程式碼在產品層面有價值。無論我們的開發效率多快，質量有多高，實現很多沒有價值的程式碼是沒有任何意義的。

那麼測試同學呢？我們設想一下，在成功實踐 DevOps 後，交付顆粒度很小，交付速度很快，基本上每次就是幾行程式碼或者一兩個資料庫欄位的變更。但是這樣的變更頻率很快，有的時候甚至是連續釋出。我們很容易感覺到，要達到這樣的模式，不僅需要完備的生產環境交付系統、監控系統，業務系統也要針對基礎架構體系進行調整。但是還有一些必須的工具，我們試想一下，整個研發體系需不需要工具平臺進行支援？研發效率和質量需不需度量？研發過程需不需持續改進？我們千萬不要覺得，研發體系的工具平臺應該是運維或者其他角色來提供，度量和持續改進應該是領導來推動的。這些工作在 DevOps 其實也屬於測試同學的本職工作一部分。做好這些工作，足以使測試人員在 DevOps 體系下面有成績斐然的職業生涯和影響力。在 DevOps 體系裡，所有人都為了讓交付有高價值、高質量、高效率而努力。

任何模式都需要進行迭代和改進

當前的現狀不一定是最優的，任何模式都需要進行迭代和改進，DevOps 體系本身就是持續改進的結果，即使當前已經開展了 DevOps，仍然需要分析現狀，找到待改進點，制定目標和方向，推動團隊實施改進，我們甚至要思考 DevOps 的下一代是什麼。

極小的交付顆粒度，極快的交付速度，是手段，不是最終目的，我們的最終目的是要讓交付有高價值、高質量、高效率。所有能有助於到達我們目的得工具或者方法都是研發體系的工具平臺的範疇。為了使交付顆粒度和交付顆粒度達到一定的程度，需求、變更、版本、分支、測試用例、測試環境、部署的產生速度和顆粒度也會變化，所有的過程和產物都應該進行精細的管理，因此，首先應當對這些部分的管理進行系統化的設計和開發。

舉個簡單的例子，隨著業務的開展，應用和域名的數量越來越多，如果沒有一個系統統一的管理，那麼一段時間後這些應用和域名是做什麼的，負責人是誰，都分屬於哪些部門，呼叫數以及流量數都是多少都無從得知，有些業務甚至已經停止了，域名和應用還線上上跑著，當然這些可能適合偏運維角色的開發人員來做這個系統。

同樣的道理，我們發掘一下研發測試過程中的工具，比如測試用例的管理，DevOps 體系會怎麼影響我們的測試呢，我們的測試用例應該如何變化呢，我們肯定不希望每次迭代都維護一個龐大的用例結構，因為如果這樣的話牽扯的精力太多，根本無法做到快速交付，但是如果我們不考慮用例的結構化，我們又不希望寫的測試用例是一次性的，寫完就放到用例庫裡吃灰了，一段時間後都自己都不認識自己的測試用例了，我們希望的是測試用例是高價值、高質量、高效率的，能夠盡最大可能的複用、回顧和重構。為了達到這樣的狀態我們就要修改我們的用例管理體系和用例管理工具，例如用例的形式是什麼，由誰寫，由誰審，由誰執行，如何管理都需要進行思考和改進。

以上是很簡單結合對 DevOps 認知，對於測試未來進行發散思維式的一些思考，只是寫了個開頭，希望拋磚引玉，未來究竟有什麼樣的可能。