为什么不使用函数依赖图来加速测试呢？
在我看来，如果您有源代码的依赖关系图（显示代码库中所有函数的调用堆栈的树），那么您应该能够在每次发布后进行功能和集成测试节省大量时间，这似乎是合乎逻辑的。
本质上，您将能够准确地告诉测试人员要测试哪些功能，因为从源代码的角度来看，其余功能保持不变。
例如，如果您更改了一段代码中的拼写错误，则没有理由再次运行整个测试脚本“以防万一”您引入了严重错误。
我的问题是，为什么软件工程中不使用依赖树？如果使用它们，如何维护它们？有哪些工具可以为 C# .NET、C++ 和 C 源代码生成这些树？
It seems logical to me that if you have a dependency graph of your source code (tree showing call stack of all functions in your code base) you should be able to save a tremendous amount of time doing functional and integration tests after each release.
Essentially you will be able to tell the testers exactly what functionality to test as the rest of the features remain unchanged from a source code point of view.
If for instance you change a spelling mistake in once piece of the code, there is no reason to run through your whole test script again "just in case" you introduced a critical bug.
My question, why are dependency trees not used in software engineering and if you use them, how do you maintain them? What tools are available that generate these trees for C# .NET, C++ and C source code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Visual Studio 2010 的高端版本（Premium 和 Ultimate）与 TFS 结合提供了这种依赖性分析，称为“影响分析”。
请参阅“通过测试影响分析简化测试流程”和
“识别代码更改对测试的影响”。
The high-end versions of Visual Studio 2010 (Premium and Ultimate), in conjunction with TFS, provide such dependency analysis, called "impact analysis".
See "Streamline Testing Process with Test Impact Analysis" and
"Identifying Code Change Impact on Tests".
理想情况下，您应该使用某种持续集成，特别是如果您有多个开发人员，这样源存储库中保存的所有内容都可以每天至少测试一次，以确保当所有内容都在一起时，不会出现任何问题。引入了新的错误。
我很少进行修复拼写错误的更改，就像修复实际错误或添加新功能一样。
但是，您也许可以在 VS2010 的架构工具中找到您想要的东西(http://blogs.msdn.com/b/somasegar/archive/2009/08/29/architecture-tools-in-vsts-2010.aspx)，或者在 VS2008 中这可能会有所帮助： http://www.codeproject.com/ KB/cs/depgraph.aspx。
我对 VS2010 图的问题是，要使其完整，它会变得太复杂而没有多大用处。
理想情况下，如果有某种方法可以选择一个函数或一组函数/类，并让它突出显示所有受影响的内容，这可能会很有用，但只能帮助进行一些功能测试，因为您的测试人员仍然应该仔细检查所有事情，以防发生其他会导致问题的情况。
Ideally you should be using some sort of continuous integration, especially if you have more than one developer, so that everything that has been saved in your source repository can be tested at least once per day to ensure that when everything is together to ensure that no new bugs have been introduced.
Seldom do I have changes where I fix a spelling mistake, as much as fixing actual bugs or adding new features.
But, you may be able to find what you want in VS2010, in the architectural tools(http://blogs.msdn.com/b/somasegar/archive/2009/08/29/architecture-tools-in-vsts-2010.aspx), or in VS2008 this may be helpful: http://www.codeproject.com/KB/cs/depgraph.aspx.
My problem with the VS2010 diagram is that to make it complete it gets too complicated to be of much use.
Ideally, if there was some way to pick one function, or a set of functions/classes, and have it highlight everything that would be affected, that could be useful, but only to help with some functional testing, as, your testers should still go through everything in case something else happened that will cause a problem.
我不同意你的假设。除了执行路径依赖性之外，您的代码还具有数据依赖性。假设您有线程
A和B正在运行。A调用a()，它执行以下操作：线程 B 调用
b()：并且一切正常（比方说；)）。然后有一天，您
出于某种原因更改了第一个函数并改为执行此操作。如果您只检查依赖于
a()的函数，您将永远无法测试b()因为它在某个地方分支 - 它甚至可能是动态回调。这实际上并不限于多线程——只是选择它作为示例。每个共享数据或与外界通信的地方都需要检查 - 这意味着真正使用您列出的语言的“整个程序”。
在某些语言中，在某种程度上可能可以进行此类分析 - 要么是因为缺乏副作用，要么是因为对托管代码进行了一些静态分析 - 但在某些情况下（C/C++），您需要在许多情况下，无法从中获取任何有用的数据。
I do not agree with your assumptions. Your code has data dependencies in addition to the execution path dependencies. Let's say you have threads
AandBrunning.Acallsa()which does:Thread B calls
b():And everything works fine (let's say ;) ). Then one day, you change the first function and do
instead for some reason. If you only check the functions depending on
a(), you'll never get to testb()because it branched in some place - it might be even a dynamic callback.This isn't limited to multithreading really - just chose it as an example. Every place that shares the data, or communicates with the outside world needs to be checked - which means "the whole program" really in the languages you listed.
It might be possible to do to some extent to do such analysis in some languages - either because of the lack of side effects, or because of some static analysis of the managed code - but in some cases (C/C++), you're not going to get any useful data out of it in many cases.
除了 Visual Studio 之外，还有许多独立的源代码依赖分析器可用于此目的； Source Insight 就是这样一种工具，它提供依赖关系图和可视化调用堆栈。
Apart from visual studio there are many standalone source code dependency analyzers which can be used for that; Source insight is one such tool which provides dependency graph and visual call stack.
这是一个非常好的主意，一旦您开始拥有更昂贵的测试用例（需要很多时间来运行）。此外，一个好的测试套件可能会因为没有人运行而被破坏，因为开发人员没有耐心等待运行。
Softagram 是一种独立的源代码依赖性分析器，它还提供用于测试自动化目的的信息。它分析了所有主流语言，如 Java、C、C++、C#、Python、PHP、JavaScript、TypeScript 等。
目前有一个 REST API 提供 Jenkins 脚本中通常使用的信息。借助网络钩子和集中分析设置，Softagram 可以在所有拉取请求出现或修改后立即自动分析它们，以及任何未合并的分支，然后测试自动化就可以提供尽可能新鲜的数据来选择受影响的分支测试用例。
编写一个脚本来为开发人员环境用例从分析服务器请求数据也很容易。当您有大量测试并且想要在从计算机上推送更改之前找到错误时，这使得单元测试变得更加可行。
当前的限制是 Softagram 分析器无法安装到开发人员工作站，而是安装在服务器上。它不分析副作用。在动态语言中，很难正确检测所有函数调用，因此如果代码中还有一些 #include/import 语句以使分析工具了解文件到文件的依赖关系，这会很有用。
免责声明：我来自 Softagram，我们自己将其用于上述目的。
That is very good idea, once you start having test cases that are more expensive (takes much time to run). Also, a good test suite might be spoiled just because nobody is running it, because developer don't have patience to wait for the runs.
Softagram is one standalone source code dependency analyzer that provides the information also for the test automation purposes. It analyzes all the mainstream languages such as Java, C, C++, C#, Python, PHP, JavaScript, TypeScript etc.
Currently there is a REST API that provides the information that is typically used in Jenkins scripts. With help of webhooks and centralized analysis set-up, Softagram can analyze automatically all the pull requests as soon as they appear or are modified, and also any unmerged branches, and the test automation has then as fresh as possible data available for selecting the impacted test cases.
It is also easy to write a script that will request the data from the analysis server for the developer environment use case. This makes unit testing much more feasible when you have huge amount of tests and want to find the errors even before pushing the changes forwards from your computer.
Current limitations are that Softagram analyzer cannot be installed to the developer workstation but is a server installation instead. It does not analyze side-effects. In dynamic languages it is hard to detect all the function calls correctly, so it is useful if you also have some #include/import statements in your code to make the analysis tool aware of your file to file dependencies.
Disclaimer: I am from Softagram and we use it ourselves for abovementioned purpose.