說說被遺忘的數(shù)據(jù)庫開發(fā)職業(yè) - 數(shù)據(jù)庫測試

點擊藍色“有關(guān)SQL”關(guān)注我喲

數(shù)據(jù)庫測試，似乎是被人遺忘的數(shù)據(jù)庫職業(yè)，但依然是不錯的選擇。底下是我在某站找的招聘啟事，就連螞蟻金服都在積極尋找數(shù)據(jù)庫測試人：

要說我經(jīng)歷的項目，大大小小也有幾十個，從 C/S, B/S, 再到 B/C/S， M/S. 無論怎么變化，總也離不開 UI/DB 這種框架。

以前 C/S,B/S，自己動手寫寫沒問題，就拿很早的 C/S 架構(gòu)來說，C 代表了客戶端，S 代表了服務(wù)器?？蛻舳丝梢允褂?vb, vfp, delphi, c#, java 來寫，邏輯都放在數(shù)據(jù)庫服務(wù)器上，具體來說，就是封裝在存儲過程里。

而 B/S 時代，客戶端換成了 Browser,也就是瀏覽器，而 S 端還是數(shù)據(jù)庫服務(wù)器。那么 B/S 時代，語言從強編譯性語言，逐步向弱編譯傾斜。Javascript 和 JQuery 就在這個時候應(yīng)運而強。

如果說 C/S,B/S 時代還有全棧程序員，現(xiàn)在如此復(fù)雜的時代，要做到真正全棧，就特別不容易。僅從測試來說，需要的功底一下子就變得豐富至極。

鑒于前端變化太快，我很明智地選擇了 S 端，即數(shù)據(jù)庫服務(wù)器。數(shù)據(jù)庫的測試，相對前端來說，穩(wěn)定得多。

為什么要做數(shù)據(jù)庫測試

一些不同的聲音

大部分反對給數(shù)據(jù)庫做測試的理由，來自兩大類：

一是沒有時間。在開發(fā)和調(diào)優(yōu)上花費的時間夠多了，為什么還要去寫大量的測試用例。

二是測試案例復(fù)雜。針對業(yè)務(wù)復(fù)雜的測試，對數(shù)據(jù)質(zhì)量要求很高，一個沒有設(shè)置好地區(qū)，折扣，渠道的訂單，測試出來的結(jié)果肯定不令人滿意，那么做好一份質(zhì)量高的測試數(shù)據(jù)，本身就需要花費很長時間和精力，對于團隊資源是種低收成的回報。

有個搞笑的段子，大家聽聽：

我們從來不做數(shù)據(jù)庫測試，要做就在生產(chǎn)環(huán)境做

可，認真看過這張圖的朋友，大概是笑不出來的。
在各個階段做測試，出現(xiàn)Bug后，修復(fù)所花的代價是天壤之別。

但做好測試，可以收獲下面這些益處，至于要不要做，完全取決于當前你的團隊：

• 早發(fā)現(xiàn)，早治療

  在數(shù)據(jù)庫開發(fā)領(lǐng)域，手工測試和一次性腳本測試，是最常用的。但不利于找出是否有破壞性的功能缺陷因為新加的特性而引入。有了自動化的測試工具，任何時候針對任何數(shù)據(jù)庫版本，都可隨時完成測試。

  往往尋找一個bug的產(chǎn)生，需要耗費8-16小時，甚至更多，僅僅是因為某個開發(fā)簽入了一個新模塊的代碼，針對數(shù)據(jù)庫開發(fā)來說，沒有特別好的debug工具，只能靠人肉眼去逐行掃描代碼，最終才能定位到某個可疑的地方。但幾千行代碼消耗下來，一天，不熟悉那個模塊的開發(fā)，甚至3，5天也都過去了。

  所以最高效的解決方案莫過于在每次新代碼簽入的時候，我們對其做一次全量的代碼測試，把新版本的測試用例都跑一邊，如果沒有特別的報錯，簽入才算驗收過關(guān)，可簽入發(fā)布版本。一旦這個時候出現(xiàn)Bug,就可以快速跟蹤到代碼和人，進行修復(fù)。

• 2BMore ( to be more ):更有設(shè)計感，更整潔，更具有擴展性。

  往往我們很多開發(fā)都是側(cè)重開發(fā)，炫技，和快速。認為把任務(wù)做完，就是厲害，或者更著急去做新任務(wù)。冥冥之中好像就是有只手推著我們不斷快速的往前沖，爭取更大，更多，更快。這么做，好處是有的，項目進度看上去更快了，老板更開心了，而業(yè)務(wù)也就更加熱衷提需求了。反正你們做那么快，為什么不給你們開發(fā)多開點需求，實現(xiàn)更多功能，讓我們挑著用呢。

  其實更快的實現(xiàn)，只能給程序員增加壓力，一點好處都沒有。沒有及時對之前所作項目的復(fù)盤和整理，靠量的增長，很難完成質(zhì)的飛躍。

  就好比，我們寫SQL， 5000行一個存儲過程也是寫，10個組織結(jié)構(gòu)良好的500行也能寫。但你說5000行與10個500行，哪個
  更有利于人員質(zhì)量的磨練，項目后期的維護呢？一直往前沖的干勁要有，及時吸取和補充理論知識也不能少。我自己也曾做過卯足勁往前沖的前鋒，但那些年除了體重漲了，其他都沒漲。反而這些年，時不時停下來自己反思下，把代碼反復(fù)的重改，才有了現(xiàn)在一點點技術(shù)的積累。

  大概這也是外包，給大家的錯覺。一個個項目的接，平均3-6個月?lián)Q個組，最后弄的自己一直在重復(fù)做相同的事情。業(yè)務(wù)知識倒是知道不少，但積累一個都沒有，樣樣稀松不稀奇。

  而測試思維一旦加入開發(fā)，就能逼著我們?nèi)ニ伎冀怦?。如何拆分一個復(fù)雜的實現(xiàn)，使得代碼更結(jié)構(gòu)化，簡潔和易擴展。

• 減少重構(gòu)風險

  網(wǎng)上有個玩笑，中年（35歲）程序員如何才能保住自己的飯碗？將SQL寫的越長越好，越少人看得懂越好。碰到這樣的祖?zhèn)鞔a，很多新人都是要問候原作者的直系親屬的。我上次說5000行代碼的維護，就已經(jīng)有讀者受不了了。那么怎么規(guī)避這種毫無設(shè)計感的代碼呢？

  還是測試。

  假如一開始，一個用戶需求就是一套測試用例，那么放心的去重構(gòu)吧，愛怎么重構(gòu)就怎么構(gòu)，完了跑下測試就行。但如果沒有測試，你敢動這大幾千行的代碼么，即使你拍著胸脯說，你敢，你老板敢么？

• 保障團隊協(xié)作

  如果說程序員比較宅，不喜歡旅游，可以天天上線解決代碼問題，那么誰還能不生個病呢。如果生病的時候，你負責的代碼出問題了，誰來解決呢？全組都要等一個人才能繼續(xù)往下工作，這種風險也太大了。

  如果有了測試策略，一個人斷了線，另一個人接上，接著往下碼。只要大家都是同一個平臺，接手完全沒有問題。這對數(shù)據(jù)庫開發(fā)就更有利了。無論是sql server, oracle,mysql, 只要測試用例都在，我們的目標就是編寫出通過測試用例的代碼，至于T-SQL, PL/SQL的轉(zhuǎn)換，文檔查查，一點問題沒有。

數(shù)據(jù)庫測試怎么做

那么數(shù)據(jù)庫怎么做測試呢，特別是看到上千行的存儲過程，一大堆的 ETL 程序？作為開發(fā)，完成功能的實現(xiàn)就萬事大吉，但作為測試，既沒有實現(xiàn)功能的大快人心，還必須提心吊膽為最后的質(zhì)量把關(guān)，弄不好，老板認為測試不具備生產(chǎn)力，還要壓低你的薪水，徹底悲劇了你。

既然測試這么難，那么我們怎么保障自己測試的質(zhì)量呢？下面說說我的一些個人看法。

就跟看書一樣，如果拿起一本書從頭看到尾（曾經(jīng)我也是這樣么像教科書一樣看計算機的圖書），那么我敢打賭，一本800頁的數(shù)據(jù)結(jié)構(gòu)，99.99%的人，看到300頁的時候，絕對放棄了，頂多再往后多翻 5 頁，即305頁。然后不停的翻翻后面，數(shù)數(shù)還有多少 頁沒看，還需要花多少時間，不用問為什么我知道，你懂得。

那么我從什么時候開始不這么看書了呢？從看完《CLR Via C#》開始.本書777頁，我花了近 5 個多月，每個禮拜天就躲在家里看，看不下去了，就喝杯星巴克，繼續(xù)看，邊看邊畫。最終一頁不落，全部看完。有些地方還看了不止5遍。還有本手冊，《Oracle Concepts》,大概看了不少于 6 遍，邊看邊畫，每個晚上8點準時看，一直到看不動為止。

那么為什么看完這兩本之后，再也不相信從頭到尾的看書方式了呢？因為好的書，配上好的結(jié)構(gòu)，你看任何 一章，都是可以不需要前面章節(jié)的知識，依舊可以讀的很愉快。如果讀不懂，通過想象力和搜索引擎，反而能解決當下最重要的問題。

因此，讀書最重要的是明白自己想要什么。測試也一樣，必須根據(jù)測試內(nèi)容，而制定測試計劃。如果要測試并發(fā)壓力，就不能用單元測試；要測試新功能，就不能執(zhí)行回歸測試。

那么，數(shù)據(jù)庫測試主要有哪些分類呢？

• 功能性測試，諸如CRUD操作，就要執(zhí)行功能性測試

• 數(shù)據(jù)庫特性測試，比如備份、還原，集群故障切換

• 數(shù)據(jù)庫壓力測試，比如并發(fā)測試，大數(shù)據(jù)量測試

有的同學(xué)會覺得數(shù)據(jù)庫測試很簡單，先 R（retrieve） 一下，再CUD(Create Update Delete) 一波，最后再 R 一下，如果滿足結(jié)果就算測試通過。

畫個圖介紹下，不就是這樣么：

其實，正確的測試應(yīng)該做到這樣：

將測試封裝在一個存儲過程里。

單元測試：單元測試的目的，就是取最小單元的程序，比如一個存儲過程，用測試數(shù)據(jù)來測試它是否完成了我們需要完成的功能。

來自微軟

數(shù)據(jù)庫測試方法

就如電子設(shè)備的評測，我喜歡看王自如，大魔王，何同學(xué)的視頻；影視類設(shè)備的評測，喜歡看影視颶風；而數(shù)據(jù)庫評測，就必須看TPC（很遺憾，我們《有關(guān)SQL》微信公眾號只能算是評測的二道販子）

別看我對評測類視頻那么熱衷，自己做一期，則多半會說的磕磕巴巴，一塌糊涂。對于我這種愛挑戰(zhàn)的人來說，怎么能允許自己有做不好的地方，雖評測電子設(shè)備講得一塌糊涂，但評測數(shù)據(jù)庫，必須專業(yè)啊。數(shù)據(jù)庫怎么去測，測的原理是什么，用的測試方法是什么，絕不能忍受有黑盒啊。

測試組拿著買來的軟件，仿佛他們的工作就只會大聲朗讀這些測試軟件的報告，然后一頓劈頭蓋臉地對我們的應(yīng)用狂噴，是真不解氣！我需要知道真相。

那我們就來好好研究，數(shù)據(jù)庫性能測試的評測方法。也就是怎么去設(shè)計一套評測數(shù)據(jù)庫性能的軟件。我的數(shù)據(jù)庫性能好不好，必須由我說了算。

這套軟件的特點必須是：

1）分布式：模擬從不同設(shè)備訪問數(shù)據(jù)庫，以達到真實的用戶訪問。
2）實時監(jiān)控：如果性能弱的時候沒有及時抓住，那么很可能呢下次帶來更大麻煩的時候，我們依然手足無措。所以在測試階段就必須一擊即中。

《計算機軟件開發(fā)的數(shù)據(jù)庫測試技術(shù)探討》作者牛傳明。

說實話，這篇論文對于我來說，很有收獲。設(shè)計數(shù)據(jù)庫測試軟件，不是一朝一夕的事情，他是一個體系，值得作為職業(yè)。