本机 C++ 中的自动死代码检测 Windows 上的应用程序？
背景
我有一个用本机 C++ 编写的应用程序，花了几年的时间，大约有 60 KLOC。 有很多函数和类已经死了（可能有 10-15% 就像下面提出的类似的基于 Unix 的问题）。 我们最近开始对所有新代码进行单元测试，并尽可能将其应用于修改后的代码。 不过，我想说的是，我们目前的测试覆盖率还不到 5%。
假设/约束
方法和/或工具必须支持：
- 本机（即非托管）C++
- Windows XP
- Visual Studio 2005
- 不得要求用户提供测试用例来进行覆盖。 （例如不能依赖单元测试来生成代码覆盖率）
如果方法支持超过这些要求，那就太好了。
注意：我们当前使用 Visual Studio 2005 专业版，而不是 Team System。 因此，使用团队系统可能是一个有效建议（我不知道，我从未使用过它），但我希望它不是唯一解决方案。
为什么使用单元测试进行代码覆盖率是有问题的
我相信通用工具不可能在任何任意应用程序中以零误报找到所有死区（例如无法访问的代码）（我认为这相当于停止问题）。 然而，我也相信通用工具有可能找到许多类型的死代码，这些代码很可能实际上已经死了，比如在代码中从未被其他任何东西引用的类或函数。
通过使用单元测试来提供此覆盖范围，您不再使用通用算法，从而增加了您可以检测到的死代码的百分比以及任何命中不是误报的概率。 相反，使用单元测试可能会导致漏报，因为单元测试本身可能是唯一执行给定代码段的东西。 理想情况下，我会进行回归测试，以执行所有外部可用的方法、API、用户控件等，这将作为代码覆盖率分析的基线测量，以排除某些方法的误报。 然而遗憾的是，我目前没有这种自动化测试。
然而，由于我拥有如此庞大的代码库，而测试用例覆盖率却如此之低，因此我正在寻找一些可以提供帮助的东西，而不需要在编写测试用例上投入大量时间。
问题
如何使用 Visual Studio 2005 开发环境在 Windows 平台上的本机 C++ 应用程序中以自动或半自动方式检测死代码？
另请参阅
Background
I have an application written in native C++ over the course of several years that is around 60 KLOC. There are many many functions and classes that are dead (probably 10-15% like the similar Unix based question below asked). We recently began doing unit testing on all new code and applying it to modified code whenever possible. However, I would make a SWAG that we have less than 5% test coverage at the present moment.
Assumptions/Constraints
The method and/or tools must support:
- Native (i.e. unmanaged) C++
- Windows XP
- Visual Studio 2005
- Must not require user supplied test cases for coverage. (e.g. can't depend on unit tests to generate code coverage)
If the methods support more than these requirements, then great.
NOTE: We currently use the Professional edition of Visual Studio 2005, not the Team System. Therefore, using Team System might be a valid suggestion (I don't know, I've never used it) however I'm hoping it is not the only solution.
Why using unit tests for code coverage is problematic
I believe that it is impossible for a generic tool to find all the dead (e.g. unreachable code) in any arbitrary application with zero false positives (I think this would be equivalent to the Halting problem). However, I also believe it is possible for a generic tool to find many types of dead code that are highly probable to in fact be dead, like classes or functions which are never reference in the code by anything else.
By using unit tests to provide this coverage, you no longer using a generic algorithm and are thus increasing both the percentage of dead code you can detect and the probability that any hits are not false positives. Conversely, using unit tests could result in false negatives since the unit tests themselves might be the only thing exercising a given piece of code. Ideally, I would have regression testing that exercises all externally available methods, APIs, user controls, etc. which would serve as a baseline measurement of code coverage analysis to rule out certain methods from being false positives. Sadly however, I do not have this automated testing at the present time.
Since I have such a large code base with such a low test case coverage percentage however, I'm looking for something that could help without requiring huge amounts of time invested in writing test cases.
Question
How do you go about detecting dead code in an automated or semi-automated fashion in a native C++ application on the Windows platform with the Visual Studio 2005 development environment?
See Also
Dead code detection in legacy C/C++ project
I want tell the VC++ Compiler to compile all code. Can it be done?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
要求链接器删除未引用的对象 (/OPT:REF)。 如果您使用函数级链接和详细链接器输出，则链接器输出将列出它可以证明未使用的每个函数。 此列表可能远未完成，但您已经拥有所需的工具。
Ask the linker to remove unreferenced objects (/OPT:REF). If you use function-level linking, and verbose linker output, the linker output will list every function it can prove is unused. This list may be far from complete, but you already have the tools needed.
我们使用 Bullseye，我可以推荐它。 它不需要从单元测试环境运行，尽管我们就是这么做的。
We use Bullseye, and I can recommend it. It doesn't need to be run from a unit test environment, although that's what we do.
针对您的单元测试套件使用代码覆盖率工具。
Use a code coverage tool against your unit test suite.