数据库测试，似乎是被人遗忘的数据库职业，但依然是不错的选择。底下是我在某站找的招聘启事，就连蚂蚁金服都在积极寻找数据库测试人：

要说我经历的项目，大大小小也有几十个，从 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）实时监控：如果性能弱的时候没有及时抓住，那么很可能呢下次带来更大麻烦的时候，我们依然手足无措。所以在测试阶段就必须一击即中。

《计算机软件开发的数据库测试技术探讨》作者牛传明。

说实话，这篇论文对于我来说，很有收获。设计数据库测试软件，不是一朝一夕的事情，他是一个体系，值得作为职业。

--完--