技术编程|一个快要被忘记的数据库开发岗位,但应该被尊重


【技术编程|一个快要被忘记的数据库开发岗位,但应该被尊重】数据库测试 , 似乎是被人遗忘的数据库职业 , 但依然是不错的选择 。 底下是我在某站找的招聘启事 , 就连蚂蚁金服都在积极寻找数据库测试人:

技术编程|一个快要被忘记的数据库开发岗位,但应该被尊重
本文插图

要说我经历的项目 , 大大小小也有几十个 , 从 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的转换 , 文档查查 , 一点问题没有 。 数据库测试怎么做


推荐阅读