数据库测试，看似是一个被遗忘的数据库职业，但依然是一个不错的选择。以下是我在某网站上找到的招聘启事。连蚂蚁金服也在积极找数据库测试人员：说起我经历过的项目，有几十个，从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个小时甚至更多，只是因为某个开发嵌入了一个新模块的代码。对于数据库开发，没有特别好的调试工具，只能靠人眼逐行扫描代码，才能最终定位到可疑的地方。网上流传着一个笑话，说的是降低重构的风险。中年（35岁）程序员如何保住饭碗？SQL写得越长越好，能看懂的人越少越好。遇到这样的祖传代码，很多新人都想跟原作者的直系亲属打个招呼。上次讲到5000行代码的维护，有些读者看不下去了。那么如何避免这种没有设计感的代码呢？或测试。如果一开始，一个用户需求是一组测试用例，那么可以随意重构，想重构就重构，搞定了跑测试就行了。但是如果没有测试，你敢碰这几千行代码吗，就算你拍着胸脯说，你敢，你老板敢吗？保证团队合作如果程序员比较宅，不喜欢出差，天天上网解决代码问题，谁能不生病。如果你生病的时候你负责的代码出了问题，谁来解决？整个团队必须等待一个人继续工作。这种风险太大了。如果有测试策略，一个人断开连接，另一个人连接，然后编码下来。只要大家在同一个平台上，接手是没有问题的。这对于数据库开发更是有利。不管是sqlserver、oracle、mysql，只要有测试用例，我们的目标就是写出能通过测试用例的代码。至于T-SQL、PL/SQL、文档的转换，完全没有问题。如何做数据库测试那么如何做数据库测试，尤其是看到几千行的存储过程和大量的ETL程序呢？作为开发，完成功能的实现就万事大吉了，但是作为测试，实现功能就没有乐趣了。您还必须担心最终的质量检查。如果你失败了，老板认为测试没有成效，会降低你的薪水，这对你来说是一个彻头彻尾的悲剧。既然测试这么难，我们如何保证自己测试的质量呢？我来说说我个人的一些看法。就像看书一样，如果你拿起一本书从头读到尾（我以前把计算机书当成教科书一样看），那我敢打赌一个800页的数据结构，99.99%的人，看到了300页，我彻底放弃了，顶多再翻5页，也就是305页。然后我就不停地翻后面，数着我有多少页没看过，要花多少时间，别问我为什么知道，你懂的。那么我什么时候停止阅读这样的书了呢？读完《CLR Via C#》。这本书777页，花了我将近5个月的时间。我每个星期天都躲在家里看。喝杯星巴克，一直看，边看边画画。最后一页都没留下，全部看完了。有的地方看了5遍以上。还有这本说明书，《Oracle Concepts》，我大概看了不下6遍，边看边画，每天晚上八点看，直到看不下去了。那为什么看完这两本书，就不再相信从头到尾的阅读方式了呢？因为一本好书，结构很好，你可以在不了解前面章节的情况下阅读任何章节。阅读是一种乐趣。如果你看不懂，你可以发挥你的想象力和搜索引擎来解决当下最重要的问题。所以，读书最重要的是明白自己想要什么。测试也是如此，必须根据测试的内容制定测试计划。如果要测试并发压力，就不能使用单元测试；如果你想测试新功能，你不能进行回归测试。那么，数据库测试的主要类别有哪些呢？功能测试，比如CRUD操作，需要数据库特性测试的功能测试，比如备份、恢复、集群故障转移，以及数据库压力测试，比如并发测试、大数据量测试。同学们会觉得数据库测试很简单，先是R（retrieve），然后是CUD（CreateUpdateDelete），最后在R下面，如果结果满意，测试就通过了。画个图介绍一下，不就是这样吗：其实正确的测试应该是这样的：把测试封装在一个存储过程中。单元测试：单元测试的目的是把最小单元的程序，比如存储过程，用测试数据来测试它是否完成了我们需要完成的功能。数据库测试方法下面我们来研究一下数据库性能测试的评估方法。即如何设计一套评估数据库性能的软件。我的数据库性能好不好，肯定是我说了算。这套软件的特点一定是：分布式：模拟不同设备访问数据库，实现真实用户访问。实时监控：如果在性能较弱的时候不及时捕捉，很可能下次它带来更大的麻烦时，我们仍然手足无措。所以在测试阶段它必须是成功的。说实话，这篇论文对我来说是很有收获的。设计数据库测试软件不是一蹴而就的事情，它是一个不愧为职业的系统。
