是不是第一种 androidElement 参数本身就先定位了元素然后才判断的存在,如果不存在应该就直接抛异常了

自己写方法，断言 exsit, text, selected 等属性

算了，你自己琢磨吧

没看懂的是你啊 老弟，线程的等待时间也算进 响应时间了

请你再把我主贴看一遍 高线程等不等于高压力

兄弟，别人知道 jmeter 是 BIO，会认为更高的线程能造成更高的压力吗。另外 线程！=并发。

多的我不想解释了也不想反驳了，我自己测过我自然知道。

44 楼大神已经说过了 rps>tps 可以通过 jmeter 多实例和分布式来实现，我自己也有测过， 完全不会出现你所推测的压力机自爆压力不稳定的情况。你那么笃定的说 120 就是 服务器能承受的最大 rps 我认为也是没有依据的。后续我自会进行详细的测试

你这是知道了服务器 是 120 的 TPS， 那你不知道的时候呢，如果服务器的 TPS 是 1000，我限制 300 有问题吗。 并且 我贴子不就是说明 120TPS 的时候 jmeter 达不到 300RPS 吗？ 这不就是 jmeter 作为 BIO 的局限性吗。 我想寻找下降拐点 来判断 服务器最大能承受的 RPS，有问题吗， 120 是 服务器能承受的最大 RPS 吗？

单实例 jmeter 不能造成大于服务器处理能力的压力，这就是他的局限性

你这 大概就是 100 分的答案吧

这就是我这个帖子要表达的，很多人并不了解，包括我之前也误以为 jmeter 可以制造无限大的压力。

1. 在服务器能够处理的过来的时候（也就是 RPS 小于接口最大 TPS），RPS=TPS。
2. 我的数据应该说明的很清楚了，jmeter 再增加线程 也不能造成更高的 RPS，所以 jmeter 测试不了 RPS>TPS 的情况
3. 我帖子的主要目的是说明 jmeter 的这个问题，不是为了说怎样测试服务器性能
4. 我自己写了个 python 多线程的脚本，只发请求，不管请求响应。很快 第三方接口 (我压测的接口瓶颈在第三方) 就出现了超时的异常。只不过这个脚本不太好做数据统计。代码如下：

# -*- coding:utf-8 -*-
import threading,time,requests

def post():
    url = 'http://***/'
    param = {'message':'***','client_acc_code':'***'}
    start = time.time()
    res = requests.post(url,param)
    if res.status_code!=200:
        print(threading.current_thread().getName() + ' error : ' + str(res.status_code))
    else:
        end = time.time()
        print(threading.current_thread().getName() + ' : ' + str(end - start))

if __name__=='__main__':
    run_time = 60 #执行次数
    thread_count = 100 #并发数
    for x in range(run_time):
        i = 0
        while i < thread_count:
            i += 1
            t = threading.Thread(target=post)
            t.start()

是这个意思

我假设 服务器每秒能处理 10000 并发，并且在 10000 并发下 服务一切正常，这个时候你用 jmeter 配置 20000 线程，去压测，我的观点是，jmeter 只能造成 1W QPS, 因而 服务 不会挂。 你配置的线程数 并不是实际造成的并发。不然 按我上面的数据，500 线程 压 100tps 的接口为什么 一个报错都没有

所言极是

你们好像搞错重点了 ，帖子的标题才是我发这个帖子的目的，我要说的是 jmeter 的问题，他提供的 QPS 受限于服务器处理能力，导致 我不能 给 100tps 的接口 施加 200qps 的压力。也就找不到 服务器最大能承受 QPS,即 什么时候开始 服务崩溃，连接超时等。

补充一点吧，这个接口 TPS 只有 100 是因为他调用了第三方的接口， 纯前端 接口 TPS 能达到 500~600

内网， 从 阿里云 A 压 阿里云 B

我要找的吞吐量拐点 是 下降的拐点， 上升的拐点 不就是图中的 110 吗

我压测对象是 生产环境的 阿里云服务器（施压服也是阿里云内网），有没有连接数限制 我不清楚，但是 远不至于最大只支持 100 个同时连接

对，是想测拐点， 4 核 E5 16G 的压测服务器 没有什么压力。我的结论是 QPS 瓶颈是 jmeter 自己的，他因为要等待 线程返回 再进行下一次请求，所以你线程设置的再高没用，只有第一次请求能达到 那么多并发。 时间长 了 QPS 就达不到了

我猜你压测的对象 能达到 2W 的 TPS，如果 2W 是他的上限，你就不可能再提高 QPS 了

他凭什么不背 ,我设置的 QPS 他根本达不到

也就是说，jmeter 不能在 服务器只能处理 100 个请求每秒的情况下，提供 200QPS 的 压力