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

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

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

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

那就不要用 JMETER 了。

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

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

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

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

支持

做完这些应为不太确定是不是完全正确，然后需要测试再全量回归一下，有时想想测试确实痛苦，这本来就是不存在的事情。及不重要又不紧急的事情，最后被推到了又紧张，又紧急的事情。关键是万一问题还要背锅，没出问题都是应该的。测试开发何苦折腾测试呢。 就这个事情，和代码重构真的不在一个维度上的，代码根本就没有重构， 重构什么了？那个 Bean 还是那个 Bean，只不过是编译的时候把 GET/SET 方法给自己生成了而已，对代码没有做任何形式的重构。

提高效率是好事，但是提高到代码重构工具，这肯定上不合适的，这肯定说不上重构，哪怕一点都说不上。

用@Data和用 IDE 直接生成 GET/SET 没大区别，就是看着烦了点，但是 Lombak 说不定还存在点坑，然后不只不觉的就引入了风险。

一切都是矛盾呀，一面说管控变更，一面一动手就用代码改代码了， 代码改代码风险并不会小。

业务体量还不够复杂，这个确实，不过呢也不算太简单，同时业务体量这个东西很有迷惑性，是指功能多？还是指用户量多。如果用户量多，其实呢不一定用例多。业务复杂，使用人少，也可能用例很多，所以这个光一句业务体量不够复杂本身就不够清晰.
公司内某业务回归几万条用例的问题，需要精准测试，但是呢，重复的多少？没人愿意去重新搞搞清楚的可能也是有的？
另外为什么要全量回归呢？不是拆分了微服务了吗，不是敏捷小步快走吗？那么如果还是动一下要几万个 Case，那么微服务的意义在哪里，敏捷的意义在哪里，是不是先反思一下领域拆分问题？

如果精准到几千条，那我想问下，如果直接通过优先级是 P1-P2 的过滤一下筛选，几万条能过滤到几千条吗？然后这个几万条用例，一条用例的定义是什么？是一个步骤还是一个场景？

个人觉得更全面的了解一下实际情况对我做决定很有帮助，所以多问几个问题。先谢过！

我觉得这些都没有问题，我只是考虑我自己实际的情况分析，同时想看看如果要做怎么做成本更低，

1. 比如你说 OpenTracingAPI，Skywalking 只是一个例子，事实上如果一个公司多语言的话，我第一反应链路 Trace 会比从代码 AST 解析出来分析要方便，否则你每个语言来一套？
2. 而追踪接口变化，我第一反应也是觉得通过 API Spec 文件差异更容易实现，而我们确实也是多语言也使用 API Spec 先行这种方式进行开发，所以我觉得没有必要去做 AST 方式或者 Parse 代码方式去实现；
3. 至于内部调用链和 Opentracing API 个人理解没什么冲突，如果 Tracing ID 一直传下去，直到返回，远程和内部调用没多大区别，至于是不是 JAVA 微服务，问题是我看到的例子大部分 code instrumetation 都是用 JVM 做例子，JACOCO 做例子的，如果是 JAVA 微服务，反而我觉得可能成本相对低一些，毕竟很多人都做了这个，至于其他语言的，我不确定成本会到哪里
4. 另外就是关于精准的判断遗漏，工程师还是会加入，那么你说为了防止遗漏，我觉得没问题，只是我们可能还没到这个程度，公司小选择相信人，毕竟最终你还是要工程师做决定，那就考虑省去这部分平台建设
5. 代码调用链路分析这个事儿，本身并不复杂，就是个会者不难难者不会的问题， 这个肯定的，几乎所有的问题都这样

好多对上英文你就不惊讶了，比如造数工厂， data factory，就这么个事情。

何必搞这么复杂呢？这样不行吗？ 数据驱动就在最外面驱动好了

import unittest
from ddt import ddt, data
type = [1,2]
@ddt
class MyTestCase(unittest.TestCase):
    courseClassify_list = []    #最终为[('data3', 'data4'),('data3', 'data4')]的状态
    @data(*type)
    def test_A(self,data):
        # 执行A测试用例并向courseClassify_list插入数据
        self.courseClassify_list.append(('data3', 'data4'))  #共2条用例，都会生成一份('data3', 'data4')
        print(self.courseClassify_list)  # 验证是否成功插入数据
        for item in self.courseClassify_list:
            print(item)

if __name__ == '__main__':
    unittest.main()

我觉得权责要对等，谁背锅谁负责，我都是直接说，我背锅那以后都是我负责，你们都得配合我，看整不死你们。。。。。。。。。

不会出现响应时间和 TPS 同时变多的情况，因为这两个本身就有点互斥的意思。

这都需要有前提吧，如果是多节点，分布式呢？响应时间长一点，TPS 增加也做得到的吧，而且分布式，多节点的目的就是用网络传输上有额外小延时的损耗换取获取更大的 TPS. 所以响应时间和 TPS 是可以同时增长的，就是有前提。

会 Java 才算是会代码？这么说的人大部分我估计也不会代码，现在语言和语言直接的差别越来越小了，各种特性都在趋同，并且还有发展，这么语言和好的，可以加到另外的语言里面去的。 脚本语言 python，typescript 和 JAVA 区别越来越小了，会代码这个程度，最重要的我个人认为是熟练度。

这个做出来之后，其实数据检查上面其实不需要测试的。为什么：

1. 产品直接定义 Input 原数据在哪里，那个字段，到 Output 到哪里，那个表那个字段，最终的认为正确值应该是什么的就是校验规则
2. 开发开发过程中，也是可以直接配置，他其实也是一个字段一个字段起获取的，如果期望值本来就是可以自己起好的
3. 如果上面两个都做了，那要测试做什么？

那么为什么还需要测试呢？因为做这个工具平台也不太容易，另外呢，产品/开发一个个对字段其实也挺痛苦的，为什么不找另外一个人帮着对呢，反正不用自己出工资，有了这个平台还要自己输入，也没太多好处

回到具体问题，这种就看你主要目标：

1. 如果是对着回归去的，那么可能就是一个执行保存脚本的地方，这个相对比较简单，可能就是平时测试怎么测的，用什么脚本 SQL 测试，查出了数据是自己对，还是有什么方法对，对什么字段，就把这些实现下，不需要全部支持，只需要有一部分处理就行，如果只是实现这部分的功能，我觉得你可以看看这个里面 极简测试管理系统
2. 如果你对着直接新功能测试去的，那么可能就复杂多了，就像我上面说的，Output = f(input) ，每个字段都去配规则吧，当然我觉得呢，这个应该有部分开发工具可以用的，就是写 ETL 的时候，好多也就是直接的字段对应，可能开发有现有工具了 。。。。。。。， 至于复杂的逻辑，那么你怎么检查，你检查的方式不是 SQL 就是计算，总之都能变成代码， 就是工作量你感觉下吧

左移不就是听国外说的 shift testing ‘left’， 翻译过来就是测试左移，有啥要要领先的，测试多了新工具，可能就少点职位，再说这都是国外的，说不定都不能用

35K

大佬牛！

牛

https://www.dongcb.com/818.html， Spring + Jackson 有可能导致类数量爆炸 这个文章看着和你的情况比较近， 反射也就可能稍微慢一点，怎么可能一直在内存不能被 GC 呢？我其实还是不明白你说的意思。

metapsace GC 也有的哦， https://poonamparhar.github.io/understanding-metaspace-gc-logs/

1. 这个 JAVA 实例内存用了多少？
2. 为什么 GC 没有回收这些呢？
3. 使用反射是必然的，很难想象对反射怎么做优化？
4. 换 json 序列化包？ 另外 BeanUtil 不是处理 JSON 的

个人认为还是没有说清楚。

com.tcl.tof? 这是 tcl？

投入产出比吧，如果减少一部分时间就足够了，因为实际上我什么都没投入。

投入：
最多就是总结一些需求，这个本来就要做，然后写一个 prompt，这个基本上每个都可以用，一次性工作，然后其他我什么都没有投入，AI 调用也不需要费用

获得：
少写一写已经很熟练的用例的时间，可以有时间做点其他，摸鱼也好，学技术也要，其他也好

我一点不觉得有什么鸡肋的。一口气反正也吃不成一个胖子，如果你觉得 AI 真能去 Review 用例：

1. 实际也需要给他进行数据标注的，而谁来做数据标注，我觉得测试也跳不掉的
2. 实现 Review 用例也不知道什么时候有，有能用用的就先用着呗
3. 最少用上 AI 了，空谈无意义

我这个方式主要解决的问题是:

1. 少点打字，意义不大的格式转换
2. 可以快速的完成测试用例写法
3. 只针对比较简单的场景，比如对一个资源的增删改查，以及一些字段校验

有个想法，如果想让 ai 帮忙写用例，你需要提供大量的信息，以及标准规范的文档。
那么，如何快速让 ai 介入测试工作，我想最合适的应该是，让 ai 补充，查缺补漏，就是测试人员先把测试用例先写好，然后再把文档给 ai，让 ai 进行用例评审，或者让 ai，重新优化，输出更加规范标准的测试用例。我想，这种才是目前现阶段，比较符合现实的方式。

关于您说的这个想我，我没有想过，看了之后的感觉是，有可能做到吧，但是不是我现在的目标，我现在就是想减少成为打字员的时间

不管怎么样，也算一个实践吧，我只是把我想要做的东西，用最简单的方式串联起来，并且可以留存了数据，至于 AI 评审这些，我能力范围之外了，或许较少了打字时间，我有更多时间可以学学这个怎么评审，才有机会做到评审。

看了这么多留言，我感觉其实做什么怎么做测试都不重要，重要的是结果，和测试一样，重要的是线上不出严重 Bug，要出也不是和你有关; 不过从测试角度去判断一些这个回复里面，有些逻辑我觉得也不是很对,是可能出 Bug 的地方:

比如这条:

我会选择不进入这个行业，直接考公，然后回到老家等拆迁，
捞个几百万，建 5-6 栋房出租（可惜没有如果）

我不是很理解，考公和等拆迁有什么关系？还有等拆迁和做测试有什么关系？做了测试也不影响等拆迁呀，做做测试，同时等着拆迁，再辞职回去收租，不是应该这样吗？或者有其他关系，做了测试就家里不能拆迁了？这里可能有 Bug 出现的

还有这个：

在我开始进入测试行业的时候买比特币，然后记住东方通信，酒鬼酒，
诚迈科技，阳光电源，锦浪科技，石大胜华，九安医疗，中通客车，西安饮食，剑桥科技，鸿博股份

你确信你记住了这些就可以拿得住？会有不一样的结果？这些你 Bug 级的东西你能复现吗？如果能复现，并且每次都能复现，那我觉得可以多找找这种 Bug，软件点点这种事情也就不做了，不过你肯定会去点点其他东西的，比如什么数据，什么图表，也是点点哦，你会觉得枯燥吗？有时看了半年都动静，你熬得住吗？Bug 疑问点还是很多的，容易出 Bug 地方也很多