迷陣
“單元測試和橙，集成測試仔燕，端到端測試，安全測試魔招，性能測試涨享，壓力測試，契約測試仆百，冒煙測試，驗(yàn)收測試奔脐，API測試俄周，UI測試，兼容性測試……”
不知道你是不是像我一樣髓迎，曾被這些各種各樣的“測試”搞得暈頭轉(zhuǎn)向峦朗。作為一個(gè)有追求的開發(fā)人員，保證所寫的程序排龄，所構(gòu)建的系統(tǒng)具備良好的質(zhì)量自然是分內(nèi)之事波势。但是面對這些千奇百怪的測試自然望而卻步，只能勸自己一句“專業(yè)的事情還是交給專業(yè)的人去做吧”橄维，然后把測試的工作一把推給QA尺铣，悶頭寫自己的代碼去了。
不光是測試種類眾多争舞，對于某一個(gè)測試的理解凛忿，每個(gè)人也都不一樣。就拿大家最熟悉的“單元測試（unit testing）”來舉例竞川，問題的關(guān)鍵就被聚焦到了到底如何才算是一個(gè)單元（unit）店溢？有人說是一個(gè)方法叁熔，有的人說是一個(gè)類，有的人說都不對床牧，應(yīng)該是一個(gè)最小的業(yè)務(wù)單元（至少是API級別的）荣回。還有人提出了Integration Unit Test的概念，即集成級別的單元測試戈咳。
不光是我等軟件小輩心软，就連很多IT界的神級人物也常常為此爭論不休。
古話說的好除秀，一千個(gè)人心中有一千種單元測試糯累，看來說的是有道理的。
列表法
這是昨天陪閨女寫作業(yè)的時(shí)候册踩，看到她使用了一種被稱作“列表法”的方法去解一個(gè)小學(xué)2年級的邏輯題泳姐。閨女說，這種方法很神奇暂吉，原本看起來彎彎繞的問題胖秒，畫個(gè)表勾勾叉叉就解決了。
隨后我也查了一下：“列表法是小學(xué)數(shù)學(xué)學(xué)科中經(jīng)常使用的一種方法慕的，使用列表法可以解決許多復(fù)雜而有趣的問題阎肝。運(yùn)用列出表格來分析思考、尋找思路肮街、求解問題风题，經(jīng)常用來解決類似于雞兔同籠的經(jīng)典問題……”
雖然我一直沒有搞清楚為啥要把雞和兔子放到一個(gè)籠子里，但回到測試迷陣的問題嫉父，好像這種小學(xué)3年級就教授的方法也能適用沛硅。
測試矩陣
測試的種類繁多，難于理解绕辖，難于溝通摇肌。我覺得主要是在于我們將兩個(gè)測試分類的維度混雜在了一起。
其中第一個(gè)維度是測試實(shí)現(xiàn)的層次或叫粒度仪际，說白了就是在哪個(gè)層次上的測試围小，也可以理解成測試到底測的是哪兒。是方法树碱？是類肯适？是API？是單個(gè)Service成榜？是兩兩Service疹娶？還是應(yīng)用？還是系統(tǒng)伦连？還是平臺雨饺？
我們常說的單元測試钳垮，API測試，端到端測試额港，UI測試都是側(cè)重于按照這種唯獨(dú)去分類不同的測試種類的饺窿。
但是我們在談?wù)撨@些測試的時(shí)候，其實(shí)隱含了一個(gè)概念就是他們測得是什么移斩？也就是測試的目標(biāo)肚医。例如當(dāng)我們提到上邊的單元測試，API測試向瓷，端到端測試的時(shí)候其實(shí)隱含的想表達(dá)的是單元級別的功能測試肠套，API級別的功能測試和端到端級別的功能測試。
這時(shí)候你肯定會想猖任，這不廢話么你稚，不測功能我測什么？
這就是我想說的第二個(gè)測試分類的維度：我們測試的標(biāo)的朱躺，或是說測試的目標(biāo)刁赖。如果說第一種測試維度是根據(jù)“測哪兒”區(qū)分的，那第二個(gè)維度就是根據(jù)“測什么”區(qū)分的长搀。
例如宇弛，我們常常提到的：功能測試，集成測試源请，性能測試枪芒，安全測試，壓力測試谁尸，兼容性測試病苗，契約測試都是這種按照這個(gè)維度去區(qū)分不同的測試種類的，他們都不是關(guān)注于我們要測哪兒症汹，而是更側(cè)重于我們到底要測什么：業(yè)務(wù)功能是否正確？是否能按預(yù)期集成贷腕？是契約是否被保證背镇？是安全能否達(dá)到要求？性能是否滿足預(yù)期和要求泽裳？
只不過我們?nèi)粘９ぷ髦新髡叮蠖鄶?shù)情況下測試都是在驗(yàn)證功能是否正確，所以我們常常忽略了第二個(gè)維度涮总，只關(guān)注于測哪兒胸囱。只有當(dāng)我們?nèi)y試像性能和安全這種非功能需求的時(shí)候才會想到第二個(gè)維度，但有趣的是往往我們這時(shí)候又會忽略第一個(gè)維度瀑梗，例如當(dāng)我們聽到有人提及性能測試的時(shí)候烹笔，并沒有明確的表達(dá)倒是是測的是方法的性能裳扯，API的性能，還是UI的性能谤职，從而導(dǎo)致了理解的不一致和混亂饰豺。
換個(gè)叫法
可見，之前困擾我很久的測試迷陣允蜈，其本質(zhì)原因就是并沒有明確區(qū)分開這兩個(gè)維度冤吨，甚至將之混為一談，從而使我們對于“XX測試”的定位和理解包括溝通都變得模糊而不準(zhǔn)確饶套。
如果我們不再提“單元測試”漩蟆、“性能測試”這種含糊不清的概念，而是通過測試矩陣上的二維定位法妓蛮，改稱“方法級別的功能測試”和“API級別的性能測試”怠李，我想我們對于測試的溝通討論甚至學(xué)習(xí)實(shí)現(xiàn)將明確的多，也簡單的多仔引。
