這是我2020年11月份寫(xiě)的一篇文章，后面統計了一下，不同平臺加總的瀏覽量短期內超過(guò)了1萬(wàn)次，也算是我近幾年單篇文章瀏量的高峰了。自我感覺(jué)之所以有這樣的瀏覽量，無(wú)非是起了一個(gè)略帶爭議的標題，也正趕上當時(shí)鋪天蓋地的“測試左移”。

怕有些人看了標題就產(chǎn)生了價(jià)值判斷，我在文章的開(kāi)頭先說(shuō)一下觀(guān)點(diǎn)：我不反對真正原始意義上得“測試左移”，我反對的是軟件測試領(lǐng)域故意或者非故意的把“測試左移”直接歪曲為“測試工程師左移”的歪理，從而“販賣(mài)焦慮”的人！具體的論述，看下面的文章就行了。

后面有時(shí)間我再總結一下有價(jià)值的，針對這篇文章的評論！

所謂的“測試左移”是什么？

通過(guò)百度的搜索，國內查到“測試左移”最早的描述起始于2016年年底到2017年年初。換句話(huà)說(shuō)，“測試左移”是一個(gè)新概念。

最初在談到“測試左移”這個(gè)概念時(shí)候，更多是指軟件研發(fā)過(guò)程中的測試活動(dòng)應盡早介入。

圖一 ?測試左移

上面這張圖描述了測試左移的基本原理。即軟件研發(fā)生命周期中的缺陷大部分是在編碼過(guò)程中引入的，但是發(fā)現這些缺陷通常是在編碼之后才逐步的發(fā)現出來(lái)。如果在編碼過(guò)程中發(fā)現和修復缺陷的成本是1X，那發(fā)布給用戶(hù)后，則發(fā)現缺陷和修復的成本會(huì )增長(cháng)為640X。這也就引出了，如果我們提早做測試工作即“測試左移”，則發(fā)現或修復缺陷的成本會(huì )顯著(zhù)的降低。這也就是“測試左移”的理論基礎。

如果你足夠細心，這張網(wǎng)絡(luò )流傳的圖還有個(gè)問(wèn)題，即它默認缺陷的注入是從編碼開(kāi)始的，不過(guò)真實(shí)的情況只要有人開(kāi)始參與了研發(fā)工作（如需求分析，設計等），就勢必會(huì )開(kāi)始注入缺陷，在這里我們就不累述了。

需要注意的是，最早開(kāi)始說(shuō)的“測試左移”這個(gè)概念是指測試工作要提前做，而不是特指測試工程師“左移”即全職測試工程師從編碼階段介入，這兩者是有區別的!區別我們放到后面再闡述。

“測試左移”雖然提出時(shí)間不長(cháng)，但這是個(gè)新概念嗎？

大家所熟悉的軟件工程瀑布模型（waterfall model）概念，起源于 Winston Royce 發(fā)表于 1970 年的著(zhù)名文章 "Managing the Developmentof Large Software Systems" (Proc. Westcon, IEEE CS Press, 1970, pp.328-339)。

圖二：瀑布模型

在我看來(lái)，所謂的“測試左移”正是在彌補瀑布模型的不足，即不要讓測試工作只成為交付前的最后且唯一的質(zhì)量保障手段，應該往前提，需要貫穿于整個(gè)軟件研發(fā)生命周期中。
但是請注意，瀑布模型是1970年提出的，距今已經(jīng)有50多年了，這么大的一個(gè)問(wèn)題，怎么會(huì )幾年前才給出個(gè)答案？

經(jīng)典的V模型早把這件事情說(shuō)完了！

V模型是由Paul Rook在1980年率先提出的，在1990年出現在英國國家計算中心的出版物中，它是對瀑布模型的一種改進(jìn)。

圖三：V模型

在這里我不想解釋V模型，有興趣可以在網(wǎng)絡(luò )上自行查詢(xún)。

我想說(shuō)的是，測試工作從需求開(kāi)始，貫穿于整個(gè)軟件研發(fā)周期是40年前就提出來(lái)的，這壓根就不是啥新概念，如果你最近才知道那是你的問(wèn)題！

那為什么近期換了個(gè)說(shuō)法，又提出了“測試左移” ？

測試左移一詞（shift-left testing）最早出現在A(yíng)rthur Hicken的博客里，在他的博客中提到了對測試左移的看法。

圖三：最早談到“測試左移”

原文可以訪(fǎng)問(wèn)這個(gè)地址：https://www.stickyminds.com/article/shift-left-approach-software-testing

但是這篇文章發(fā)布時(shí)間“測試左移”在2018年，比國內開(kāi)始談?wù)摰臅r(shí)間晚，有可能這個(gè)地址并不是首發(fā)地址，但并不影響我們的討論。

從字面意義上看，“測試左移”更多的是強調開(kāi)發(fā)工程師應該在軟件研發(fā)生命周期內盡早的驗證自己代碼的正確性。注意是開(kāi)發(fā)工程師自己測試自己的代碼。

在敏捷和持續交付的場(chǎng)景下，這個(gè)說(shuō)法一點(diǎn)問(wèn)題都沒(méi)有，任何一個(gè)工程化的軟件研發(fā)模型都在強調盡早驗證和確認（這就是著(zhù)名的V&V模型），最早可以追溯到40年前的V模型。

那為什么又開(kāi)始強調“測試左移”那？很簡(jiǎn)單，一直沒(méi)做唄！沒(méi)做什么那？比如：單元測試，持續集成，單功能點(diǎn)驗證等。注意以上這些測試，最合適的執行的人員是開(kāi)發(fā)工程師本人。

為什么一直不按照要求做那？除了怕麻煩，對交付質(zhì)量要求低，后續還可以讓測試工程師代勞還能有什么原因？這也是在敏捷活動(dòng)中，一直在推動(dòng)開(kāi)發(fā)人員自測，對自己代碼質(zhì)量負責，進(jìn)行TDD實(shí)踐等的核心原因！

綜上所述，最開(kāi)始提出“測試左移”的本意只是再次強調開(kāi)發(fā)工程師應該自己做單元測試，對自己的代碼負責，這是個(gè)老生常談的話(huà)題。新的名詞的出現，只是為了讓開(kāi)發(fā)工程師再次重視起來(lái)！

那炮轟“測試左移”，到底炮轟的是什么？

截止到現在，我們并沒(méi)有發(fā)現“測試左移”的提法有什么問(wèn)題，雖然“測試左移”本質(zhì)上只不過(guò)重新發(fā)明了個(gè)名詞，換湯不換藥 。

可事實(shí)上并沒(méi)有這么簡(jiǎn)單。

“測試左移”這個(gè)提法朗朗上口，隨著(zhù)時(shí)間的推移，“測試左移”被曲解成“測試工程師左移”，即測試工程師應該全部變?yōu)闇y試開(kāi)發(fā)工程師，需要具備優(yōu)異的開(kāi)發(fā)技能，參與到單元測試，集成測試的環(huán)節中，或者說(shuō)直接取代開(kāi)發(fā)工程師來(lái)進(jìn)行代碼邏輯和接口的測試，通過(guò)編寫(xiě)代碼測試代碼。

更有甚者甚至鼓吹，今后將不再需要不懂代碼的測試工程師，不會(huì )編碼的測試工程師將全部失業(yè)，不會(huì )有未來(lái)，手工測試終將被代碼測試代碼取代。媒體廣告中充斥著(zhù)測試開(kāi)發(fā)工程師，全棧測試工程師的宣傳，這一氛圍讓手工測試工程師感覺(jué)低人一等，逐步的被邊緣化，一夜之間仿佛軟件測試工作不談代碼，不談自動(dòng)化就是政治不正確，就是被行業(yè)拋棄的角色。

在我的微信公眾號:領(lǐng)測軟件測試網(wǎng) 后臺，和領(lǐng)測老賀聊測試的QQ群中總能看到這樣的言論，以上的提法在軟件測試工程師圈子內持續的蔓延，人云亦云的結果就是制造焦慮，對自己技能的不信任，對基于功能測試，基于手工測試工作的質(zhì)疑！面對開(kāi)發(fā)人員不夠硬氣，總覺(jué)得低人一等，由此進(jìn)入惡性循環(huán)！

為什么“測試左移”和“測試工程師左移”有巨大的，本質(zhì)的區別？

我嘗試從以下幾個(gè)方面加以分析

1.?????開(kāi)發(fā)工程師和測試工程師的工作目標存在巨大差異

開(kāi)發(fā)工程師的工作目標是實(shí)現功能，目標相對明確，判定成功的標準也明確即目標功能實(shí)現正確。

但測試工程師的工作目標是高效的尋找軟件缺陷，需要的是風(fēng)險思維和概率思維，判定測試成功的標準也不算明確，發(fā)布后的評估才是終極審判。注意這里評價(jià)測試工作的兩個(gè)維度，一個(gè)是高效，一個(gè)是缺陷。

2.?????同樣的事情，從組織的角度考慮誰(shuí)做更劃算

做每件事情都有成本，標準的思考模型應該是兩利相權取其大，兩害相權取其輕。針對代碼邏輯的單元測試誰(shuí)做成本最低？收效最高？當然是編寫(xiě)代碼的本尊了！企業(yè)必須用最有效率的方案去獲取目標。

3.?????單功能點(diǎn)驗證不是測試工程師眼中的軟件測試

如果你細心觀(guān)察，你會(huì )發(fā)現大多數具有開(kāi)發(fā)背景的工程師口中的軟件測試基本上都是單功能點(diǎn)驗證，并且他們堅持認為這就是測試的全部。作為一個(gè)有20年軟件測試經(jīng)驗的測試工程師，我可以很負責任的告訴你，單功能點(diǎn)驗證通過(guò)只是系統化軟件測試的入口條件，絕不是測試的全部，或者在嚴格意義上來(lái)說(shuō)這根本就不是軟件測試。專(zhuān)業(yè)的軟件測試工作研究的是功能的組合，在無(wú)窮無(wú)盡的功能組合中尋找當前場(chǎng)景下的最優(yōu)解才是你應該追尋的目標。什么是最優(yōu)解那？就是在平衡各方利益的情況下，如何最有效率的滿(mǎn)足既定的質(zhì)量目標！

理想情況下，我們拿到的軟件就應該是一個(gè)單功能點(diǎn)驗證通過(guò)的產(chǎn)品。換句話(huà)說(shuō)，單功能點(diǎn)驗證應該是開(kāi)發(fā)工程師的職責！只有這樣，專(zhuān)業(yè)的測試工程師才能發(fā)揮最大的效用。

如果你的公司只做單功能點(diǎn)驗證，或者說(shuō)絕大多數工作都是單功能點(diǎn)驗證，我可以明確地跟你說(shuō)，你做的不是專(zhuān)業(yè)測試工作。你測試的產(chǎn)品質(zhì)量一定很差！你需要系統的學(xué)習一下軟件測試到底怎么做。

綜上所述，開(kāi)發(fā)的測試和測試的測試根本就是兩個(gè)概念，單元測試本就應該由開(kāi)發(fā)工程師完成，單功能點(diǎn)的驗證不能是測試的全部，專(zhuān)業(yè)的測試工程師要具備風(fēng)險思維，要做基于風(fēng)險的測試覆蓋。

讓功能測試工程師集體轉型做單元測試，并稱(chēng)為“測試左移”：“不是傻就是壞”！

測試工程師不需要了解代碼嗎？

基于代碼測試代碼的自動(dòng)化測試可以取代專(zhuān)業(yè)的功能組合測試嗎？

很遺憾，至少目前不行。

目前的自動(dòng)化測試技術(shù)是將手工測試用例中，適合重復執行或數據驅動(dòng)的用例抽取出來(lái)，并將其自動(dòng)化執行?；谶@個(gè)原理，所以自動(dòng)化測試通常是手工測試的最小用例集，是用來(lái)做質(zhì)量的最低防火墻的。

出于成本考慮，在很多場(chǎng)景下，手工測試的成本也會(huì )遠遠小于自動(dòng)化的成本。所以也沒(méi)有道理將所有的手工測試自動(dòng)化。

再有，例如發(fā)現Bug能力超強的探索性測試技術(shù)，本身就不需要提前規劃測試路徑，從原理上說(shuō)自動(dòng)化測試是不可能替代探索性測試的。

MBT基于模型的測試技術(shù)，至少目前看還不可能建模后做全遍歷覆蓋，這樣會(huì )造成用例爆炸。

基于A(yíng)I進(jìn)行自主學(xué)習的測試，現在并沒(méi)有看到可以實(shí)用的解決方案。還處于探索，研究階段，對此我也保持謹慎樂(lè )觀(guān)。

說(shuō)了這么多，無(wú)非是想說(shuō)明，依靠代碼測試代碼，測試開(kāi)發(fā)工程師能解決的問(wèn)題有限，不可能完全取代手工測試工程師。

如果你的企業(yè)真的是這么做的，我想請你思考一下，目前你的企業(yè)軟件產(chǎn)品的質(zhì)量高嗎？是不是對發(fā)布質(zhì)量要求比較低？后期主要依賴(lài)用戶(hù)發(fā)現？如果是的話(huà)，這是個(gè)特例，并不是普遍情況，而且以互聯(lián)網(wǎng)應用為主，客戶(hù)對發(fā)布質(zhì)量不敏感。

為什么說(shuō)“測試左移”是個(gè)偽概念

首先，最前面已經(jīng)提及“測試左移”不是新概念，只是對幾十年前原有理論的一個(gè)重新命名而已！

其次，“測試左移”與“測試工程師左移”是完全不同的。

第三點(diǎn)，與其現在持續強調“測試左移”帶來(lái)的誤解，為什么不強調“開(kāi)發(fā)右移”。讓開(kāi)發(fā)工程師意識到單元測試，單功能點(diǎn)測試是開(kāi)發(fā)工作的一部分，不能，也不應該讓測試工程師替你來(lái)完成。因為只有如此，測試工程師才能將精力集中在真正的測試工作上面來(lái)。當開(kāi)發(fā)抱怨測試技術(shù)含量低，測試效果不好的時(shí)候，測試工程師沒(méi)有將工作重點(diǎn)放到真正的測試工作上來(lái)才是癥結所在！

第四點(diǎn)，具體到應該“測試左移”還是“測試右移”，我想分歧無(wú)非是“單元測試”和“單功能點(diǎn)測試”誰(shuí)來(lái)測？也可能很多企業(yè)還上升不到這個(gè)高度，因為壓根就不測！我的觀(guān)點(diǎn)是：當然測比不測強，但是如果現在是測試工程師進(jìn)行的單功能點(diǎn)測試，我想請你意識到，這不是測試工作，或者說(shuō)這不是測試工作的全部。如果你的企業(yè)想讓軟件質(zhì)量上一個(gè)臺階，請你們有體系，有步驟的將這項工作轉移到研發(fā)部門(mén)。也就是開(kāi)始強調“開(kāi)發(fā)右移”！

第五點(diǎn)，請別跟我談敏捷，就這件事情上來(lái)說(shuō)沒(méi)什么區別。開(kāi)發(fā)人員必須完成自己的測試工作，請“開(kāi)發(fā)右移”。

第六點(diǎn)，所謂的測試工程師的“測試左移”是提高了質(zhì)量還是降低了質(zhì)量？

短期看似提高（因為以前沒(méi)人做的事情有人做了），但長(cháng)期穩步下降（因為質(zhì)量的第一責任人開(kāi)發(fā)工程師放棄了這部分工作）。

誰(shuí)的職責就是誰(shuí)的職責！可以協(xié)助、教，但是絕不能替代！（所謂的教就是敏捷中的測試教練的工作）。

貫穿于全生命周期的軟件測試，不意味著(zhù)全生命周期的軟件測試工作均由全職測試工程師完成，不同角色應該完成各自意義上的測試工作。

請諸位測試工程師充分的意識到：軟件測試工程師是為質(zhì)量服務(wù)，不是為軟件開(kāi)發(fā)工程師服務(wù)，具體的任何一項測試工作都是手段，你的目標是建立一個(gè)集合所有角色的質(zhì)量保證或者說(shuō)測試體系。所有角色分工協(xié)作，才能共同有效的保證質(zhì)量。

醒醒吧：軟件測試和軟件開(kāi)發(fā)處理的問(wèn)題不一樣，不要自怨自艾！到底是測試做的不好，水平太低，還是你理解的測試壓根就不對？

用正確測試理念武裝起來(lái)的，硬氣的測試工程師對企業(yè)才有價(jià)值！

放棄能效比談質(zhì)量都是耍流氓

我們前面分析了大量開(kāi)發(fā)工程師應該保證自己代碼質(zhì)量的原因?？赡苡腥藭?huì )問(wèn)，你說(shuō)開(kāi)發(fā)人員自測自己的代碼，保證單功能點(diǎn)的正確性姑且算你正確。但是“測試左移”說(shuō)的是提早測試，這個(gè)提早測試并不唯一指單元測試、集成測試，還包括對需求的測試??！“測試左移”泛指專(zhuān)業(yè)的測試工程師應該從需求階段開(kāi)始介入，這總不會(huì )有問(wèn)題吧？如果沒(méi)有問(wèn)題，怎么能說(shuō)“測試左移”或者說(shuō)“測試工程師左移”是偽概念那？

這個(gè)問(wèn)題很好，所以我放到最后討論這個(gè)話(huà)題。先說(shuō)一下我的結論，全職測試工程師從需求開(kāi)始介入，可以認為是測試工程師左移的一個(gè)好的實(shí)踐，但是不是一個(gè)所有企業(yè)都普遍適用的最佳實(shí)踐那？我看未必！

為什么“測試左移”或者說(shuō)“測試工程師左移”是偽概念

為了說(shuō)清楚這個(gè)話(huà)題，我們從如下幾點(diǎn)加以說(shuō)明：

首先，我們要區分測試工作和全職測試工程師的工作，測試工作廣義上指驗證和確認工作，可能由專(zhuān)職的測試工程師完成，也可能由團隊中更合適的角色來(lái)完成。具體由誰(shuí)來(lái)完成，需要組織綜合考慮：技能適配性、溝通成本、職業(yè)發(fā)展、效率最優(yōu)、成本最低等制約要素。

“測試工程師從需求階段介入”是不是一個(gè)好的實(shí)踐。

如果測試工程師從需求階段介入，對測試工程師的技能有沒(méi)有特殊要求那？答案是肯定的，當然有！

• 第一，??在需求階段介入的測試工程師要對業(yè)務(wù)非常熟悉，至少是個(gè)業(yè)務(wù)專(zhuān)家，對業(yè)務(wù)的理解不能弱于需求分析師，否則根本沒(méi)有辦法進(jìn)行對等的交流。
• 第二，??在需求階段介入的測試工程師要對需求文檔的書(shū)寫(xiě)技能和語(yǔ)言邏輯很清楚，這樣才能參與到需求的獲取和評審工作中來(lái)。
• 第三，??在需求階段介入的測試工程師要有很強的溝通技能，這個(gè)階段的工作很多是從溝通交流中切入的。
• 第四，??在需求階段介入的測試工程師要有很強的測試分析和設計能力，因為這就是他此時(shí)介入的分內工作。

綜上所述，在需求階段介入的測試工程師是整個(gè)測試團隊中核心中的核心！

那在需求階段介入的測試工程師在這個(gè)階段具體的產(chǎn)出物是什么那？

如果在需求評審之前介入的話(huà)，老實(shí)說(shuō)，沒(méi)有什么硬性的產(chǎn)出物，更多的是提前對系統需求進(jìn)行了解。提出后續測試工作要點(diǎn)和組織方式的規劃，由于需求文檔也沒(méi)有完全定稿，所以當前所有的工作都存在被推翻的可能性。

如果在需求評審中或需求評審通過(guò)后介入的話(huà)，更多的是作為需求評審人員參與需求評審工作，綜合需求和其它文檔等，進(jìn)行測試的分析和設計，這里是有明確產(chǎn)出物的。但是請一定注意，測試人員如果參與需求評審工作，你首先是個(gè)業(yè)務(wù)專(zhuān)家，可以為需求評審貢獻一份綿薄之力，其次你才是測試工程師，從系統的可測試性思考需求的問(wèn)題。千萬(wàn)不要搞反了！需求工作的第一責任人是需求分析師，切記！

綜上所述，如果作為質(zhì)量的負責人，你應該如何選擇？讓測試工程師從需求評審前，評審中，評審后那個(gè)階段介入更合理那？

這里并沒(méi)有唯一或者最佳實(shí)踐，你要綜合考慮成本，環(huán)境，技術(shù)，風(fēng)險，投入產(chǎn)出比等制約條件，綜合考慮。

我的建議是：最早評審完成后介入，或者推遲到系統測試開(kāi)始之前介入，主要是從投入產(chǎn)出比的角度考慮。當然，每個(gè)組織對質(zhì)量的期望是不同的，需要按照自己的實(shí)際質(zhì)量目標進(jìn)行綜合考慮。

就這個(gè)話(huà)題來(lái)說(shuō)，我們談?wù)摰姆秶](méi)有超過(guò)幾十年前V模型涵蓋的內容，如果說(shuō)這就是最“先進(jìn)”的“測試左移”理念，我表示不服！

總結一下

放棄成本談質(zhì)量，就是耍流氓！合理的團隊協(xié)作模型，讓組織效率整體提升，過(guò)程質(zhì)量、產(chǎn)品質(zhì)量雙提高才應該是追求的目標！

對在軟件測試圈內“販賣(mài)焦慮”說(shuō)不！

軟件測試領(lǐng)域是個(gè)專(zhuān)業(yè)的領(lǐng)域，作為這個(gè)行業(yè)的從業(yè)者，我們應該系統化我們的測試體系，用正確的測試理念武裝自己。

我們構建的是一個(gè)基于風(fēng)險，基于概率思維的質(zhì)量評估體系，技術(shù)手段是為測試目標服務(wù)的。

???????專(zhuān)業(yè)的軟件測試不能脫離整體的覆蓋率談測試技術(shù)。