#11 楼 @laputa 20000 的高并发只是楼上提问时,我在网上找的一个对比资料。里面比较 gatling 和 Jmeter 时用的一个测试场景:10000 个用户并发、每分钟 30000 个请求、持续 20 分钟其中 10 分钟呈增加负载趋势。后面的博客又将 Vuser 加到 20000。由于持续的并发,所以肯定不是 atOnceUsers,我猜测可能是 rampUsersPerSec 或者 constantUsersPerSec。
详见:
https://blog.flood.io/benchmarking-jmeter-and-gatling/
https://blog.flood.io/stress-testing-jmeter-and-gatling/
#7 楼 @13651969749 建议你看下我发的 flood.io 博客地址,里面有特别具体的环境准备及测试计划。他只是为了比较工具的性能,而一般我们用不到 20000 用户的。
—— 来自 TesterHome 官方 安卓客户端
#4 楼 @ansonwoo 刚刚下班,看到你的回复……这个问题是这样的,其实我用 Jmeter 用得不多,以前一直用 loadrunner。首先我要说这两款工具和 LR 相比,无论是功能上还是易用性上都差了太多,毕竟 LR 收费。Gatling 和 Jmeter 相比的话,资源占用更小,编写场景(注意是场景)更方便,很容易做到数据和脚本分离;Jmeter 我觉得还是它使用 Java,用的人多,而且资料、实践方案、扩展工具都更多。
我的一点浅薄之见,更具体的分析请移步这位大神的博客:
https://blog.flood.io/benchmarking-jmeter-and-gatling/
https://blog.flood.io/stress-testing-jmeter-and-gatling/
如果没有耐心看完的话,我就简单说下结论:两种工具都很好,都能满足一般的测试需求。Gatling 在高并发下的表现更好,20000 并发的表现完爆 Jmeter,即使在 40000 并发下还能正常工作不受影响。
反正我对我的团队的要求就是会定位 bug 就行。有些容易的 bug 很容易知道是哪里写错了,测试是有能力(但不代表应该)直接改的。但是更多时候,测试要面对 N 多个系统,你对这么多系统的代码不会熟悉到每行是做啥的,所以很容易引入新的 bug。
还是不建议测试改 bug。
#2 楼 @13651969749 没测试过单机的最大并发。不过试过单机 1000 个同时启动的用户,没有问题,应该够用了。
Quick Start 的部分另有高手翻译过,不再赘述了。
想知道 Quick Start 部分的同学,请移步:http://gatling.io/docs/2.1.7/quickstart.html
你是什么手机什么系统啊,我用小米 2S 是可以的啊。
CSDN 有篇博客就是关于 robotium 自动化测试报告的,看看是否有用:http://blog.csdn.net/hunterno4/article/details/14485663
另外,我现在都是直接把执行结果输出到 txt 文件里,所以很锉……
也听说过有人做的 web 版,把字符串一点点 append 成一个 html 文件,后续我也想试试。
#1 楼 @lihuazhang 原来这样啊,很有道理,就是稍微有些麻烦……
我之前用过 waitForText,是可以识别纯文本的 toast 的。
其他的思路我暂时能想到的是 waitForView,但是 Toast 并没有 id 啊,所以我觉得应该很难吧。
2 楼正解。
这种操作最好使用 scroll 方法完成,robotium 提供了一大堆 scroll 的方法。
LZ 的方法不是很好,使用 Text 去识别控件本身失败率就很高。原因可能有:
1.“登录” 两个字之间有空格;
2.“登录” 看上去是文字,实际上是图片;
3.这个控件并不是 button,而是 imageView;
建议使用 ClickOnView
其实楼上各位给出的都对,但 robotium 本身就有个方法:
waitForCondition(Condition condition, int timeout)
Condition 本身就是一个 robotium 提供的类,里面只有一个待实现的接口,你把这两个条件都加进去就实现了你的需要。
另:个人觉得 monkey 的方法其实更好
哪个 qq 群啊。。。
求分享啊!