测试覆盖率 大家有没有兴趣一起搞个开源的平台化的精准测试代码覆盖率平台

King · 2024年05月09日 · 最后由 陈先生 回复于 2024年05月14日 · 6710 次阅读

来来来,在此集合众多测试同学我们来一起共建 TesterHome 第一个社区开源代码覆盖率平台,有兴趣的一起搞,看看能不能引起大家的共识,社区的大佬们有没有想法一起搞呀,就像社区自研的性能工具一样,搞起来

共收到 42 条回复 时间 点赞

我入门技术,可以获得一份分工吗

支持
可以把具体的想法分享下,大家可以更好的考量下

怎么搞加个群?

6楼 已删除

申请加 1

这个玩意必须要流量采集和代码分析这两个基础能力,流量采集可以基于开源的 JVM-sandbox 来做,虽然需要二次开发。代码分析,一方面可以借助 code diff 工具了解代码的变更,另方面可以借助 AST 类工具(Babel、jscodeshift 以及 esprima、recast、acorn、estraverse 等)、覆盖率分析工具(如 JaCoCo)、Java Dependence Analysis(JDA)+ Java 自带的 jdeps 等方案进行代码依赖性分析,而且不是有大佬说精准测试一般公司都不需要吗?开发口头效率更高吧

wanjingwang 回复

精准测试也不是为了测试更快速才产生的,结合业务和公司,效率只要不是很低,使测试更精准应该是没毛病。
毕竟楼主的想法是开源平台,不仅对楼主这些开发者有益,更我们测试人有好处。点赞👍

这玩意我也有想法。调用链分析、覆盖率、录制回放我们都有,最近正好考虑做一下整合,可以的话大家一起构思一下

只会 python,围观一下

我们这边搞了好几年精准测试,覆盖了三端 web,服务,app,功能包括:覆盖率,调用链路,追溯关系,用例推荐,全流程等。涉及到的技术有 java,有二次开发 jacoco 的能力,能开发 Android,iOS SDK 的能力,前端 react,vue 项目开发构建能力,chrome 插件开发能力,要求还是比较高的,说实话,想搞个开源的,没有那么容易的,不过可以尝试一下。

能力,时间有限,围观一下。

精准化测试和 LLM 结合有搞头吗 调用链和用例知识库的维护成本是不是更低一点, 有没有新方向?

申请加 1

插眼

插眼,摆烂太久了

申请加入

要搞面向什么技术栈的?

为啥不去搞搞国外比较出名的测试方面的项目,带带国内的测试多参与开源?

滴 学生卡 带我

滴 学生卡 带我

小黑子 回复

那你需要排队一坤年

滴 关爱卡 带我

mark 一下,感兴趣

会 Java/Python,做过平台开发,求带

import coverage

# 创建一个Coverage对象
cov = coverage.Coverage(source=['my_project'], include='my_project')

# 开始收集覆盖率信息
cov.start()

# 运行测试用例
run_test_cases()

# 停止收集覆盖率信息
cov.stop()

# 生成覆盖率报告
cov.report()

我感觉可以把调用链路分析的环节也融入监控平台,监控到线上环境出现问题后,能够追踪到具体的代码位置

申请加入


你们 battle 一下

申请加入,带带我

研究过,申请加入

申请加入

我还是来泼个冷水,很多问题要得到回答:

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

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

很好的想法,申请加入,贡献力量

申请加入

仅楼主可见
King #39 · 2024年05月13日 Author

统一回复,代码覆盖率并不是为了博眼球,就是单纯集合有想法的同学,搭建一个通用的代码覆盖率平台,后续需要拓展的功能,可以在此基础版本上去做二开,毕竟每个公司业务不一样,代码规范不一致,所以公共的基础基建很有必要。

即使我很菜,我也想提供一份力量。

好好保住工作吧,别瞎折腾了

我已经做完了的说,我搞到 luckyframe 上面去,但是没想过做一个单独平台,有点意思

大厂其实都有自己的研发的一套,主要也是面对中小公司

44楼 已删除
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册