java - 依赖关系分析工具 - 更新回归测试用例

Question

问题

我想这是一个很常见的问题。添加新代码转化为回归——现有的测试用例变得过时。代码中的依赖关系意味着即使您知道如何修复这个特定的回归，也可能在两个方向的 n 多个地方存在间接回归 - 传入和传出。

需求

我有一家运行 SVN、Maven+Nexus、Sonar、Jenkins 和 JIRA、QC、QTP 的商店。总而言之，良好的CI环境。

随着每一个新的构建，我都会有新的回归案例。我想在两个方向上找到 Java 包依赖项并正确更新测试用例以涵盖所有类型的回归 - 直接和间接。
这更像是一个问题，因为我的单元测试覆盖率甚至没有接近 50%，并且集成测试的自动化跟不上开发的步伐。

我的选择

声纳

Google CodePRO

JArchitect

Jtest (与供应商 Parasoft 进行了讨论。他们没有为此提供工具)

杠杆现有环境我有，比如说，一个 Atlassian 插件

Kalisitck (供应商演示 - 不错的工具 - 涉及学习曲线和成本)

覆盖 (就像 Kalistick - 学习曲线和复杂的安装。非常昂贵的许可证。

任何其他开源/付费？

JArchitect、SONAR 和 CodePro 会给你一个简单的矩阵，比如 this或 this .通过告诉我哪个满足我一半的要求 用户 和 用户 类(class)受到影响。我想要的是更进一步和 让工具告诉我 哪些相应的测试用例受到影响，以及我是否需要更新和/或执行它们以覆盖我的回归风险。

Kalistick、Coverity 和也许其他人可能会做我想做的事 - 它们的设置和配置很繁重，随着您的系统缓慢增长，因此不能立即产生生产力，需要成本并且需要学习曲线。

简短问题

考虑到安装、学习曲线、成本、可用性或任何其他参数等所有因素，在我的设置中使用上述哪种工具。



我已经阅读了 static-analysis 上的常见问题解答部分, 很少有人喜欢 Static Analysis tool recommendation for Java? ,
https://stackoverflow.com/questions/3716203/automatic-code-quality-and-architecture-quality-static-code-analysis和
What is the fascination with code metrics?
和许多链接的，但他们没有回答我的具体问题。

Answer 1

与 JDepend您可以分析包之间的依赖关系，甚至可以创建单元测试以确保依赖关系或将其与 Fitnesse 集成有一个很好的依赖表测试。
如果您的测试在特定包中，这可能会有所帮助...