diffy 是个好工具啊，界面也不错。应该可以搞定我的问题，即便搞不定二次开发的工作量也比较小，主要是这测试结果是在线的很赞。

接口返回值可以包含多个表的数据，再说接口可能有缓存的，都不调用 DB 的数据，直接测试数据库是不行的。

不了解这么高端的工具。

beyond compare 命令行没用过， 能把 JSON 格式化后再对比吗？

这个地方主要是对比测试，两个环境海量接口返回值的对比测试。
Json Schema 明显是没做的……你的建议很好，不过很难推行。

不仅仅是测试返回码啊~返回值的格式，甚至大小写匹配，返回值的 key value 都要一致的。

我过后也介绍一些我自己写的在线 Jmeter 用例管理吧，点我头像进 github（帮忙点个星星最好了多谢）。没想到这还能整个公司出来。

学习了。
不知道你是第几面产生这些感慨的，面试要招的人是最适合这个岗位的人，而不是技术能力最强的人，所以面试题往往点到为止，你符合岗位要求就行了，如果你要的钱比较多，那么会问一些比较深入的看看你是不是把面试官当 SB，不是说你技术最牛钱就最多的，主要还是看是否适合这个岗位（技术只是一个大的方面）。
再多说几句吧，你写的这几个问题挺对我胃口的。
首先你这 4 个问题，其实实际运用中意义不大，开发都很少用，更不用说测试了。
1.3 问题是锁的，多线程的，但是现在服务器都是分布式的，使用的都是分布式锁，单进程内讨论锁和多线程意义不大，脱离实际。
2.问题是线程池，意义很好，不过单进程内再开线程池，意义也不大，现在都是分布式，一般是队列实现任务分发，仍然是跨进程的。
4.问题是垃圾回收机制，讨论的是各种垃圾回收机制的优缺点，可是你应该也了解，CMS 一旦出问题就是致命的，而多线程回收是默认的，你讲究这些问题，理论研究很好，实际应用上谁能让你上 CMS 呢。更何况 CMS 提高性能也并不是很明显。
你能熟悉 JVM 到这个深度自然非常好，但对于测试工作是锦上添花并非雪中送碳，希望能理解。

我才刚买《腾讯 iOS 测试实践》，还没到货呢惭愧。
我和楼主不一样啊，我是 Java，mysql 这类书一定要精读的，测试书才是当工具书看或者 google 了。

感谢肯定，前端我还有太多东西需要学习，向你学习。

谢谢。
AI 不像测试，测试还可以讲是质量保证，是软件所必须的。AI 可不是必须的。

说技术，AI 和测开，对技术的要求都是无止境的。
只学 AI 是够呛的，原因很简单：
1.AI 人才给炒热了，小公司接不起普通的 AI 人了都，年薪好几十万一个普通的，不容易接。
2.上点规模的非 AI 方向的公司，也不特意搞 AI，AI 更向是噱头，企业生存还是第一位的，AI 能否提高利润是需要评估的，何况 AI 人才那么贵。这样的公司更希望内部大数据人才自我提升到 AI。这样的公司更希望是和专业的 AI 公司做合作。
3.AI 的基础即大数据高度集中在几个知名公司手里，很多甚至全部的热门数据都在人家手里，其它打算专门搞 AI 的公司，难为无米之炊，前途漫漫，更多的是提供服务。
4.说到提供服务，由于当前是云时代，云上可以直接提供 AI 服务，楼主可以关注一下腾讯云，已经将 AI 的好几十个算法平台化了，只要你提供数据，腾讯云自动给你训练出 AI 的结果。甚至你都没有数据，只有想法，腾讯云上的大数据也能给你弄出来。我相信阿里云也会马上出现类似功能。
以上，
小公司，请不起 AI；非 AI 方向公司，不自己搞 AI 希望寻求合作；AI 方向公司，人才越来越多门槛越来越高；最后，云有希望一统 AI 天下，赢者通吃。
那么楼主的路越发的艰难了，但是比较清晰：
1.专心搞 AI，如果让 AI 当饭吃，肯定要小有所成。
2.从事 AI 相关工作，最好是到大数据和 AI 牛逼的公司去，如 A 如 T 如搜狗如讯飞如 H 等。
3.一定要学大数据相关知识，自己要有造血的能力。
4.一定要有能带路的人，能带你学习，内推到你去知名公司的人。
带来的问题：
1.楼主从 0 开始，难度是我难以想象的。AI 对数学的要求极高，同时需要实验室级别的环境来联系算法，闭门造车是非常艰难的。
2.楼主年纪在这，分析到这里可能大家也看到了，去小规模 AI 公司基本是没有希望的，只能去牛逼公司这条路才能行，楼主年纪让这成为不可能的任务，不可能近 40 岁的人和不到 30 岁的人拿一样的钱，领导都比你岁数小，是被刷荣誉去了吗。
3.靠 AI 进小公司拿较低薪水，然后精进 AI 和大数据然后在小公司混到风声水起。这种是幻想。a.需要多少年才能到这个地步，我预估得个 5 年。b.这条路比你现在的测开的路好吗？我认为不见得。
一些想法：
1.不要以为测开没有技术含量，测开和大数据一样要求技术高度和广度，而 AI 和大数据孰优孰劣还说不清呢。
2.测开都搞不好，去搞 AI，本身就是没有底气的事。
3.本科 top10 是好事，但是年纪的增长是无法避免的。
4.如果没有带路人，纯脱产自学，无疑拿头撞墙。

没搞过 nodejs，我先看看源码再说吧。
这个平台有借鉴意义，需要学习。

多谢指点。
你在 issue 上提的问题我看了，Locust 的作者解决不了你提的问题。

这篇文章粗略看了一下，说实话，他讲的和没讲一样，他基本没说性能测试的痛点，是每个都夸了一下。
我怀疑他是否真正做过性能测试。
如果我分析的话，会接地气一点儿吧。

我会稍微介绍一下的。

你说的有道理。不过我还没写网页版的性能测试平台呢，这里仅是在看 Locust。
@debugtalk 他阿里同事实现了 GO 语言的 Locust 客户端 boomer，我未来还会继续分析 GO 语言的可行性的。boomer 的源码我也在学习。

我写的是 Locust 的你竟然来问我 Jmeter 的问题……让我一阵心酸啊。
我开始以为你问的是 Threads(users) 的数量，后来仔细看了一下，是问的 sampler 即用例中的请求数。
最终能设置多少个 sampler 确实是依赖内存的消耗的，这里解释一下。
Jmeter 编辑用例增加 sampler 的时候，用例是会保存成 jmx 用例文件的，jmx 用例文件中即包含了每个 sampler 的信息。
而 Jmeter 性能测试时，会将正常状态（没有灰化隐藏）的 sampler 信息（很多个）加载到本身的内存中，确切说是 JVM 的 Heap 中，用来当做原始测试数据。
那么这会遇到第一个内存障碍，如果你的有效的 jmx 用例文件就 100MB，Jmeter 的内存 Heap 才设置了 50MB，那这个用例可能是加载不起来的。
性能测试时，由于不能污染原始的内存中的 jmx 文件，比如做参数化等细节，每一个 jmx 会被复制出去，由于具体 Jmeter 是使用线程来实现压力机制的，所以复制的 jmx 文件会到线程的内存中，这次是在 JVM 的永久代中，而每个线程的内存可以使用-Xss 参数配置。
那么这回遇到第二个内存障碍，如果 jmx 有效的比较大，而-Xss 设置的比较小，那么性能测试时也是有可能失败的。
注意：
1.Jmeter 加载/运行 用例/sampler 时，如果遇到问题，都会抛出 JVM 级别的异常的，肯定是会打到日志上的，这部分定位问题十分简单，而解决也比较简单，增加内存就好了。
2.真正的用例在内存中不会像 jmx 文件那么大的，Jmeter 会提炼用例数据的，内存占用会比文件占用的空间小得多。（具体提炼多少需要看源码，这里无法尽述）。
总结：
sampler 多少确实是内存决定的，内存够大就没事，有问题就看日志，注意调整-Xms -Xmx -Xss 参数。

1.你到底什么理解，我到底什么误解，你说出来，想喷我就勇敢点儿。
2.“locust 更新的少可能是因为没有太多高并发场景能达到 locust 应用级别，jmeter 就足够了”。这句暴露了你的实力。我可以这么讲，Jmeter3.3 目前的功能，甩开 locust 太远，基本就没有 locust 什么事情了。locust 的作者是有自知自明，不更新很明智。

你直接用 Jmeter 就都有这些功能了。

号前段时间丢了，导致一直挖坟……
楼主是很有激情的，一直在不断解决问题的路上，看你搞 docker，服务器监控，那就是把运维的活也干了。
测试开发的工作还是比较杂的，我的观点还是测开做的都是开发没时间搞的事情，比如应该自测阶段完成的用例，比如整个流程的串通，然后测开闲下来的时候还要做各种工具，把开发没时间搞的事情做的更高效。
那么测试面对的，比开发接触的要广的多很多，同样工龄的开发和测试，接触的肯定不一样，不同的语言，比开发多得多的工具，运维工作，很多开发集合起来的业务，还有你说的 bug 平台，各种用例平台，性能测试平台，云平台等等。
工作就是这样，楼主也一直在这条路上有激情的奔跑着，很棒。
如果说技术的 x 轴是广度，y 轴是深度，那么测试偏向于 x 轴，开发偏向于 y 轴。(x,y) 的值是你的技术能力。
在此我就是希望楼主多关注一些深度的东西吧。
2 年就到管理层，甚至让手下面试你，各种嘲讽，至少说明，这个团队的能力真的太弱了，你说的，如果每一个人专注不同的业务，不同的技术，那么问住你是分分钟的事情，这说明，或者他们没有你深入，或者他们就没深入，或者你们就没啥值得骄傲的东西。你们团队每个人的特点很弱，也就是说，人员太弱，没有技术深度。
当然你都跳出来了，希望楼主能感受到更大的挑战。
从楼主的字里行间也看出来了，想做创业者，也就是要带领一些人，这没啥不好，不是说非得技术如何如何才有资格带人，这是错的，带人也是要一步一步学的，这没什么。
我只是想说，希望楼主在热心于技术的广度，带人的热情，也不要忘了技术的深度，多看一些底层的东西。
底层的东西并非多么难，你有代码基础，再看一些比如 CPU，磁盘，计算机原理，各种协议原理，简单算法，linux，数据库原理，缓存原理，数据结构，应该就差不多了。
楼主的经理也在激励着我，共勉。

我还以为你弃用 Jmeter 是业务不对头呢……对接口测试，现阶段的 Jmeter 比 httprunner 好多了。你还来了一句操作不方便……别误导别人了好不好。说些肯定能遇到的：httprunner 面对循环重复请求要怎么做？断言的正则表达式怎么做？出了问题怎么 debug？怎么搞定时器？不是 http(s) 协议怎么办？遇到需要校验数据库/缓存变动，只需要一个简单的 SQL，并不是 http 请求怎么弄？怎么实时看到访问结果，如果有 1000 个请求前 2 个就失败了而不需要执行后面的 998 个以免脏数据 httprunner 要怎么做？
这些问题你要打开 IDE，自己造轮子了？
我都不用说 locust 的测试性能有硬伤，协程 + 脚本语言性能的硬伤，上面这些你都搞不定，要二次开发。
别简单一句这些更好，你到底做没做过接口测试，我都怀疑。
如果是你业务不符合，就说业务的问题，别扯工具能力。

呵呵了，我能发现这个 bug 你就庆幸吧，要不然上线出了问题，你更惨，除了加班纠正，如果有错误数据更完（内存 bug 等更是致命伤）。
我才赚多少钱，我可不陪你加班。
这种 bug 就是你自己都没验过功能，你要是嫌不好改发邮件，抄送你们项目经理，抄送我老大。

楼主这套框架很值得学习借鉴，好东西。
测试数据的痛点，docker 的学习，楼主加油。

正好我也有需求要做 Jmeter+ant+Jenkins 的自动化接口测试。
不同的是我的用例信息保存在数据库里，数据来源不同，搞了一天。

楼主最主要的细节没写：获取测试数据对应行。
我的做法是：获取 count 循环数量的同时，获取数据的 ID 主键集合，用逗号分隔保存在一个变量里。
获取测试数据对应行时，同时保存及设置用户变量 index，index 从 0 开始计数。
index 是 ID 主键集合的索引，由于已经根据逗号分隔过了，很容易取到。
再根据得到的 ID 主键来获取数据行，完成用户参数的初始化。

再说一下，其实报告的模板我没修改得像楼主这么麻烦，我就是把 beanshell samper 的名称改成了空格，自动就过滤掉了。

还有 if 逻辑控件，注意是 == 号。

有时间我也出一个 JDBC 的接口测试实践。