SQL测试可行性分析

由于公司大部分产品都是企管类，采用三层架构，代码包括页面布局，js脚本，后台业务处理，以及SQL；因此，针对代码进行单元测试的意义并不大。本人打算对SQL进行专门的自动化测试开发，目前先做个简单的思路，希望大家能给点意见。下面是我对进行SQL测试提出的问题，并小范围的做了下调查。

SQL测试的目的？快速对SQL进行重复性校验，减少回归时的人力，给开发快速的反馈。

SQL测试的意义有多大？有没有更好的替代品？调查结果：5个一线开发人员认为50%的缺陷需要修改sql，一个经理（这人是我好朋友）认为如果程序员sql写错了可以去死了，因此没有测试的必要。一名高级测试人员emma认为，手工进行sql测试确实浪费时间，而且不可能每轮都很细致的去测试，因为组织数据太复杂。

SQL测试的致命瓶颈：代码和sql修改混合进行。调查结果：大部分SQL是为了解决业务层的问题，也就是说SQL实例有稳定的业务逻辑支持。因此可以进行设计。

SQL测试的难度：

1. 大量的背景数据设计：需要独立的数据库，暂不清楚设计背景数据的复杂程度
2. 输入值和输出值的设计：需要根据业务来进行，文档虽然不全，但是开发人员都在附件，测试人员对业务很熟悉。
3. 如何同步或者调用最新的SQL：SQL都写在独立的sqlmap里，能够直接调用。
4. 维护和开发的时间和成本： 技术难度适中，人员需求少，对于单个项目感觉时间上可能有点紧。
5. 数据初始化和清空： 由于数据库复杂，需要对表间关联很了解。另外，复杂的SQL基本属于查询，不存在清空问题。
6. 脚本粒度：暂时不明。
7. 脚本或场景二次发现bug的能力：暂不明。

以目前的情况看，应该是可以进行SQL测试的。但是，测试的效果到底怎么样呢？心里真是没底。大家能不能帮我预言一下，谢谢。