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

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

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

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

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

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

為什么要做數據庫測試

一些不同的聲音

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

一是沒有時間。在開發和調優上花費的時間夠多了，為什么還要去寫大量的測試用例。

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

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

我們從來不做數據庫測試，要做就在生產環境做

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

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

• 早發現，早治療
  在數據庫開發領域，手工測試和一次性腳本測試，是最常用的。但不利于找出是否有破壞性的功能缺陷因為新加的特性而引入。有了自動化的測試工具，任何時候針對任何數據庫版本，都可隨時完成測試。
  往往尋找一個bug的產生，需要耗費8-16小時，甚至更多，僅僅是因為某個開發簽入了一個新模塊的代碼，針對數據庫開發來說，沒有特別好的debug工具，只能靠人肉眼去逐行掃描代碼，最終才能定位到某個可疑的地方。但幾千行代碼消耗下來，一天，不熟悉那個模塊的開發，甚至3，5天也都過去了。
  所以最高效的解決方案莫過于在每次新代碼簽入的時候，我們對其做一次全量的代碼測試，把新版本的測試用例都跑一邊，如果沒有特別的報錯，簽入才算驗收過關，可簽入發布版本。一旦這個時候出現Bug,就可以快速跟蹤到代碼和人，進行修復。
• 2BMore ( to be more ):更有設計感，更整潔，更具有擴展性。
  往往我們很多開發都是側重開發，炫技，和快速。認為把任務做完，就是厲害，或者更著急去做新任務。冥冥之中好像就是有只手推著我們不斷快速的往前沖，爭取更大，更多，更快。這么做，好處是有的，項目進度看上去更快了，老板更開心了，而業務也就更加熱衷提需求了。反正你們做那么快，為什么不給你們開發多開點需求，實現更多功能，讓我們挑著用呢。
  其實更快的實現，只能給程序員增加壓力，一點好處都沒有。沒有及時對之前所作項目的復盤和整理，靠量的增長，很難完成質的飛躍。
  就好比，我們寫SQL， 5000行一個存儲過程也是寫，10個組織結構良好的500行也能寫。但你說5000行與10個500行，哪個
  更有利于人員質量的磨練，項目后期的維護呢？一直往前沖的干勁要有，及時吸取和補充理論知識也不能少。我自己也曾做過卯足勁往前沖的前鋒，但那些年除了體重漲了，其他都沒漲。反而這些年，時不時停下來自己反思下，把代碼反復的重改，才有了現在一點點技術的積累。
  大概這也是外包，給大家的錯覺。一個個項目的接，平均3-6個月換個組，最后弄的自己一直在重復做相同的事情。業務知識倒是知道不少，但積累一個都沒有，樣樣稀松不稀奇。
  而測試思維一旦加入開發，就能逼著我們去思考解耦。如何拆分一個復雜的實現，使得代碼更結構化，簡潔和易擴展。
• 減少重構風險
  網上有個玩笑，中年（35歲）程序員如何才能保住自己的飯碗？將SQL寫的越長越好，越少人看得懂越好。碰到這樣的祖傳代碼，很多新人都是要問候原作者的直系親屬的。我上次說5000行代碼的維護，就已經有讀者受不了了。那么怎么規避這種毫無設計感的代碼呢？
  還是測試。
  假如一開始，一個用戶需求就是一套測試用例，那么放心的去重構吧，愛怎么重構就怎么構，完了跑下測試就行。但如果沒有測試，你敢動這大幾千行的代碼么，即使你拍著胸脯說，你敢，你老板敢么？
• 保障團隊協作
  如果說程序員比較宅，不喜歡旅游，可以天天上線解決代碼問題，那么誰還能不生個病呢。如果生病的時候，你負責的代碼出問題了，誰來解決呢？全組都要等一個人才能繼續往下工作，這種風險也太大了。
  如果有了測試策略，一個人斷了線，另一個人接上，接著往下碼。只要大家都是同一個平臺，接手完全沒有問題。這對數據庫開發就更有利了。無論是sql server, oracle,mysql, 只要測試用例都在，我們的目標就是編寫出通過測試用例的代碼，至于T-SQL, PL/SQL的轉換，文檔查查，一點問題沒有。

數據庫測試怎么做

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

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

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

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

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

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

那么，數據庫測試主要有哪些分類呢？

• 功能性測試，諸如CRUD操作，就要執行功能性測試
• 數據庫特性測試，比如備份、還原，集群故障切換
• 數據庫壓力測試，比如并發測試，大數據量測試

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

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

其實，正確的測試應該做到這樣：

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

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

來自微軟

數據庫測試方法

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

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

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

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

這套軟件的特點必須是：

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

《計算機軟件開發的數據庫測試技術探討》作者牛傳明。

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

--完--

總結

以上是生活随笔為你收集整理的sqlserver跟踪数据库_说说被遗忘的数据库开发职业 - 数据库测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。