Статические методы устранения ошибок

Способы устранения статической ошибки.

1. Увеличение
   коэф-та передачи системы. Оно не может
   осущ. не ограниченно, т.к. это ведет к
   потере уст-ти системы.

2. Передаточная
   ф-ия по каналу возмущения =0.

Ф_f(0)
=(Знаменатель приравниваем к ∞, или
чиcлитель
приравниваем к 0).

При
реализ-ии управления по возмущению,
возмущение в системе прикладывается
по 2 каналам:

1.
естественному;

2.
искусственному.

W_к(S)
– передат. ф-ия управления по возмущению.

W_f(S)
= W_f0(S)
+ W_k(S)*W₀(S)

W_f(0)
= W_f0(0)
+ W_k(0)*W₀(0)

K_f0
= k_k*k₀=0;
k_k
= —
k_f0/
k₀
— коэф-т
передачи по искусств. каналу.

«-»
означает, что корректирующую связь мы
должны заводить с обратным знаком по
возмущающему воздействию.

Такой
способ устранения статической ошибки
устраняет только ту статическую ошибку,
возмущение по которой можно
проконтролировать.

2-ой
путь компенсации
статической ошибки – введение
астатизма.
Астатической наз. САУ, структурные схемы
которых, будучи приведенные к одноконтурным,
содержат хотя бы одно интегрирующее
звено (астатическое). У интегрир. звеньев
характеристики астатические. Закон
регулирования в астатич. САУ интегральный,
т.е. выход. сигнал регулятора пропорц.
интегралу от ошибки. Если вне объекта
имеется хотя бы одно интегрирующее
звено, то статич. ошибка, вызванная любой
причиной, по принципу действия такой
САУ=0.Интегрирующее звено будет изменять
управляющее воздействие на объект до
тех пор, пока на входе интегрир. звена
сигнал не будет = 0, т.е. пока ошибка не
станет = 0.

Постоянные
ошибки. Среди
типовых режимов работы САУ простейшим
явл. режим работы при постоянной величине
внеш. воздействия (задающего, возмущающего).

G(t)
= const
W(S)
=
,
свободный член = 1

Ф_ε(S)
=

(1)

Диф.
ур-ие в операторной форме:

[L(p)
+ kN(p)]*ε
= L(p)*x(t) (2)

Если
к записи (2) применить теорему о конечном
значении,то ε_уст
= lim
ε(t)
= lim
Ф_ε(S)*X(S)*S
(3) X(S)=X₀/S
X₀

Пользуясь
(3) с учетом (1) запишем: ε_уст
= X₀/(1+k),
если L(S)
и N(S)
имеют свобод. член = 1.

Это
значение ошибки наз. статической ошибкой.
Её можно получить из диф. ур-ия (2) как
частное решение при X(t)=X_0.
Р/м случай,
когда на вход системы подается задающее
воздействие, изменяющееся с постоянной
скоростью. X(t)=
X₀
+ X₁(t).
В этом случае установившаяся ошибка,
как частный случай ур-ия (2) так же будет
изменяться с постоянной скоростью.
Естественно, что при длительном
воздействии такое нарастание ошибки
недопустимо. Для ликвидации этого
явления нужно изменить структуру системы
так, чтобы L(S)
не имел свободного члена. L(S)=S*L(S)
(6). Надо сделать так, чтобы знаменатель
передаточной ф-ии разомкнутой цепи имел
нулевой полюс: X(S)
= X₀/S
+ X₁/S².Получим:
ε_уст
= X₁/k.
В такой системе при задающем воздействии,
изменяющемся с постоянной скоростью,
не будет статической ошибки. Но при этом
в системе устанавл-ся скоростная
ошибка. Если
система содержит хотя бы одно интегральное
звено, то в системе присутствует
скоростная ошибка. Если система имеет
астатизм 1-го порядка (6), то в ней
отсутствует статическая ошибка и
присутствует постоянная скоростная
ошибка.

Соседние файлы в папке ТАУ

• #

  20.06.201423.55 Кб365.doc

• #

  20.06.2014419.84 Кб356.doc

• #

  20.06.201489.6 Кб357.doc

• #

  20.06.2014437.76 Кб348.doc

• #

  20.06.201480.38 Кб369.doc

• #
• #
• #

В фундаментальную концепцию проектирования ПС входят базовые положения, стратегии, методы, которые применяются на процессах ЖЦ и обеспечивают тестирование (верификацию) на множестве тестовых наборов данных. К методам проектирования ПС относятся структурные, объектно-ориентированные и др. Их основу составляют теоретические, инструментальные и прикладные средства, которые влияют на процесс тестирования.

Теоретические средства определяют процесс программирования и тестирования программного продукта. К ним относятся методы верификации и доказательства правильности спецификации программ (см.
«Формальные спецификации,
доказательство и верификация программ»
), метрики измерения (Холстеда, цикломатичная сложность Маккейба и др.) в качестве отдельных характеристик как формализованных элементов теории определения правильности и гарантии свойств конечного ПО. Например, концепция » чистая комната » базируется на формализмах доказательства и изучения свойств процессов кодирования и тестирования программ. Что касается тестирования как процесса, то это проверка правильности работы программы по заданным описаниям тестов и покрытия данными соответствующих критериев программы [7.1-7.5].

Инструментальные средства — это способы поддержки кодирования и тестирования (компиляторы, генераторы программ, отладчики и др.), а также организационные средства планирования и отбора тестов для программ, которые обеспечивают обработку текста на ЯП и подготовку для них соответствующих тестов.

При проверке правильности программ и систем рассматриваются процессы верификации, валидации и тестирования ПС, которые регламентированы в стандарте ISO/IEC 12207 [7.7] жизненного цикла ПО. В некоторой зарубежной литературе процессы верификации и тестирования отождествляются. С теоретической точки зрения верификация была рассмотрена в
«Формальные спецификации,
доказательство и верификация программ»
, здесь же будут определены задачи и действия, соответствующих процессов ЖЦ.

Тестирование — это процесс обнаружения ошибок в ПО путем исполнения выходного кода ПС на тестовых данных, сбора рабочих характеристик в динамике выполнения в конкретной операционной среде, выявления различных ошибок, дефектов, отказов и изъянов, вызванных нерегулярными и аномальными ситуациями или аварийным прекращением работы ПО.Важное место в проведении верификации и тестирования занимают организационные аспекты — деятельность группы специалистов, осуществляющих планирование этих процессов, подготовку тестовых данных и наблюдение за тестированием.

7.1. Процессы ЖЦ верификация и валидация программ

Верификация и валидация, как методы, обеспечивают соответственно проверку и анализ правильности выполнения заданных функций и соответствия ПО требованиям заказчика, а также заданным спецификациям. Они представлены в стандартах [7.7-7.8] как самостоятельные процессы ЖЦ и используются, начиная от этапа анализа требований и кончая проверкой правильности функционирования программного кода на заключительном этапе, а именно, тестировании.

Для этих процессов определены цели, задачи и действия по проверке правильности создаваемого продукта (рабочие, промежуточные продукты) на этапах ЖЦ. Рассмотрим их трактовку в стандартном представлении.

Процесс верификации. Цель процесса — убедиться, что каждый программный продукт (и/или сервис) проекта отражает согласованные требования к их реализации. Этот процесс основывается:

• на стратегии и критериях верификации применительно ко всем рабочим программным продуктам;
• на выполнении действий стандарта по верификации;
• на устранении недостатков, обнаруженных в программных (рабочих и промежуточных) продуктах;
• на согласовании результатов верификации с заказчиком.

Процесс верификации может проводиться исполнителем программы или другим сотрудником той же организации, или сотрудником другой организации, например заказчиком. Этот процесс включает в себя действия по его внедрению и выполнению.

Внедрение процесса заключается в определении критических элементов (процессов и программных продуктов), которые должны подвергаться верификации, в выборе исполнителя верификации, инструментальных средств поддержки процесса верификации, в составлении плана верификации и его утверждении. В процессе верификации выполняются задачи проверки условий: контракта, процесса, требований, интеграции, проекта, кода и документации.При верификации согласно плану и требований заказчика проверяется правильность выполнения функций системы, интерфейсов и взаимосвязей компонентов, а также доступа к данным и к средствам защиты.

Процесс валидации. Цель процесса — убедиться, что специфические требования для программного продукта выполнены, и осуществляется это с помощью:

• разработанной стратегии и критериев валидации для всех рабочих продуктов;
• оговоренных действий по проведению валидации;
• демонстрации соответствия разработанных программных продуктов требованиям заказчика и правилам их использования;
• согласования с заказчиком полученных результатов валидации.

Процесс валидации может проводиться самим исполнителем или другим лицом, например, заказчиком, осуществляющим действия по внедрению и проведению этого процесса по плану, в котором отражены элементы и задачи проверки. При этом используются методы, инструментальные средства и процедуры выполнения задач процесса для установления соответствия тестовых требований и особенностей использования программных продуктов проекта.

На других процессах ЖЦ выполняются дополнительные действия:

• проверка и контроль проектных решений с помощью методик и процедур просмотра хода разработки;
• обращение к CASE-системам [7.10], которые содержат процедуры проверки требований к продукту;
• просмотры и инспекции промежуточных результатов на соответствие их требованиям для подтверждения того, что ПО имеет корректную реализацию требований и удовлетворяет условиям выполнения системы.

Таким образом, основные задачи процессов верификации и валидации состоят в том, чтобы проверить и подтвердить, что конечный программный продукт отвечает назначению и удовлетворяет требованиям заказчика. Эти процессы взаимосвязаны и определяются, как правило, одним общим термином «верификация и валидация» или «Verification and Validation» (V&V) [7.7].

V&V основаны на планировании их как процессов, так и проверки для наиболее критичных элементов проекта: компонент, интерфейсов (программных, технических и информационных), взаимодействий объектов (протоколов и сообщений), передач данных между компонентами и их защиты, а также оставленных тестов и тестовых процедур.

После проверки отдельных компонентов системы проводятся их интеграция и повторная верификация и валидация интегрированной системы, создается комплект документации, отображающий правильность проверки формирования требований, результатов инспекций и тестирования.

7.2. Тестирование программ

Тестирование можно рассматривать, как процесс семантической отладки (проверки) программы, заключающийся в исполнении последовательности различных наборов контрольных тестов, для которых заранее известен результат. Т.е. тестирование предполагает выполнение программы и получение конкретных результатов выполнения тестов [7.1-7.5, 7.11, 7.12].

Тесты подбираются так, чтобы они охватывали как можно больше типов ситуаций алгоритма программы. Менее жесткое требование — выполнение хотя бы один раз каждой ветви программы.

Исторически первым видом тестирования была отладка.

Отладка — это проверка описания программного объекта на ЯП с целью обнаружения в нем ошибок и последующее их устранение. Ошибки обнаруживаются компиляторами при их синтаксическом контроле. После этого проводится верификация по проверке правильности кода и валидация по проверке соответствия продукта заданным требованиям.

Целью тестирования — проверка работы реализованных функций в соответствии с их спецификацией. На основе внешних спецификаций функций и проектной информации на процессах ЖЦ создаются функциональные тесты, с помощью которых проводится тестирование с учетом требований, сформулированных на этапе анализа предметной области. Методы функционального тестирования подразделяются на статические и динамические.

7.2.1. Статические методы тестирования

Статические методы используются при проведении инспекций и рассмотрении спецификаций компонентов без их выполнения.Техника статического анализа заключается в методическом просмотре (или обзоре) и анализе структуры программ, а также в доказательстве их правильности. Статический анализ направлен на анализ документов, разработанных на всех этапах ЖЦ и заключается в инспекции исходного кода и сквозного контроля программы.

Инспекция ПО — это статическая проверка соответствия программы заданным спецификациями, проводится путем анализа различных представлений результатов проектирования (документации, требований, спецификаций, схем или исходного кода программ) на процессах ЖЦ. Просмотры и инспекции результатов проектирования и соответствия их требованиям заказчика обеспечивают более высокое качество создаваемых ПС.

При инспекции программ рассматриваются документы рабочего проектирования на этапах ЖЦ совместно с независимыми экспертами и участниками разработки ПС. На начальном этапе проектирования инспекция предполагает проверку полноты, целостности, однозначности, непротиворечивости и совместимости документов с исходными требованиями к программной системе. На этапе реализации системы под инспекцией понимается анализ текстов программ на соблюдение требований стандартов и принятых руководящих документов технологии программирования.

Эффективность такой проверки заключается в том, что привлекаемые эксперты пытаются взглянуть на проблему «со стороны» и подвергают ее всестороннему критическому анализу.

Эти приемы позволяют на более ранних этапах проектирования обнаружить ошибки или дефекты путем многократного просмотра исходных кодов. Символьное тестирование применяется для проверки отдельных участков программы на входных символьных значениях.

Кроме того, разрабатывается множество новых способов автоматизации символьного выполнения программ. Например, автоматизированное средство статического контроля для языков ориентированной разработки, инструменты автоматизации доказательства корректности и автоматизированный аппарат сетей Петри.

7.2.2. Динамические методы тестирования

Динамические методы тестирования используются в процессе выполнения программ. Они базируются на графе, связывающем причины ошибок с ожидаемыми реакциями на эти ошибки. В процессе тестирования накапливается информация об ошибках, которая используется при оценке надежности и качества ПС.

Динамическое тестирование ориентировано на проверку корректности ПС на множестве тестов, прогоняемых по ПС, в целях проверки и сбора данных на этапах ЖЦ и проведения измерения отдельных показателей (число отказов, сбоев) тестирования для оценки характеристик качества, указанных в требованиях, посредством выполнения системы на ЭВМ. Тестирование основывается на систематических, статистических, (вероятностных) и имитационных методах.

Дадим краткую их характеристику.

Систематические методы тестирования делятся на методы, в которых программы рассматриваются как «черный ящик» (используется информация о решаемой задаче), и методы, в которых программа рассматривается как «белый ящик» (используется структура программы). Этот вид называют тестированием с управлением по данным или управлением по входувыходу. Цель — выяснение обстоятельств, при которых поведение программы не соответствует ее спецификации. При этом количество обнаруженных ошибок в программе является критерием качества входного тестирования.

Цель динамического тестирования программ по принципу «черного ящика» — выявление одним тестом максимального числа ошибок с использованием небольшого подмножества возможных входных данных.

Методы «черного ящика» обеспечивают:

• эквивалентное разбиение;
• анализ граничных значений;
• применение функциональных диаграмм, которые в соединении с реверсивным анализом дают достаточно полную информацию о функционировании тестируемой программы.

Эквивалентное разбиение состоит в разбиении входной области данных программы на конечное число классов эквивалентности так, чтобы каждый тест, являющийся представителем некоторого класса, был эквивалентен любому другому тесту этого класса.

Классы эквивалентности выделяются путем перебора входных условий и разбиения их на две или более групп. При этом различают два типа классов эквивалентности: правильные, задающие входные данные для программы, и неправильные, основанные на задании ошибочных входных значений.Разработка тестов методом эквивалентного разбиения осуществляется в два этапа: выделение классов эквивалентности и построение тестов. При построении тестов, основанных на выборе входных данных, проводится символическое выполнение программы.

Итак, методы тестирования по принципу «черного ящика» используются для тестирования функций, реализованных в программе, путем проверки несоответствия между реальным поведением функций и ожидаемым поведением с учетом спецификаций требований. Во время подготовки к этому тестированию строятся таблицы условий, причинно-следственные графы и области разбивки. Кроме того, подготавливаются тестовые наборы, учитывающие параметры и условия среды, которые влияют на поведение функций. Для каждого условия определяется множество значений и ограничений предикатов, которые тестируются.

Метод «белого ящика» позволяет исследовать внутреннюю структуру программы, причем обнаружение всех ошибок в программе является критерием исчерпывающего тестирования маршрутов потоков (графа) передач управления, среди которых рассматриваются:

• (а) критерий покрытия операторов — набор тестов в совокупности должен обеспечить прохождение каждого оператора не менееодного раза;
• (б) критерий тестирования ветвей (известный как покрытие решений или покрытие переходов) — набор тестов в совокупности должен обеспечить прохождение каждой ветви и выхода, по крайней мере, один раз.

Критерий (б) соответствует простому структурному тесту и наиболее распространен на практике. Для удовлетворения этого критерия необходимо построить систему путей, содержащую все ветви программы. Нахождение такого оптимального покрытия в некоторых случаях осуществляется просто, а в других является более сложной задачей.

Тестирование по принципу «белого ящика» ориентировано на проверку прохождения всех путей программ посредством применения путевого и имитационного тестирования.

Путевое тестирование применяется на уровне модулей и графовой модели программы путем выбора тестовых ситуаций, подготовки данных и включает тестирование следующих элементов:

• операторов, которые должны быть выполнены хотя бы один раз, без учета ошибок, которые могут остаться в программе иззабольшого количества логических путей и необходимости прохождения подмножеств этих путей;
• путей по заданному графу потоков управления для выявления разных маршрутов передачи управления с помощью путевых предикатов, для вычисления которого создается набор тестовых данных, гарантирующих прохождение всех путей. Однако все пути протестировать бывает невозможно, поэтому остаются не выявленные ошибки, которые могут проявиться в процессе эксплуатации;
• блоков, разделяющих программы на отдельные частиблоки, которые выполняются один раз или многократно при нахождении путей в программе, включающих совокупность блоков реализации одной функции либо нахождения входного множества данных, которое будет использоваться для выполнения указанного пути.

«Белый ящик» базируется на структуре программы, в случае «черного ящика», о структуре программы ничего неизвестно. Для выполнения тестирования с помощью этих «ящиков» известными считаются выполняемые функции, входы (входные данные) и выходы (выходные данные), а также логика обработки, представленные в документации.

From Wikipedia, the free encyclopedia

In computer science, static program analysis (or static analysis) is the analysis of computer programs performed without executing them, in contrast with dynamic program analysis, which is performed on programs during their execution.^[1][2]

The term is usually applied to analysis performed by an automated tool, with human analysis typically being called «program understanding», program comprehension, or code review. In the last of these, software inspection and software walkthroughs are also used. In most cases the analysis is performed on some version of a program’s source code, and, in other cases, on some form of its object code.

Rationale[edit]

The sophistication of the analysis performed by tools varies from those that only consider the behaviour of individual statements and declarations,^[3] to those that include the complete source code of a program in their analysis. The uses of the information obtained from the analysis vary from highlighting possible coding errors (e.g., the lint tool) to formal methods that mathematically prove properties about a given program (e.g., its behaviour matches that of its specification).

Software metrics and reverse engineering can be described as forms of static analysis. Deriving software metrics and static analysis are increasingly deployed together, especially in creation of embedded systems, by defining so-called software quality objectives.^[4]

A growing commercial use of static analysis is in the verification of properties of software used in safety-critical computer systems and
locating potentially vulnerable code.^[5] For example, the following industries have identified the use of static code analysis as a means of improving the quality of increasingly sophisticated and complex software:

1. Medical software: The US Food and Drug Administration (FDA) has identified the use of static analysis for medical devices.^[6]
2. Nuclear software: In the UK the Office for Nuclear Regulation (ONR) recommends the use of static analysis on reactor protection systems.^[7]
3. Aviation software (in combination with dynamic analysis).^[8]
4. Automotive & Machines (functional safety features form an integral part of each automotive product development phase, ISO 26262, section 8).

A study in 2012 by VDC Research reported that 28.7% of the embedded software engineers surveyed currently use static analysis tools and 39.7% expect to use them within 2 years.^[9]
A study from 2010 found that 60% of the interviewed developers in European research projects made at least use of their basic IDE built-in static analyzers. However, only about 10% employed an additional other (and perhaps more advanced) analysis tool.^[10]

In the application security industry the name Static application security testing (SAST) is also used. SAST is an important part of Security Development Lifecycles (SDLs) such as the SDL defined by Microsoft^[11] and a common practice in software companies.^[12]

Tool types[edit]

The OMG (Object Management Group) published a study regarding the types of software analysis required for software quality measurement and assessment. This document on «How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations» describes three levels of software analysis.^[13]

Unit Level

Analysis that takes place within a specific program or subroutine, without connecting to the context of that program.

Technology Level

Analysis that takes into account interactions between unit programs to get a more holistic and semantic view of the overall program in order to find issues and avoid obvious false positives.

System Level

Analysis that takes into account the interactions between unit programs, but without being limited to one specific technology or programming language.

A further level of software analysis can be defined.

Mission/Business Level

Analysis that takes into account the business/mission layer terms, rules and processes that are implemented within the software system for its operation as part of enterprise or program/mission layer activities. These elements are implemented without being limited to one specific technology or programming language and in many cases are distributed across multiple languages, but are statically extracted and analyzed for system understanding for mission assurance.

Formal methods[edit]

Formal methods is the term applied to the analysis of software (and computer hardware) whose results are obtained purely through the use of rigorous mathematical methods. The mathematical techniques used include denotational semantics, axiomatic semantics, operational semantics, and abstract interpretation.

By a straightforward reduction to the halting problem, it is possible to prove that (for any Turing complete language), finding all possible run-time errors in an arbitrary program (or more generally any kind of violation of a specification on the final result of a program) is undecidable: there is no mechanical method that can always answer truthfully whether an arbitrary program may or may not exhibit runtime errors. This result dates from the works of Church, Gödel and Turing in the 1930s (see: Halting problem and Rice’s theorem). As with many undecidable questions, one can still attempt to give useful approximate solutions.

Some of the implementation techniques of formal static analysis include:^[14]

• Abstract interpretation, to model the effect that every statement has on the state of an abstract machine (i.e., it ‘executes’ the software based on the mathematical properties of each statement and declaration). This abstract machine over-approximates the behaviours of the system: the abstract system is thus made simpler to analyze, at the expense of incompleteness (not every property true of the original system is true of the abstract system). If properly done, though, abstract interpretation is sound (every property true of the abstract system can be mapped to a true property of the original system).^[15]
• Data-flow analysis, a lattice-based technique for gathering information about the possible set of values;
• Hoare logic, a formal system with a set of logical rules for reasoning rigorously about the correctness of computer programs. There is tool support for some programming languages (e.g., the SPARK programming language (a subset of Ada) and the Java Modeling Language—JML—using ESC/Java and ESC/Java2, Frama-C WP (weakest precondition) plugin for the C language extended with ACSL (ANSI/ISO C Specification Language) ).
• Model checking, considers systems that have finite state or may be reduced to finite state by abstraction;
• Symbolic execution, as used to derive mathematical expressions representing the value of mutated variables at particular points in the code.

Data-driven static analysis[edit]

Data-driven static analysis uses large amounts of code to infer coding rules.^{[16][better source needed]} For instance, one can use all Java open-source packages on GitHub to learn a good analysis strategy. The rule inference can use machine learning techniques.^[17] It is also possible to learn from a large amount of past fixes and warnings.^{[16][better source needed]}

Remediation[edit]

Static analyzers produce warnings. For certain types of warnings, it is possible to design and implement automated remediation techniques. For example, Logozzo and Ball have proposed automated remediations for C# cccheck.^[18]

See also[edit]

References[edit]

Further reading[edit]

• Ayewah, Nathaniel; Hovemeyer, David; Morgenthaler, J. David; Penix, John; Pugh, William (2008). «Using Static Analysis to Find Bugs». IEEE Software. 25 (5): 22–29. CiteSeerX 10.1.1.187.8985. doi:10.1109/MS.2008.130. S2CID 20646690.
• Brian Chess, Jacob West (Fortify Software) (2007). Secure Programming with Static Analysis. Addison-Wesley. ISBN 978-0-321-42477-8.
• Flemming Nielson; Hanne R. Nielson; Chris Hankin (2004-12-10). Principles of Program Analysis (1999 (corrected 2004) ed.). Springer. ISBN 978-3-540-65410-0.
• «Abstract interpretation and static analysis,» International Winter School on Semantics and Applications 2003, by David A. Schmidt

Статический анализ кода

• Обзор кода
• Статический анализ как автоматизация обзоров кода
• Что даёт внедрение статического анализа в процесс разработки?
• Инструменты статического анализа кода
• Сильные стороны статического анализа кода
• Слабые стороны статического анализа кода
• Статическое тестирование безопасности приложений (SAST)
• Как выбрать и внедрить статический анализатор кода
• Примеры ошибок, обнаруживаемых статическим анализом кода
• Другие ресурсы

Статический анализ кода — это процесс выявления недочетов, ошибок и потенциальных уязвимостей в исходном коде программ. Статический анализ можно рассматривать как автоматизированный процесс обзора кода.

Обзор кода

Обзор кода (code review) – один из самых старых и полезных методов выявления дефектов. Он заключается в совместном внимательном чтении исходного кода и высказывании рекомендаций по его улучшению. В процессе чтения кода выявляются ошибки или участки кода, которые могут стать ошибочными в будущем. Также считается, что автор кода во время обзора не должен давать объяснений, как работает та или иная часть программы. Алгоритм работы должен быть понятен непосредственно из текста программы и комментариев. Если это условие не выполняется, то код должен быть доработан.

Как правило, обзор кода хорошо работает, так как программисты намного легче замечают ошибки в чужом коде. Более подробно с методикой обзора кода можно познакомиться в замечательной книге Стива Макконнелла «Совершенный код» (Steve McConnell, «Code Complete»).

Статический анализ как автоматизация обзоров кода

Существенный недостаток методологии совместного обзора кода — это крайне высокая стоимость. Необходимо регулярно собирать нескольких программистов для обзора нового кода или повторного обзора кода после внесения рекомендаций. При этом программисты должны регулярно делать перерывы для отдыха. Если пытаться просматривать сразу большие фрагменты кода, то внимание быстро притупляется, и польза от обзора кода быстро сходит на нет.

Получается, что с одной стороны хочется регулярно осуществлять обзор кода. С другой — это слишком дорого. Компромиссным решением являются инструменты статического анализа кода. Они без устали обрабатывают исходные тексты программ и выдают программисту рекомендации обратить повышенное внимание на определенные участки кода. Конечно, программа не заменит полноценного обзора кода, выполняемого коллективом программистов. Однако соотношение польза/цена делает использование статического анализа полезной практикой, применяемой многими компаниями.

Что даёт внедрение статического анализа в процесс разработки?

• Выявление ошибок в программах и «кода с запахом» (например, непереносимый или сложный для понимания код).
• Обнаружение потенциальных уязвимостей.
• Рекомендации по оформлению кода. Некоторые статические анализаторы позволяют проверять, соответствует ли исходный код принятому в компании стандарту оформления кода. Имеется в виду контроль количества отступов в различных конструкциях, использование пробелов/символов табуляции и так далее.
• Подсчет метрик. Метрика программного обеспечения — это мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.
• Проверка соответствия текста программы определённым стандартам кодирования (MISRA, CWE, SEI CERT, и т.д.).
• Контроль качества кода во времени. Собирая статистику, можно узнать, растёт или уменьшается плотность ошибок со временем. Это позволяет отвечать на вопросы, какие изменения в процессе разработки проекта пошли на пользу, а какие нет.

Есть и другие способы использования инструментов статического анализа кода. Например, статический анализ можно использовать как метод контроля и обучения новых сотрудников, еще недостаточно знакомых с правилами программирования в компании.

Инструменты статического анализа кода

Существует большое количество коммерческих и бесплатных статических анализаторов кода. Большой список статических анализаторов имеется на сайте Wikipedia: List of tools for static code analysis. Список языков, для которых существуют статические анализаторы кода, также достаточно велик (C, C++, C#, Java, Ada, Fortran, Perl, Ruby, …).

Если вам интересно, как анализаторы кода выявляют ошибки, то вы можете познакомиться с их устройством на примере PVS-Studio: Технологии статического анализа кода PVS-Studio.

Сильные стороны статического анализа кода

Как и у любой другой методологии выявления ошибок, у статического анализа есть свои сильные и слабые стороны. Важно понимать, что нет идеального метода тестирования программ. Для разных классов программного обеспечения разные методики будут давать разные результаты. Добиться высокого качества программы можно, только используя сочетание различных методик.

Главное преимущество статического анализ состоит в возможности существенного снижения стоимости устранения дефектов в программе. Чем раньше ошибка выявлена, тем меньше стоимость ее исправления. Так согласно данным, приведенным в книге Макконнелла «Совершенный Код», исправление ошибки на этапе тестирования обойдется в десять раз дороже, чем на этапе конструирования (написания кода):

Рисунок 1. Средняя стоимость исправления дефектов в зависимости от времени их внесения и обнаружения (данные для таблицы взяты из книги С. Макконнелла «Совершенный Код»).

Инструменты статического анализа позволяют выявить большое количество ошибок этапа конструирования (написания кода), что существенно снижает стоимость разработки всего проекта. Например, статический анализатор кода PVS-Studio может запускаться в фоновом режиме сразу после компиляции и в случае нахождения потенциальной ошибки уведомит программиста (см. режим инкрементального анализа).

Другие преимущества статического анализа кода:

• Тестирование всего кода. Статические анализаторы проверяют даже те фрагменты кода, которые выполняются крайне редко. Такие участки кода, как правило, не удается протестировать другими методами. Это позволяет находить дефекты в обработчиках редких ситуаций, в обработчиках ошибок или в системе логирования.
• Статический анализ не зависит от используемого компилятора и среды, в которой будет выполняться скомпилированная программа. Это позволяет находить скрытые ошибки, которые могут проявить себя только через несколько лет. Например, это ошибки неопределенного поведения. Такие ошибки могут проявить себя при смене версии компилятора или при использовании других ключей для оптимизации кода. Другой интересный пример скрытых ошибок приводится в статье «Перезаписывать память — зачем?».
• Можно легко и быстро обнаруживать опечатки и последствия использования Copy-Paste. Как правило, нахождение этих ошибок другими способами является крайне неэффективной тратой времени и усилий. Обидно после часа отладки обнаружить, что ошибка заключается в выражении вида «strcmp(A, A)». Обсуждая типовые ошибки, про такие ляпы, как правило, не вспоминают. Но на практике на их выявление тратится существенное время.

Слабые стороны статического анализа кода

• Статический анализ, как правило, слаб в диагностике утечек памяти и параллельных ошибок. Чтобы выявлять подобные ошибки, фактически необходимо виртуально выполнить часть программы. Это крайне сложно реализовать. Также подобные алгоритмы требуют очень много памяти и процессорного времени. Как правило, статические анализаторы ограничиваются диагностикой простых случаев. Более эффективным способом выявления утечек памяти и параллельных ошибок является использование инструментов динамического анализа.
• Программа статического анализа предупреждает о подозрительных местах. Это значит, что на самом деле код может быть совершенно корректен. Это называется ложноположительными срабатываниями. Понять, указывает анализатор на ошибку или выдал ложное срабатывание, может только программист. Необходимость просматривать ложные срабатывания отнимает рабочее время и ослабляет внимание к тем участкам кода, где в действительности содержатся ошибки.

Ошибки, обнаруживаемые статическими анализаторами весьма разнообразны. Вот, например, список диагностик, которые реализованы в инструменте PVS-Studio. Некоторые анализаторы специализируются на определенной области или типах дефектов. Другие, поддерживают определенные стандарты кодирование, например MISRA-C:1998, MISRA-C:2004, Sutter-Alexandrescu Rules, Meyers-Klaus Rules и так далее.

Статическое тестирование безопасности приложений (SAST)

В качестве одной из разновидностей статического анализа можно выделить Static Application Security Testing (SAST). Эти анализаторы ориентированы на выявление потенциальных уязвимостей с целью защитить код приложений от уязвимостей нулевого дня. Другими словами, задача состоит в том, чтобы команда разработчиков сама нашла и устранила дефекты безопасности на этапе написания кода, а не чтобы это позже сделал злоумышленник в своих целях.

Анализатор PVS-Studio также является SAST-решением.

Как выбрать и внедрить статический анализатор кода

Сфера статического анализа активно развивается, появляются новые инструменты, новые стандарты кодирования. В статических анализаторах реализуются новые диагностические правила, некоторые правила устаревают. Разные анализаторы интегрируется с разными IDE, CI, облачными CI и так далее.

В итоге нет возможности всесторонне сравнить статические анализаторы и выбрать «самый лучший». Сложность подтверждается и тем, что в интернете можно найти только поверхностные статьи о сравнении статических анализаторов. Поэтому рационально выбрать и попробовать несколько подходящих под ваши требования: поддержка языков, интеграция с CI/CD, плагины для IDE, поддерживаемые стандарты кодирования и так далее. А затем выбрать тот, который показался вам наиболее удобным и нашёл реальные ошибки в вашем проекте.

Следующий этап: внедрение инструмента в ваш процесс разработки. Про это есть две статьи, в которых хорошо раскрыта эта тема:

• Как внедрить статический анализатор кода в legacy проект и не демотивировать команду.
• Внедряйте статический анализ в процесс, а не ищите с его помощью баги.

Примеры ошибок, обнаруживаемых статическим анализом кода

• Ноль, один, два, Фредди заберёт тебя.
• Зло живёт в функциях сравнения.
• Эффект последней строки.
• Espressif IoT Development Framework: 71 выстрел в ногу.
• Обработка дат притягивает ошибки или 77 дефектов в Qt 6.
• Примеры ошибок, которые может обнаружить PVS-Studio в коде LLVM 15.0.
• Ошибки и подозрительные места в исходниках .NET 6.

Другие ресурсы

• Википедия. «Статический анализ кода».
• Coverity. A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World.
• Джон Кармак. Статический Анализ Кода.
• Андрей Карпов. Развитие инструментария С++ программистов: статические анализаторы кода.
• Андрей Карпов, Виктория Ханиева. Использование машинного обучения в статическом анализе исходного кода программ.
• Сергей Васильев. Место SAST в Secure SDLC: 3 причины внедрения в DevSecOps-пайплайн.