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