首先我们公司是做大数据，卖数据库产品的，公司体量很一般。
个人其实测试理论很薄弱，只会执行上面给的任务，现在赶鸭子上架，闷头搞了很多，还是不得要领。
涉及到的接口主要是检索，会有很多入参，出参数据量也很大，接口内部的数据处理逻辑还是有点繁杂的，接口间的关联性不是很大。
首先，生产环境不让跑，只有测试环境可供部署，数据跟线上差异很大，线上环境，老板一万个不允许!
目前的策略，在测试环境Daily，上线前在测试环境跑一遍。然后大部分问题就是，环境崩了啊，服务挂了啊，在刷数据啊，去维护用例啊。
然后，这样做了很久，我不知道自己在干嘛了。这一套做下来，感觉好像没有任何用。
我有很大的疑惑
1、自动化用例最大的作用不应该是监控么，每天在测试环境巡检有什么意义呢。
2、迭代发布的时候跑一遍。在什么情况下，这一个环节能在测试环境反馈出问题？更何况，改动的地方经过了测试，甚至自动化用例也重新设计维护了，几乎100% ok的，没改动的地方，它能发生什么呢？这一环节，难道不也应该是去针对线上发布么，去验证发布有没有问题么…
3、关于校验方法，全字段校验不现实，数据每天都有可能不一样；或者说通过写sql去完整实现开发的逻辑，查询到后台的值，去替换预期值，再。。。这也不现实。
我目前设计了很多种方法，做到了通用，查一个人，就check有没有这个人，也有去做数据库查询但更多的也仅仅是简单的count(*)。但是在这种情况下，我又对上面说的那条，作为上线前的保证，产生了更大的质疑。我觉得，要依靠它替代测试，那接口的后台逻辑全都要，至少针对当前字段的，得摸清，并用同样的逻辑在用例里实现才可以，这个定制程度就高了，用框架是做不出来的。
鉴于以上种种，我觉得目前我做的这么多东西，除非接口不通了，不然好像确实没得什么用，以下想了几种情况：
1、某开发，睡觉时摁到了delte却没人发现(不存在)
2、代码有复用，改了一块儿，别人那儿没改（还不一定能发现）
3、其它莫名奇妙的多因素引起的bug导致接口不通
目前扑在上面一个季度多，丝毫没感觉到用处在哪，请教了同事领导，但都没有较好的指点，我已经有点怀疑自己了。
从量变到质变需要一个过程，这期间一年左右的积累，还是必要的。超过了，就得深入进去了。
这种测试也是很经典的测试场景，把业务逻辑和算法摸清楚是其实就可以提高能力。
老板不让跑，说明有他的业务考量，也可能是对的。如果线上不让跑，你可以搭建stage预发布环境，结合线上流量同步来充分的模拟线上环境。
这也侧面说明了，你们需要独立搭建一套预发布环境。
自动化测试的最大作用仍然还是测试，监控只是一个作用之一。你的巡检在测试环境就相当于是简单的冒烟，也有价值，只是要排除误报。预发布环境也需要巡检的，产生不了作用是因为误报太多，而误报多的原因就是你们没有独立的预发布环境，
建设你有个100个功能，发布后没问题，接着研发更新版本，你100个功能手工测试的成本，可以通过自动化替代。如果代码出问题，你的自动化测试用例就可以以最低的成本发现问题。回归测试是自动化的价值之一。
如果发现不了bug，你需要做出判断，是你们的研发团队很牛逼没bug，还是你的自动化测试用例设计有问题，或者是你们的自动化测试滞后于手工测试，bug被手工测试提前发现了？就算不在线上运行，自动化测试依然是可以发现bug的。
自动化测试和手工测试本质都是测试，只是执行形式不同。大部分公司的自动化测试问题之一就是自动化测试很简单，没有手工测试那么深入完备。
全字段检验是必要的，数据不一样你怎么知道是对，还是错，所以才是需要校验的。比如百度的搜索，出来100页记录，还是出来101页记录，虽然每个记录都对，但是数据量不对，其实就是一个很大的问题。代表了召回率的问题。
自己写sql判断也是有问题的，因为你自己写的可能也有bug，用一个可能有bug的算法去检验另外一套可能有bug的算法，是一个办法，但不是一个稳妥的办法。
一般的做法
- 测试场景设计，你得自己维护一套完备的测试数据模型，利用这套数据去校验各方面的结果。比如测试百度，我们得自己设计10000条原始数据，其中100条是我们故意插入的跟特定关键字相关的数据，然后检索，判断搜索到的结果是不是全部找到，判断每条数据与原始数据是否一致等等。
- 利用diff对比，跟类似算法进行对比，比如用百度的搜索结果和google的搜索进行结果测评，看谁更精准。你设计一套sql，本质是类似的。这个是参考方法之一，有我前面提到的问题，不能作为主要方法。
- 全量回归结合基准测试，每次跟上个版本对比，每次更新，检索的结果跟以前有什么变化，指标是提升，还是下降。其实是就是自身跟自身的历史版本对比。可以快速发现问题。
从你的做法来看，你的测试设计肯定是没法发现深层次的bug的。比如你们的代码出问题，有些数据查不出来，你只判断了查出来的结果是正确的，却没去判断是不是还有数据没有查出来。还包括性能，如果性能下降了，你其实也没测试。到时候上线了肯定会引发问题。每个字段你也没深刻检查。
至少我能看到的改进点就有如下几个
- 你可以从你们的历史bug和历史故障去看看，这些问题的形成原因，并设计对应的测试用例
- 构建自己的基准测试数据体系，构建经典测试场景
- 看你的算法是不是可以用简单的类似算法进行参考检验，用近似sql也是一种对比方法
- 构建预发布环境
- 建立全量回归基准测试体系
- 完善你们的自动化测试断言
- 自动化测试要用在手工测试之前
非常感谢思寒老师指点迷惑，以上老师指出的几点感觉还需要吸收跟理解，我决定暂时停下无脑的制作与维护，思考下改进方向与策略。