• 求助贴 Jmeter 报错 at 2024年05月28日

    # For the first scenario, the error javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate) indicates that there might be an issue with the SSL/TLS protocol or cipher suites being used. You can try specifying the SSL context and enabling specific protocols and cipher suites. Here's an example of how you can modify your code to specify the SSL context with specific protocols and cipher suites:
    
    # Add the following code snippet to your TCPSample code where you create the SSL socket:
    # This example enables TLSv1.2 and specifies some common cipher suites, you can adjust them based on your requirements.
    
    # Make sure to import necessary classes:
    # import javax.net.ssl.SSLContext;
    # import javax.net.ssl.SSLSocketFactory;
    # import javax.net.ssl.SSLSocket;
    
    SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
    sslContext.init(null, null, null);
    
    SSLSocketFactory sslSocketFactory = sslContext.getSocketFactory();
    SSLSocket sslSocket = (SSLSocket) sslSocketFactory.createSocket("{{host}}", {{port}});
    sslSocket.setEnabledProtocols(new String[] {"TLSv1.2"});
    sslSocket.setEnabledCipherSuites(new String[] {"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"});
    
    # Test your TCPSample with these modifications to see if the SSL handshake issue is resolved.
    
    # For the second scenario, the error Cause: cannot recognise keyAlgorithm: 22 in JMeter might be related to the version compatibility of the JDK used with JMeter. You can try updating your JDK version or ensuring that the JDK version is compatible with JMeter. Additionally, make sure that the gradle dependencies you added are correct and compatible with JMeter 5.6.
    
    # If the issue persists, you can try checking the JMeter logs for more detailed error messages or consult the JMeter documentation for troubleshooting this specific error.
    
    
    1. 网页调用上面调用相当于调用 http 请求,所以你要建立一个 API 服务
    2. python 建立 API 服务非常旁边,flask/fastapi 都可以
    3. 你遇到了 CORS 问题,直接在 Flask/FASTAPI 里面设置 CORS 策略就可以
    4. 你不如直接把你的 HTML 文件放到你的测试代码中,使用 Flask/FastAPI 都可以启动 web 服务
  • 幂等性(Idempotence)是指一个操作无论执行多少次,其效果都和执行一次是一样的。在分布式系统、网络通信、数据库事务等领域,幂等性是一个重要的概念,因为它可以确保系统的一致性和可靠性。

    在你提到的场景中,我们可以这样理解幂等性:

    1. 第一次处理没有执行某个操作:这可能是因为操作依赖于某些条件或资源,而这些条件或资源在第一次尝试时并不满足或不可用。例如,在数据库操作中,可能是因为事务冲突或锁竞争导致操作未能执行。

    2. 第二次重试又执行某个操作:在第一次操作未能成功执行后,系统可能会自动或手动触发重试机制。如果操作是幂等的,那么即使重试,也不会对系统状态产生不良影响。

    3. 常见于有缓存的地方,缓存失效后会重新执行:在很多系统中,为了提高性能,会使用缓存来存储一些数据。当缓存的数据失效(例如,由于数据更新或缓存过期)时,系统需要重新从原始数据源获取数据并更新缓存。如果数据获取和更新操作是幂等的,那么即使在缓存失效后多次触发这些操作,也不会导致数据不一致或重复处理的问题。

    幂等性的重要性在于:

    • 一致性:确保系统状态不会因为重复的操作而变得不一致。
    • 可靠性:在面对网络波动、系统故障等不确定性因素时,幂等性可以保证操作的最终正确执行。
    • 简化设计:幂等性简化了错误处理和重试逻辑的设计,因为开发者不需要担心重复操作带来的副作用。

    在实际应用中,设计幂等的操作通常涉及到使用唯一事务 ID、检查操作是否已经执行过、确保操作的副作用有限等策略。这样,即使在复杂的系统交互中,也能够保持操作的确定性和可控性。

    来自 AI 的回复

    1. 哪个钱多?
    2. 做的东西有多少差别?
    3. 测试和开发的区别在编译器这个领域差别到底在哪里?差别到底有多大?
    4. 做测试工具算开发吗?
  • 是的,可以这样的,顺手写了一个 pytest 的一些使用,https://testerhome.com/articles/39759, 仅供参考。

  • 对这个问题的间接回答:
    为什么一定都要参数化呢?专门写一个有 order id 的,其他错误的用参数化一下不行吗?
    为了这个事情,其实花的时间更多了吧,比直接写个测试用例专门测有 order id 的场景。

    对这个问题的直接回答:

    1. @pytest.mark.parametrize 需要的是一个 set 的列表作为参数化列表
    2. 可以使用如下的方式可能会更可读一些:
    
    cases = CaseLoader.load_cases() ## load_cases可以让你的order api在这个里面调用
    
    @user2ize("p1,P2", cases)
    def test_abc():
        test_it()
    
    1. 也可以使用一些 pytest 执行顺序插件,强制让订单接口执行
  • 我还是来泼个冷水,很多问题要得到回答:

    1. JUNIT 到现在多少年了?可能有 20 年了,做单元测试的有多少?不过这个项目其实也维护了这么久了。
    2. JACOCO 是不是半死不活的?你看看项目历史他有多少年了?能坚持吗?
    3. 为什么看到的大部分都是 JAVA 的,其他语言很少?难道开发语言只有 JAVA 吗,还有 Javascript,typescript,golang,php,。。。。。。
    4. 如果精准测试这么好,这么能把问题解决了而且成本也没那么高的话,为什么几十年里面没有一个开源平台在持续做?为什么连云服务国内大厂都没有提供这些服务?或者没有提供好用的服务,为什么连 google,微软,amazon 他们也听说过?(当然可能是我不知道) 那么多开源的东西都是坚持了 10 年以上,为什么这个没有精准测试的知名开源项目?为什么微软什么的宁愿把测试裁员也不让他们来做这种可以变成云产品的东西? 实话是,我对精准测试的效果怀疑的,效果好有很多种原因的,是不是就是主要是精准测试,开发工具的人当然说这个工具好,但是是不是也有越来越多测试会看代码,会分析代码的原因呢?在实际的测试活动种是不是也有了一些改变了?
    5. 代码能力真的到了这个程度了吗?测试想要解决的问题,真的是架构师,开发想要解决的问题吗?测试也不是说要消灭 Bug,只是尽可能让重大 Bug 没有,不严重的 Bug 尽可能少。就像之前有个帖子说的那个 AI 扫描之类的,如果仔细一看你会发现其实可能 MAVEN 的一些常见错误接触少了,或者有些可能架构设计上的问题都不敢提出或者也难提出被人接受的观点,那么其实做好这个平台的难度是不小的。常见错误见的太少了,代码量不够,常见错误见的会偏少是正常的,但是会不会给自己带来误判,觉得这些东西必须要搞个平台来检测;而不是因为自己对常见错误的经历太少了,结果可能杀鸡用牛刀了
    6. AI 来了,到底是生成单元测试生成方便一点还是用 AI 扫描方便推理出可能的问题方便一点?还是沿用覆盖率比较这种方式呢?
    7. 调用链这种,Exception Log 记录这种当然可以收集,但是你说这是精准测试吧,他更多是事后的事情,要做到新需求都要精准我不知道用什么来表达?覆盖率?改动的地方的测试,指出?

    当然这种是和大佬学习的好机会,肯定支持。

  • 吐槽一下,要不然您出一个节点选择指南?

  • 问题不是语气,问题是为啥要吐槽这个地址没写的事情?不过感谢你把地址写出来了,然后呢?有人问你梯子,你教人怎么用梯子吗?

  • 我只是自我感叹一下顺便在社区感叹一下. 你也没必要指责我吧。