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