想做測(cè)試工程師，這7件事你必須先知道（測(cè)試工程師都要會(huì)什么）

一、“開(kāi)發(fā)者測(cè)試” 就是“開(kāi)發(fā)者來(lái)測(cè)試”

開(kāi)發(fā)者測(cè)試是現(xiàn)代軟件工程中非常重要的一環(huán)，敏捷開(kāi)發(fā)、主干開(kāi)發(fā)這些先進(jìn)的項(xiàng)目管理方法和流程都基于完善的開(kāi)發(fā)者測(cè)試。當(dāng)每個(gè)月甚至每周都要交付一個(gè)版本時(shí)，不可能投入大量的測(cè)試工程師來(lái)進(jìn)行大規(guī)模的系統(tǒng)級(jí)別測(cè)試，這時(shí)候就需要把整個(gè)測(cè)試金字塔中的絕大部分測(cè)試通過(guò)自動(dòng)化來(lái)完成。

我們今天談開(kāi)發(fā)者測(cè)試，什么是“開(kāi)發(fā)者測(cè)試”？ 我司有清晰的開(kāi)發(fā)與測(cè)試之分。寫代碼歸開(kāi)發(fā)攻城獅，測(cè)試歸測(cè)試攻城獅，大部分情況下雙方處于“紅藍(lán)對(duì)峙”狀態(tài)。這與我10多年前的研發(fā)團(tuán)隊(duì)狀況非常相似。而現(xiàn)在的軟件工程，專職的“測(cè)試攻城獅”非常少，很多公司開(kāi)發(fā)測(cè)試比例大于10:1，甚至一些部門沒(méi)有測(cè)試攻城獅一說(shuō)。 而測(cè)試攻城獅的角色不再是手動(dòng)跑測(cè)試用例的“苦力”，而是管理產(chǎn)品的測(cè)試系統(tǒng)，對(duì)產(chǎn)品測(cè)試進(jìn)行規(guī)劃、分析歸納功能測(cè)試思維導(dǎo)圖、設(shè)計(jì)測(cè)試用例及帶領(lǐng)研發(fā)團(tuán)隊(duì)進(jìn)行測(cè)試工作，更像一位“測(cè)試專家/測(cè)試教練”。舉個(gè)簡(jiǎn)單的例子，我之前做的產(chǎn)品是在線視頻會(huì)議協(xié)作產(chǎn)品。我們每天的線上例會(huì)就是用自己做的產(chǎn)品，而且會(huì)使用自己開(kāi)發(fā)的新功能測(cè)試站點(diǎn)來(lái)開(kāi)“站會(huì)”。除了花少量的時(shí)間做dialy update，然后就是測(cè)試專家?guī)ьI(lǐng)團(tuán)隊(duì)（包括PO、架構(gòu)師、SM、Dev）按照計(jì)劃來(lái)進(jìn)行集中（半個(gè)小時(shí)）的測(cè)試。所以說(shuō)“開(kāi)發(fā)者測(cè)試”就是“開(kāi)發(fā)者來(lái)測(cè)試”，而我們傳統(tǒng)的眾多測(cè)試工程師面臨三種出路：成長(zhǎng)、轉(zhuǎn)型、淘汰?！皽y(cè)試專家”在項(xiàng)目中的話語(yǔ)權(quán)也很高，我之前的公司使用主干開(kāi)發(fā)，有個(gè)“一進(jìn)一出”的評(píng)審，團(tuán)隊(duì)的這種類型的“測(cè)試專家”有一票否決權(quán)。甚至在公司有PE級(jí)別的測(cè)試專家（相當(dāng)于我司20-21級(jí)的技術(shù)專家）。

一進(jìn)：對(duì)于一個(gè)功能是否能夠進(jìn)入release branch，在release branch打開(kāi)feature toggle進(jìn)行發(fā)布級(jí)別的測(cè)試。

一出：在engineer release時(shí)，該功能質(zhì)量合格，允許feature toggle進(jìn)入產(chǎn)線。

二、沒(méi)有什么測(cè)試不可以“自動(dòng)化測(cè)試”

回到測(cè)試金字塔，從測(cè)試的"開(kāi)發(fā)成本"、“執(zhí)行成本”、“測(cè)試覆蓋率”、“問(wèn)題定位”四個(gè)維度來(lái)看，基于代碼級(jí)別的白盒測(cè)試是及其重要的。

開(kāi)發(fā)成本： 實(shí)現(xiàn)測(cè)試用例的成本。

執(zhí)行成本：運(yùn)行一次測(cè)試用例的成本。

測(cè)試覆蓋率：我們通常所說(shuō)的line coverage和branch coverage

問(wèn)題定位：測(cè)試出現(xiàn)問(wèn)題，定位問(wèn)題的效率

通過(guò)測(cè)試金字塔及其四個(gè)測(cè)試維度評(píng)估，我們可以得出：

盡可能地多做Low Level Test ：因?yàn)樗麄兊膱?zhí)行速度相較于上層的幾個(gè)測(cè)試類型來(lái)說(shuō)快很多且相對(duì)穩(wěn)定，可以一天多次執(zhí)行。一般來(lái)說(shuō)，LLT灰做到持續(xù)集成構(gòu)建任務(wù)中去，甚至在MR中執(zhí)行，保障進(jìn)入代碼倉(cāng)庫(kù)的代碼質(zhì)量。

在自動(dòng)化保障的情況下，執(zhí)行一定規(guī)模的IT、ST、UI Test：因?yàn)樗麄兊膱?zhí)行速度較慢，環(huán)境依賴較多，測(cè)試先對(duì)不穩(wěn)定。通常在夜里執(zhí)行一次，階段性的檢查代碼質(zhì)量，反饋代碼問(wèn)題。

盡可能地少做大規(guī)模的手動(dòng)測(cè)試：因?yàn)樗麄兊膱?zhí)行速度相較LLT且不夠穩(wěn)定，人力成本較高，也無(wú)法做到一天多次執(zhí)行，每次執(zhí)行都要等很久才能獲得反饋結(jié)果。但是，他們更貼近真實(shí)用戶場(chǎng)景，所以要確保一定周期內(nèi)或者關(guān)鍵節(jié)點(diǎn)時(shí)間執(zhí)行以下這幾個(gè)測(cè)試以確保軟件質(zhì)量。

現(xiàn)在很多公司已經(jīng)迭代發(fā)布的周期越來(lái)越短，甚至做到了2周。手動(dòng)測(cè)試顯然無(wú)法適應(yīng)這種開(kāi)發(fā)模式，而把手動(dòng)測(cè)試的用例通過(guò)各種技術(shù)方案自動(dòng)化是唯一途徑。代碼層面，從底層業(yè)務(wù)代碼到UI代碼，只要架構(gòu)設(shè)計(jì)合理，都是可以做UT。最頂層的UI交互測(cè)試，測(cè)試用例也是可以自動(dòng)化運(yùn)行（大部分UI框架都可以通過(guò)accessibility的接口進(jìn)行UI自動(dòng)化測(cè)試），試想連咱們手機(jī)硬件都可以自動(dòng)化測(cè)試“摔手機(jī)”這種極端測(cè)試，軟件有啥做不到？至少有些業(yè)界技術(shù)大牛公司的某些產(chǎn)品，從代碼提交Merge Request，到產(chǎn)品上產(chǎn)線是可以以天來(lái)計(jì)算的。這種產(chǎn)品的測(cè)試是不會(huì)也不可能通過(guò)手工測(cè)試來(lái)完成的。

三、開(kāi)發(fā)者測(cè)試“利在當(dāng)下”，“贏得未來(lái)”

很多人都認(rèn)為底層的開(kāi)發(fā)者測(cè)試，花了大量的時(shí)間，寫了大量的代碼，然后來(lái)保證功能的正確性，但是每次代碼功能或者結(jié)構(gòu)的的變更都要修改測(cè)試代碼。我手動(dòng)調(diào)試和驗(yàn)證效率更高。的確通過(guò)UT，API測(cè)試來(lái)調(diào)試代碼與自己手動(dòng)運(yùn)行調(diào)試區(qū)別不大，但是通過(guò)開(kāi)發(fā)者測(cè)試對(duì)代碼進(jìn)行調(diào)試，從而保證當(dāng)前項(xiàng)目迭代的質(zhì)量；但是其更重要的作用不是這個(gè)。

我們?cè)赽ug分類中有這樣一些名詞 : Build Regression Bug， Release Regression Bug。

Build Regression Bug ： 開(kāi)發(fā)中同樣的功能在新版本出現(xiàn)一個(gè)bug，但是在之前的版本沒(méi)有這個(gè)問(wèn)題，我們叫做Build Regression Bug。

Release Regression Bug : 產(chǎn)線上同樣的功能在新版本出現(xiàn)一個(gè)bug，但是在之前的版本沒(méi)有這個(gè)問(wèn)題，我們叫做Release Regression Bug。

我們每次commit到產(chǎn)品中的代碼，沒(méi)有人可以保證其100%不會(huì)出現(xiàn)問(wèn)題，在敏捷開(kāi)發(fā)的這種快速迭代下，不太可能進(jìn)行全功能的手動(dòng)測(cè)試，所以開(kāi)發(fā)者測(cè)試，特別是底層的UT、API測(cè)試、集成測(cè)試，能夠很容易的識(shí)別發(fā)現(xiàn)這類問(wèn)題。所以說(shuō)開(kāi)發(fā)者測(cè)試”利在當(dāng)下“，”贏得未來(lái)“。

四、TDD不是必須先寫測(cè)試代碼

對(duì)于TDD，大家的認(rèn)知是先寫測(cè)試代碼，再在寫實(shí)現(xiàn)代碼，這個(gè)說(shuō)法對(duì)也不對(duì)。概念上沒(méi)錯(cuò)，但是如果嚴(yán)格這樣做，效率未必最高，這也是TDD很難推廣的原因之一。我們把編碼實(shí)現(xiàn)分成3個(gè)部分：實(shí)現(xiàn)代碼、測(cè)試代碼、調(diào)試代碼。按照TDD的概念時(shí)先寫測(cè)試代碼、然后編碼，最后調(diào)試。我們通常在代碼實(shí)現(xiàn)時(shí)，一開(kāi)始不大可能考慮的非常清晰，把接口定義的完全準(zhǔn)確，如果嚴(yán)格按照測(cè)試、編碼、調(diào)試來(lái)做，測(cè)試代碼要隨著編碼頻繁修改。 當(dāng)然這本身不是什么大問(wèn)題，在實(shí)際執(zhí)行過(guò)程中，很多人習(xí)慣先搭好代碼框架、測(cè)試框架，然后在編碼，測(cè)試。等測(cè)試完成后在進(jìn)行調(diào)試。所以從華為灰度管理的角度上來(lái)說(shuō)，只要單元測(cè)試在調(diào)試之前，都可以稱作TDD開(kāi)發(fā)模式。BTW，當(dāng)然現(xiàn)在開(kāi)始流行BDD，這里想說(shuō)的是如果連我說(shuō)的TDD都做不到的團(tuán)隊(duì)，就不要考慮BDD了。

（Behavior-Driven Development：BDD將TDD的一般技術(shù)和原理與領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)的想法相結(jié)合。 BDD是一個(gè)設(shè)計(jì)活動(dòng)，您可以根據(jù)預(yù)期行為逐步構(gòu)建功能塊。 BDD的重點(diǎn)是軟件開(kāi)發(fā)過(guò)程中使用的語(yǔ)言和交互。 行為驅(qū)動(dòng)的開(kāi)發(fā)人員使用他們的母語(yǔ)與領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的語(yǔ)言相結(jié)合來(lái)描述他們的代碼的目的和好處。 使用BDD的團(tuán)隊(duì)?wèi)?yīng)該能夠以用戶故事的形式提供大量的“功能文檔”，并增加可執(zhí)行場(chǎng)景或示例。 BDD通常有助于領(lǐng)域?qū)＜依斫鈱?shí)現(xiàn)而不是暴露代碼級(jí)別測(cè)試。它通常以GWT格式定義：GIVEN WHEN＆THEN。）

五、UT覆蓋率100%真的很不好

于單元測(cè)試，我們都會(huì)關(guān)注一個(gè)指標(biāo)“覆蓋率”。不管模塊、函數(shù)、行、分支覆蓋率，必須要有一定比例的覆蓋率。但是每一項(xiàng)你都做到了100%，那么會(huì)給你打“差評(píng)”。不是說(shuō)你做到不好（這里不談是不是用了正確的方式），而是成本和性價(jià)比問(wèn)題。以最難達(dá)到的分支覆蓋率（branch coverage），如果要做到100%的覆蓋率，有些內(nèi)存分配或者容錯(cuò)保護(hù)的分支都必須測(cè)試到，那么你的測(cè)試用例考慮要翻倍，但是并沒(méi)有帶來(lái)的相應(yīng)價(jià)值。甚至一些代碼條件分支在程序運(yùn)行的生命周期內(nèi)都沒(méi)有被執(zhí)行過(guò)。

模塊覆蓋率：業(yè)務(wù)模塊代碼通過(guò)UT，架構(gòu)模塊代碼通過(guò)IT；就從UT的覆蓋率的角度上去看，不需要去測(cè)試架構(gòu)代碼。

函數(shù)覆蓋率：不要為一些無(wú)任何邏輯的代碼去寫UT。比如我們有些函數(shù)就是get/set一個(gè)屬性，內(nèi)部實(shí)現(xiàn)就用一個(gè)變量來(lái)賦值保存。這種函數(shù)寫UT就是為了覆蓋率而寫，沒(méi)有任何真正的意義。

行覆蓋率：通常來(lái)看平局80%上下的行覆蓋率是一個(gè)合理的指標(biāo)，有些可以為0%，而有些需要100%，如果全部代碼都超過(guò)90%，其成本較高，效率較低，不建議這樣做。

分支覆蓋率：越復(fù)雜的業(yè)務(wù)邏輯，越要寫更多的測(cè)試用例來(lái)覆蓋，而一些內(nèi)存分配出錯(cuò)邏輯判斷可以不需要測(cè)試。

六、用測(cè)試來(lái)驅(qū)動(dòng)架構(gòu)和代碼質(zhì)量

這里談測(cè)試驅(qū)動(dòng)架構(gòu)和代碼質(zhì)量，主要說(shuō)的是讓代碼具備完善的可測(cè)試性，什么是代碼的可測(cè)試性？簡(jiǎn)單的說(shuō)就是類與類之間，模塊與模塊關(guān)系解耦，類與類，模塊與模塊通過(guò)接口編程。依賴的接口通過(guò)被動(dòng)注入式傳入，而不是主動(dòng)獲取式。對(duì)于程序正常運(yùn)行時(shí)，所傳入的接口參數(shù)是真實(shí)的業(yè)務(wù)對(duì)象，而做測(cè)試時(shí)，可以傳入fake的模擬實(shí)現(xiàn)。當(dāng)然不是所有的依賴模塊都這樣做，一些與業(yè)務(wù)無(wú)關(guān)的Utility Library，或者一些特定的數(shù)據(jù)對(duì)象實(shí)現(xiàn)，可以直接調(diào)用。

這里我們講到了fake與mock，關(guān)于Test Doubles，基本上的概念如下，具體每種代表什么意義，大家可以自行上網(wǎng)搜索

虛擬對(duì)象（dummy）

存根（stub）

間諜（spy）

模擬對(duì)象（mock）

偽對(duì)象（fake）

當(dāng)前我司大家在做開(kāi)發(fā)者測(cè)試時(shí)，基本上都在用Mock Object（實(shí)際上在用的過(guò)程中，很多是在用入?yún)⒎祷刂悼刂频腟tub）。拋開(kāi)概念上的問(wèn)題，雖然通過(guò)Mock的方式也是可以測(cè)試代碼，但是實(shí)際上用Mock基本上意味著我們的代碼關(guān)聯(lián)性較強(qiáng)，模塊顯示依賴較重，模塊移植性較差，特別是C語(yǔ)言編程這種問(wèn)題特別多。以至于現(xiàn)在很多模塊根本無(wú)法開(kāi)展單元測(cè)試，更多的是在做集成測(cè)試。

為什么會(huì)出現(xiàn)這種情況？ 我們的高級(jí)別的架構(gòu)師更多的在考慮系統(tǒng)級(jí)別的架構(gòu)設(shè)計(jì)，把系統(tǒng)模塊，各個(gè)應(yīng)用之間的關(guān)系梳理的非常清晰，通常情況下，高級(jí)別的架構(gòu)師可以把系統(tǒng)模塊或應(yīng)用之間的關(guān)系設(shè)計(jì)的較為合理。然而到了具體的應(yīng)用業(yè)務(wù)內(nèi)部的設(shè)計(jì)與實(shí)現(xiàn)，交給了低級(jí)別的架構(gòu)師來(lái)完成。實(shí)際上這些模塊內(nèi)部的代碼量并不小，很多都是幾十萬(wàn)行甚至上百萬(wàn)行的代碼量。這時(shí)候架構(gòu)師的水平?jīng)Q定了代碼的Clean Code質(zhì)量。我司目前代碼上的問(wèn)題很多不是系統(tǒng)架構(gòu)的問(wèn)題，而是具體業(yè)務(wù)實(shí)現(xiàn)中，缺少嚴(yán)格的要求和合理的架構(gòu)設(shè)計(jì)。如果在應(yīng)用級(jí)別有一套架構(gòu)方案來(lái)規(guī)范，那么至少在模塊的接口以及模塊與模塊之前的交互上也能達(dá)到和系統(tǒng)設(shè)計(jì)一樣較為清晰合理。那么不確定的部分就時(shí)每個(gè)子模塊內(nèi)部幾千上萬(wàn)行的代碼部分。

之所以提出用測(cè)試驅(qū)動(dòng)架構(gòu)和代碼質(zhì)量，當(dāng)給測(cè)試提出一個(gè)很高的標(biāo)準(zhǔn)時(shí)，大家不得不從架構(gòu)上去解決測(cè)試的問(wèn)題，當(dāng)測(cè)試的問(wèn)題解決時(shí)，Clean Code L3自然而然就達(dá)到了。

七、從“我要寫測(cè)試依賴代碼”到“我要寫測(cè)試依賴代碼”

這句話看著很奇怪，實(shí)際上是從根本上去解決單元測(cè)試的根本方法。 模塊之間有依賴，不管是通過(guò)Mock還是Fake的方法，不管架構(gòu)上如何合理，這種依賴是不能消除的，我們做到更多的是合理的設(shè)計(jì)讓依賴與模塊解耦。第一個(gè)“我要寫測(cè)試依賴代碼”，指的是當(dāng)我實(shí)現(xiàn)我的模塊時(shí)，我要寫測(cè)試代碼來(lái)測(cè)試。而然我要考的是如何寫我的測(cè)試依賴。而第二個(gè)“我要寫測(cè)試依賴代碼”指的是，當(dāng)我實(shí)現(xiàn)我的代碼時(shí)，我要考慮的是依賴我的模塊在測(cè)試時(shí)，對(duì)于我的依賴該怎么解決，"我要寫測(cè)試依賴代碼”（就是我說(shuō)的fake對(duì)象與實(shí)現(xiàn)）來(lái)幫助依賴我的模塊解決測(cè)試依賴問(wèn)題。

思維轉(zhuǎn)變、測(cè)試驅(qū)動(dòng)：開(kāi)發(fā)一個(gè)模塊，不要先考慮怎么測(cè)試自己，先考慮如果別人依賴我，我該怎么讓別人更容易測(cè)試。模塊的提供者，不止要提供模塊代碼，還要提供一個(gè)可復(fù)用的Faked對(duì)象（調(diào)用驗(yàn)證；返回值；參數(shù)驗(yàn)證；參數(shù)處理；功能模擬等）。

模塊代碼的編寫者實(shí)現(xiàn)自己的Fake實(shí)現(xiàn)，基本上大部分的代碼是由模塊編寫者來(lái)完成，同時(shí)這是一個(gè)可復(fù)用的Fake實(shí)現(xiàn)。模塊依賴方根據(jù)自己一些特殊的業(yè)務(wù)需求來(lái)添加自己的代碼?；旧献裱?0/20原則。

架構(gòu)上依賴解耦，通過(guò)注入依賴的方式進(jìn)行接口編程。開(kāi)發(fā)者測(cè)試使用Fake來(lái)實(shí)現(xiàn)依賴。

當(dāng)編寫測(cè)試代碼時(shí)，所有依賴的接口、依賴的實(shí)現(xiàn)都基本完成，更多的關(guān)注些測(cè)試用例而不是測(cè)試依賴。

專家 開(kāi)發(fā)者 自動(dòng)化測(cè)試

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。