软件动态分析喝静态分析

Our team writes a lot about the usefulness of static analysis and the benefits it brings to your projects. We like to run our tool on various open-source projects to find possible bugs, which is our way to popularize the static code analysis method. In its turn, static analysis helps to make programs more high-quality and reliable and reduce the number of potential vulnerabilities. Perhaps everyone who is directly involved in work on source code has that feeling of satisfaction at having bugs fixed. But even if the process of successfully spotting (and fixing) bugs doesn't trigger your endorphins, you surely enjoy the thought of having development expenses reduced thanks to the static analyzer, which has helped your programmers use their time more effectively and efficiently. To find out more about how you can benefit from the use of static analysis in terms of money, see this article. It gives an approximate estimate for PVS-Studio, but those results can be extrapolated to other static analysis tools available on market.

我们的团队撰写了大量有关静态分析的有用性及其为您的项目带来的好处的文章。 我们喜欢在各种开源项目上运行我们的工具，以发现可能的错误，这是我们推广静态代码分析方法的方式。 反过来，静态分析有助于使程序更优质，更可靠，并减少潜在漏洞的数量。 也许每个直接从事源代码工作的人都对修复错误感到满意。 但是，即使成功发现(和修复)错误的过程没有触发您的内啡肽，您也一定会喜欢使用静态分析器来减少开发费用的想法，这有助于您的程序员更有效地利用他们的时间。 要了解更多有关如何从金钱上使用静态分析的好处，请参阅本文 。 它提供了PVS-Studio的近似估算值，但这些结果可以推断到市场上可用的其他静态分析工具中。

All said above seems to suggest that the purpose of static analysis is to find bugs in the source code as early as possible, thus reducing the expenses on bug fixing. But why do we need dynamic analysis then, and why sticking only to one of the two techniques may be insufficient? Let's give more formal and clear definitions of static and dynamic analyses and try to answer these questions.

以上所述似乎暗示了静态分析的目的是尽早发现源代码中的错误，从而减少了错误修复的费用。 但是，为什么我们需要动态分析，为什么仅坚持两种技术之一可能不够用呢？ 让我们给出静态和动态分析的更正式，更清晰的定义，并尝试回答这些问题。

Static code analysis is the process of detecting errors and code smells in software's source code. To analyze a program, you don't need to execute it; the analysis will be performed on the available code base. The closest analogy to static analysis is the so called code review except that static analysis is an automated version of code review (i.e. performed by a bot program).

静态代码分析是检测软件源代码中的错误和代码味道的过程。 要分析程序，您无需执行它。 分析将在可用代码库上进行。 与静态分析最接近的类比是所谓的代码审查，除了静态分析是代码审查的自动版本(即由bot程序执行)。

The main pros of static analysis:

静态分析的主要优点：

1. Bug detection at the early development stages. This helps to make bug fixing much cheaper because the earlier a defect is detected, the easier — and, therefore, the cheaper — it is to fix.在早期开发阶段进行错误检测。 这有助于使错误修复便宜得多，因为发现缺陷的时间越早，修复起来就越容易-因此也就便宜了。
2. It allows you to precisely locate the potential bug in the source code.它使您可以在源代码中精确定位潜在的错误。
3. Full code coverage. No matter how often one block of code or another gets control while executing, static analysis checks the entire code base.完整的代码覆盖率。 无论一个代码块或另一个代码块在执行时获得控制的频率，静态分析都会检查整个代码库。
4. Easy to use. You don't need to prepare any input data sets to do a check.易于使用。 您无需准备任何输入数据集即可进行检查。
5. Static analyzers detect typos and copy-paste related mistakes fairly quickly and easily.静态分析仪可以相当快速，轻松地检测到打字错误和与复制粘贴相关的错误。

The objective cons of static analysis:

静态分析的客观缺点：

1. Inevitable false positives. A static analyzer can get angry about code fragments that actually don't have any bugs in them. Only the programmer can solve this problem and mark a warning as a false positive, which means it will take some of their working time.不可避免的误报。 静态分析器可能会对实际上没有任何错误的代码片段感到生气。 只有程序员才能解决此问题，并将警告标记为误报，这意味着这将花费他们一些工作时间。

2. Static analysis is generally bad at detecting memory leaks and concurrency related errors. To detect such errors, you'd in fact have to execute some part of the program in virtual mode, which is an extremely difficult task. Besides, such algorithms would require too much memory and CPU time. Static analyzers typically don't go any farther than analyzing some simple cases. Dynamic analyzers are more fit to diagnose memory leaks and concurrency related errors.

   静态分析通常不利于检测内存泄漏和与并发相关的错误。 要检测此类错误，实际上您必须在虚拟模式下执行程序的某些部分，这是一项极其困难的任务。 此外，此类算法将需要过多的内存和CPU时间。 静态分析器通常不会比分析一些简单的情况更复杂。 动态分析器更适合于诊断内存泄漏和并发相关的错误。

It should be noted that static analyzers don't focus exclusively on bug catching. For instance, they can provide recommendations on code formatting. Some tools allow you to check your code for compliance with the coding standard your company sticks to. This includes indentation of various constructs, the use of space/tabulation characters, and so on. In addition, static analysis can be helpful for measuring metrics. A software metric is a quantitative measure of the degree to which a program or its specifications possess some property. See this article to learn about other uses of static analysis.

应该注意的是，静态分析器并不仅专注于错误捕获。 例如，他们可以提供有关代码格式的建议。 一些工具使您可以检查代码是否符合公司所遵循的编码标准。 这包括各种结构的缩进，空格/制表符的使用等。 此外，静态分析可能有助于度量指标。 软件度量标准是对程序或其规范具有某种属性的程度的定量度量。 请参阅本文以了解静态分析的其他用途。

Dynamic code analysis is the analysis performed on a program at execution time. This means you must have your source code converted into an executable file first. In other words, code containing compilation or build errors can't be checked by this type of analysis. The check is done with a set of input data fed to the program under analysis. That's why the effectiveness of dynamic analysis directly depends on the quality and quantity of the test input data. It is this data that determines the extent of code coverage at the end of the test.

动态代码分析是在执行时对程序执行的分析。 这意味着您必须先将源代码转换为可执行文件。 换句话说，这种类型的分析无法检查包含编译或生成错误的代码。 该检查是通过将一组输入数据馈送到要分析的程序来完成的。 因此，动态分析的有效性直接取决于测试输入数据的质量和数量。 正是这些数据确定了测试结束时代码覆盖的程度。

With dynamic testing, you can get the following metrics and warnings:

通过动态测试，您可以获得以下指标和警告：

1. Resources used: execution time of the entire program or its individual parts, the number of external queries (for instance, to a database), the amount of RAM and other resources used by the program.使用的资源：整个程序或其各个部分的执行时间，外部查询的数量(例如，对数据库的查询)，RAM的数量以及程序使用的其他资源。
2. The extent of code coverage by tests and other metrics.测试和其他指标的代码覆盖范围。
3. Software bugs: division by zero, null dereference, memory leaks, race conditions.软件错误：被零除，空取消引用，内存泄漏，竞争条件。
4. Some security vulnerabilities.一些安全漏洞。

The main pros of dynamic analysis:

动态分析的主要优点：

1. You don't have to have access to the program's source code to analyze it. It should be noted, however, that dynamic analysis tools are differentiated by the way they interact with the program under analysis (this is discussed in more detail here). For example, one quite common dynamic analysis technique involves code instrumentation before the check, i.e. the addition of special code fragments to the application's source code for the analyzer to be able to diagnose errors. In that case, you do need to have the source code of the program at hand.

   您不必访问程序的源代码即可对其进行分析。 应当指出，然而，动态分析工具的方式区分它们与所分析的程序(这是更详细的讨论互动这里 )。 例如，一种非常普遍的动态分析技术涉及在检查之前进行代码检测，即在应用程序的源代码中添加特殊代码片段，以使分析器能够诊断错误。 在这种情况下，您确实需要手头程序的源代码。

2. It can detect complex memory handling errors such as indexing beyond array bounds and memory leaks.它可以检测复杂的内存处理错误，例如超出数组范围的索引编制和内存泄漏。
3. It can analyze multithreaded code at execution time, thus detecting potential problems that have to do with access to shared resources or possible deadlocks.它可以在执行时分析多线程代码，从而检测与共享资源访问或可能出现的死锁有关的潜在问题。
4. Most implementations of dynamic analyzers don't generate false positives since errors get caught as they occur. Therefore, a warning issued by a dynamic analyzer is not a prediction made by the tool based on the analysis of the program model but a mere statement of the fact that an error has occurred.动态分析器的大多数实现都不会产生误报，因为错误会在错误发生时被捕获。 因此，动态分析器发出的警告不是该工具根据程序模型的分析做出的预测，而仅仅是对发生错误这一事实的陈述。

The cons of dynamic analysis:

动态分析的缺点：

1. Full code coverage is not guaranteed. That is, you are very unlikely to get 100% coverage by dynamic testing.不能保证完整的代码覆盖率。 也就是说，您不太可能通过动态测试获得100％的覆盖率。
2. Dynamic analyzers are bad at detecting logic errors. For example, an always true condition is not a bug from a dynamic analyzer's perspective since such an incorrect check simply disappears earlier at the compilation step.动态分析器不善于检测逻辑错误。 例如，从动态分析器的角度来看，始终为真的条件并不是错误，因为这种不正确的检查只会在编译步骤的早期消失。
3. It's more difficult to precisely locate the error in the code.在代码中精确定位错误更加困难。
4. Dynamic analysis is more difficult to use in comparison with static analysis as you need to feed enough data to the program to get better results and attain as full code coverage as possible.与静态分析相比，动态分析更难以使用，因为您需要向程序中馈入足够的数据以获得更好的结果并获得尽可能多的代码覆盖率。

Dynamic analysis is particularly useful in those areas where program reliability, response time, or resources consumed are the primary concern. A real-time system managing a critical production sector or a database server are some examples of such systems. Any error in these areas can be critical.

动态分析在程序可靠性，响应时间或消耗的资源是主要关注的那些领域特别有用。 管理关键生产部门或数据库服务器的实时系统是此类系统的一些示例。 这些区域中的任何错误都可能是至关重要的。

Getting back to the question why sticking only to one of the two types of analysis may not be sufficient, let's take a look at a couple of quite trivial examples of bugs that one analysis method has no problems diagnosing while the other is not fit to detect, and vice versa.

回到为什么仅坚持两种分析中的一种可能还不够的问题，让我们看几个错误的例子，一种错误的诊断方法没有问题，而另一种不适合检测，反之亦然。

The following example is taken from the Clang project:

以下示例取自Clang项目：

MapTy PerPtrTopDown;
MapTy PerPtrBottomUp;
void clearBottomUpPointers() {PerPtrTopDown.clear();
}
void clearTopDownPointers() {PerPtrTopDown.clear();
}

A static analyzer would point out that the bodies of the two functions are identical. Of course, two functions having identical bodies aren't necessarily a definite sign of a bug, but it is very likely that they have resulted from using the copy-paste technique combined with carelessness on the programmer's side — and that leads to unexpected behavior. In this case, the clearBottomUpPointers method should call the PerPtrBottomUp.clear method. Dynamic analysis wouldn't notice anything wrong in this example because it's an absolutely legitimate piece of code from its point of view.

静态分析器会指出这两个函数的主体是相同的。 当然，具有相同主体的两个函数不一定是错误的明确标志，但是它们很有可能是由于使用复制粘贴技术以及程序员的粗心大意而导致的，并且导致了意外行为。 在这种情况下， clearBottomUpPointers方法应调用PerPtrBottomUp.clear方法。 在此示例中，动态分析不会发现任何错误，因为从它的角度来看，它是绝对合法的代码。

Another example. Suppose we have the following function:

另一个例子。 假设我们具有以下功能：

void OutstandingIssue(const char *strCount)
{unsigned nCount;sscanf_s(strCount, "%u", &nCount);int array[10];memset(array, 0, nCount * sizeof(int));
}

In theory, a static analyzer could suspect there's something wrong with this code, but implementing such a diagnostic is a very difficult and pointless task. The example is taken from this article, which also elaborates on why it's a bad idea to teach static analyzers how to diagnose errors like that. In brief, static analyzers are very bad at figuring out that a call of the memset function may result in indexing beyond array bounds as they cannot foresee what number will be read from the strCount string; and if the value of strCount is read from a file, it becomes an impossible task for static analysis altogether. On the other hand, a dynamic analyzer would have no trouble noticing and pointing out the memory handling error in this code (given that the program is fed the right data).

从理论上讲，静态分析器可能会怀疑此代码有问题，但是实现这种诊断是一项非常困难且毫无意义的任务。 该示例摘自本文 ， 该文章还详细说明了为什么教静态分析仪如何诊断此类错误是个坏主意。 简而言之，静态分析器很难弄清楚调用memset函数可能导致索引超出数组范围，因为它们无法预见将从strCount字符串读取什么数字。 如果从文件中读取了strCount的值，则对于静态分析而言，这完全是不可能的任务。 另一方面，动态分析器可以毫不费力地注意到并指出此代码中的内存处理错误(假设已向程序提供了正确的数据)。

This article doesn't aim at comparing static and dynamic analyses. There's no single technique that could diagnose the whole variety of software defects. Neither type of analysis can completely replace the other. To improve the quality of your programs, you'll have to use different types of tools so that they complement each other. I hope the examples shown above are persuading enough.

本文的目的不是比较静态分析和动态分析。 没有一种技术可以诊断出各种软件缺陷。 两种分析都不能完全替代另一种。 为了提高程序的质量，您必须使用不同类型的工具，以便它们可以相互补充。 我希望上面展示的例子能令人信服。

I don't wish to look too biased toward static analysis, but it is this technique that's being most spoken of and, more importantly, included by companies into their CI processes lately. Static analysis acts as one of the steps of the so called quality gates to building a reliable and high-quality software product. We believe static analysis is going to become a standard software development practice in a couple of years, just like unit testing once did.

我不希望偏向于静态分析，但是最近最常被谈论的是此技术，更重要的是，公司最近将其包含在其CI流程中。 静态分析是构建可靠且高质量的软件产品的所谓质量门的步骤之一。 我们认为静态分析将在几年内成为标准的软件开发实践，就像单元测试曾经一样。

To wrap up, I'd like to point out once again that dynamic analysis and static analysis are just two different methods, which complement each other. In the end, all these techniques serve the single purpose of increasing software quality and reducing development expenses.

最后，我想再次指出，动态分析和静态分析只是两种不同的方法，它们相互补充。 最后，所有这些技术都可以达到提高软件质量和减少开发费用的单一目的。

参考文献： (References:)

1. Terminology. Static code analysis.

   术语。 静态代码分析 。

2. Terminology. Dynamic code analysis.

   术语。 动态代码分析 。

3. Andrey Karpov. Static and Dynamic Code Analysis.

   安德烈·卡波夫(Andrey Karpov)。 静态和动态代码分析 。

4. Andrey Karpov. Myths about static analysis. The third myth — dynamic analysis is better than static analysis.

   安德烈·卡波夫(Andrey Karpov)。 关于静态分析的神话。 第三个神话-动态分析优于静态分析 。

5. Andrey Karpov. PVS-Studio ROI.

   安德烈·卡波夫(Andrey Karpov)。 PVS-Studio的投资回报率 。

翻译自: https://habr.com/en/company/pvs-studio/blog/461173/

软件动态分析喝静态分析