軟體測試也出現內捲了？！測試行業的內卷究竟是什麼？

內卷，是現在熱度非常高的一個詞彙，隨著熱度不斷攀升，隱隱有了“萬物皆可卷”的程度。究其來源，內卷這個詞的出現，是伴隨著996開始討論的。很不幸，996、福報等等這些詞的重災區和源頭就是計算機/網際網路行業。那麼作為行業中一個非常重要的分支，測試圈的情況怎麼樣呢?加我VX：atstudy-js 回覆“測試”，進入軟體測試學習交流裙~~

在談起測試圈的內卷之前，我們必須先搞清楚我們常說的內卷是什麼。

一、軟體測試圈的內卷是怎樣的?

內卷，網路流行詞，本意是指人類社會在一個發展階段達到某種確定的形式後，停滯不前或無法轉化為另一種高階模式的現象。當社會資源無法滿足所有人的需求時，人們透過競爭來獲取更多資源。

後經網路流傳，用來指代非理性的內部競爭或“被自願”競爭，現在指同行間競相付出更多努力以爭奪有限資源，從而導致個體“收益努力比”下降的現象。可以看作是努力的“通貨膨脹”。

在測試圈，隨著基於敏捷甚至是Devops的架構，作為這些架構重要內容的自動化成為了熱門，而測試行業也進入了推廣自動化的“軍備競賽”。近些年來，不管是作為測試工程師，還是敏捷QA，甚至是其他角色，恐怕都對於自動化測試的洶湧之勢都有所耳聞，而從公司角度，在諸多公司中，自動化測試藉著敏捷轉型的要求也都幾乎成為了測試工作的標配，各大公司對於測試的招聘要求也紛紛升級成為自動化測試，彷佛只要有了自動化測試，一切問題就迎刃而解。事實真的是這樣嗎?

有一個“電影院困境”，很形象地說明了“內卷”的表現和身處其中的人們的感受：一個電影院裡正在播放電影，觀眾席中黑壓壓地坐滿了觀眾，這時，前面有人為了看得更清楚，站起來看電影，於是後面的人為了不被擋住，於是也站了起來……終於電影院裡所有人都站著看完了電影。而本來他們是可以很舒服地看完這部電影的。

在這個環境下，每個人都付出了極高的時間成本和精力，但是獲得的收益卻十分有限。同樣的，在測試領域中，按照測試分層測試金字塔進行組合的架構遭到了一定的衝擊和破壞。由內卷化而形成的行業內“納什均衡”所帶來的35歲現象等等，成為附著在這個行業上的傷痕和毒瘤。這個問題以後專門會提到，這次只談一下測試技術本身的內卷。

二、軟體測試的技術內卷

敏捷測試中，有一個分層測試策略，一般來測試分為三個層次，分別是UI層、Service層以及Unit層。具體結構如下圖：

UI層是負責介面展示和使用者互動的那一層，也是測試工程師最常接觸到的部分，大量的測試是在這一層完成的，也是涉及方面最廣的測試層。Service層提供介面和服務，UI層可以從Service層獲取資料，也可以透過Service層將資料儲存於資料庫或其他儲存空間裡。Unit層的測試物件是函式或方法;Service層的測試物件是模組和介面;UI層的主要測試物件是展示和互動。

這是一個非常完整且工作效率極高的分層機制，它將不同功能和類別的內容進行了歸類化，使得針對每一層的測試，都有相應的手段和途徑進行相應的測試。這是基於敏捷框架或者模型下，測試作為適應模型的基礎進行的改變。針對不同層級，測試工程師用不同側重點的測試工具或測試方法，來進行搭配組合，獲得最高效和最全覆蓋的測試。

當前，自動化測試成為了一個熱點，所有的測試工作都開始向自動化轉型，而本身只是測試工作一個重要組成部分的自動化測試，瞬間彷彿成為了測試工作升級更新轉型的唯一內容，而其簡單高效的衡量方式，也使得自動化測試成為了KPI和OKR的青睞物件。

最明顯的是，按照自動化測試金字塔理論，大量的基礎工作是在單元測試階段進行的，而介面測試是基於單元測試完成，然後最終透過UI測試進行介面化的驗證。這個三角形是自動化測試的策略結構。

單元測試

單元測試要求在開發中對每個功能模組(函式、類方法)進行測試，如檢測其中某一項功能是否按預期要求正常執行。單元測試中通常採用白盒測試，主要對程式碼內部邏輯結構進行測試。

介面測試

介面測試要求對資料傳輸、資料庫效能等進行測試，從而保證資料傳輸以及處理的完整性。介面功能的完整運作對整個專案功能擴充套件、升級與維護有著重要的作用，介面測試通常使用黑盒測試和白盒測試相結合的方式進行。

UI測試

UI測試以使用者體驗為主，軟體的所有功能都是透過這一層展示給使用者的，因此UI測試的工作也很重要。

單元測試由於大量涉及白盒測試，更基礎的方面則是由人員進行程式碼走查或程式碼review來完成，而Service則是部分採用人工進行，而UI介面以最終的使用者體驗為主，因此在UI測試中並不是100%地使用自動化測試，其中需要人工操作來確定UI介面的易用程度。由此可見，這樣的金字塔策略，依然不能完全捨棄手動測試在整個測試工作中的重要作用。

需要注意的是，很多鼓吹測試全面自動化的管理人員，甚至沒有細細區分這兩個圖例的差異，就簡單地將二者合一，將自動化測試策略和分層測試策略進行了混淆。

在開發人員陷入針對框架和前端機制無休止地更新追求下，內卷也逐漸向測試圈進行擴充套件，但是和開發中單純求新求快的情況又略有不同。當決策層的好大喜功和自動化測試的特點結合起來的時候，簡單粗暴地大幹快上成了唯一的選擇，於是，測試技術的內卷就這樣轟轟烈烈地開始了。加我VX：atstudy-js 回覆“測試”，進入軟體測試學習交流裙~~

三、測試員如何從內卷中走出來?

測試工程師不得不花費大量的精力，進行自動化測試的改造和框架搭建，而這樣的“大幹快上”又忽略了自動化測試本身的一些要求。例如：需求相對穩定，有充足的用例庫，交付時間允許專案進行自動化改造等等。造成的一大結果就是，行業中大量的測試工程師變成了以寫測試程式碼為主要工作的工作人員，甚至在職業認知上，將自己有意無意地同開發人員進行了混淆。

這樣的結果對於測試行業和測試工程師的職業生涯有著重大影響：首先，手工測試作為整個測試行業的基礎，地位和重要性被大大弱化，很多測試人員的基本能力被大大削弱，而後期的很多能力提升和擴充，都是需要從基於手工測試的分析和操作開始的。其次，很多測試專案並不適宜進行自動化改造，削足適履的最終結果就是對專案的測試效率等有了極大的限制，本末倒置。最後，當所有的測試聚焦在自動化上時，會陷入對於技術棧本身的更新和迭代。對於程式碼能力的提升，顯然是一個相對更容易出成果的路徑。這樣無法將焦點集中在業務本身，這對於測試人員本身能力的發展是極為不利的。

在測試工作中，原本起到規範和框架作用的敏捷架構，就不可避免地受到內卷的影響，其中對於測試質量和測試覆蓋率具有極強規範和限制能力的測試用例，會被大大弱化，大量的測試工程師會主動或被動地向測試開發工程師轉型，由原本聚焦在基於業務的測試用例等方面，轉向對於自動化測試架構與指令碼的打磨和迭代。當聚焦點從業務移開時，測試工作本身的壓艙石——質量，就會不可避免地受到影響。

另外，測試工程師的職業要求，在多方面都有體現，但這樣的內卷會使得整個行業的從業人員將注意力向程式碼能力集中，從而陷入盲目追求程式碼能力，而不重視測試能力提升基礎的怪圈裡。當形成這樣的惡性迴圈之後，測試圈的發展會受到極大衝擊，而對於圈中的測試工程師來說，測試技能和測試理念的更新會受到極大的干擾。

不忘初心，方得始終。在技術浪潮不斷更新迭代的今天，測試工程師也應該做到“不忘初心”，所謂形而上者謂之“道”，在意識方面，始終將業務需求作為工作的基準，把握住質量核心，需求基準;形而下者謂之“器”，不管是手工測試，還是自動化測試，抑或是探索性測試，都是要基於“道”這個初心，圍繞著測試工作服務的。只有這樣，測試工程師才能在測試圈不斷內生或外壓的內卷中，走出屬於自己的職業道路。