作者 | 顧況
出品 | 騰訊云開發(fā)者
最近兩年，互聯(lián)網(wǎng)大廠的招聘中，測(cè)試工程師崗位似乎顯著減少。在騰訊內(nèi)部，隨著一些 BG 的研效改革 逐漸深入，測(cè)試工程師這個(gè)崗位開始逐漸減少。似乎正在印證一個(gè)現(xiàn)象：測(cè)試崗位的未來已經(jīng)不那么樂觀？
但軟件測(cè)試伴隨著軟件行業(yè)的出現(xiàn)經(jīng)過了幾十年的進(jìn)化，花了很多時(shí)間和汗水才走到今天，測(cè)試這個(gè)領(lǐng)域是不會(huì)消失的。不少人都議論過崗位和角色的消失是否合理，一般都分成兩派，一派認(rèn)為測(cè)試工程師是獨(dú)立且專業(yè)的崗位應(yīng)該保留，合理縮減比例；另外一派認(rèn)為軟件測(cè)試領(lǐng)域并不復(fù)雜，覺得自己對(duì)于測(cè)試和自動(dòng)化測(cè)試已經(jīng)非常熟悉，完全可以勝任。
不管你屬于哪一派，首先要熟悉軟件測(cè)試才能更有發(fā)言權(quán)。熟悉是個(gè)模糊的說法，我們可以思考一個(gè)簡(jiǎn)單的問題，測(cè)試自動(dòng)化和自動(dòng)化測(cè)試這兩個(gè)名詞有什么區(qū)別？如果區(qū)分不出來或者沒有概念的話，這篇文章非常適合你，這是專門寫給開發(fā)的測(cè)試漫談。
軟件測(cè)試發(fā)展史
軟件測(cè)試這件事本身就伴隨著計(jì)算機(jī)的出現(xiàn)而出現(xiàn)，并且持續(xù)保持著演進(jìn)，但在我的身邊特別是一些改革較為激進(jìn)的 BG，這種演進(jìn)成為了噩夢(mèng)的開始。逐漸發(fā)量化的測(cè)試工程師投入導(dǎo)致產(chǎn)品質(zhì)量逐漸下滑，為了規(guī)避政治不正確的測(cè)試兜底而自裁系統(tǒng)測(cè)試導(dǎo)致缺陷滿天飛。有意思的是，結(jié)果數(shù)據(jù)也從事實(shí)上證明了這一點(diǎn)，測(cè)試開發(fā)比越低的項(xiàng)目，質(zhì)量和口碑就越不堪，故障越來越頻繁，質(zhì)量差到讓用戶逐漸麻木。
有些樂于嘗試的開發(fā)，積極擁抱變化，實(shí)踐 TDD，關(guān)注覆蓋率，但結(jié)果工作越來越累，任務(wù)越來越 delay，產(chǎn)品今天說老板中午吃飯?zhí)崃藗€(gè)甚好的建議你趕緊改改，項(xiàng)目經(jīng)理明天說我們重新調(diào)整了一下優(yōu)先級(jí)你先做另外一個(gè)需求，你想哭但哭不出來，甚至覺得 TDD 是 Tech Driven Dead 的縮寫。更離譜的是某天連一位在平行世界早已被你捅了100刀的產(chǎn)品都忍不住站出來振臂高呼，別再瞎xx搞啦，再搞項(xiàng)目就要黃啦。所以軟件測(cè)試的演進(jìn)到底是怎么回事，是不符合國(guó)情，比如硅谷工時(shí)短收入高，還是文化所限，比如硅谷技術(shù)至上產(chǎn)品靠邊站，且讓我們往下聊。
1.1 面向調(diào)試期（Debugging period）
參考軟件測(cè)試大師Hetzel 和 Dave Gelprin 可以將測(cè)試劃分為五個(gè)重要的時(shí)代。
第一次出現(xiàn)術(shù)語“Bug”和“Debugging”的故事大家應(yīng)該都在課本里學(xué)過，1947年，哈佛大學(xué)科學(xué)家 Grace Murray 在Mark II 計(jì)算機(jī)中檢測(cè)到一只飛蛾卡在了繼電器中，導(dǎo)致繼電器接觸不良。她描述這起事件時(shí)將飛蛾稱為導(dǎo)致缺陷的“Bug”，并將消除缺陷的行為稱“Debugging”。
當(dāng)時(shí)，因?yàn)橛?jì)算機(jī)的發(fā)展主要還集中在硬件設(shè)備的發(fā)展商，所以測(cè)試也相應(yīng)的集中在硬件上，而且硬件的可靠性對(duì)于軟件的正常運(yùn)行至關(guān)重要，稍有不慎便是災(zāi)難（可能跟當(dāng)時(shí)的存儲(chǔ)條件有關(guān)，還沒有持久性存儲(chǔ)技術(shù)）。這個(gè)階段的測(cè)試其實(shí)就是調(diào)試，沒有任何區(qū)別，也沒有所謂的測(cè)試人員之分，所執(zhí)行的測(cè)試僅具有糾正性質(zhì)，通過采取某些措施以使程序能正常工作。
1949年，艾倫·圖靈 (Alan Turing) 寫了他的第一篇關(guān)于對(duì)程序進(jìn)行調(diào)試的文章，緊接著在1950年，他在“圖靈測(cè)試“一文中解釋了軟件必須如何適應(yīng)項(xiàng)目要求以及機(jī)器或參考系統(tǒng)（人類邏輯）的行為必須無法區(qū)分的情況。簡(jiǎn)而言之就是軟件必須經(jīng)過人類邏輯的驗(yàn)證，讓機(jī)器執(zhí)行結(jié)果和人類預(yù)期相符。
1.2 演示期（Demonstration period）
1957年，Charles Baker 進(jìn)一步且系統(tǒng)性的解釋了開發(fā)測(cè)試的必要性，他對(duì) Dan McCracken 所著的 Digital Computer Programming 一書的評(píng)論中將程序測(cè)試與調(diào)試區(qū)分開來，認(rèn)為兩者的區(qū)別在于確保軟件滿足預(yù)先設(shè)計(jì)的要求（測(cè)試）以及程序的功能（調(diào)試）。
在這個(gè)時(shí)期，測(cè)試開始作為一項(xiàng)單獨(dú)的活動(dòng)進(jìn)行，軟件測(cè)試的主要目標(biāo)是確保滿足軟件需求。例如，需求是“QQ 的登錄狀態(tài)有7種”。測(cè)試人員會(huì)確保只展示 7種狀態(tài)。
隨著計(jì)算機(jī)軟件的蓬勃發(fā)展，應(yīng)用程序的開發(fā)變得越來越復(fù)雜，越來越昂貴，成本也越來越高，解決軟件缺陷的成本明顯影響了項(xiàng)目的盈利能力，因此測(cè)試開始變得極為重要。隨之而來的是，軟件測(cè)試這個(gè)新領(lǐng)域正在被逐漸重視，更多的從業(yè)人員開始關(guān)注并投入進(jìn)來。這個(gè)階段對(duì)于軟件測(cè)試的關(guān)注，主要體現(xiàn)在測(cè)試的數(shù)量和質(zhì)量，軟件產(chǎn)品的質(zhì)量第一次開始與測(cè)試結(jié)果關(guān)聯(lián)。逐漸的，軟件開發(fā)領(lǐng)域，細(xì)分出了軟件測(cè)試領(lǐng)域。
1.3 破壞導(dǎo)向期（Destruction period）
“軟件測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而運(yùn)行程序的過程”，1979年，Glenford J. Myers 從根本上改變了軟件測(cè)試這個(gè)行為的定義。
Myers 擔(dān)心的是，如果軟件測(cè)試用來追求證明程序是合格的這個(gè)目標(biāo)時(shí)，人們可能會(huì)下意識(shí)地選擇導(dǎo)致程序失敗的可能性較低的測(cè)試數(shù)據(jù)，因?yàn)檫@樣更容易接近和達(dá)成目標(biāo)。而如果目標(biāo)是證明程序有缺陷，我們的測(cè)試數(shù)據(jù)將更有可能檢測(cè)到它們，我們將在測(cè)試中獲得更多的收獲，從而推動(dòng)軟件質(zhì)量的提升。
“成功的測(cè)試用例是檢測(cè)到尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試用例”，從此，軟件測(cè)試被重新定義，測(cè)試主要為了嘗試證明程序無法正常工作，從而幫助發(fā)現(xiàn)軟件質(zhì)量的問題，并推動(dòng)質(zhì)量提升。這與之前的定義和工作方式相反，當(dāng)這個(gè)定義被廣泛認(rèn)同后，軟件開發(fā)領(lǐng)域逐漸產(chǎn)生了新的測(cè)試和分析技術(shù)，軟件測(cè)試領(lǐng)域真正的開始嶄露頭角。
1.4 面向評(píng)估期（Evaluation period）
從1983年到1987年，軟件測(cè)試的重點(diǎn)是評(píng)估和衡量軟件的質(zhì)量。測(cè)試提高了對(duì)軟件工作方式的信心指數(shù)，大中型軟件沒有得到充分測(cè)試的情況下是不允許發(fā)布的，Winston Royce 提出的“瀑布模型”在這個(gè)時(shí)期幾乎是唯一被廣泛采用的軟件開發(fā)模型，模型中要求測(cè)試人員在下游進(jìn)行測(cè)試，直到達(dá)到可接受的點(diǎn)，檢測(cè)到的錯(cuò)誤數(shù)量減少，否則將無法進(jìn)入到下一個(gè)環(huán)節(jié)。
自此測(cè)試階段被認(rèn)為是軟件產(chǎn)品研發(fā)過程中不可或缺的階段，如工業(yè)領(lǐng)域一般，QA 開始進(jìn)入到軟件開發(fā)團(tuán)隊(duì)，測(cè)試結(jié)果決定了產(chǎn)品是否達(dá)到發(fā)布標(biāo)準(zhǔn)。相應(yīng)的為了提高這個(gè)階段的研發(fā)效率，一些自動(dòng)化測(cè)試的工具逐漸出現(xiàn)。當(dāng)年的軟件開發(fā)領(lǐng)域不像工業(yè)領(lǐng)域可以靠堆積大量的人力去降低耗時(shí)，人才是十分稀缺的，所以提效工具自然而然的就被醞釀了出來。
1.5 預(yù)防期（Prevention period）
1988年 William Hetzel 出版了“軟件測(cè)試的成長(zhǎng)”一書，他將測(cè)試按規(guī)劃、設(shè)計(jì)、構(gòu)建、維護(hù)和執(zhí)行這幾個(gè)研發(fā)環(huán)節(jié)做了區(qū)分，不同的環(huán)節(jié)測(cè)試的行為和目的不同。顯著的變化是從產(chǎn)品規(guī)劃階段就涉及到了測(cè)試行為，這個(gè)階段的測(cè)試更多的是針對(duì)產(chǎn)品方案進(jìn)行測(cè)試，起到提前預(yù)防的作用，有點(diǎn)類似我們的需求和用例評(píng)審。
測(cè)試所起到的作用更加廣泛，不僅需要證明軟件符合預(yù)期，還要嘗試發(fā)現(xiàn)更多的故障，并且還要嘗試預(yù)防缺陷。在這個(gè)時(shí)代，識(shí)別測(cè)試技術(shù)是關(guān)鍵。20 世紀(jì)的最后十年也出現(xiàn)了探索性測(cè)試，測(cè)試人員探索并深入了解軟件以試圖發(fā)現(xiàn)更多錯(cuò)誤。再往后測(cè)試驅(qū)動(dòng)開發(fā) (TDD) 和行為驅(qū)動(dòng)開發(fā) (BDD) 等新測(cè)試概念興起，也是試圖更早的起到預(yù)防的作用。啰嗦一句，可能不少年輕人對(duì)于軟件測(cè)試的這個(gè)時(shí)間線會(huì)覺得跟我們的認(rèn)知有些脫節(jié)，主要是因?yàn)槲覀儑?guó)家軟件行業(yè)起步較晚，如果把這個(gè)時(shí)間線加上10-20年，并且把每個(gè)時(shí)期壓縮，基本上就能對(duì)齊我們國(guó)內(nèi)的軟件業(yè)發(fā)展節(jié)奏了。
歷史告訴我們軟件測(cè)試是基于對(duì)軟件質(zhì)量要求越來越高而形成的特定領(lǐng)域，又因?yàn)槟硞€(gè)時(shí)期的大型軟件對(duì)質(zhì)量有極高的重視度，催生了專職且專業(yè)的軟件測(cè)試工程師這個(gè)角色和崗位，但一些中小型特別是start up公司，他們并不會(huì)設(shè)立專職的軟件測(cè)試工程師，但別搞混淆了，沒有測(cè)試工程師不代表他們不做軟件測(cè)試。所以我們可以嘗試達(dá)成概念上的一致，軟件測(cè)試這個(gè)環(huán)節(jié)和行為是不可或缺的，軟件測(cè)試工程師的角色則根據(jù)公司和產(chǎn)品定位會(huì)有不同的設(shè)定。
縱觀軟件測(cè)試發(fā)展史，如果我們把整個(gè)開發(fā)階段想象成一條有限的線，從需求規(guī)劃（requirement）到產(chǎn)品上線，我們會(huì)看到測(cè)試階段是如何向左移動(dòng)的：它最初是在產(chǎn)品完成階段的活動(dòng)，后來開始在開發(fā)中后期活動(dòng)，再后來更是提前到了需求規(guī)劃階段，這種現(xiàn)象被稱之為測(cè)試左移。所以你會(huì)發(fā)現(xiàn)，我們近兩年大力提倡測(cè)試左移非常符合軟件發(fā)展歷史規(guī)律。所以接下來我們直接聊「測(cè)試左移」，一個(gè)張口就來，卻沒有背普遍深入理解的概念。
測(cè)試左移（Testing shift left）
眾所周知，缺陷越晚在生命周期中被發(fā)現(xiàn)，修復(fù)起來就越困難，成本也越高。整個(gè)項(xiàng)目的風(fēng)險(xiǎn)和壓力時(shí)常在瀑布模型下層層傳遞最后壓在了測(cè)試人員的頭上，因此軟件測(cè)試社區(qū)中近些年最重要和最廣泛討論的趨勢(shì)之一便是左移測(cè)試，試圖打破這種局面，尋找更平衡更有效的方法保障質(zhì)量。
2.1 怎么理解左移
測(cè)試左移本質(zhì)上意味著“經(jīng)常測(cè)試，并盡早開始”。但是為什么它被稱為“左”呢？聽上去容易令人困擾但很好理解，我們通常習(xí)慣從左到右閱讀（除了阿拉伯、希伯來和意第緒語等少數(shù)語言），所以如果我們要表示一個(gè)連續(xù)的階段，描述方式會(huì)從最左邊開始向右，瀑布模型中的階段可以表示如下：
Requirement →
Design →
Implementation →
Verification →
Maintenance 驗(yàn)證階段（通常就是測(cè)試活動(dòng)）是倒數(shù)第二個(gè)階段，如果我們想把測(cè)試活動(dòng)提前到研發(fā)階段更早期開始介入，則需要把 Verification 階段向左側(cè)移動(dòng)，于是社區(qū)將這樣的趨勢(shì)稱之為左移。
然而，不要誤解測(cè)試左移提倡的測(cè)試是一個(gè)離散的階段，只放在開始階段，而非結(jié)束階段。因?yàn)樵谡嬲能浖艚蓍_發(fā)中，不應(yīng)該有階段，而是更早的開始關(guān)注質(zhì)量和介入測(cè)試，是在短的迭代周期中發(fā)生的連續(xù)活動(dòng)。
2.2 為什么要左移
幾十年來，無數(shù)大型項(xiàng)目證明了瀑布模型會(huì)導(dǎo)致缺陷通常在生命周期后期被發(fā)現(xiàn)，這種工作模式下，時(shí)間久了就會(huì)對(duì)這個(gè)軟件項(xiàng)目造成巨大的傷害：
許多需求、架構(gòu)和設(shè)計(jì)缺陷直到在它們的實(shí)現(xiàn)上浪費(fèi)了大量的時(shí)間后才被發(fā)現(xiàn)和修復(fù)。
代碼和功能越堆越多，調(diào)試（包括識(shí)別、定位、修復(fù)和回歸測(cè)試缺陷）變得更加困難。
封裝使得執(zhí)行白盒測(cè)試和在測(cè)試期間實(shí)現(xiàn)高水平代碼覆蓋率變得更加困難。
修復(fù)缺陷的時(shí)間比開發(fā)新功能的時(shí)間更多，項(xiàng)目可能會(huì)嘗試犧牲質(zhì)量，這會(huì)加劇技術(shù)債的產(chǎn)生，如果不加以管控，可能會(huì)使項(xiàng)目沉沒。
如果為了提升質(zhì)量而放慢項(xiàng)目節(jié)奏，項(xiàng)目進(jìn)度將會(huì)成為災(zāi)難，因?yàn)殚_發(fā)們將會(huì)面臨著改不完的bug，做不完的需求變更。
造成這上面一系列問題的原因在于軟件開發(fā)項(xiàng)目中，項(xiàng)目成員總是對(duì)質(zhì)量保證有不同的對(duì)待，他們承擔(dān)著不同的角色、擁有不同的職責(zé)、定義了不同的工作描述和以及不同的領(lǐng)導(dǎo)。
我們?cè)诠ぷ髦?，特別是在騰訊的傳統(tǒng)項(xiàng)目管理風(fēng)格下，經(jīng)常會(huì)碰到以下場(chǎng)景：
測(cè)試人員時(shí)常處于高壓狀態(tài)，一方面要為項(xiàng)目進(jìn)度承擔(dān)風(fēng)險(xiǎn)，一方面要為項(xiàng)目質(zhì)量承擔(dān)主要責(zé)任，這樣很容易導(dǎo)致測(cè)試環(huán)節(jié)的執(zhí)行效果變形。
開發(fā)人員、產(chǎn)品人員和測(cè)試人員長(zhǎng)期保持對(duì)立狀態(tài)，測(cè)試本著工作職責(zé)要保證最終產(chǎn)品的質(zhì)量，會(huì)嚴(yán)格把控產(chǎn)品和開發(fā)的輸出，但開發(fā)有時(shí)會(huì)將問題歸咎到產(chǎn)品，而產(chǎn)品又會(huì)將矛頭指向開發(fā)，當(dāng)開發(fā)和產(chǎn)品達(dá)成一致時(shí)又會(huì)將矛頭指向測(cè)試。
測(cè)試環(huán)節(jié)的完成度和效果，幾乎完全依賴當(dāng)前這個(gè)測(cè)試執(zhí)行者的個(gè)人能力和經(jīng)驗(yàn)，如果遇到能力不足，或工作狀態(tài)不佳的情況，最終輸出的產(chǎn)品質(zhì)量可能會(huì)造成災(zāi)難。
但是，如果我們將質(zhì)量保證和開發(fā)人員以及團(tuán)隊(duì)其他所有角色掛鉤，quality assurance is everyone’s responsibility，作為一個(gè)項(xiàng)目團(tuán)隊(duì)每個(gè)人都要為質(zhì)量負(fù)責(zé)，共同的目的是生產(chǎn)最終適合客戶的產(chǎn)品，我們很大幾率會(huì)得到以下效果：
在軟件開發(fā)生命周期的早期發(fā)現(xiàn)錯(cuò)誤，并且能有效降低解決錯(cuò)誤的成本。
獲得更高質(zhì)量的產(chǎn)品，意味著打更少的 patch，改更少的 bug，更少的加班。
產(chǎn)品發(fā)布預(yù)期會(huì)更加可控，降低每個(gè)人發(fā)版本的焦慮。
極少技術(shù)債，代碼庫(kù)一直保持高質(zhì)量維護(hù)狀態(tài)。
因?yàn)橘|(zhì)量保障人人有責(zé)，所以我們提倡質(zhì)量左移。又因?yàn)槲覀兿Ｍ苿?dòng)質(zhì)量左移，所以人人都應(yīng)該參與質(zhì)量保障。
2.3 如何開展左移
如上面所說，測(cè)試左移是要讓開發(fā)參與到質(zhì)量保障中來，將測(cè)試行為推向編碼階段。一個(gè)很好的采用方法是測(cè)試驅(qū)動(dòng)開發(fā) ( TDD )， 它首先根據(jù)程序應(yīng)有的邏輯來實(shí)現(xiàn)單元測(cè)試，然后編寫使測(cè)試正常工作的代碼。這種做法的目的是在開始寫代碼之前有一個(gè)清晰的結(jié)構(gòu)，一個(gè)更健壯和高效的代碼（包括測(cè)試代碼），對(duì)于后續(xù)的迭代更具有持續(xù)性（持續(xù)集成，持續(xù)測(cè)試）。
還有一種工具化的測(cè)試左移的方法是使用靜態(tài)分析工具。靜態(tài)分析工具有助于識(shí)別參數(shù)類型或接口使用不當(dāng)?shù)膯栴}，將這類工具集成在 IDE 里可以更早更快的發(fā)現(xiàn)問題，比如大家熟知的 ESLint 便一個(gè)非常著名的靜態(tài)代碼檢查工具。
此外，行為驅(qū)動(dòng)開發(fā) (BDD) 也可以加速測(cè)試左移的開展。BDD 定義了一種所有利益相關(guān)者都可以理解的通用設(shè)計(jì)語言，例如產(chǎn)品經(jīng)理、開發(fā)人員和其他角色。因此，它使所有相關(guān)利益相關(guān)者能夠同時(shí)處理相同的產(chǎn)品功能，從而加快團(tuán)隊(duì)的敏捷性。特別要注意的是，這種模式較好地卷入了產(chǎn)品人員提前關(guān)注質(zhì)量，將左移進(jìn)一步前置，以將需求結(jié)構(gòu)化的形式來驗(yàn)證需求質(zhì)量。試想一下，如果一個(gè) scenario 寫出來就覺得不對(duì)勁，是不是應(yīng)該先看看需求哪里有問題，而不是急于去實(shí)現(xiàn)它。所以換句話說，BDD 可以促進(jìn)跨團(tuán)隊(duì)協(xié)作，同時(shí)縮短了功能交付時(shí)間。
不過我們應(yīng)該要理解的是測(cè)試左移的頂層思想，目標(biāo)上希望盡可能早的發(fā)現(xiàn)甚至規(guī)避問題，角色上需要全員為質(zhì)量負(fù)責(zé)，執(zhí)行上是要將軟件測(cè)試主流的冰淇凌模式轉(zhuǎn)變?yōu)榻鹱炙Ｊ剑?/strong>基于這個(gè)思想之下具體到團(tuán)隊(duì)該怎么做，完全可以因地制宜，比如 BDD 和 TDD 本身并無沖突，甚至還可以嘗試 BDD+TDD 的模式，另外 TDD 更適合無用戶交互的項(xiàng)目比如純后臺(tái)，BDD 則更適合重交互的項(xiàng)目如客戶端和前端，還有 TDD 的進(jìn)化版本 ATDD 是一個(gè)更重用戶體驗(yàn)的模式。
2.4 測(cè)試左移的局限性
推行測(cè)試左移，通過 TDD、BDD 和 ATDD 框架，研發(fā)團(tuán)隊(duì)可以利用清晰的流程來捕獲需求并在低級(jí)別（單元測(cè)試）和高級(jí)別（驗(yàn)收測(cè)試）進(jìn)行測(cè)試，以確保應(yīng)用程序的質(zhì)量，并且可以持續(xù)的享受穩(wěn)定可靠的測(cè)試代碼帶來的收益。然而，在現(xiàn)實(shí)世界中，我們面臨著許多壓力——競(jìng)爭(zhēng)、時(shí)間、技能短缺——這使得這一切都難以成為現(xiàn)實(shí)，或者在執(zhí)行過程中產(chǎn)生各種各樣的技術(shù)變形，最終實(shí)現(xiàn)效果并沒有達(dá)到預(yù)期。
舉個(gè)充分具有騰訊特色的例子：開發(fā)A 在很好的踐行 TDD 開發(fā)，但某天產(chǎn)品說今天上午開會(huì)老板對(duì)一個(gè)特性表示了不同意見，產(chǎn)品們中午飯都沒吃開會(huì)討論出了調(diào)整方案，希望明天就能上線，時(shí)間緊迫來不及廢話，就拿著這張照片開發(fā)吧（會(huì)議室白板拍下來的方案），這時(shí)開發(fā)A 該如何保障質(zhì)量？可能有人說這太特色了，場(chǎng)景反而沒那么多，那再舉個(gè)常見的例子：Android 50/iOS 80要發(fā)布了，開發(fā)B 提前拿到了開發(fā)者版本要針對(duì)新系統(tǒng)對(duì) APP 做一次全面體驗(yàn)和質(zhì)量排查，發(fā)現(xiàn)了不少嚴(yán)重影響用戶使用的問題，大部分是兼容性問題可以直接優(yōu)化，也有一些是新功能產(chǎn)生的體驗(yàn)問題需要產(chǎn)品給方案，但臨新系統(tǒng)發(fā)布不到一周時(shí)間了，這時(shí)開發(fā)B該如何保障這波更新的質(zhì)量？
受時(shí)間和資源所限，我們只能將質(zhì)量放在需求交付之后再進(jìn)行把控，以希望快速發(fā)現(xiàn)和修復(fù)，避免產(chǎn)生更大范圍和更嚴(yán)重的影響，這就涉及到了下一個(gè)話題，測(cè)試右移。
測(cè)試右移（Testing shift right）
3.1 怎么理解右移
如果在產(chǎn)品開發(fā)周期的早期進(jìn)行測(cè)試意味著向左移動(dòng)，那么稍后進(jìn)行就必須向右移動(dòng)。這就是測(cè)試右移的意義所在——在產(chǎn)品發(fā)布后進(jìn)行測(cè)試。按照測(cè)試左移的概念，我們將在生產(chǎn)環(huán)境進(jìn)行的測(cè)試行為和質(zhì)量保障稱之為測(cè)試右移。
在去年的一項(xiàng)由 Capgemini 和 Broadcom 聯(lián)合進(jìn)行的問卷調(diào)查中，生產(chǎn)中的測(cè)試被列為目前實(shí)施或計(jì)劃中的首要實(shí)踐。此外，39% 的受訪者提到使用運(yùn)營(yíng)分析來確定或優(yōu)化測(cè)試覆蓋率。簡(jiǎn)單來說就是越來越多的軟件企業(yè)開始重視生產(chǎn)環(huán)境的測(cè)試驗(yàn)證，而非一味的追求前置的保障。
當(dāng)被問及客戶如何衡量持續(xù)測(cè)試流程的有效性時(shí)，利用生產(chǎn)數(shù)據(jù)和利用用戶反饋分別排名第一和第二。
有些專業(yè)人士將測(cè)試右移劃到SRE領(lǐng)域，也有一些DevOps概念將之稱之為TestOps，強(qiáng)調(diào)測(cè)試與運(yùn)維之間的緊密結(jié)合，甚至還有一種說法叫運(yùn)維左移，叫什么不重要，重要的是這說明測(cè)試右移引起了足夠的重視，值得關(guān)注和嘗試。
3.2 為什么要右移
先說第一個(gè)理由，創(chuàng)建質(zhì)量門（Quality Gate）是開始左移運(yùn)動(dòng)的一個(gè)行之有效且簡(jiǎn)單的方法。大多數(shù)公司都有某種類型的生產(chǎn)質(zhì)量門，最簡(jiǎn)單的形式是“所有測(cè)試用例的 X% 必須通過，并且關(guān)鍵優(yōu)先級(jí)缺陷少于 Y?！?，相信各位都經(jīng)歷過或正在經(jīng)歷這個(gè)階段。更DevOps的玩法則是流水線質(zhì)量紅線，通過持續(xù)測(cè)試以及紅線來攔截潛在的質(zhì)量問題。
但是如測(cè)試左移局限性章節(jié)所述，有些時(shí)候我們會(huì)收到來自各方的影響甚至干擾，導(dǎo)致技術(shù)動(dòng)作變形，質(zhì)量門也好流水線紅線也好，時(shí)常會(huì)被打破和踐踏，前幾年作為測(cè)試工程師我最大的噩夢(mèng)便是來自項(xiàng)目經(jīng)理的一句「我們?cè)賮韗eview下bug單」......下圖是一張常見的影響和可能性對(duì)缺陷優(yōu)先級(jí)的視覺描述。低影響 + 低可能性 = 低優(yōu)先級(jí)（P2）；低影響 + 中等可能性 = 低優(yōu)先級(jí)（P2）；低影響 + 高可能性 = 中優(yōu)先級(jí)（P1）；中等影響 + 中等可能性 = 中優(yōu)先級(jí)（P1）；中等影響 + 高可能性 = 高優(yōu)先級(jí)（P0）；高影響 + 高可能性 = 關(guān)鍵優(yōu)先級(jí)（P00）。善于發(fā)明創(chuàng)造的鵝廠項(xiàng)目經(jīng)理可能還會(huì)發(fā)明P000，甚至P0000來讓更多缺陷看上去優(yōu)先級(jí)沒有那么高，從而放過問題盡快發(fā)布。
于是在缺乏適當(dāng)?shù)馁|(zhì)量心態(tài)的團(tuán)隊(duì)或者場(chǎng)景下，第一道門被打破后，必須建立起第二道門來對(duì)質(zhì)量進(jìn)行把控，否則千里之堤將毀于蟻穴，每一次的缺陷漏出（不論是有意還是無意）都會(huì)對(duì)項(xiàng)目的未來造成不同程度的影響甚至傷害。
這第二道門便是測(cè)試右移（也可以叫做質(zhì)量右移），當(dāng)缺陷在并非我們預(yù)期的階段漏出了，我們應(yīng)該具備足夠的能力和手段（工具）發(fā)現(xiàn)并修復(fù)，并且確保未來不會(huì)再次漏出。
再說第二個(gè)理由，研發(fā)團(tuán)隊(duì)提高速度的最有效方法之一是將質(zhì)量目標(biāo)左移，也就是測(cè)試左移。實(shí)際情況，我們也正在推動(dòng)早期測(cè)試的各種基礎(chǔ)設(shè)施和管道，以最終減少新增代碼發(fā)布到生產(chǎn)并且質(zhì)量穩(wěn)定的時(shí)間。前面我們也探討了有多種測(cè)試可以輕松地將測(cè)試行為向左移動(dòng)，例如單元測(cè)試。但有時(shí)候有些事情超出了傳統(tǒng)測(cè)試工程師的覆蓋范疇， 例如服務(wù)器可能會(huì)停機(jī)，又如一些熱點(diǎn)事件導(dǎo)致訪問激增，性能和可用性問題隨時(shí)可能爆發(fā)。雖然部署到測(cè)試環(huán)境可以模擬與生產(chǎn)相當(dāng)?shù)沫h(huán)境，但事實(shí)證明模擬畢竟是模擬，不是完全替代品。
生產(chǎn)環(huán)境的全面廣度和多樣性很難在測(cè)試環(huán)境中復(fù)制，用戶流量的真實(shí)場(chǎng)景也很難模擬。即使我們根據(jù)以往的案例構(gòu)建并優(yōu)化了測(cè)試手段，隨著生產(chǎn)需求的不斷發(fā)展，維護(hù)這些配置文件和行為也成為一項(xiàng)重大責(zé)任。此外，生產(chǎn)環(huán)境也在不斷變化。它從來都不是一成不變的，即使我們的業(yè)務(wù)沒有變化，它下面的一切也在不斷變化，比如它所依賴的基礎(chǔ)設(shè)施。因此，經(jīng)過一段時(shí)間后，團(tuán)隊(duì)發(fā)現(xiàn)某些類型的測(cè)試只能也必須要在生產(chǎn)環(huán)境中進(jìn)行。
兩個(gè)理由其實(shí)只是從不同角度說了同一件事，百分百的可靠性/質(zhì)量通常是一個(gè)不切實(shí)際的目標(biāo)。我們從 Google 的 SRE 哲學(xué)中學(xué)到的一個(gè)關(guān)鍵原則是，100% 的可靠性/完美質(zhì)量的產(chǎn)品不僅不切實(shí)際，而且通常成本太高而無法實(shí)現(xiàn)。SRE 建立了服務(wù)水平目標(biāo)(SLO) 和風(fēng)險(xiǎn)預(yù)算的概念，以量化生產(chǎn)系統(tǒng)中可接受的風(fēng)險(xiǎn)容忍度，同樣的原則也適用于測(cè)試和整體質(zhì)量。Netflix 在這方面我個(gè)人覺得已經(jīng)做到了業(yè)界極致，他們?cè)?019年O'Reilly SACon 上名為《Anatomy of Testing in Production》的分享介紹了 Netflix 如何演進(jìn)到在生產(chǎn)環(huán)境做測(cè)試的全歷程，內(nèi)容非常清晰明了，我就不在本文越俎代庖湊字?jǐn)?shù)了。
3.3 如何開展右移
關(guān)于測(cè)試右移，我的經(jīng)驗(yàn)并不多，還在邊學(xué)習(xí)邊實(shí)踐，很多事物都超出了我以前的經(jīng)驗(yàn)范疇，涉及到很多新名詞、新角色和新技術(shù)，我用我有限的知識(shí)幫大家捋一捋，開闊下思路。
數(shù)據(jù)分析能力：由于大多數(shù)生產(chǎn)數(shù)據(jù)都是大量、多樣且通常是臨時(shí)的，因此我們必須進(jìn)行數(shù)據(jù)分析，以便快速?gòu)倪@些數(shù)據(jù)中獲得洞察力，并與其他數(shù)據(jù)集進(jìn)行關(guān)聯(lián)以識(shí)別操作。高級(jí)分析技能（例如預(yù)測(cè)分析或機(jī)器學(xué)習(xí)）對(duì)于預(yù)測(cè)事件（例如發(fā)布質(zhì)量）也是必不可少的。雖然這些分析技能在運(yùn)營(yíng)領(lǐng)域都是稀松平常的事物，不過對(duì)于開發(fā)人員和測(cè)試人員來說相對(duì)較新。
CX 測(cè)試能力(Customer Experience)：CX 現(xiàn)在被認(rèn)為是衡量生產(chǎn)質(zhì)量的關(guān)鍵指標(biāo)。如今常見的 CX 測(cè)試包括 A/B test、金絲雀測(cè)試以及眾測(cè)。與其他運(yùn)營(yíng)數(shù)據(jù)一樣，CX 數(shù)據(jù)通常也非常龐大且通常是非結(jié)構(gòu)化的。雖然理論上來說 CX 應(yīng)該是運(yùn)營(yíng)團(tuán)隊(duì)關(guān)注的事情，但如果要在生產(chǎn)環(huán)境做質(zhì)量保障，則需要獲得足夠的技能來從 CX 流程和數(shù)據(jù)中收集數(shù)據(jù)并提升洞察力。舉個(gè)例子，現(xiàn)在騰訊文檔的很多生產(chǎn)缺陷反饋都來自于用戶反饋，然后其中參雜著體驗(yàn)問題和功能缺陷，開發(fā)人員不得不對(duì)這些反饋?zhàn)鲆坏朗止み^濾，以便將有效的質(zhì)量問題轉(zhuǎn)入研發(fā)計(jì)劃，這顯然是一種低效的做法。
監(jiān)控和操作能力(Ops)：了解監(jiān)控原理（例如創(chuàng)建、測(cè)試和部署監(jiān)控器以及使用監(jiān)控器中的數(shù)據(jù)）是測(cè)試右移的一項(xiàng)關(guān)鍵技能。同樣，熟悉 oncall 流程，運(yùn)營(yíng)手冊(cè)（事件、故障、警報(bào)、MTBF、MMTR、配置定義等）也是非常必要的。
可靠性技能：越來越多的項(xiàng)目開始組建 SRE 團(tuán)隊(duì)，說明可靠性已經(jīng)被意識(shí)到是一個(gè)非常關(guān)鍵的質(zhì)量屬性。SRE 涉及到測(cè)試的包括混沌/彈性測(cè)試、部署和回滾測(cè)試以及配置測(cè)試。
新工具的支持：對(duì)于測(cè)試右移來說，工具的支持是不可或缺的，沒有合適的工具就無法執(zhí)行測(cè)試右移，這其中包括監(jiān)控、數(shù)據(jù)分析（針對(duì)生產(chǎn)和 CX 數(shù)據(jù)）、CX 測(cè)試（例如 A/B 和金絲雀測(cè)試）和可靠性測(cè)試等很多領(lǐng)域的工具。
復(fù)盤能力：當(dāng)問題無法避免的在生產(chǎn)環(huán)境被放大，我們除了第一時(shí)間修復(fù)問題外，還需要對(duì)問題進(jìn)行復(fù)盤，找出根因，想辦法從源頭或者更早的環(huán)節(jié)發(fā)現(xiàn)和攔截問題，甚至從最早的設(shè)計(jì)階段就可以避免它，不要浪費(fèi)每一個(gè)被漏出去的問題，「Now, what did we learn today?」。
自動(dòng)化測(cè)試 VS 測(cè)試自動(dòng)化
如果你有耐心認(rèn)真看到了這里，恭喜你已經(jīng)開始對(duì)測(cè)試領(lǐng)域產(chǎn)生了興趣，那么我們接著聊點(diǎn)更「測(cè)試」的東西，也就是開頭提到的自動(dòng)化測(cè)試和測(cè)試自動(dòng)化的區(qū)別。
不管是前面說到的測(cè)試左移還是測(cè)試右移，都繞不過自動(dòng)化測(cè)試這個(gè)詞，那么「測(cè)試自動(dòng)化」又到底是個(gè)什么概念？作為開發(fā)我需要理解這個(gè)東西嗎？是不是測(cè)試領(lǐng)域的故弄玄虛？它們是相關(guān)的概念，但每一個(gè)都有非常具體的含義和目的。在簡(jiǎn)單聊過測(cè)試左移和右移的重要性之后，是時(shí)候定義這兩個(gè)概念，闡明它們之間的不同和相似之處，因?yàn)樗麄兊膮^(qū)別真的很重要。
先說自動(dòng)化測(cè)試，“自動(dòng)化測(cè)試”只是自動(dòng)運(yùn)行一組特定的測(cè)試并驗(yàn)證其結(jié)果的過程，而不是手動(dòng)進(jìn)行。當(dāng)我在機(jī)器上跑運(yùn)行單元測(cè)試時(shí)，我正在做的是自動(dòng)化測(cè)試。當(dāng)有人MR新代碼時(shí)，CI 流水線自動(dòng)執(zhí)行單元和集成測(cè)試，它也在做自動(dòng)化測(cè)試。接著說測(cè)試自動(dòng)化，“測(cè)試自動(dòng)化”解釋起來可能有點(diǎn)棘手，雖然自動(dòng)化測(cè)試=將測(cè)試驗(yàn)證通過自動(dòng)化執(zhí)行，但“測(cè)試自動(dòng)化”是一個(gè)更廣泛的概念。它是指將管理組織內(nèi)部不同測(cè)試需求以及行為的整個(gè)過程完全自動(dòng)化。
如果把自動(dòng)化測(cè)試比作流水線（Pipeline），那測(cè)試自動(dòng)化則是工作流（Workflow）?，F(xiàn)實(shí)情況自動(dòng)化測(cè)試確實(shí)更多的是以 pipeline 的形式運(yùn)用在 CI/CD 中，而測(cè)試自動(dòng)化則是通過 worklfow 的形式對(duì)研發(fā)流程中涉及到測(cè)試行為進(jìn)行編排，使這些環(huán)節(jié)可以自動(dòng)串聯(lián)和執(zhí)行，而每個(gè)環(huán)節(jié)是用自動(dòng)化測(cè)試還是其他測(cè)試工具來實(shí)現(xiàn)，都是測(cè)試自動(dòng)化需要考慮的范圍。
4.1 自動(dòng)化測(cè)試
貫徹自動(dòng)化測(cè)試團(tuán)隊(duì)中收益最大的角色是誰？在我看來，答案很明確：開發(fā)人員，but why？為了方便開發(fā)同學(xué)們聚焦，讓我們暫時(shí)專注于單元測(cè)試。其實(shí)“單元測(cè)試”并不是一個(gè)很好的名字，對(duì)于初學(xué)者來說，他們可能會(huì)被帶偏認(rèn)為覆蓋了某個(gè)函數(shù)就叫單元測(cè)試或者代碼覆蓋率達(dá)到 X%就叫好的單元測(cè)試。真正意義上的單元測(cè)試要考慮的東西很多，或者說單元測(cè)試要承載的功能很多：
提升代碼質(zhì)量，它可以幫助開發(fā)人員在進(jìn)行集成測(cè)試之前識(shí)別單元中可能存在的最小缺陷。
提升調(diào)試性，可測(cè)試性一定程度上等于調(diào)試性（capability of being (easily) debugged）。
功能文檔，想要了解代碼邏輯的開發(fā)人員可以通過閱讀每個(gè)單獨(dú)模塊的單測(cè)輕松了解系統(tǒng)。
開發(fā)效率，因?yàn)閱卧獪y(cè)試天然是自動(dòng)化測(cè)試的緣故，可以快速變更快速驗(yàn)證快速迭代。
提升信心，重構(gòu)代碼和更新引用庫(kù)變得更加容易，不論是擔(dān)心改動(dòng)對(duì)他人的影響，還是他人的改動(dòng)對(duì)自己的影響，在進(jìn)入下一階段之前，優(yōu)秀的單元測(cè)試意味著該單元在與其他模塊集成之前已被證明處于正常工作狀態(tài)。
單元測(cè)試是由程序員編寫的，對(duì)于程序員來說，是為了“證明”，至少在一定程度上有信心，一段給定的代碼確實(shí)做了它應(yīng)該做的事情。截至目前，自己驗(yàn)證自己產(chǎn)生的代碼，聽上去很合理，收益最大的人自然也是自己或其他協(xié)同開發(fā)的人，即開發(fā)人員。
我們?cè)賹ⅰ翱蓤?zhí)行規(guī)范”的定義擴(kuò)展到集成測(cè)試。集成測(cè)試簡(jiǎn)單來說就是將測(cè)試范圍擴(kuò)大到系統(tǒng)級(jí)別的功能驗(yàn)證，并且使用真實(shí)的數(shù)據(jù)庫(kù)/文件系統(tǒng)/賬號(hào)等而非模擬/存根。集成測(cè)試要考慮的東西是什么，或者說集成測(cè)試要承載的功能有哪些？我就不再展開細(xì)說了，聰明的你一定已經(jīng)結(jié)合上面單元測(cè)試的結(jié)論有了自己的答案。
最后我們將“可執(zhí)行規(guī)范”的定義擴(kuò)展到端到端測(cè)試，已無需多言，答案似乎很清楚：項(xiàng)目中“自動(dòng)化測(cè)試”的主要受益者是開發(fā)人員。或者，換句話說：自動(dòng)化測(cè)試是實(shí)現(xiàn)開發(fā)人員理性的工具（曾經(jīng)的你「一把梭」過嗎，DDDD），測(cè)試代碼和業(yè)務(wù)代碼相輔相成，它允許開發(fā)人員無所畏懼地重構(gòu)，因?yàn)樗麄冎烙幸粋€(gè)可靠的安全網(wǎng)，分別在不同層面以測(cè)試套件的形式出現(xiàn)，如果他們破壞了什么，都會(huì)被發(fā)現(xiàn)并被攔截。
看到這里如果你還認(rèn)為自動(dòng)化測(cè)試是為了節(jié)約測(cè)試工程師人力，那......是在下認(rèn)輸了。
4.2 測(cè)試自動(dòng)化
貫徹測(cè)試自動(dòng)化，團(tuán)隊(duì)中誰會(huì)從中受益最大？這個(gè)答案可能有爭(zhēng)議，但在我看來最大受益人依然是開發(fā)人員。
在傳統(tǒng)的瀑布模式的組織中，測(cè)試只不過是整個(gè)周期中的另一個(gè)階段。測(cè)試階段往往發(fā)生在周期結(jié)束或接近結(jié)束時(shí)。我們?cè)谇懊娴臏y(cè)試左移中已經(jīng)討論的足夠清晰，這樣做實(shí)在太晚了，反饋周期變慢會(huì)降低整個(gè)測(cè)試策略的實(shí)用性和效率。如今，推行 DevOps 的公司正朝著全面 CI/CD 的世界邁進(jìn)，他們不能永遠(yuǎn)等待測(cè)試的反饋，測(cè)試本身必須是連續(xù)的（continuous testing），這樣才能在開發(fā)的所有階段確保質(zhì)量，不然 CI/CD 很難完整。
在這種情況下，自動(dòng)化測(cè)試是可以派上用場(chǎng)，但這只解決了單點(diǎn)的測(cè)試行為被自動(dòng)化執(zhí)行的問題。如果要將測(cè)試完全且徹底的融入到 CI/CD 中，這必須依賴更完整的測(cè)試工具鏈，比如測(cè)試環(huán)境、測(cè)試數(shù)據(jù)（賬號(hào)、素材等）的自動(dòng)生成和管理；又比如通過 IDE 實(shí)現(xiàn)本地開發(fā)遠(yuǎn)程執(zhí)行自動(dòng)化測(cè)試；再比如針對(duì)一些核心業(yè)務(wù)或模塊需要設(shè)置定時(shí)任務(wù)以及風(fēng)險(xiǎn)告警；最后再提一個(gè)對(duì)自動(dòng)化測(cè)試本身的運(yùn)營(yíng)思路，使用自動(dòng)化測(cè)試本身已經(jīng)比較成熟沒有難度，但在哪個(gè)階段/環(huán)節(jié)執(zhí)行，執(zhí)行哪種類型的測(cè)試任務(wù)，執(zhí)行結(jié)果是否可以作為有效的攔截依據(jù)，這些是需要花些心思的。如果前面說的這些測(cè)試域的事情不能自動(dòng)化，就很難提升自動(dòng)化測(cè)試的速度和一致性，也無法連續(xù)的啟動(dòng)和運(yùn)行測(cè)試。更惡劣的情況甚至?xí)屪詣?dòng)化測(cè)試本身變得非常困難且容易出錯(cuò)，而且還很耗時(shí)，最終失去了做這件事的全部意義。這并非危言聳聽，騰訊文檔項(xiàng)目就正在經(jīng)歷著折磨......
通過自動(dòng)化管理上述測(cè)試需求，測(cè)試自動(dòng)化可幫助組織在整個(gè)開發(fā)周期中將質(zhì)量保持在最高標(biāo)準(zhǔn)。此外，測(cè)試自動(dòng)化我認(rèn)為屬于測(cè)試域，屬于研效部的事兒，而非業(yè)務(wù)自己做，他們要考慮工具的持續(xù)迭代，考慮解決通用、抽象的問題，這意味著業(yè)務(wù)的開發(fā)們可以專注于創(chuàng)建更有針對(duì)性的 testcase 并更有效的通過測(cè)試代碼來覆蓋（對(duì)，我說的就是你，刷覆蓋率的，出來挨打）。這點(diǎn)文檔后臺(tái)團(tuán)隊(duì)做的就不錯(cuò)，在我跟他們短暫的合作過程中能感受到他們?cè)谔ぬ?shí)實(shí)的寫能讓自己放心的 UT，并將工具交給更專業(yè)和專注的團(tuán)隊(duì)去負(fù)責(zé)，這里要點(diǎn)名感謝 Testone 后臺(tái)測(cè)試工具鏈的開發(fā)同學(xué)非常接地氣的合作。
說到這里我埋個(gè)小坑，今年的 DORA state of DevOps 2021 report 又重點(diǎn)強(qiáng)調(diào)了持續(xù)測(cè)試，他們指出正在進(jìn)行 DevOps 轉(zhuǎn)型的公司的持續(xù)測(cè)試能力對(duì)能否真正實(shí)現(xiàn)持續(xù)交付有著重大影響，未來我應(yīng)該會(huì)輸出一些關(guān)于持續(xù)測(cè)試的內(nèi)容。
4.3 我該怎么做
我在這里澄清“自動(dòng)化測(cè)試”和“測(cè)試自動(dòng)化”之間的混淆，并不是想爭(zhēng)論命名的歧義，而是概念本身確實(shí)不同。我希望給開發(fā)同學(xué)們普及更廣泛的測(cè)試概念，如果你希望你的團(tuán)隊(duì)能持續(xù)以最高質(zhì)量標(biāo)準(zhǔn)交付軟件，就要懂得更多。自動(dòng)化測(cè)試很重要，尤其是讓開發(fā)人員有信心無畏地重構(gòu)他們的代碼，毫無疑問，這有助于提高代碼質(zhì)量，你已經(jīng)感受到我很克制的在傳遞「自動(dòng)化測(cè)試完全應(yīng)該由開發(fā)人員自行完成」這個(gè)思想。但是，當(dāng)你的團(tuán)隊(duì)或項(xiàng)目開始轉(zhuǎn)向持續(xù)集成/持續(xù)部署（CI/CD）場(chǎng)景時(shí)，測(cè)試自動(dòng)化變得至關(guān)重要，因?yàn)闇y(cè)試不僅要左移也要右移。除此以外還要將測(cè)試行為流程化并且盡可能自動(dòng)化，質(zhì)量不是一道門就可以完全把關(guān)好，而是需要層層把關(guān)，守護(hù)好自己創(chuàng)造出來的東西。當(dāng)你了解了測(cè)試自動(dòng)化這個(gè)更高維度的概念，你便走進(jìn)了如何通向高質(zhì)量產(chǎn)品的大門，你會(huì)發(fā)現(xiàn)質(zhì)量這東西除了測(cè)試工程師，還要跟 Infra/SRE，DevOps 工程師和數(shù)據(jù)工程師等各種角色打交道和密切配合才能追求卓越，精益求精。
來自 EX 測(cè)試的寄語
筆者在騰訊做了近十年的測(cè)試工程師，很多開發(fā)人員因各種理由習(xí)慣性的將隱患甚至顯而易見的問題直接丟給下一個(gè)環(huán)節(jié)也就是測(cè)試，真正發(fā)自內(nèi)心對(duì)質(zhì)量和品質(zhì)有意識(shí)的開發(fā)屈指可數(shù)，不過有個(gè)很有意思的現(xiàn)象是，這些鳳毛菱角的開發(fā)們現(xiàn)在都逐漸擔(dān)做起了管理工作，有的做完需求敢跟我對(duì)賭，一個(gè) bug 一頓飯，利用我來鞭策他提升自己的開發(fā)質(zhì)量；有的當(dāng) bug 輾轉(zhuǎn)多人幾個(gè)月仍未解決的時(shí)候，我就會(huì)想到把 bug 單轉(zhuǎn)給他，即便不是他負(fù)責(zé)的模塊他也會(huì)抽時(shí)間根治，并且很討厭的拉著你說一堆你一點(diǎn)也不想聽的分析過程；當(dāng)年合作時(shí)還沒升技術(shù)高 P 的某位，質(zhì)量意識(shí)之高從現(xiàn)在騰訊會(huì)議這款產(chǎn)品完全能體會(huì)得到。騰訊文檔的開發(fā)們我就不夸了，一來做的確實(shí)還不夠好，二來怕大家驕傲～
我在想，可能沒有天生就對(duì)質(zhì)量有追求或測(cè)試能力強(qiáng)的開發(fā)，但一定有 owner 意識(shí)、責(zé)任心以及合作精神都很強(qiáng)的開發(fā)，他們重視自己所做的項(xiàng)目，重視自己的每一個(gè)產(chǎn)出，重視跟自己合作的伙伴，所以他們?cè)敢饣〞r(shí)間，甚至犧牲時(shí)間去保障質(zhì)量。擁有這樣品質(zhì)的同事，已不僅僅被局限在是一位優(yōu)秀的開發(fā)，一定會(huì)被領(lǐng)導(dǎo)認(rèn)可，被放在更高的位置去影響更多人。
“在計(jì)算機(jī)存在的整個(gè)過程中，如何設(shè)計(jì)軟件以及如何開發(fā)軟件一直是一直討論的中心。沒有哪篇文章像 Frederick P. Brooks 的“No Silver Bullet”那樣成為討論的核心。然而，在他寫下這篇對(duì)知識(shí)的貢獻(xiàn)將近 35 年后，布魯克斯的觀察仍然正確。軟件工程是一個(gè)復(fù)雜且要求很高的領(lǐng)域，它給從業(yè)者帶來了許多問題，并且沒有單一的解決方案，即沒有靈丹妙藥，可以提供一種簡(jiǎn)單的方法來減少創(chuàng)建軟件產(chǎn)品所需的工作?！?/p>
很多開發(fā)者覺得讓開發(fā)為質(zhì)量負(fù)責(zé)，對(duì)開發(fā)們?cè)斐闪撕艽蟮膫?，甚至是一種變相的壓榨。但現(xiàn)在政策和市場(chǎng)暗流涌動(dòng)，互聯(lián)網(wǎng)行業(yè)風(fēng)云變化，快速抓住機(jī)遇和有效保障質(zhì)量之間如何平衡很難抉擇，去測(cè)試化不是銀彈，但不可否認(rèn)是符合趨勢(shì)的一種為未來做人才儲(chǔ)備的手段。至少我們要先學(xué)會(huì)自動(dòng)化測(cè)試，并接受測(cè)試左移和右移的思想，這是軟件測(cè)試發(fā)展的趨勢(shì)，再遠(yuǎn)一些幾十年后會(huì)怎么樣我不知道，當(dāng)下我們只是在嘗試走別人走過的路，僅此而已。
本文經(jīng)授權(quán)轉(zhuǎn)載騰訊云開發(fā)者，如需轉(zhuǎn)載，請(qǐng)聯(lián)系
熱門跟貼