技术编程|一个快要被忘记的数据库开发岗位，但应该被尊重
数据库测试 ， 似乎是被人遗忘的数据库职业 ， 但依然是不错的选择 。 底下是我在某站找的招聘启事 ， 就连蚂蚁金服都在积极寻找数据库测试人：
本文插图
要说我经历的项目 ， 大大小小也有几十个 ， 从 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工具 ， 只能靠人肉眼去逐行扫描代码 ， 最终才能定位到某个可疑的地方 。
减少重构风险网上有个玩笑 ， 中年（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 以下 ， 如果满足结果就算测试通过 。
画个图介绍下 ， 不就是这样么：
本文插图
其实 ， 正确的测试应该做到这样：
本文插图
将测试封装在一个存储过程里 。
单元测试：单元测试的目的 ， 就是取最小单元的程序 ， 比如一个存储过程 ， 用测试数据来测试它是否完成了我们需要完成的功能 。 数据库测试方法
那我们就来好好研究 ， 数据库性能测试的评测方法 。 也就是怎么去设计一套评测数据库性能的软件 。 我的数据库性能好不好 ， 必须由我说了算 。
这套软件的特点必须是：
1）分布式：模拟从不同设备访问数据库 ， 以达到真实的用户访问 。
2）实时监控：如果性能弱的时候没有及时抓住 ， 那么很可能呢下次带来更大麻烦的时候 ， 我们依然手足无措 。 所以在测试阶段就必须一击即中 。
本文插图
说实话 ， 这篇论文对于我来说 ， 很有收获 。
【技术编程|一个快要被忘记的数据库开发岗位，但应该被尊重】设计数据库测试软件 ， 不是一朝一夕的事情 ， 它是一个体系 ， 值得作为职业 。
推荐阅读
- 小龙虾|三农探析：池塘养殖小龙虾如何高产？高产养殖技术全解析
- 猪身上一个部位，无筋无骨不塞牙，比排骨受欢迎，上桌立马被抢光
- 红豆和玉米面是绝配，一个做皮一个做馅，包好入锅一蒸，特香
- 天暖了，趁着这个功夫我们做一个芝麻馅，不煎不炸，蒸熟后包上芝麻糖馅，糯糯甜甜，真好吃
- 肺部|肺不好，会出现“1粗、2痛、3多”，占一个，也最好去查肺CT
- 吸烟|想戒烟反复几次不成功，告你一个简单有效的方法
- 简单快手又下饭的芹菜肉末炒粉丝，吃起来那叫一个香
- 冬天就适合用此物烙饼，鲜香营养，孩子爱吃，早餐吃一个暖心暖胃
- 地球|古代地球是一个水世界吗？
- 中国镇|你知道中国的“心脏”在哪吗？经国家地理测量，位于一个村庄上