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

要說我經(jīng)歷的項(xià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 時代，語言從強(qiáng)編譯性語言，逐步向弱編譯傾斜。Javascript 和 JQuery 就在這個時候應(yīng)運(yùn)而生。

如果說 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èi)的時間夠多了，為什么還要去寫大量的測試用例。
• 二是測試案例復(fù)雜。針對業(yè)務(wù)復(fù)雜的測試，對數(shù)據(jù)質(zhì)量要求很高，一個沒有設(shè)置好地區(qū)，折扣，渠道的訂單，測試出來的結(jié)果肯定不令人滿意，那么做好一份質(zhì)量高的測試數(shù)據(jù)，本身就需要花費(fèi)很長時間和精力，對于團(tuán)隊(duì)資源是種低收成的回報。

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

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

可，認(rèn)真看過這張圖的朋友，大概是笑不出來的。

在各個階段做測試，出現(xiàn)Bug后，修復(fù)所花的代價是天壤之別。

但做好測試，可以收獲下面這些益處，至于要不要做，完全取決于當(dāng)前你的團(tuán)隊(duì)：

早發(fā)現(xiàn)，早治療在數(shù)據(jù)庫開發(fā)領(lǐng)域，手工測試和一次性腳本測試，是最常用的。

但不利于找出是否有破壞性的功能缺陷因?yàn)樾录拥奶匦远?。有了自動化的測試工具，任何時候針對任何數(shù)據(jù)庫版本，都可隨時完成測試。

往往尋找一個bug的產(chǎn)生，需要耗費(fèi)8-16小時，甚至更多，僅僅是因?yàn)槟硞€開發(fā)嵌入了一個新模塊的代碼，針對數(shù)據(jù)庫開發(fā)來說，沒有特別好的debug工具，只能靠人肉眼去逐行掃描代碼，最終才能定位到某個可疑的地方。

減少重構(gòu)風(fēng)險網(wǎng)上有個玩笑，中年(35歲)程序員如何才能保住自己的飯碗?將SQL寫的越長越好，越少人看得懂越好。碰到這樣的祖?zhèn)鞔a，很多新人都是要問候原作者的直系親屬的。我上次說5000行代碼的維護(hù)，就已經(jīng)有讀者受不了了。

那么怎么規(guī)避這種毫無設(shè)計感的代碼呢?還是測試。假如一開始，一個用戶需求就是一套測試用例，那么放心的去重構(gòu)吧，愛怎么重構(gòu)就怎么構(gòu)，完了跑下測試就行。但如果沒有測試，你敢動這大幾千行的代碼么，即使你拍著胸脯說，你敢，你老板敢么?

保障團(tuán)隊(duì)協(xié)作如果說程序員比較宅，不喜歡旅游，可以天天上線解決代碼問題，那么誰還能不生個病呢。如果生病的時候，你負(fù)責(zé)的代碼出問題了，誰來解決呢?全組都要等一個人才能繼續(xù)往下工作，這種風(fēng)險也太大了。

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

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

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

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

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

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

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

因此，讀書最重要的是明白自己想要什么。測試也一樣，必須根據(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é)果就算測試通過。

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

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

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

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

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

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

這套軟件的特點(diǎn)必須是：

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

說實(shí)話，這篇論文對于我來說，很有收獲。

設(shè)計數(shù)據(jù)庫測試軟件，不是一朝一夕的事情，它是一個體系，值得作為職業(yè)。