数据库测试,似乎是被人遗忘的数据库职业,但依然是不错的选择。底下是我在某站找的招聘启事,就连蚂蚁金服都在积极寻找数据库测试人:
要说我经历的项目,大大小小也有几十个,从 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)实时监控:如果性能弱的时候没有及时抓住,那么很可能呢下次带来更大麻烦的时候,我们依然手足无措。所以在测试阶段就必须一击即中。
说实话,这篇论文对于我来说,很有收获。
设计数据库测试软件,不是一朝一夕的事情,它是一个体系,值得作为职业。
数据分析 BI
原创文章,作者:kepupublish,如若转载,请注明出处:https://blog.ytso.com/tech/bigdata/173523.html