測(cè)試金字塔實(shí)戰(zhàn)
這是一篇非常漫長(zhǎng)并且艱深的文章的節(jié)選，它解釋了為什么我們需要測(cè)試，以及如何對(duì)軟件進(jìn)行測(cè)試的問(wèn)題。好消息是，這篇文章提供的信息經(jīng)得起時(shí)間推敲，無(wú)論你在構(gòu)建什么樣的軟件都能適用。不管你是工作在一個(gè)微服務(wù)項(xiàng)目上，還是 IoT 設(shè)備上，抑或是手機(jī)應(yīng)用或者網(wǎng)頁(yè)應(yīng)用，這篇文章提供的觀點(diǎn)應(yīng)該都有章可尋。
(測(cè)試)自動(dòng)化的重要性
軟件已經(jīng)成為我們?nèi)粘Ｉ钪械囊粋€(gè)重要組成部分。早期它僅僅用于提高企業(yè)的效率，但如今它的作用遠(yuǎn)不止如此。如今許多公司都想方設(shè)法成為一流的數(shù)字化公司。作為用戶，我們每天使用的軟件越來(lái)越多。創(chuàng)新的車輪正加速向前滾動(dòng)。
如果你想跟上時(shí)代的步伐，你必須研究如何在不犧牲質(zhì)量的情況下更快地交付你的軟件。持續(xù)交付——一種高度自動(dòng)化的、確保你可以隨時(shí)將軟件發(fā)布到生產(chǎn)環(huán)境中的實(shí)踐——正能幫你達(dá)到這個(gè)目的。它通過(guò)構(gòu)建流水線自動(dòng)測(cè)試你的軟件，自動(dòng)將其部署到測(cè)試和生產(chǎn)環(huán)境中。
軟件的數(shù)量正以前所未有的速度增長(zhǎng)，手動(dòng)進(jìn)行構(gòu)建、測(cè)試和部署，很快就會(huì)變得不可能——除非你想把所有的時(shí)間都用來(lái)進(jìn)行手動(dòng)重復(fù)的工作，而不是用來(lái)開發(fā)可工作的軟件。將一切自動(dòng)化，從構(gòu)建到測(cè)試，從部署到基礎(chǔ)架構(gòu)，這是你唯一的出路。
(使用構(gòu)建流水線來(lái)自動(dòng)并可靠地將你的軟件部署到生產(chǎn)環(huán)境)
傳統(tǒng)的軟件測(cè)試過(guò)于依賴手工操作：首先將應(yīng)用程序部署到測(cè)試環(huán)境，然后執(zhí)行一些黑盒測(cè)試，例如，通過(guò)點(diǎn)擊用戶界面來(lái)查看一切是否工作如常。通常這些測(cè)試將由文檔指定，以確保測(cè)試人員每次測(cè)試的內(nèi)容是一致的。
很明顯，手動(dòng)測(cè)試所有更改非常耗時(shí)、重復(fù)而且繁瑣。重復(fù)很無(wú)趣，無(wú)趣就容易犯錯(cuò)，這樣子還沒(méi)測(cè)到這周工作結(jié)束你就會(huì)想找下一份工作了。
幸運(yùn)的是，重復(fù)性勞動(dòng)還是有藥可治的：自動(dòng)化。
自動(dòng)化繁瑣重復(fù)的測(cè)試將給軟件開發(fā)人員的生活帶來(lái)重大改變。自動(dòng)化這些測(cè)試后，你就不需要再一味遵循測(cè)試文檔點(diǎn)點(diǎn)點(diǎn)以確保軟件是否仍正常工作。自動(dòng)化這些測(cè)試，你可以充滿自信地修改你的代碼。如果你曾試過(guò)在沒(méi)有適當(dāng)自動(dòng)化測(cè)試的情況下進(jìn)行大規(guī)模重構(gòu)，那你應(yīng)該知道這種體驗(yàn)多么恐怖。你怎么知道你是否意外地破壞了某些功能呢?顯然，你需要將所有的測(cè)試用例手動(dòng)點(diǎn)一遍。不過(guò)老實(shí)說(shuō)，你真的享受這個(gè)過(guò)程嗎?你想象一下，如果你對(duì)代碼做了大規(guī)模改動(dòng)后愜意地喝了一口咖啡，喝完咖啡后就能馬上得知你的改動(dòng)有沒(méi)有破壞原有功能。這樣的開發(fā)體驗(yàn)是不是聽起來(lái)就讓人舒服多了?
測(cè)試金字塔
如果你真的想為你的軟件構(gòu)建自動(dòng)化測(cè)試，你必須知道一個(gè)關(guān)鍵的概念：測(cè)試金字塔。Mike Cohn 在他的著作《Succeeding with Agile》一書中提出了這個(gè)概念。這個(gè)比喻非常形象，它讓你一眼就知道測(cè)試是需要分層的。它還告訴你每一層需要寫多少測(cè)試。
(測(cè)試金字塔)
根據(jù) Mike Cohn 的測(cè)試金字塔，你的測(cè)試組合應(yīng)該由以下三層組成(自下往上分別是)：
- 單元測(cè)試
- 服務(wù)測(cè)試
- 用戶界面測(cè)試
不幸的是，如果你仔細(xì)思考就會(huì)發(fā)現(xiàn)，測(cè)試金字塔的概念有點(diǎn)太短了。有人認(rèn)為，Mike Cohn 的測(cè)試金字塔里的命名或某些概念不是最理想的。我也同意這一點(diǎn)。從當(dāng)今的角度來(lái)看，測(cè)試金字塔似乎過(guò)于簡(jiǎn)單了，因此可能會(huì)產(chǎn)生誤導(dǎo)。
然而，由于其簡(jiǎn)潔性，在建立你自己的測(cè)試組合時(shí)，測(cè)試金字塔本身是一條很好的經(jīng)驗(yàn)法則。你最好記住 Cohn 測(cè)試金字塔中提到的兩件事：
- 編寫不同粒度的測(cè)試
- 層次越高，你寫的測(cè)試應(yīng)該越少
為了維持金字塔形狀，一個(gè)健康、快速、可維護(hù)的測(cè)試組合應(yīng)該是這樣的：寫許多小而快的單元測(cè)試。適當(dāng)寫一些更粗粒度的測(cè)試，寫很少高層次的端到端測(cè)試。注意不要讓你的測(cè)試變成冰淇淋那樣子，這對(duì)維護(hù)來(lái)說(shuō)將是一個(gè)噩夢(mèng)，并且跑一遍也需要太多時(shí)間。
不要太拘泥于 Cohn 測(cè)試金字塔中各層次的名字。事實(shí)上，它們可能相當(dāng)具有誤導(dǎo)性：服務(wù)測(cè)試是一個(gè)難以掌握的術(shù)語(yǔ)(Cohn 本人說(shuō)他觀察到很多開發(fā)人員完全忽略了這一層)。在單頁(yè)應(yīng)用框架(如 react，angular，ember.js 等)的時(shí)代，UI 測(cè)試顯然不必位于金字塔的最高層，你完全能夠用這些框架對(duì) UI 進(jìn)行單元測(cè)試。
考慮到原始名稱的缺點(diǎn)，只要在你的代碼庫(kù)和團(tuán)隊(duì)討論中達(dá)成一致，你完全可以為測(cè)試層次提供其他名稱。
結(jié)語(yǔ)
我希望這篇文章能對(duì)你有些幫助。有興趣你可以去示例代碼看看，把這里介紹的一些概念納入到你的測(cè)試組合中。想擁有一套穩(wěn)固的測(cè)試組合確實(shí)需要付出努力。但長(zhǎng)遠(yuǎn)來(lái)看，它們是會(huì)給你回報(bào)的，它們會(huì)給作為開發(fā)者的你帶來(lái)更多清凈。相信我。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
