跑步干呕太写实，咱也是这样..

其实现在如果是数仓里面的数据测试，其实在现在一站式平台发展的比较好的期间，垂直某个领域的业务能力可能更加重要了。比如以前在实时数据还需要手动写 flink 代码的时候，现在阿里云一些优秀的工具都能写 flinksql 来解决百分之 99 的问题。然后如果是离线数据，这一点倒是你现在可以进步的，你需要非常熟悉 ETL 过程，也就是 hivesql 这些 sql。要能在一千甚至几千行里面梳理清楚数据脉络，以及数据源是业务库的哪些表，这个期间有良好的文档梳理能力也是很好的，这给后续做数据治理也有帮助。然后也要思考怎么结合业务，做数据质量监控体系。对业务数据进行质量分级，因为大多数数据都会在应用层 ads 给大老板，或者对接的中台，一些核心数据是有必要做质量体系的。另外你说的验证数据量，数据增量，主键一致这种比较通用的是可以抽象成统一测试模板，在对数据进行测试的时候，先过这一类统一的三板斧，然后在对数据质量中蕴含的业务进行梳理。其实大数据测试是在你有充足的综合前后端知识，优秀的 SQL 能力的前提的，能够更好的接近公司核心业务，向上走的一个很好的发展职位

是的，有兴趣吗

飞哥，你应该不是没想起来，可能确实很久没用，但是飞哥你想一下你可能就记起来了，比如 SELECT sales_person, SUM(amount) as total_sales
FROM sales
WHERE region = 'East' -- 先过滤行
GROUP BY sales_person
HAVING SUM(amount) > 1000; -- 再过滤组
按着思路写出来其实就发现是先 where 做数据行过滤，再用聚合函数对整体过滤出来的组数据再过滤了。不过飞哥你说的也对，很多技术如果自己没有正在做，就算是很粗钱的，也会第一时间卡克，比如 UI 自动化的 webdriver 很基础吧，但是现在让我手写 ui 自动化的用 webdriver 打开百度我都忘记了。所以我也觉得是简历上有什么就考察什么。当然如果简历是瞎写的就其次了。而且 5-10 年的测试，其实真的来讲，约到后面越看重公司的人情世故和站队方向，大多数技术如果不是天天在用，基本都是面试的之前半个月恶补的...

大方向上可能有问题，如果你是面向 kpi 可以捣鼓各种花里胡哨的，如果你是真想测试解决问题，不妨分析一下每次 bi 展示出错，是开发搭建组件 BI 操作失误，还是数据集本身 sql 逻辑问题，不是所有问题都可以自动化测试或者迁移到 UI 自动化测试或者接口自动化上面。database 本身是一个健壮性本身很强的工具了，不存在动了一个数据集或者仪表盘，其他模块出问题的情况。可以分析历史原因的 bug，哪些本身是口径上的问题还是什么。总而言之在 BI 和看板上考虑自动化不是很明智和 ROI 回报率高的选择。最好更注重数据集本身中的业务含义和背景

看来看去健身网教比较靠谱哈哈哈哈

fastapi 既视感

本硕 base 武汉，有个 20+ 的薪资应该也还稳健了吧

首先，如果你正在问结合 AI 的测试落地方案，那么这个问题就算有答案也不是一个人能回答你的，除非他们带领自己的效能团队直接进去你得公司，进行演练，联调，资料适配

你刚起步，那么我的建议是不要选测试这条道路，不管别人说多少天花乱坠的理由，但是你要相信客观

你这确实挺坎坷了，多想想开心的，题外话，如果两个人都有焦虑，来个宝宝会不会...

福星好玩吗，我还在 S13 上分

我嬲嘞

还别说，刚蹲坑干死一个国服第一奶妈，吃俩把分哈哈

游戏也很卷了，大多数人只有技术是充不进去那个内卷赛道的，游戏赛道可能比互联网更卷哈哈，我们娱乐娱乐就好

晚上做的不粘锅用 8g 油建的鸡腿肉加螺丝椒加大葱炒熟，蔬菜是牙白炒的 也是最近学会做法

96 年哈哈，6 年级到初一，在我爸那边遇到一个叔叔在打天空之城，他说上厕所，让我打一下怪。从此一去不复返

你把个人上升到全球国家局势来看，你觉得非发达国家焦虑不，它会不会抱怨为啥你们这些发达国家还要继续内卷，继续搞资源，它可能会抱怨，但是强国会牺牲自己的道路来救你吗？不，它只会在一个发达国家圈子里，政治性的救济你一下，所以，拳头，强大才是硬道理。没有过程，没有诉苦，只有结果。你胜出了就是胜出了，你胜出了以后，卷赢了以后，你说啥都是对的，不要像个诗人，也不要像个圣者，你赢了之后，你就是诗人和圣者

去尚硅谷学习吧，把谷粒商城看完，基本任何中厂开发都接得住了，别说测开了

云原生受众确实在测试比较少，感觉 SRE 运维会比较多或者中间件开发者

我也觉得，不知道这个分享出来干嘛的。。。开发培训机构必学的三件套，redison 或者 springcache 都能解决

为什么会有数据工厂的概念？大家可以类比一下数据仓库，本身不做产出，只做收集，你可以认为接口测试平台里面的场景链路就是数据工厂里面的一个卡片事务，但这是职责方向不同，数据工厂面向的是数据产出，只需要单个或者少量入参就封装好了大量的写事务，接口平台你需要手动录入，串联上下文 context，或者流量录制，总之你要自己去编写链路，数据工厂本身是一个调用方（理解什么是工厂），本质上它是做一个调度，管理，执行的地方。好比如果你要赋能其他业务线或者开发线，你去要开发新增一个优惠券去自测一下，开发说太麻烦了，链路很长，你这个时候封装一个事务卡片在工厂里，给开发自己去点击这个卡片，他肯定也会乐意，如果是接口自动化平台，难不成你丢给他这么大个平台，说你去找一下我这个场景链路（他压根不想看），所以，工厂的后续优化方向，肯定是怎么更好的去让其他业务线使用，不要看到底层链路细节，只管造数用来测试即可

全局窗口一般不用，会话窗口又贼麻烦，还得合并

爬楼，时隔半年，目前已经全部能看懂了

胖虎兄看到你了，建议慢慢走管理方向，然后赛道，建议走大数据方向，不是因为我自己搞才推荐你搞，而是因为这个赛道确实还有不少余温和红利，测试里面基本很少有会 flink 测试，或者大数据性能测试这块的，并且这块生态也是 java 或者 scala，做个数据测试 leader 也不错