sikuli 做图形对比就是这个路子

https://www.liaoxuefeng.com
自己去学

照你的意思，用 JMeter 就做不了功能测试了吗……嘿嘿，换个思路就行了

三大主流框架都差不多的玩法，主要是为了配合 webpack 或者 gulp 等其他的，方便管理打包、压缩、静态化什么的，为了提升编译速度、降低加载的网络开销，局域网应用可能要求稍微松一点，毕竟带宽足够

那好办了，想必 sikuli 就可以满足你了，只不过不同设备需要配置不同的原型图库吧，我没干过移动端的，胡扯的你参考一下

现在流行 template、js、css 分离，通过 import 或者 require 引入的居多
当然像我这种没追求的会合在一起（当然通用函数、模块也会剥离），like this：

布局可以通过分析 dom、v-dom、css，css 还要区分嵌入式、内联式、外联式样式定义来测试，有 js 操作 dom 属性修改的还得对 js 进行语法分析
至于实现是否跟原型设计一致，我劝你还是别想着自动化了……除非你们的前端实现和原型设计之间有一套模型化的自动化生成方案，不然靠着 sikuli 之类的得累死你

前端渲染要自动化测试，似乎有点倒行逆施的意思~

因为你的水平和眼界提升了，看同样水平的帖子就觉得质量下降了
而你感觉比你牛逼的那拨人，说实在的，应该是太忙了——不然怎么牛逼起来的呢，没空经常写帖子，也就是偶尔出来冒个泡吧

大佬真 JB 太粗……鲁了，很佩服大佬的动手能力和文字功底，估计平时没少遭团队里妹纸的白（青）眼吧，这车开的 666……

平安一年上报成功专利一千多项，多亏了你们

嗯嗯嗯，你说得对

方法多得很：注解、配置文件、配置中心……

楼主，看你列的这个顺序，想必你心里已经有答案了吧，没错，你列的一点都没错

不是因为测试好欺负，是因为他们都觉得测试是 “保证质量” 的，不信你去问问看

有赞的技术做得太好了，老板都看不过去了，热烈欢迎各位有赞的质量技术大牛加盟，

你就说你敢不敢实名吧，哈哈哈哈
我特别认同你的观点，不过你的措辞有点过激
以前我们那代是 20% 的优秀，20% 的弱鸡，60% 的平庸，现在的这代 30% 的优秀，可惜只有 20% 的平庸……

沟通大于天，拒绝沟通、眼中无团队的，灭之！

这段看起来就让人觉得不喜欢了：

想不通为啥不用 csv，excel 在低并发系统里我们都会限制在 2M 以内，只能用文件流处理，不允许一次加载到内存，而且文件流处理也要非常谨慎。
虽然过程看起来比较长知识，总觉得没太 care 别人踩过的坑，有点找不自在的意味

楼主心很细，居然发现了乘坐滴滴会遇害的真相~

报告首长，Katalon Recorder 这个我第一次听说

80% 的业务发生在 20% 的时间内，日活——日，一般就是拿工作时间作为参考基准时间窗口的，人家又没说是时活

同 3 楼，先找出业务发生主要的时间点，如果没有明确的需求，那就 2/8 原则来弄：80% 的业务发生在 20% 的时间内
80%*20W/(3600*20%*8)=28，也就是每秒至少完成 28 笔，如果是 30 秒内就要完成 20W 笔那就是另外一回事了，直接除：20W/30=6667，每秒 6667 笔
如果每笔业务最慢能接受的响应时间是 2S，那并发就好算了：28 * 2 或者 6667 * 2，就是需要分别确保在 56 和 13334 并发的情况下响应时间在 2S 以内，服务器资源使用率在可控范围内便可……至于是否有其他的额外事物时间，就需要根据自己的业务来了
楼主的测试需求属于容量范畴，不应该单纯的考虑压力测试场景，压力测试的主要目标是限定资源、持续加压，找到系统 fail 的点，这跟需要在多久时间内完成多少笔业务其实是两个维度的事情。

ssh、chmod、chown、chattr、sed、awk、sar、iptables、make、make install、ln、chkconfig、sysctl 这些个反倒比较常用，因为搞环境搞得比较多