现在的工作项目有一点财务属性，对一些金额的校验很看重。一般情况下，操作一笔交易可以在 3~4 个库的 6~8 个表里产生数据。
现在我自己认为的工作中可能存在危险的点：
1、操作一笔交易，需要去不同库核对不同表数据产生是否正常，这个过程太过于漫长（有时候时间紧急就只校验了比较重要的表）
2、测试组测试策略采用交叉测试，新接手功能的同事可能没有全部了解到细节校验点，在校验的过程中可能会有遗漏，或是疏忽。
针对以上情况，我想搭建的数据校验平台有如下设想：
1、数据校验平台直接连接数据库进行取值校验
2、取值规则就跟随业务规则来， 提供一个配置功能，去取值，去校验
3、校验正常仅记录，校验失败就产生报告输出
4、还可以结合接口自动化，配置做数据校验
然后我存在一些不懂得地方：
1、一般这种数据校验是主动去校验，还是定时任务去校验
比如业务触发交易操作，然后平台观测到数据产生，就去做校验？ 这种是不是需要内嵌代码到业务系统去。 还是做一个实时查询：检测到主要的表产生数据之后，就去做校验
2、项目仅测试环境没有限制数据库访问， UAT 环境，生产环境数据库都限制了访问。也就是说我这个数据校验平台，其实只能应用在测试环境里，但测试环境经常会产生垃圾数据，这样的情况下，好像我这个数据监控平台的应用范围很狭窄。从这个角度会怀疑是否有必要投入这么多精力去做这件事情
3、第一次有这种搭建平台，或者是实现比较大功能的想法，从设计思路上，代码实现上，需求上有什么需要规划好的吗？
期望大家能赐教，我在 github 上找相关开源，结果没找到😅
我的建议是：步子迈大了容易扯着 D
1.平台》框架》脚本集》脚本
你可以选择一步到位，也可以选择期望的逐步降级，先实现再升级
2.怎么校验？
曾经也做过一小段时间的银行业务测试，最大的感慨就是 “SQL 是真 TM 的长！”
当时也有想过自动化校验该怎么实现？
既然是校验数据，那数据必然是经过了一系列的处理，或者数据清洗
那脚本是不是要比对着该业务处理逻辑来对入参同样做处理，最后以脚本结果为期望去比对业务结果
那该怎么保证你的处理逻辑没有 bug 呢？
又该怎么能保证你的逻辑实现能力是强于 ETL 的呢？
如果不能保证，那期望就失去了价值，比对也失去了意义，做的一切也就是无用功
3.你的业务是否真的适合做自动化？
自动化的核心是 “重复”，而你描述的业务给我的印象是：漫长、复杂
这点我认为你可以实际的去梳理下业务线，确定下是不是真的适合脚本化，确定下脚本的维护成本和性价比
最后给你个建议：
遇事不决，可问 5W2H
这个没必要搞个平台吧，既然在跑接口用例，拿接口跑几个订单和财务数据，直接读库校验就行，至于规则我理解是直接写死，又快又好使不是
赞同一楼的说法，步子不要迈太大。建议先把完整的流程拆分成几个模块，按模块先完成脚本集，脚本跑完发个群通知，一样能达到效果。
这个做出来之后，其实数据检查上面其实不需要测试的。为什么：
- 产品直接定义 Input 原数据在哪里，那个字段，到 Output 到哪里，那个表那个字段，最终的认为正确值应该是什么的就是校验规则
- 开发开发过程中，也是可以直接配置，他其实也是一个字段一个字段起获取的，如果期望值本来就是可以自己起好的
- 如果上面两个都做了，那要测试做什么？
那么为什么还需要测试呢？因为做这个工具平台也不太容易，另外呢，产品/开发一个个对字段其实也挺痛苦的，为什么不找另外一个人帮着对呢，反正不用自己出工资，有了这个平台还要自己输入，也没太多好处
回到具体问题，这种就看你主要目标：
- 如果是对着回归去的，那么可能就是一个执行保存脚本的地方，这个相对比较简单，可能就是平时测试怎么测的，用什么脚本 SQL 测试，查出了数据是自己对，还是有什么方法对，对什么字段，就把这些实现下，不需要全部支持，只需要有一部分处理就行，如果只是实现这部分的功能，我觉得你可以看看这个里面 极简测试管理系统
- 如果你对着直接新功能测试去的，那么可能就复杂多了，就像我上面说的，Output = f(input) ，每个字段都去配规则吧，当然我觉得呢，这个应该有部分开发工具可以用的，就是写 ETL 的时候，好多也就是直接的字段对应，可能开发有现有工具了 。。。。。。。， 至于复杂的逻辑，那么你怎么检查，你检查的方式不是 SQL 就是计算，总之都能变成代码， 就是工作量你感觉下吧
维护在接口自动化用例里就好了