DevOps會導致測試人員失業，何去何從(上)

07-15

來自專欄性能測試5 人贊了文章

DEVOPS 是什麼鬼

DevOps可以看做是敏捷開發模式的延伸，將持續集成（CI）、持續部署、持續交付（CD）擴展到運維，打通開發與運維之前的壁壘，在整個生命周期中消除傳統的孤島，促進研發與運維的協作，從而縮短軟體產品交付周期，提高軟體服務質量。

DevOps強調構建、測試、部署和運維等工作的高度自動化，構建工具鏈或自動化全覆蓋的持續研發的方法和工具，讓基礎設施、運維也成為產品代碼的一部分，能夠實現持續設計、持續編程、持續構建、持續測試、持續發布、持續部署、持續監控（持續-X / C-X實踐）等，能夠及早發現並更快修復缺陷，整個研發更具透明性、運維環境更加穩定，實現越來越快的軟體交付，減少協作、測試和溝通成本。

這裡給出一組數據，不管你信不信：相對低性能的同行，高性能的IT組織遇到的失效減少為60分之一，失敗後恢復的速度提高到168倍、部署頻率提高到30多倍、從研發周期縮短為原來的200分之一。

隨著DevOps實踐的興起，測試需求正在下降。這個觀點的支撐是：自動化方法已經足夠先進，在整個研發、發布和運維過程中在很大程度上人為干預可以逐步減少，先進的、高度自動化的技術解決方案的速度和效率勝過了傳統的、基於流程改進的QA/測試方法。

與之相反的觀點，認為DevOps只是一個概念，上述想法只是理論上一種理想，難以落地實施。許多互聯網企業由於能力和資源等限制做不了自動化全覆蓋，而且工具發現缺陷的能力比較弱，即使能發現60～80%的缺陷，還有20～40%的缺陷會遺留到上線後，這樣的質量對大多數應用（更不要說像銀行、電信等關鍵系統）根本不能接受。其次，如果需求定義不規範、不可測或者需求不穩定，自動化測試就很難，還有諸如UI、移動體驗之類的組件呈現出許多不可控或不確定的因素，這對於自動化測試來說更具挑戰性，而人類測試者卻很容易地完成這類測試（UI測試和易用性測試），自動化的代價反而大得多。再者，DevOps只能適用於SaaS（Software asa Service, 軟體即服務）這類軟體的研發與運維，非SaaS的軟體研發很難採用。不同類型的產品、不同的用戶和不同的研發團隊，採用的軟體開發模式和實踐千差萬別，DevOps在許多場合是不適用的，而適合自己的開發模式和實踐才是最好的。

但是如果公司（如非關鍵系統的SaaS公司）採用了DevOps模式，有沒有可能徹底消滅傳統意義的軟體測試專職人員？

如果能，軟體研發是怎樣的一道風景？

如果不能，軟體測試或QA的地位是不是會下降？

DevOps這個名字繞過了「測試」，也許是對的，更強調「質量是構建的」。但做測試、做QA的人們一定會有意見，希望將DevOps改為DevQAOps，以糾正DevOps忽視QA的問題，有沒有這個必要？甚至有沒有必要增加一個新術語TestOps？可能都沒有必要，徹底的DevOps也許是未來研發的趨勢。

1. 適合採用DevOps的企業，傳統意義的軟體測試人員可以消失嗎？

這完全是有可能的。Google、微軟和一些歐美公司等的實踐證明這是可行的。他們去掉了專職測試人員，

沒有「TestEngineer」角色，而是採用「測試開發工程師

或全棧測試架構師」，或乾脆像微軟公司那樣都叫軟體工程師（Software Engineer，SE），你要知道，2014年前，微軟公司還有一萬多專制的測試工程師，而今天他們已經消失了，成為軟體工程師。Google的SET (Software Engineer in test) 實際上也是一個開發角色，谷歌在我國有幾百研發人員，但測試開發只有幾十個。他們（SDET、SE、SET等）做的事情已經不同於傳統的測試人員所做的事情，而是：

需求分析

測試環境搭建和部署；

自動構建與集成

協調組織和指導團隊制定自動化測試

定位瓶頸，指導優化改善瓶頸

跟全棧性能很像，請期待魯德相關DEVOPS新書

……