问题
我想要的是一个非常普遍的问题。添加新代码转换为回归 - 现有的测试用例已过时。代码中的依赖关系意味着即使你知道如何修复这个特定的回归，也可能在两个方向的更多地方进行间接回归 - 传入和传出。
要求
我有一家运营SVN，Maven + Nexus，Sonar，Jenkins和JIRA，QC，QTP的商店。总而言之，这是一个良好的CI环境。
对于每一个新版本，我都会有新的回归案例。我希望在两个方向上找到Java包依赖关系并正确更新测试用例，以便涵盖所有类型的回归 - 直接和间接。 这是一个更大的问题，因为我的单元测试覆盖率甚至没有接近50％，并且集成测试的自动化无法跟上开发的步伐。
我的选择
JArchitect，SONAR和CodePro将为您提供一个简单的矩阵，如this或this。通过告诉我哪些用户和使用类受到影响，满足了我的一半要求。我想要的是更进一步，让工具告诉我哪些相应的测试用例受到影响，如果我需要更新和/或执行它们以覆盖我的回归风险。
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? 和许多相关的，但他们没有回答我的具体问题。
答案 0 :(得分：2)
答案 1 :(得分：2)
我自己是Sonar的忠实粉丝，因为你已经让它运行，并且在CI环境中工作，这将是我的建议。我不太确定Sonar的依赖循环矩阵怎么没有做你想要的，或者更确切地说你想要的是什么。
答案 2 :(得分：2)
如果我正确地阅读了这个问题，你需要一个分析源代码的工具，并确定哪些测试不需要重新运行。
首先要考虑的是始终运行所有测试的问题是什么？这就是CI 的意思。如果你不能在15分钟内完成所有的单元测试以及所有的整合/压力测试，那么可以通过购买一些硬件来解决导致这种情况的任何问题。
如果做不到这一点，唯一可以跟踪潜在测试回归的是覆盖率分析（例如http://www.eclemma.org/）。即使是基本的OO设计，更不用说依赖注入，静态包或类依赖关系最多也是毫无意义的，并且可能会主动误导，因为哪些更改会导致哪些测试失败。而这忽略了问题是A应该调用B的情况，而不是。但是，交叉引用已经更改了带有被调用文件的文件，如果没有交集，也许不能重新运行测试可以说是安全的 - 剩下的失败就像是一些代码添加事件处理程序之前没有的那样。
我认为没有一个免费工具可以做到这一点，但它应该可以从Jenkins / Emma / Git编写脚本。或者使用像Kalistick这样的集成解决方案之一。但我怀疑它可以基于与开发团队就他们正在尝试做什么进行沟通来有效地击败人类的判断。
在一个模糊的相关说明中，Java世界实际需要的简单工具，但不存在，是junit的扩展，运行一组测试依赖顺序，并停止第一个错误。这将为开发人员专注于最有可能的回归源提供一些额外的帮助。
答案 3 :(得分：2)
您可以使用Classycle-Dependency Checker找到最高级别的依赖关系。指南中的部分 - Check Classes Dependency可能会对您的情况有所帮助。但是，通常使用静态分析工具，我们分析源代码库（例如：Project-＆gt; src目录）或测试代码库（例如：Project-＆gt; test directory），但不能同时分析两者。但在您的情况下，您似乎也希望找出源代码和测试代码之间的依赖关系。因此，通过提供输入路径作为src和test（例如：项目根目录）的父路径来执行适当的依赖关系分析工具可能是您需要的（例如：使用依赖关系找出 - >如果源X更改，测试中的哪些依赖类会受到该更改的影响。）
答案 4 :(得分：2)
您可以找到解决问题的最佳工具实际上不是工具，而是实践。我强烈建议你阅读有关测试驱动开发的信息（参见Lasse Koskela's book）和示例规范（参见Gojko Adzic's books，它们很棒）。
使用这些做法将从根本上改变两件事：
我发现这与你的问题相关的原因是你的场景暗示了测试的完全相反的作用：人们将执行代码的变化，然后他们会想“哦，不......现在我必须去弄清楚我在那些该死的测试中打破了什么“。
根据我的经验，测试不应该被忽视或被视为“低级代码”。虽然我的答案指出了一种方法上的变化，从长远来看只会产生明显的结果，但它可能有助于在将来完全避免这个问题。
答案 5 :(得分：2)
一些可能有用的工具。请注意，并非所有这些都与CI集成。
iPlasma是一个很棒的工具
CodePro是一个Eclipse插件，它有助于检测代码和设计问题（例如重复的代码，破坏封装的类或放在错误类中的方法）。 （现由Google获得）
Relief是一个可视化Java项目的以下参数的工具： 包的大小，即它包含多少个类和接口 可视化的项目类型（包和类表示为框，接口和类型的字段表示为球体）。 物品的使用重量（表示为重力，即中心距离） 依赖数量（以深度表示）。
Stan4j是一种商业工具，需要花费几百美元。它只针对Java项目，非常接近（或者报告比报告要好一些？不确定）Sonar。它具有良好的Eclipse集成。
从我能从您的问题中理解的是 - 您需要跟踪两个OO指标 - Efferent Coupling (Ca)和Afferent Couplings (Ce)。有了这个，你可以缩小到所需的包。您可以探索在每个构建中编写eclipse插件的机会 - 可以根据Ca，Ce指标突出显示所需的类。
答案 6 :(得分：2)
您可以通过跟踪他们触摸的代码来确定哪些测试相关。您可以 使用测试覆盖率工具跟踪他们触摸的代码。
大多数测试覆盖工具都会构建一组运行测试执行的显式位置;这是＆＃34;覆盖＆＃34;的重点。如果您组织测试运行以一次执行一个单元测试，然后拍摄覆盖率数据的快照，那么您就知道每个测试它所涵盖的代码。
修改代码后，您可以确定修改后的代码与单个测试所涵盖的内容的交集。如果交集非空，您肯定需要再次运行该测试，并且您可能需要更新它。
使这项工作有几个实际问题。
首先，通常很难弄清楚测试覆盖率工具如何记录此定位数据。其次，你必须得到测试机制，以便在每个测试的基础上捕获它;可能难以组织，和/或覆盖数据可能是笨拙的提取和存储。第三，你需要计算修改后的代码和＃34;用＆＃34;代码覆盖＆＃34;通过测试;这在抽象的大位向量中很大程度上是一个问题。最后，捕获＆＃34;代码修改＆＃34;有点棘手，因为有时代码移动;如果文件中的位置100已经过测试，且行在文件中，则可能无法获得可比较的位置数据。这将导致误报和漏报。
有一些测试覆盖工具可以轻松捕获的形式记录覆盖率数据，并可以进行计算。确定代码更改比较棘手;您可以使用diff但移动的代码会稍微混淆问题。你可以找到比较代码结构的diff工具，它们可以识别这些动作，从而获得更好的答案。
如果你有source code slicers，你可以根据输入计算测试输出（后向切片）的方式;显然，该切片中的所有代码都会影响测试。我认为这里的坏消息是这样的切片机并不容易获得。
