這是我2020年11月份寫的一篇文章，后面統計了一下，不同平臺加總的瀏覽量短期內超過了1萬次，也算是我近幾年單篇文章瀏量的高峰了。自我感覺之所以有這樣的瀏覽量，無非是起了一個略帶爭議的標題，也正趕上當時鋪天蓋地的“測試左移”。
怕有些人看了標題就產生了價值判斷，我在文章的開頭先說一下觀點：我不反對真正原始意義上得“測試左移”，我反對的是軟件測試領域故意或者非故意的把“測試左移”直接歪曲為“測試工程師左移”的歪理，從而“販賣焦慮”的人！具體的論述，看下面的文章就行了。
后面有時間我再總結一下有價值的，針對這篇文章的評論！
? ? ?緣起
所謂的“測試左移”是什么？
通過百度的搜索，國內查到“測試左移”最早的描述起始于2016年年底到2017年年初。換句話說，“測試左移”是一個新概念。
最初在談到“測試左移”這個概念時候，更多是指軟件研發過程中的測試活動應盡早介入。
圖一 ?測試左移
上面這張圖描述了測試左移的基本原理。即軟件研發生命周期中的缺陷大部分是在編碼過程中引入的，但是發現這些缺陷通常是在編碼之后才逐步的發現出來。如果在編碼過程中發現和修復缺陷的成本是1X，那發布給用戶后，則發現缺陷和修復的成本會增長為640X。這也就引出了，如果我們提早做測試工作即“測試左移”，則發現或修復缺陷的成本會顯著的降低。這也就是“測試左移”的理論基礎。
如果你足夠細心，這張網絡流傳的圖還有個問題，即它默認缺陷的注入是從編碼開始的，不過真實的情況只要有人開始參與了研發工作（如需求分析，設計等），就勢必會開始注入缺陷，在這里我們就不累述了。
需要注意的是，最早開始說的“測試左移”這個概念是指測試工作要提前做，而不是特指測試工程師“左移”即全職測試工程師從編碼階段介入，這兩者是有區別的!區別我們放到后面再闡述。
“測試左移”雖然提出時間不長，但這是個新概念嗎？
大家所熟悉的軟件工程瀑布模型（waterfall model）概念，起源于 Winston Royce 發表于 1970 年的著名文章 "Managing the Developmentof Large Software Systems" (Proc. Westcon, IEEE CS Press, 1970, pp.328-339)。
圖二：瀑布模型
在我看來，所謂的“測試左移”正是在彌補瀑布模型的不足，即不要讓測試工作只成為交付前的最后且唯一的質量保障手段，應該往前提，需要貫穿于整個軟件研發生命周期中。
但是請注意，瀑布模型是1970年提出的，距今已經有50多年了，這么大的一個問題，怎么會幾年前才給出個答案？
經典的V模型早把這件事情說完了！
V模型是由Paul Rook在1980年率先提出的，在1990年出現在英國國家計算中心的出版物中，它是對瀑布模型的一種改進。
圖三：V模型
在這里我不想解釋V模型，有興趣可以在網絡上自行查詢。
我想說的是，測試工作從需求開始，貫穿于整個軟件研發周期是40年前就提出來的，這壓根就不是啥新概念，如果你最近才知道那是你的問題！
那為什么近期換了個說法，又提出了“測試左移” ？
測試左移一詞（shift-left testing）最早出現在Arthur Hicken的博客里，在他的博客中提到了對測試左移的看法。
圖三：最早談到“測試左移”
原文可以訪問這個地址：https://www.stickyminds.com/article/shift-left-approach-software-testing
但是這篇文章發布時間“測試左移”在2018年，比國內開始談論的時間晚，有可能這個地址并不是首發地址，但并不影響我們的討論。
從字面意義上看，“測試左移”更多的是強調開發工程師應該在軟件研發生命周期內盡早的驗證自己代碼的正確性。注意是開發工程師自己測試自己的代碼。
在敏捷和持續交付的場景下，這個說法一點問題都沒有，任何一個工程化的軟件研發模型都在強調盡早驗證和確認（這就是著名的V&V模型），最早可以追溯到40年前的V模型。
那為什么又開始強調“測試左移”那？很簡單，一直沒做唄！沒做什么那？比如：單元測試，持續集成，單功能點驗證等。注意以上這些測試，最合適的執行的人員是開發工程師本人。
為什么一直不按照要求做那？除了怕麻煩，對交付質量要求低，后續還可以讓測試工程師代勞還能有什么原因？這也是在敏捷活動中，一直在推動開發人員自測，對自己代碼質量負責，進行TDD實踐等的核心原因！
綜上所述，最開始提出“測試左移”的本意只是再次強調開發工程師應該自己做單元測試，對自己的代碼負責，這是個老生常談的話題。新的名詞的出現，只是為了讓開發工程師再次重視起來！
那炮轟“測試左移”，到底炮轟的是什么？
截止到現在，我們并沒有發現“測試左移”的提法有什么問題，雖然“測試左移”本質上只不過重新發明了個名詞，換湯不換藥 。
可事實上并沒有這么簡單。
“測試左移”這個提法朗朗上口，隨著時間的推移，“測試左移”被曲解成“測試工程師左移”，即測試工程師應該全部變為測試開發工程師，需要具備優異的開發技能，參與到單元測試，集成測試的環節中，或者說直接取代開發工程師來進行代碼邏輯和接口的測試，通過編寫代碼測試代碼。
更有甚者甚至鼓吹，今后將不再需要不懂代碼的測試工程師，不會編碼的測試工程師將全部失業，不會有未來，手工測試終將被代碼測試代碼取代。媒體廣告中充斥著測試開發工程師，全棧測試工程師的宣傳，這一氛圍讓手工測試工程師感覺低人一等，逐步的被邊緣化，一夜之間仿佛軟件測試工作不談代碼，不談自動化就是政治不正確，就是被行業拋棄的角色。
在我的微信公眾號:領測軟件測試網 后臺，和領測老賀聊測試的QQ群中總能看到這樣的言論，以上的提法在軟件測試工程師圈子內持續的蔓延，人云亦云的結果就是制造焦慮，對自己技能的不信任，對基于功能測試，基于手工測試工作的質疑！面對開發人員不夠硬氣，總覺得低人一等，由此進入惡性循環！
為什么“測試左移”和“測試工程師左移”有巨大的，本質的區別？
我嘗試從以下幾個方面加以分析
1.?????開發工程師和測試工程師的工作目標存在巨大差異
開發工程師的工作目標是實現功能，目標相對明確，判定成功的標準也明確即目標功能實現正確。
但測試工程師的工作目標是高效的尋找軟件缺陷，需要的是風險思維和概率思維，判定測試成功的標準也不算明確，發布后的評估才是終極審判。注意這里評價測試工作的兩個維度，一個是高效，一個是缺陷。
2.?????同樣的事情，從組織的角度考慮誰做更劃算
做每件事情都有成本，標準的思考模型應該是兩利相權取其大，兩害相權取其輕。針對代碼邏輯的單元測試誰做成本最低？收效最高？當然是編寫代碼的本尊了！企業必須用最有效率的方案去獲取目標。
3.?????單功能點驗證不是測試工程師眼中的軟件測試
如果你細心觀察，你會發現大多數具有開發背景的工程師口中的軟件測試基本上都是單功能點驗證，并且他們堅持認為這就是測試的全部。作為一個有20年軟件測試經驗的測試工程師，我可以很負責任的告訴你，單功能點驗證通過只是系統化軟件測試的入口條件，絕不是測試的全部，或者在嚴格意義上來說這根本就不是軟件測試。專業的軟件測試工作研究的是功能的組合，在無窮無盡的功能組合中尋找當前場景下的最優解才是你應該追尋的目標。什么是最優解那？就是在平衡各方利益的情況下，如何最有效率的滿足既定的質量目標！
理想情況下，我們拿到的軟件就應該是一個單功能點驗證通過的產品。換句話說，單功能點驗證應該是開發工程師的職責！只有這樣，專業的測試工程師才能發揮最大的效用。
如果你的公司只做單功能點驗證，或者說絕大多數工作都是單功能點驗證，我可以明確地跟你說，你做的不是專業測試工作。你測試的產品質量一定很差！你需要系統的學習一下軟件測試到底怎么做。
綜上所述，開發的測試和測試的測試根本就是兩個概念，單元測試本就應該由開發工程師完成，單功能點的驗證不能是測試的全部，專業的測試工程師要具備風險思維，要做基于風險的測試覆蓋。
讓功能測試工程師集體轉型做單元測試，并稱為“測試左移”：“不是傻就是壞”！
測試工程師不需要了解代碼嗎？
基于代碼測試代碼的自動化測試可以取代專業的功能組合測試嗎？
很遺憾，至少目前不行。
目前的自動化測試技術是將手工測試用例中，適合重復執行或數據驅動的用例抽取出來，并將其自動化執行?；谶@個原理，所以自動化測試通常是手工測試的最小用例集，是用來做質量的最低防火墻的。
出于成本考慮，在很多場景下，手工測試的成本也會遠遠小于自動化的成本。所以也沒有道理將所有的手工測試自動化。
再有，例如發現Bug能力超強的探索性測試技術，本身就不需要提前規劃測試路徑，從原理上說自動化測試是不可能替代探索性測試的。
MBT基于模型的測試技術，至少目前看還不可能建模后做全遍歷覆蓋，這樣會造成用例爆炸。
基于AI進行自主學習的測試，現在并沒有看到可以實用的解決方案。還處于探索，研究階段，對此我也保持謹慎樂觀。
說了這么多，無非是想說明，依靠代碼測試代碼，測試開發工程師能解決的問題有限，不可能完全取代手工測試工程師。
如果你的企業真的是這么做的，我想請你思考一下，目前你的企業軟件產品的質量高嗎？是不是對發布質量要求比較低？后期主要依賴用戶發現？如果是的話，這是個特例，并不是普遍情況，而且以互聯網應用為主，客戶對發布質量不敏感。
為什么說“測試左移”是個偽概念
首先，最前面已經提及“測試左移”不是新概念，只是對幾十年前原有理論的一個重新命名而已！
其次，“測試左移”與“測試工程師左移”是完全不同的。
第三點，與其現在持續強調“測試左移”帶來的誤解，為什么不強調“開發右移”。讓開發工程師意識到單元測試，單功能點測試是開發工作的一部分，不能，也不應該讓測試工程師替你來完成。因為只有如此，測試工程師才能將精力集中在真正的測試工作上面來。當開發抱怨測試技術含量低，測試效果不好的時候，測試工程師沒有將工作重點放到真正的測試工作上來才是癥結所在！
第四點，具體到應該“測試左移”還是“測試右移”，我想分歧無非是“單元測試”和“單功能點測試”誰來測？也可能很多企業還上升不到這個高度，因為壓根就不測！我的觀點是：當然測比不測強，但是如果現在是測試工程師進行的單功能點測試，我想請你意識到，這不是測試工作，或者說這不是測試工作的全部。如果你的企業想讓軟件質量上一個臺階，請你們有體系，有步驟的將這項工作轉移到研發部門。也就是開始強調“開發右移”！
第五點，請別跟我談敏捷，就這件事情上來說沒什么區別。開發人員必須完成自己的測試工作，請“開發右移”。
第六點，所謂的測試工程師的“測試左移”是提高了質量還是降低了質量？
短期看似提高（因為以前沒人做的事情有人做了），但長期穩步下降（因為質量的第一責任人開發工程師放棄了這部分工作）。
誰的職責就是誰的職責！可以協助、教，但是絕不能替代！（所謂的教就是敏捷中的測試教練的工作）。
貫穿于全生命周期的軟件測試，不意味著全生命周期的軟件測試工作均由全職測試工程師完成，不同角色應該完成各自意義上的測試工作。
請諸位測試工程師充分的意識到：軟件測試工程師是為質量服務，不是為軟件開發工程師服務，具體的任何一項測試工作都是手段，你的目標是建立一個集合所有角色的質量保證或者說測試體系。所有角色分工協作，才能共同有效的保證質量。
醒醒吧：軟件測試和軟件開發處理的問題不一樣，不要自怨自艾！到底是測試做的不好，水平太低，還是你理解的測試壓根就不對？
用正確測試理念武裝起來的，硬氣的測試工程師對企業才有價值！
放棄能效比談質量都是耍流氓
我們前面分析了大量開發工程師應該保證自己代碼質量的原因?？赡苡腥藭?，你說開發人員自測自己的代碼，保證單功能點的正確性姑且算你正確。但是“測試左移”說的是提早測試，這個提早測試并不唯一指單元測試、集成測試，還包括對需求的測試??！“測試左移”泛指專業的測試工程師應該從需求階段開始介入，這總不會有問題吧？如果沒有問題，怎么能說“測試左移”或者說“測試工程師左移”是偽概念那？
這個問題很好，所以我放到最后討論這個話題。先說一下我的結論，全職測試工程師從需求開始介入，可以認為是測試工程師左移的一個好的實踐，但是不是一個所有企業都普遍適用的最佳實踐那？我看未必！
為什么“測試左移”或者說“測試工程師左移”是偽概念
為了說清楚這個話題，我們從如下幾點加以說明：
首先，我們要區分測試工作和全職測試工程師的工作，測試工作廣義上指驗證和確認工作，可能由專職的測試工程師完成，也可能由團隊中更合適的角色來完成。具體由誰來完成，需要組織綜合考慮：技能適配性、溝通成本、職業發展、效率最優、成本最低等制約要素。
“測試工程師從需求階段介入”是不是一個好的實踐。
如果測試工程師從需求階段介入，對測試工程師的技能有沒有特殊要求那？答案是肯定的，當然有！
- 第一，??在需求階段介入的測試工程師要對業務非常熟悉，至少是個業務專家，對業務的理解不能弱于需求分析師，否則根本沒有辦法進行對等的交流。
- 第二，??在需求階段介入的測試工程師要對需求文檔的書寫技能和語言邏輯很清楚，這樣才能參與到需求的獲取和評審工作中來。
- 第三，??在需求階段介入的測試工程師要有很強的溝通技能，這個階段的工作很多是從溝通交流中切入的。
- 第四，??在需求階段介入的測試工程師要有很強的測試分析和設計能力，因為這就是他此時介入的分內工作。
綜上所述，在需求階段介入的測試工程師是整個測試團隊中核心中的核心！
那在需求階段介入的測試工程師在這個階段具體的產出物是什么那？
如果在需求評審之前介入的話，老實說，沒有什么硬性的產出物，更多的是提前對系統需求進行了解。提出后續測試工作要點和組織方式的規劃，由于需求文檔也沒有完全定稿，所以當前所有的工作都存在被推翻的可能性。
如果在需求評審中或需求評審通過后介入的話，更多的是作為需求評審人員參與需求評審工作，綜合需求和其它文檔等，進行測試的分析和設計，這里是有明確產出物的。但是請一定注意，測試人員如果參與需求評審工作，你首先是個業務專家，可以為需求評審貢獻一份綿薄之力，其次你才是測試工程師，從系統的可測試性思考需求的問題。千萬不要搞反了！需求工作的第一責任人是需求分析師，切記！
綜上所述，如果作為質量的負責人，你應該如何選擇？讓測試工程師從需求評審前，評審中，評審后那個階段介入更合理那？
這里并沒有唯一或者最佳實踐，你要綜合考慮成本，環境，技術，風險，投入產出比等制約條件，綜合考慮。
我的建議是：最早評審完成后介入，或者推遲到系統測試開始之前介入，主要是從投入產出比的角度考慮。當然，每個組織對質量的期望是不同的，需要按照自己的實際質量目標進行綜合考慮。
就這個話題來說，我們談論的范圍并沒有超過幾十年前V模型涵蓋的內容，如果說這就是最“先進”的“測試左移”理念，我表示不服！
總結一下
放棄成本談質量，就是耍流氓！合理的團隊協作模型，讓組織效率整體提升，過程質量、產品質量雙提高才應該是追求的目標！
對在軟件測試圈內“販賣焦慮”說不！
軟件測試領域是個專業的領域，作為這個行業的從業者，我們應該系統化我們的測試體系，用正確的測試理念武裝自己。
我們構建的是一個基于風險，基于概率思維的質量評估體系，技術手段是為測試目標服務的。
???????專業的軟件測試不能脫離整體的覆蓋率談測試技術。
文章評論