建站
咨詢
售后
建站咨詢
新聞中心
由于數(shù)據(jù)應(yīng)用開發(fā)和功能性軟件系統(tǒng)開發(fā)存在很大的不同，在我們實踐過程中，在開發(fā)人員和質(zhì)量保證人員間常常有大量關(guān)于測試如何實施的討論。下文將嘗試總結(jié)一下數(shù)據(jù)應(yīng)用開發(fā)的特點，并討論在這些特點之下，對應(yīng)的測試策略應(yīng)該是怎么樣的。
創(chuàng)新互聯(lián)公司2013年至今，先為武定等服務(wù)建站，武定等地企業(yè)，進行企業(yè)商務(wù)咨詢服務(wù)。為武定企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
功能性軟件的測試
先來回顧一下功能性軟件系統(tǒng)開發(fā)中的測試。
測試一般分為自動化測試和手工測試。由于手工測試對人工依賴程度很高，如果主要依賴手工測試來保證軟件質(zhì)量，將無法滿足軟件快速迭代上線的需要?，F(xiàn)代軟件開發(fā)越來越強調(diào)自動化測試的作用，這也是敏捷軟件開發(fā)的基本要求。有了全方位的自動化測試保障，就有可能做到每周上線，每日上線甚至隨時上線。
這里主要討論自動化測試。
測試金字塔
我們一般會按照如下測試金字塔的原則來組織自動化測試。
測試金字塔分為三層，自下而上分別對應(yīng)單元測試、集成測試、端到端測試。
單元測試是指函數(shù)或類級別的，較小范圍代碼的測試，一般不依賴外部系統(tǒng)（可通過Mock或測試替身等實現(xiàn)）。單元測試的特點是運行速度非常快（最好全部在內(nèi)存中運行），所以執(zhí)行這種測試的成本也就很低。單元測試在測試金字塔的最底端，占的面積最大。這指導(dǎo)我們應(yīng)該構(gòu)建大量的這類測試，并以這類測試為主來保證軟件質(zhì)量。
集成測試是比單元測試集成程度更高的測試，它在運行時執(zhí)行的代碼路徑更廣，通常會依賴數(shù)據(jù)庫、文件系統(tǒng)等外部環(huán)境。由于依賴了外部環(huán)境，集成測試的運行速度更慢，執(zhí)行測試的成本更高。集成測試在測試金字塔的中間，這指導(dǎo)我們應(yīng)該構(gòu)建中等數(shù)量的這類測試。集成測試在Web應(yīng)用場景中也常常被稱為服務(wù)測試（Service Test）或API測試。
端到端測試是比集成測試更靠后的測試，通常通過直接模擬用戶操作來構(gòu)建這樣的測試。由于需要模擬用戶操作，所以它常常需要依賴一整套完整集成好的環(huán)境，這樣一來，其運行速度也是最慢的。端到端測試在Web應(yīng)用場景中也常常被稱為UI測試。端到端測試在測試金字塔的頂端，這指導(dǎo)我們應(yīng)該構(gòu)建少量的這類測試。
測試的范圍非常廣，實施方法也非常靈活。哪里是重點？我們要在哪里發(fā)力？測試金字塔為我們指明了方向。
進入測試金字塔
為了更深入地理解一般軟件的測試要怎么做，我們需要進一步深入分析一下測試金字塔。
測試帶來的信心
上文中的金字塔圖示有一個特點并沒有反映出來，那就是，越上層的測試給團隊帶來的信心越強。這還算好理解，試想，如果沒有單元測試，只有端到端測試，我們是不是可以認(rèn)為程序大部分還是可以正常工作的（可能存在一些邊界場景有問題）？但是如果只有單元測試而沒有端到端測試，我們連程序能不能運行都不知道！
端到端測試能帶來很強的信心，但這常常構(gòu)成另一個陷阱。由于端到端測試對團隊有很大的吸引力，一些團隊可能會選擇直接構(gòu)建大量的端到端測試而忽略單元測試。這些端到端測試運行緩慢，一般也難以修改，很快就會讓團隊舉步維艱。緩慢的測試帶來了緩慢的持續(xù)集成，高頻率的上線就慢慢變得遙不可及。
單元測試雖然不能直接給人很強的信心，但是常常是更有效的測試手段，因為它可以很容易的覆蓋到各種邊界場景。
測試金字塔是敏捷軟件開發(fā)所推崇的測試原則，它是在測試帶來的信心和測試本身的可維護性兩者中權(quán)衡做出的選擇。測試金字塔可以指導(dǎo)我們構(gòu)建足夠的測試，使得團隊既對軟件質(zhì)量有足夠的信心，又不會有太多的測試維護負擔(dān)。
既然是權(quán)衡，那么我們是否可以以單元測試和集成測試為主，而根本不構(gòu)建端到端測試（此時端到端測試的功能通過手工測試完成）呢？
測試集成度
對于一些沒有UI（或者說GUI）的應(yīng)用，或者一些程序庫、框架（如Spring）等，很多時候測試金字塔中的三類測試并不直接適用。我們可以這樣理解：測試金字塔并非只是三層，它更多的是幫我們建立了在項目中組織測試的原則。
事實上，對于通用的軟件測試，我們可以理解為存在一個集成度的屬性。沿著金字塔往上，測試的集成度越高（依賴外部組件越多）。由于集成度更高，測試過程所要運行的代碼就更多更復(fù)雜，測試運行時間就越長，測試構(gòu)建和維護成本就越高。實踐過程中，為了提高軟件質(zhì)量和可維護性，我們應(yīng)當(dāng)構(gòu)建更多集成度低的測試。
有了測試集成度的理解，我們就可以知道，其實金字塔可以不是三層，它完全可以是兩層或者四層、五層。這取決于我們怎么劃定某一類測試的范圍。同時，我們還可以知道，其實單元測試、集成測試與端到端測試其實并沒有特別明顯的界限。
下面，我們從測試集成度的角度來看如何構(gòu)建單元測試。
上文提到，測試最好通過Mock或測試替身等實現(xiàn)，從而可以不依賴外部系統(tǒng)。但是，如果測試Mock或測試替身難以構(gòu)造，或者構(gòu)造之后我們發(fā)現(xiàn)測試代碼和產(chǎn)品代碼耦合非常嚴(yán)重，這時應(yīng)該怎么辦呢？一個可能的選擇是考慮使用更高集成度的測試。
Spark程序就是這樣的一個例子。一旦使用了Spark的DataFrame API去編寫代碼，我們就幾乎無法通過Mock Spark的API或構(gòu)造一個Spark測試替身的方式編寫測試。這時的測試就只能退一步選擇集成度更高一些的測試，比如，啟動一個本地的Spark環(huán)境，然后在這個環(huán)境中運行測試。
此時，上面的測試屬于哪種測試呢？如果我們用三層測試金字塔的測試劃分來看待問題，就很難給這樣的測試一個準(zhǔn)確的定位。不過，通常我們無需考慮這樣的分類，而是可以把它當(dāng)做集成度低的測試，即金字塔靠底端的測試。如果團隊成員能達成一致，我們可以稱其為單元測試，如果不能，稱其為Spark測試也并非不可。
何時停止測試
所以，對于一般的軟件測試，我們可以認(rèn)為測試策略應(yīng)當(dāng)符合一般意義的金字塔。金字塔的細節(jié)，比如應(yīng)該有幾層塔，每一層的范圍應(yīng)該是什么樣，每一層應(yīng)該用什么樣的測試技術(shù)等等，這些問題需要根據(jù)具體的情況進行抉擇。
在討論一般軟件的測試時，需要關(guān)注軟件的測試何時停止，即，如何判斷軟件測試已經(jīng)足夠了呢？
在老馬的《重構(gòu) 第二版》中，有對于何時停止測試的觀點：
有一些測試規(guī)則建議會嘗試保證我們測試一切的組合，雖然這些建議值得了解，但是實踐中我們需要適可而止，因為測試達到一定程度之后，其邊際效用會遞減。如果編寫太多測試，我們可能因為工作量太大而氣餒。我們應(yīng)該把注意力集中在最容易出錯的地方，最沒有信心的地方。
一些測試的指標(biāo)，如覆蓋率，能一定程度上衡量測試是否全面而有效，但是最佳的衡量方式可能來自于主觀的感受，如果我們覺得對代碼比較有信心，那就說明我們的測試做的不錯了。
主觀的信心指數(shù)可能是衡量測試是否足夠的重要參考。如果要問測試是否足夠，我們要自問是否有信心軟件能正常工作。
在實踐過程中，我們還可以嘗試分析每次bug出現(xiàn)的原因，如果是由于大部分bug是由于代碼沒有測試覆蓋而產(chǎn)生的，此時我們可能應(yīng)該編寫更多的測試。但如果是由于其他的原因，比如需求分析不足或場景設(shè)計不完備而導(dǎo)致的，則應(yīng)該在對應(yīng)的階段做加強，而不是一味的去添加測試。
數(shù)據(jù)應(yīng)用的測試
有了前面對測試策略的分析，我們來看看數(shù)據(jù)應(yīng)用的測試策略。
數(shù)據(jù)應(yīng)用相比功能性軟件有很大的不同，但數(shù)據(jù)應(yīng)用也屬于一般意義上的軟件。數(shù)據(jù)應(yīng)用有哪些特點，應(yīng)該如何針對性的做測試呢？下面我們來探討一下這幾個問題。
根據(jù)前面的文章分析，數(shù)據(jù)應(yīng)用中的代碼可以大致分為四類：基礎(chǔ)框架（如增強SQL執(zhí)行器）、以SQL為主的ETL腳本、SQL自定義函數(shù)（udf）、數(shù)據(jù)工具（如前文提到的DWD建模工具）。
基礎(chǔ)框架的測試
基礎(chǔ)框架代碼是數(shù)據(jù)應(yīng)用的核心代碼，它不僅邏輯較為復(fù)雜，而且需要在生產(chǎn)運行時支持大量的ETL的運行。誰也不想提交了有問題的基礎(chǔ)框架代碼而導(dǎo)致大規(guī)模的ETL運行失敗。所以我們應(yīng)當(dāng)非常重視基礎(chǔ)框架的測試，以保證這部分代碼的高質(zhì)量。
基礎(chǔ)框架的代碼通常由Python或Scala編寫，由于Python和Scala語言本身都有很好的測試支持，這十分有利于我們做測試。
基礎(chǔ)框架的另一個特點是它通常沒有GUI。
按照測試金字塔原理，我們應(yīng)當(dāng)為其建立更多的集成度低的測試（下文稱單元測試）以及少量的集成度高的測試（下文稱集成測試）。
比如，在前面的文章中，我們增強了SQL的語法，加入了變量、函數(shù)、模板等新的語法元素。在運行時進行變量替換、函數(shù)調(diào)用等等功能通過基礎(chǔ)框架實現(xiàn)。這部分功能邏輯較為復(fù)雜，應(yīng)當(dāng)建立更多的單元測試及少量的集成測試。
ETL腳本的測試
ETL腳本的測試可能是數(shù)據(jù)應(yīng)用中的最大難點。
采用偏集成的測試
ETL腳本一般基于SQL實現(xiàn)。SQL本身是一個高度定制化的DSL，如同XML配置一樣。
XML要如何測試？很多團隊可能會直接忽略這類測試。但是用SQL編寫的ETL代碼有時候還是可以達到幾百行的規(guī)模，有較多的邏輯，不測試的話難以給人以信心。如何測試呢？
如果采用基于Mock的方法寫測試，我們會發(fā)現(xiàn)測試代碼跟產(chǎn)品代碼是一樣的。所以，這樣做意義不大。
如果采用高集成度的測試方式（下文稱集成測試），即運行ETL并比對結(jié)果，我們將發(fā)現(xiàn)測試的編寫和維護成本都較高。由于ETL腳本代碼本身可能是比較簡單且不易出錯的，為了不易出錯的代碼編寫測試本身就必要性不高，更何況測試的編寫和維護成本還比較高。這就顯得集成測試這一做法事倍功半。
這里可以舉一個例子。比如對于一個分組求和并排序輸出的SQL，它的代碼可能是下圖這樣的。
如果我們?nèi)?zhǔn)備輸入數(shù)據(jù)和輸出數(shù)據(jù)，考慮到各種數(shù)據(jù)的組合場景，我們可能會花費很多的時間，這帶來了較高的測試編寫成本。并且，當(dāng)我們要修改SQL時，我們還不得不修改測試，這帶來了維護成本。當(dāng)我們要運行這個測試時，我們不得不完成建表、寫數(shù)據(jù)、運行腳本、比對結(jié)果的整個過程。這些過程都需要依賴外部系統(tǒng)，從而導(dǎo)致測試運行緩慢。這也是高維護成本的體現(xiàn)。
可見這兩種測試方式都不是好的測試方式。
測試構(gòu)建原則
那么有沒有什么好的原則呢？我們從實踐中總結(jié)出了幾點比較有價值的思路供大家參考：
(1) 將ETL腳本分為簡單ETL和復(fù)雜ETL（可以通過代碼行數(shù)，數(shù)據(jù)篩選條件多少等進行衡量）。簡單的ETL通過代碼評審或結(jié)對編程來保證代碼質(zhì)量，不做自動化測試。復(fù)雜的ETL通過建立集成測試來保證質(zhì)量。
(2) 由于集成測試運行較慢，可以考慮：
- 盡量少點用例數(shù)量，將多個用例合并為一個來運行（主要是將數(shù)據(jù)可以合并成單一的一套數(shù)據(jù)來運行）
- 將測試分級為需要頻繁運行的測試和無需頻繁運行的測試，比如可將測試分級P0-P5，P3-P5是經(jīng)常（如每天或每次代碼提交）要運行的測試，P0-P2可以低頻（如每周）運行
- 開發(fā)測試支持工具，使得運行時可以盡量脫離緩慢的集群環(huán)境。如使用Spark讀寫本地表
(3) 考慮將復(fù)雜的邏輯使用自定義函數(shù)實現(xiàn)，降低ETL腳本的復(fù)雜度。對自定義函數(shù)建立完整的單元測試。
(4) 將復(fù)雜的ETL腳本拆分為多個簡單的ETL腳本實現(xiàn)，從而降低單個ETL腳本的復(fù)雜度。
加深對業(yè)務(wù)和數(shù)據(jù)的理解
我們在實踐過程中發(fā)現(xiàn)，其實大多數(shù)時候ETL腳本的問題不在于代碼寫錯了，而在于對業(yè)務(wù)和數(shù)據(jù)理解不夠。比如，前面文章中的空調(diào)銷售的例子，如果我們在統(tǒng)計銷量的時候不知道存在退貨或者他店調(diào)貨的業(yè)務(wù)實際情況，那我們就不知道數(shù)據(jù)中還有一些字段能反映這個業(yè)務(wù)，也就不能正確的計算銷量了。
想要形成對數(shù)據(jù)的深入理解需要對長時間的業(yè)務(wù)知識積累和長時間對數(shù)據(jù)的探索分析（業(yè)務(wù)系統(tǒng)通常經(jīng)歷了長時間的發(fā)展，在此期間內(nèi)業(yè)務(wù)規(guī)則復(fù)雜性不斷增加，導(dǎo)致數(shù)據(jù)的復(fù)雜性不斷增加）。對于剛加入團隊的新人，他們更容易由于沒有考慮到某些業(yè)務(wù)情況而導(dǎo)致數(shù)據(jù)計算錯誤。
加深對業(yè)務(wù)和數(shù)據(jù)的理解是進行高效和高質(zhì)量ETL腳本開發(fā)的必由之路。
有沒有什么好的實踐方法可以幫助我們加深理解呢？以下幾點是我們在實踐中總結(jié)的值得參考的建議：
- 通過思維導(dǎo)圖/流程圖來整理復(fù)雜的業(yè)務(wù)流程（或業(yè)務(wù)知識），形成知識庫
- 盡量多的進行數(shù)據(jù)探索，發(fā)掘容易忽略的領(lǐng)域業(yè)務(wù)知識，并通過第一步進行記錄
- 找業(yè)務(wù)系統(tǒng)團隊溝通，找出更多的領(lǐng)域業(yè)務(wù)知識，并通過第一步進行記錄
- 如果有條件，可以更頻繁的實地使用業(yè)務(wù)系統(tǒng)，總結(jié)更多的領(lǐng)域業(yè)務(wù)知識，并通過第一步進行記錄
- 針對第一步搜集到的這些容易忽略的特定領(lǐng)域業(yè)務(wù)流程，設(shè)計自動化測試用例進行覆蓋
SQL自定義函數(shù)的測試
在基于Hadoop的分布式數(shù)據(jù)平臺環(huán)境下，SQL自定義函數(shù)通常通過Python或Scala編寫。由于這些代碼通常對外部的依賴很少，通常只是單純的根據(jù)輸入數(shù)據(jù)計算得到輸出數(shù)據(jù)，所以對這些代碼建立測試是十分容易的事。事實上，我們很容易實現(xiàn)100%的測試覆蓋率。
在組織測試時，我們可以用單元測試的方式，不依賴計算框架。比如，以下Scala編寫的自定義函數(shù)：
對其建立測試時，可以直接測試內(nèi)部的轉(zhuǎn)換函數(shù)array_join_f，一些示例的測試場景比如：
在建立了單元測試之后，一般還需要考慮建立少量的集成測試，即通過Spark框架運行SQL來測試此自定義函數(shù)，一個示例可以是：
如果自定義函數(shù)本身十分簡單，我們也可以直接通過Spark測試來覆蓋所有場景。
從上面的討論可以看出，SQL自定義函數(shù)是很容易測試的。除了好測試之外，SQL自定義函數(shù)還有很多好的特性，比如可以很好的降低ETL復(fù)雜度，可以很方便的被復(fù)用等。所以，我們應(yīng)該盡量考慮將復(fù)雜的業(yè)務(wù)邏輯通過自定義函數(shù)封裝起來。這也是業(yè)界數(shù)據(jù)開發(fā)所建議的做法（大多數(shù)的數(shù)據(jù)開發(fā)框架都對自定義函數(shù)提供了很好的支持，如Hive Presto ClickHouse等，大多數(shù)ETL開發(fā)工具也都支持自定義函數(shù)的開發(fā)）。
數(shù)據(jù)工具的測試
數(shù)據(jù)工具的實例可以參考文章《數(shù)據(jù)倉庫建模自動化》和《數(shù)據(jù)開發(fā)支持工具》。
這些工具的一大特點是，它們是用于支持ETL開發(fā)的，僅在開發(fā)過程中使用。由于它們并不是在產(chǎn)品環(huán)境中運行的代碼，所以我們可以降低對其的質(zhì)量要求。
這些工具通常只是開發(fā)人員為了提高開發(fā)效率而編寫的代碼，存在較大的修改和重構(gòu)的可能，所以，過早的去建立較完善的測試必要性不高。
在我們的實踐過程中，這類代碼通常只有很少的測試，我們只對那些特別復(fù)雜、沒有信心能正確工作的地方建立單元測試。如果這些工具代碼是通過TDD的方式編寫的，通常其測試會更多一些。
在持續(xù)集成流水線中運行測試
前面我們討論了如何針對數(shù)據(jù)應(yīng)用編寫測試，還有一個關(guān)于測試的重要話題，那就是如何在持續(xù)交付流水線中運行這些測試。
在功能性軟件項目中，如果我們按照測試金字塔的三層來組織測試，那么在流水線中一般就會對應(yīng)三個測試過程。
從上面的討論可知，數(shù)據(jù)應(yīng)用的測試被縱向分為四條線，如何對應(yīng)到流水線上呢？如果我們采用同一個代碼庫管理所有的代碼，可以考慮直接將流水線分為四條并行的流程，分別對應(yīng)這四條線。如果是不同的代碼庫，則可以考慮對不同的代碼庫建立不同的流水線。在每條流水線內(nèi)部，就可以按照單元測試、低集成測試、高集成測試這樣的方式組織流水線任務(wù)。
1.獨立的ETL流水線
對于ETL代碼的測試，有一個值得思考的問題。那就是，ETL腳本之間通常獨立性非常強，相互之間沒有依賴。這是由于ETL代碼常常由完善的領(lǐng)域特定語言SQL開發(fā)而成，與Python或Scala等通用編程語言編寫的代碼不同，SQL文件之間是沒有依賴的（如果說有依賴，那也是通過數(shù)據(jù)庫表產(chǎn)生依賴）。
既然如此，假設(shè)我們修改了某一個ETL文件的代碼，是不是我們可以不用運行其他的ETL文件的測試呢？其實不僅如此，我們甚至可以單獨上線部署此ETL，而不是一次性部署所有的ETL。這在一定程度上還降低了部署代碼帶來的風(fēng)險。
有了上面的發(fā)現(xiàn)，我們可能要重新思考數(shù)據(jù)應(yīng)用的持續(xù)交付流水線組織形式。
一個可能的辦法是為每一個ETL文件建立一個流水線，完成測試、部署的任務(wù)。此時每個ETL可以理解為一個獨立的小程序。
這樣的想法在實踐中不容易落地，因為這將導(dǎo)致大量的流水線存在（常常有上百條），從而給流水線工具帶來了很大的壓力。常用的流水線工具，如Jenkins，其設(shè)計是難以支撐這么大規(guī)模的流水線的創(chuàng)建和管理的。
要如何來支持上面這樣的ETL流水線呢？可能需要我們開發(fā)額外的流水線工具才行。
2.云服務(wù)中的ETL流水線
現(xiàn)在的一些云服務(wù)廠商在嘗試這樣做。他們通常會提供一個基于Web的ETL開發(fā)工具，同時會提供工具對當(dāng)前的ETL的編寫測試。此時，ETL開發(fā)人員可以在一個地方完成開發(fā)、測試、上線，這可以提高開發(fā)效率。
這類服務(wù)的一個常見缺點在于它嘗試用一套Web系統(tǒng)來支持所有的ETL開發(fā)過程，這帶來了大量繁雜的配置。這其實是將ETL開發(fā)過程的復(fù)雜性轉(zhuǎn)化為了配置的復(fù)雜性。相比編寫代碼而言，多數(shù)開發(fā)人員不會喜歡這樣的工作方式。（當(dāng)前軟件開發(fā)所推崇的是Everthing as Code的做法，嘗試將所有開發(fā)相關(guān)過程中的東西代碼化，從而可以更好的利用成熟的代碼編輯器、版本管理等功能。而Web配置的方式與Everthing as Code背道而馳。）
對于這些數(shù)據(jù)云服務(wù)廠商提供的數(shù)據(jù)開發(fā)服務(wù)，如果可以同時支持通過代碼和Web界面配置來實現(xiàn)數(shù)據(jù)開發(fā)，那將能得到更多開發(fā)者的喜愛。這在我看來是一個不錯的發(fā)展方向。
總結(jié)
由于數(shù)據(jù)應(yīng)用開發(fā)有很強的獨特的特點（比如以SQL為主、有較多的支撐工具等），其測試與功能性軟件開發(fā)的測試也存在很大的不同。
本文分析了如何在測試金字塔的指導(dǎo)下制定測試策略。測試金字塔不僅可以很好的指導(dǎo)功能性軟件開發(fā)，在進行一般意義上的推廣之后，可以很容易得到一般軟件的測試策略。關(guān)于測試金字塔，本文分析了測試帶來的質(zhì)量信心及測試集成度，這兩個概念可以幫助我們更深刻的理解測試金字塔背后的指導(dǎo)原則。
在最后，結(jié)合我們的實踐經(jīng)驗，給出了一些數(shù)據(jù)應(yīng)用中的測試構(gòu)建實踐。將數(shù)據(jù)應(yīng)用分為四個不同模塊來分別構(gòu)建測試，可以很好的應(yīng)對數(shù)據(jù)應(yīng)用中的質(zhì)量要求，同時保證有較好的可維護性。最后，我們討論了如何在持續(xù)集成流水線中設(shè)計測試任務(wù)，留下了一個有待探索的方向，即如何針對單個ETL構(gòu)建流水線。
數(shù)據(jù)應(yīng)用的質(zhì)量保證是不容易做到的，常常需要我們進行很多的權(quán)衡取舍才能找到最適合的方式。想要解決這一問題，還要發(fā)揮團隊中所有人的能動性，多總結(jié)和思考才行。
分享標(biāo)題：用測試金字塔指導(dǎo)數(shù)據(jù)應(yīng)用的測試
網(wǎng)站路徑：http://m.fisionsoft.com.cn/article/coehdpi.html
