#1 楼 @seveniruby 1. nGrinder 是个 web 服务，是动态的；而 gatling 是运行脚本，生成个静态的 html 报告；2.gatling 结果里没有 TPS 数据； 如果要做一个公共的性能测试平台最好选择个 web 服务，脚本和结果大家可以共享，也方便管理； nGrinder 功能差不多等价于阿里云的 PTS，nGrinder 还是开源的，也方便按照需求二次开发。

#21 楼 @aizaimenghuangu 恩恩，工具包。

#18 楼 @xdlhy shell 脚本还没公开，其实也比较简单，你按照文章中 “5.初始化流程” 流程图，自己就可以写出来。

#19 楼 @wanxi3 请参考：https://testerhome.com/topics/4279； 你要在配置文件 agent.conf 中修改 controller 端所在的 ip 和 port（默认是 13243）。

#17 楼 @taurus 这种问题，就好比选择哪种编程语言；不选择 jmeter 的原因是它是单实例，我们想把测试脚本和结果大家都能直接共享，包括开发也能直接查看性能测试结果，ngrinder 是个 web 服务，能做到这一点，也能很好的满足业务需求，入门比较低（开发也可以直接做些简单的压测），也便于管理，大家的东西都放在一个地方。适合自己的才是最好的。

史亮的软件测试实战写的不错。软件测试书籍精品不多，很多买来，看了一点，就没有读下去的欲望。其实把淘宝的测试白皮书系列看一遍，你的理论基础也就够了，后面加以实践，能力就上去了。

#22 楼 @chengaomin   对不起，之前理解有误，更正下 25 楼中的解答 “ 虚拟用户 n（其实是线程）， 在 nGrinder 中，是指 n 个线程去执行@Test，可以理解为 n 个请求/s。” 如果@Test执行体中只定义了一个请求，并且没有思考时间，Vusers = TPS * RT; TPS 可以理解为系统的吞吐量 (也可以理解为 qps); ； 当 TPS 的增长率小于响应时间的增长率时，这就是性能的拐点，也就是最合理的并发用户数；当 TPS 不再增长或者下降时，这个时候的压力就是最大的压力，所使用的并发用户数就是最大的并发用户数。如果此时的 TPS 不满足你的要求，那么就需要寻找瓶颈来优化。

赞，好文。

#4 楼 @lihuazhang 赞

#1 楼 @lihuazhang 辛苦，这么晚还在弄；能不能提 2 点建议，1.发帖的入口比较难找，每次我都要找几个页面才找到入口；2.增加讨论区，和技术贴分开。

#1 楼 @seveniruby JUnit5 断言功能还是没有那么多，https://junit.ci.cloudbees.com/job/JUnit5/javadoc/; Assertions Class；AssertJ 我觉得最大的 2 个亮点是流式和支持的模块总类多（比如 DB 的检验）。

请参见： https://testerhome.com/topics/4934

（至少从服务端来看，手机端不熟）测试界近 10 年，并没有什么重大的技术突破（开发技术突破较快，比如像 Hadoop, spark, storm, Docker 等等），理论还是那套，实践还总是那些工具 JUnit4(最近出了 JUnit5 重写了一遍), TestNG(inspired from junit), 测试系统大多数都是开发个 web 系统，做做管理、调度、展示，底层的还是那些东西。（吐槽哈）

#11 楼 @taki 还是保持一致，线上真实场景；如果单独拆，成本高，又不真实；当然前提是有完善的监控，随时暂停压测。

#9 楼 @neven7 更正一下 9 楼，百万级并发的数人云做到了，是用 tsung，他们用数千个 docker 容器模拟并发，可参考http://m.it168.com/article_2532243.html，但是并发量达到了，他们的性能数据怎么产生和搜集，文章中没有细节，其实也最关注结果，并发量那么大收集数据也是个瓶颈。

#7 楼 @chenhengjie123 性能还是可以的，当然 nGrinder 工具本身是用 java 写的，并发量很高时是很耗内存，这就要求安装的机器配置要很高；启 web 容器时，堆的大小也要尽量大点，单个 nGrinder controller 万级是可以支持的（实践已经到了万级），如果搭建 controller 集群几十万级的量还是可以（理论，没校验）；百万级的，我所了解，业内还没有这种工具；你如果只是想得出接口性能数据，其实不一定要模拟到百万级，你算出均摊到单台前端机的 qps，直接压测单台。接口日均 pv * (80%/20%)/(24 * 3600)/前端机总数=单台前端 qps 峰值

#6 楼 @taki 问题 1.数据隔离，其实可以通过接口参数标识，微博接口都有个来源参数，压测时用压测 source，不会影响线上的一些策略统计（忽略压测 source）；读数据可以用线上录制的参数；写数据，环境如果是线上，只能用测试数据模拟调用; 问题 2.同机房最好了，但是在同一个内网内就可以了； 问题 3.“主从或者多个从环境是否不变” 没理解意思

#4 楼 @jacexh 1.https 的问题，Gor 确实是不能录制 https，一种折中的方式是进行压测时，临时将服务 https 改成 http；CPC 现在不支持 https 协议，业务暂时不需要支持 https。

1. 上行接口（POST），如果压测的系统资源是线上资源，不会录制上行接口，因为会写花数据，这种只能用测试数据模拟请求；如果压测的系统资源是测试资源，可以录制上行接口； 你说的非匿等接口，不能重用请求参数，这种接口只能临时生成满足的参数。

#2 楼 @jacexh 角度不一样，直接流量回放是粗粒度的，性能数据不好统计，我们这边也有，是使用 TCPCopy 直接放大线上流量（开发和运维操作），一般通过监控系统观察错误和响应时间或者通过代码打点统计日志数据；CPC 是细粒度的，性能测试脚本直接通过线上的请求数据压测，通过不同的 qps 模拟正常流量和峰值流量下各项性能指标。