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

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

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

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

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

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

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

一些不同的聲音

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

• 一是沒有時(shí)間。在開發(fā)和調(diào)優(yōu)上花費(fèi)的時(shí)間夠多了，為什么還要去寫大量的測(cè)試用例。
• 二是測(cè)試案例復(fù)雜。針對(duì)業(yè)務(wù)復(fù)雜的測(cè)試，對(duì)數(shù)據(jù)質(zhì)量要求很高，一個(gè)沒有設(shè)置好地區(qū)，折扣，渠道的訂單，測(cè)試出來的結(jié)果肯定不令人滿意，那么做好一份質(zhì)量高的測(cè)試數(shù)據(jù)，本身就需要花費(fèi)很長(zhǎng)時(shí)間和精力，對(duì)于團(tuán)隊(duì)資源是種低收成的回報(bào)。

有個(gè)搞笑的段子，大家聽聽：

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

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

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

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

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

但不利于找出是否有破壞性的功能缺陷因?yàn)樾录拥奶匦远搿Ｓ辛俗詣?dòng)化的測(cè)試工具，任何時(shí)候針對(duì)任何數(shù)據(jù)庫(kù)版本，都可隨時(shí)完成測(cè)試。

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

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

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

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

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

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

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

既然測(cè)試這么難，那么我們?cè)趺幢Ｕ献约簻y(cè)試的質(zhì)量呢?下面說說我的一些個(gè)人看法。

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

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

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

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

• 那么，數(shù)據(jù)庫(kù)測(cè)試主要有哪些分類呢?
• 功能性測(cè)試，諸如CRUD操作，就要執(zhí)行功能性測(cè)試
• 數(shù)據(jù)庫(kù)特性測(cè)試，比如備份、還原，集群故障切換
• 數(shù)據(jù)庫(kù)壓力測(cè)試，比如并發(fā)測(cè)試，大數(shù)據(jù)量測(cè)試

有的同學(xué)會(huì)覺得數(shù)據(jù)庫(kù)測(cè)試很簡(jiǎn)單，先 R(retrieve) 一下，在CUD(Create Update Delete) 一波，最后在 R 以下，如果滿足結(jié)果就算測(cè)試通過。

畫個(gè)圖介紹下，不就是這樣么：

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

將測(cè)試封裝在一個(gè)存儲(chǔ)過程里。

單元測(cè)試：?jiǎn)卧獪y(cè)試的目的，就是取最小單元的程序，比如一個(gè)存儲(chǔ)過程，用測(cè)試數(shù)據(jù)來測(cè)試它是否完成了我們需要完成的功能。

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

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

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

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

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

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