• 是的,可以这样的,顺手写了一个 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 记录这种当然可以收集,但是你说这是精准测试吧,他更多是事后的事情,要做到新需求都要精准我不知道用什么来表达?覆盖率?改动的地方的测试,指出?

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

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

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

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

  • 解析出答案中的依赖 groupId 和 artifactId 等关键字段,把解析出的依赖在热点代码中查找,找到了说明大概率引出故障!
    

    这种 NoClassDefFoundError 出来,然后不太知道 MAVEN 里面可能有问题,这个基本功其实真的不怎么样,当然你说用大模型能不能解决,肯定可以,用搜索其实也能解决,成本问题。

    然后有一点小疑问就是,既然 NoClassDefFoundError 都不太知道可能哪里有问题的,为啥要去搞那些高难度的什么 AST,抽象语法树,直接代码分析,代码级别测试,如果能这么分析,我觉得还不如直接生成单元测试和集成测试来的直接呢,数据反正都能生成的,用例也能覆盖,为啥要绕着弯子去做一样的事情。

  • 其实这个论坛对技术不太感兴趣的,怎么实践也是。这些离一般的测试的实际工作稍微有点远了。

  • jmeter 卡死问题 at 2024年04月21日

    那就不要用 JMETER 了。

  • 看了这个标题时候的感受:
    问题是: 研发提测质量导致测试工作量加大,因此公司内部开始推行测试对研发的提测质量打分,与研发的绩效考核相关。
    对策是: 给研发提测质量进行打分, 请问这不会加大测试工作吗? 难道研发提测质量的提高只要政策一出就能马上改好吗?在没有改好之前,测试工作量是大了还是少了?

    看了 测试对开发质量标准的感受:

    1. 研发文档,具体指什么?这个有过于教条的问题,也很难评估,写一句话说清楚了和写一大堆说不清楚,不是有产品经理有需求文档吗?不是有 Bug 描述吗?不知道这个指的是什么。
    2. 测试顺利程度?这是什么意思?主流程没有 Block 的 Bug?低级 Bug 不低级根本不重要,只有严重程度高的 Bug 才重要,所以低级 Bug 是什么?
    3. Release Notes 需要完整准确: 我有点好奇,难道没有 Bug 管理系统吗?修改了 Bug,直接 Bug 就进入 Release Notes 呀
    4. 是否有自测: 不是和测试顺利程度有相关性吗,测试关系的是结果,是不是否自测已经是手段了,如果质量好,不自测由怎么样?因为人家找到办法了,你管不着的,看结果的。这和表示质量的指标没有一毛钱关系
    5. 是否有已知问题: 就算知道了,也不告诉你,你知道吗?也不是质量的指标吧
    6. 变改变测: 这不是常态吗?有 Bug 马上修改,和方便就发布了,马上验证,否则 CI 要来做什么?我很难理解这个的出发点是什么?变改变测很明显好处是开发测试流程缩短了,不太好的是,确实有时可能会改错,或者影响一下其他,但是我觉得没有上集成环境/回归环境,变改变测是常态呀,要不然发明哪些 CI 我不知道为了什么?

    当然一笑而过,只求大家都不要太为难相互,出问题之后可能有很多原因的,太宽泛的提测质量不好一句话很难说清楚,没有具体的东西的话,之后怎么评估提测质量好了呢?工作不要搞得像仇家一样。