迷陣

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

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

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

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

古話說(shuō)的好，一千個(gè)人心中有一千種單元測(cè)試，看來(lái)說(shuō)的是有道理的。

列表法

(列表法)

這是昨天陪閨女寫作業(yè)的時(shí)候，看到她使用了一種被稱作“列表法”的方法去解一個(gè)小學(xué)2年級(jí)的邏輯題。閨女說(shuō)，這種方法很神奇，原本看起來(lái)彎彎繞的問(wèn)題，畫個(gè)表勾勾叉叉就解決了。

隨后我也查了一下：“列表法是小學(xué)數(shù)學(xué)學(xué)科中經(jīng)常使用的一種方法，使用列表法可以解決許多復(fù)雜而有趣的問(wèn)題。運(yùn)用列出表格來(lái)分析思考、尋找思路、求解問(wèn)題，經(jīng)常用來(lái)解決類似于雞兔同籠的經(jīng)典問(wèn)題……”

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

測(cè)試矩陣

(測(cè)試矩陣)

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

其中***個(gè)維度是測(cè)試實(shí)現(xiàn)的層次或粒度，說(shuō)白了就是在哪個(gè)層次上的測(cè)試，也可以理解成測(cè)試到底測(cè)的是哪兒。是方法?是類?是API?是單個(gè)Service?是兩兩Service?還是應(yīng)用?還是系統(tǒng)?還是平臺(tái)?

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

但是我們?cè)谡務(wù)撨@些測(cè)試的時(shí)候，其實(shí)隱含了一個(gè)概念就是他們測(cè)的是什么?也就是測(cè)試的目標(biāo)。例如當(dāng)我們提到上面的單元測(cè)試、API測(cè)試、端到端測(cè)試的時(shí)候其實(shí)隱含的想表達(dá)的是單元級(jí)別的功能測(cè)試，API級(jí)別的功能測(cè)試和端到端級(jí)別的功能測(cè)試。

這時(shí)候你肯定會(huì)想，這不廢話么，不測(cè)功能我測(cè)什么?

這就是我想說(shuō)的第二個(gè)測(cè)試分類的維度：我們測(cè)試的標(biāo)的物，或是說(shuō)測(cè)試的目標(biāo)。如果說(shuō)***種測(cè)試維度是根據(jù)“測(cè)哪兒”區(qū)分的，那第二個(gè)維度就是根據(jù)“測(cè)什么”區(qū)分的。

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

只不過(guò)我們?nèi)粘９ぷ髦?，大多?shù)情況下測(cè)試都是在驗(yàn)證功能是否正確，所以我們常常忽略了第二個(gè)維度，只關(guān)注于測(cè)哪兒。只有當(dāng)我們?nèi)y(cè)試像性能和安全這種非功能需求的時(shí)候才會(huì)想到第二個(gè)維度，但有趣的是往往我們這時(shí)候又會(huì)忽略***個(gè)維度，例如當(dāng)我們聽到有人提及性能測(cè)試的時(shí)候，并沒(méi)有明確的表達(dá)測(cè)的是方法的性能、API的性能，還是UI的性能，進(jìn)而導(dǎo)致了理解的不一致和混亂。

換個(gè)叫法

可見(jiàn)，之前之所以被測(cè)試迷陣?yán)_，其本質(zhì)原因就是并沒(méi)有明確區(qū)分開這兩個(gè)維度，甚至將之混為一談，從而使我們對(duì)于“XX測(cè)試”的定位和理解包括溝通都變得模糊而不準(zhǔn)確。

如果我們不再提“單元測(cè)試”、“性能測(cè)試”這種含糊不清的概念，而是通過(guò)測(cè)試矩陣上的二維定位法，改稱“方法級(jí)別的功能測(cè)試”和“API級(jí)別的性能測(cè)試”，我想我們對(duì)于測(cè)試的溝通討論甚至學(xué)習(xí)實(shí)現(xiàn)將明確的多，也簡(jiǎn)單的多。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

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