编译语言和脚本语言各一个比较好。

请问 B 站的职位还在招吗？

确实很牛 B 啊，是真心想把事情做好的人啊。

#31 楼 @anymore 这个不是想避免就能避免的，能碰到一个 team 里没有混日子做事都很积极的绝对是三生有幸啊。如果你不想混日子的话，去多搞点技术的东西吧，点点点是死路一条（点点点≠测试设计）

哎~~典型 996 模式。
沟通=撕逼是做不出好东西，靠测试补漏只会疲于奔命，顾此失彼。
这样时间长了，就会感到毫无成就感，然后就开始 “往上爬” 不在点点点，开始混日子，与人撕逼。

Robot Framework

哎~~UT 都是梦想啊。听到最多的就是 “快速上线”。

问题 2：很奇怪啊，都是独立接口没串联？那正常的业务数据哪来？
ps：接口都是独立且没串联，这种设计没见过增删改查通过一个接口实现？

#17 楼 @heyniu 哎~~~算了白问了

额~~想确认下这个框架干的就是将 python cilent 和 fiddler 抓取的内容进行 diff？

好文，学习

requests 的官方文档好好看看吧 链接 ，post 的 body 格式是可以设定的。

所以我一直觉得测试这行有个误区。那就是以不让其他 QA 写代码为荣耀，却忽略了脚本本身的个质量。我觉得不能无限制的为了降低学习成本而牺牲质量和效率，还是想想办法怎么提升团队的技术水平吧。

非常同意，测试不会代码的时代已结束了。

类似这个吗？https://github.com/bayandin/allpairs

#1 楼 @seveniruby 求具体实现

不单单是行业浮躁，社会都是浮躁的，所以还是缘分未到啊。

就是经验多，不但是技术方面，还有与人员的交流方面。说穿了就是会扯蛋同时会对付扯蛋

#44 楼 @sigma 哦，原来如此。这个造数据的思路不错。其实做数据库快照也是有选择的，不一定要全量哦。

#42 楼 @sigma 我还是有点不理解，很大是个什么概念？我理解的很大是指每次运行脚本时间是之前一次的数倍，也是说数据很大导致测试环境整体性能下降。如是这样的情况，就像你说的 “做了基础库，目的就是减小测试环境的数据库的数据量” 我觉得这个结局方案不错啊。其实我觉得很多事情不一定要在一个 “轮子” 里完，如能我觉得是值得欣赏和借鉴的。

#37 楼 @sigma 目前的我只能说找 DBA 同学们吧，他们是专家。我理解数据量很大一般只会出现在性能测试环境，恕我浅薄。

在每个 release 版本 cut 的时候做一个数据库快照，可以解决证据和清理的问题，当然这需要 DBA 同学们的协助

赞~~~

这个 “轮子” 造的确实不错，但发现一个问题若是纯 JS 的动作和后台没有交互的话，录制也就无法抓取必须手动代码补上。不过页面样式 Page Diff 监控做的确实一亮