迷陣

“單元測試，集成測試，端到端測試，安全測試，性能測試，壓力測試，契約測試，冒煙測試，驗收測試，API測試，UI測試，兼容性測試……”

不知道你是不是像我一樣，曾被這些各種各樣的“測試”搞得暈頭轉向。作為一個有追求的開發人員，保證所寫的程序、所構建的系統具備良好的質量自然是分內之事。但是面對這些千奇百怪的測試難免會望而卻步，只能勸自己一句“專業的事情還是交給專業的人去做吧”，然后把測試的工作一把推給QA，悶頭寫自己的代碼去了。

不光是測試種類眾多，每個人對于某一個測試的理解也都不一樣。就拿大家最熟悉的“單元測試(unit testing)”來舉例，問題的關鍵就被聚焦到了“到底如何才算是一個單元(unit)?”有人說是一個方法，有的人說是一個類，有的人說都不對，應該是一個最小的業務單元(至少是API級別的)。還有人提出了Integration Unit Test的概念，即集成級別的單元測試。

不光是我等軟件小輩，就連很多IT界的神級人物也常常為此爭論不休。

古話說的好，一千個人心中有一千種單元測試，看來說的是有道理的。

列表法

(列表法)

這是昨天陪閨女寫作業的時候，看到她使用了一種被稱作“列表法”的方法去解一個小學2年級的邏輯題。閨女說，這種方法很神奇，原本看起來彎彎繞的問題，畫個表勾勾叉叉就解決了。

隨后我也查了一下：“列表法是小學數學學科中經常使用的一種方法，使用列表法可以解決許多復雜而有趣的問題。運用列出表格來分析思考、尋找思路、求解問題，經常用來解決類似于雞兔同籠的經典問題……”

雖然我一直沒有搞清楚為啥要把雞和兔子放到一個籠子里，但回到測試迷陣的問題，好像這種小學3年級就教授的方法也能適用。

測試矩陣

(測試矩陣)

測試的種類繁多，難于理解，難于溝通。我覺得主要是在于我們將兩個測試分類的維度混雜在了一起。

其中***個維度是測試實現的層次或粒度，說白了就是在哪個層次上的測試，也可以理解成測試到底測的是哪兒。是方法?是類?是API?是單個Service?是兩兩Service?還是應用?還是系統?還是平臺?

我們常說的單元測試，API測試，端到端測試，UI測試都是側重于按照這種維度去分類不同的測試種類的。

但是我們在談論這些測試的時候，其實隱含了一個概念就是他們測的是什么?也就是測試的目標。例如當我們提到上面的單元測試、API測試、端到端測試的時候其實隱含的想表達的是單元級別的功能測試，API級別的功能測試和端到端級別的功能測試。

這時候你肯定會想，這不廢話么，不測功能我測什么?

這就是我想說的第二個測試分類的維度：我們測試的標的物，或是說測試的目標。如果說***種測試維度是根據“測哪兒”區分的，那第二個維度就是根據“測什么”區分的。

例如，我們常常提到的：功能測試、集成測試、性能測試、安全測試、壓力測試、兼容性測試，契約測試都是這種按照這個維度去區分不同的測試種類的，他們都不是關注于我們要測哪兒，而是更側重于我們到底要測什么：業務功能是否正確?是否能按預期集成?契約是否被保證?安全能否達到要求?性能是否滿足預期和要求?

只不過我們日常工作中，大多數情況下測試都是在驗證功能是否正確，所以我們常常忽略了第二個維度，只關注于測哪兒。只有當我們去測試像性能和安全這種非功能需求的時候才會想到第二個維度，但有趣的是往往我們這時候又會忽略***個維度，例如當我們聽到有人提及性能測試的時候，并沒有明確的表達測的是方法的性能、API的性能，還是UI的性能，進而導致了理解的不一致和混亂。

換個叫法

可見，之前之所以被測試迷陣困擾，其本質原因就是并沒有明確區分開這兩個維度，甚至將之混為一談，從而使我們對于“XX測試”的定位和理解包括溝通都變得模糊而不準確。

如果我們不再提“單元測試”、“性能測試”這種含糊不清的概念，而是通過測試矩陣上的二維定位法，改稱“方法級別的功能測試”和“API級別的性能測試”，我想我們對于測試的溝通討論甚至學習實現將明確的多，也簡單的多。

【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】

戳這里，看該作者更多好文