Coverage Cookbook/Coverage Metrics and process (Theory)/Code Coverage Metrics/ru
|
Эта статья требует перевода на русский язык |
- Coverage Metrics and process (en)
- Code Coverage Metrics (en)
- Functional Coverage Metrics (en)
- Coverage Examples (Practice) (en)
В этом разделе мы рассмотрим различные измерения покрытия, связанные с design model's implicit implementation coverage space. В общем, эти измерения относят к покрытию кода или измерениям структурного покрытия.
Содержание |
Преимущества
Покрытие кода, чье происхождение может быть прослежено с 1960-х годов, является одним из первых методов изобретенных для систематического тестирования программного обеспечения [1]. Одним из преимуществ покрытия кода является то, что оно автоматически описывает степень, в которой исходный код программы был активирован во время тестирования, таким образом, выявляя структуры в исходном коде, которые не были активированы во время тестирования. Одним из ключевых преимуществ покрытия кода, в отличие от функционального покрытия, является то, что создание структурной модели покрытия — это автоматический процесс. Таким образом, интеграция покрытия кода в существующий маршрут моделирования проста и не требует изменений вашего текущего проекта или способа верификации.
Ограничения:
В нашем разделе, называемом "Что такое покрытие?", мы обсудили три важных условия, которые должны произойти в процессе моделирования для успешного тестирования. Это были:
- Тестовая программа должна создавать надлежащие входные воздействия для активации ошибки в проекте.
- Тестовая программа должна создавать надлежащие входные воздействия для распространения всех последствий (явлений), связанных с ошибкой в проекте, на выходной порт.
- Тестовая программа должна содержать монитор, который может обнаружить ошибку в проекте, которая была сначала активирована, затем распространена в точку, где может быть обнаружена.
Покрытие кода является измерением структур в исходном коде, которые были активированы в процессе моделирования. Одним из ограничений с метриками покрытия кода является то, что вы могли бы добиться 100% покрытия кода во время выполнения регрессии, означающее, что ваша тестовая программа обеспечивала сигналы, которые активировали все структуры в исходном коде вашего RTL, несмотря на то, что существовали ошибки в проекте. Например, входной сигнал мог активировать строку кода, которая содержала ошибку, но тестовая программа не генерировала необходимый дополнительный сигнал, который распространяет эффекты ошибки в некоторую точку тестовой программы, где это может быть обнаружено. На самом деле, исследователи изучили эту проблему и нашли случаи, когда тестовая программа достигала 90% покрытия кода, несмотря на то, что только 54% покрытого кода может наблюдаться во время моделирования. [2] Это означает, что ошибка могла существовать в строке кода, которая была помечены как covered?yet the bug was never detected due to insufficient input stimulus to propagate the bug to an observability point.
Другим ограничением покрытия кода является то, что оно не указывает, какая конкретно функциональность, определенная в спецификации, была протестирована. Например, вы можете столкнуться с ситуацией, когда вы достигли 100% покрытия кода и затем полагаете, что все готово. Тем не менее, может существовать функциональность, определенная в спецификации, которая не была протестирована или даже функциональность, которая никогда не были реализована! Метрики покрытия кода не помогут вам найти эти ситуации.
Даже с этими ограничениями, автоматический аспект покрытия кода является относительно простым способом определения недостатков входного сигнала в тестовой программе. И это отличный первый выбор для покрытия метрик, пока вы начинаете развивать ваши расширенные возможности процесса верификации.
Типы метрик покрытия кода
Покрытие переключений
Покрытие переключений это метрика покрытия кода, используемая для подсчета количества раз, сколько каждый бит регистра или wire изменил свое значение. Хотя это относительно простая метрика, многие проекты имеют такие требования тестирования, что все порты и регистры, как минимум, должно быть проверены на переходы ноль - единица и единица - ноль.
В целом, рассмотрение отчета анализа покрытия переключений может быть непреодолимым и иметь мало значения, если не отнестись к этому с должной тщательностью. Например, покрытие переключения часто используется для проверки основного соединения между IP-блоками. Кроме того, может быть полезно знать, что многие управляющие структуры, такие как one-hot select bus, были полностью выполнены.
Покрытие строк кода
Покрытие строк кода - это метрика покрытия кода, которую мы используем, чтобы определить, какие строки нашего кода были выполнены во время моделирования. Отчет метрики строкового покрытия будет иметь число, связанное с каждой строкой исходного кода, указывающее полное количество раз, когда строка выполнена. Значение количества строк выполнения не только полезно для выявления строк исходного кода, которые никогда не выполняются, но и также полезно, когда инженер считает, что требуется минимальный порог строк выполнения для достижения достаточного тестирования.
Анализ покрытия строк кода часто показывает, что редкое состояние, необходимое для активации строки кода, не произошло из-за отсутствия входного воздействия. Кроме того, анализ покрытия строк кода может показать, что данных и управления потоком исходного кода помешало ему либо из-за ошибки в коде, либо из-за мертвого кода, который в настоящее время не нужен в определенных IP конфигурациях. Для неиспользуемого или мертвого кода вы можете исключить или фильтровать этот код при записи покрытия и шагов отчетности, что позволяет сосредоточиться только на актуальном коде.
Покрытие операторов
Покрытие операторов - это метрика покрытие кода, которую мы используем, чтобы определить, какие операторы в нашем исходном коде были выполнены во время моделирования. В целом, большинство инженеров считают, что анализ покрытие операторов является более полезным, чем покрытие строк, так как оператор часто занимает несколько строк исходного кода или несколько операторов могут находиться в одной строке исходного кода.
Отчет метрик используемый для анализа покрытия операторов будет иметь число, связанное с каждой строкой исходного кода, указывающее общее количество раз, когда оператор выполнялся. Это значение выполнения операторов не только полезно для выявления строк исходного кода, которые никогда не выполнялись, но также полезны, когда инженер считает, что требуется минимальный порог оператора исполнения для достижения достаточного тестирования.
Покрытие блоков
Покрытие блоков - это вариант метрики покрытия операторов, который определяет, является ли блок кода выполненным или нет. Блок определяется как набор операторов среди условных операторов или операторов процедурного определения, ключевой момент в том, что если блок будет покрыт, то все строки внутри блока будет выполнены. Эта метрика используется, чтобы избежать unscrupulous engineers from achieving a higher statement coverage by simply adding more statements to their code.
Покрытие переходов
Покрытие переходов (также известное как покрытие решений) представляет собой метрику покрытия кода, которая сообщает какие булевы выражения тестируемые в управляющих структурах (такие операторы как if, case, while, repeat, forever, for и loop) являются истинной и ложью. Всё булево выражение считается одним истинным либо одним ложным предикатом независимо от наличия логического и или логического или.
Покрытие выражений
Покрытие выражений (иногда относится к покрытию состояний) является метрикой покрытия, которая используется для определения может ли каждое состояние иметь значение истина и ложь. Состояние - это булевы операнд, который не содержат логических операторов. Таким образом, покрытие выражений измеряет булевы условия независимо друг от друга.
Focused Expression Coverage
Focused Expression Coverage (FEC), которое также называют Modified Condition/Decision Coverage (MC/DC)), представляет собой метрику покрытия кода часто используемую в DO-178B стандарте сертификации безопасности критического программного обеспечения, а также в DO-254 стандарте сертификации формального бортового электронного оборудования. Эта метрика сильнее, чем покрытия состояние и решения. Формальное определение MC / DC из DO-178B:
Каждая точка входа и выхода в программе была вызвана по крайней мере один раз, каждое условие в решении приняло все возможные исходы по крайней мере один раз, каждое решение в программе приняло все возможные исходы по крайней мере один раз, и каждое условие в решении было показано так, чтобы независимо влиять на исход этого решения. Состояние показывается для независимого влияния на исход решения by varying just that condition while holding fixed all other possible conditions. [3]
Стоит отметить, что полное закрывание Focused Expressing Coverage может быть сложным.
Покрытие конечного автомата
Сегодняшние инструменты покрытия кода в состоянии идентифицировать конечные автоматы в исходном коде RTL. Таким образом, это позволяет автоматически извлекать метрики FSM покрытия кода для оценки условий. Например, сколько раз каждое состояние было использовано, сколько раз FSM переходил из одного состояния в каждой из соседних состояний, и даже sequential arc coverage для определения переходов между состояниями.
Типичный поток покрытия кода
Цель сбора и анализа метрик покрытия кода является выявление частей исходного кода, которые не были выполнены в текущей среде верификации. С точки зрения проекта, как правило, лучше подождать, пока реализация RTL будет близка к завершению, прежде чем начинать собирать и анализировать результаты покрытия кода. В противном случае, вы можете потратить много попыток, чтобы правильно перемещать цель с меняющимся RTL кодом. С учетом сказанного, мы рекомендуем Вам, по крайней мере, запустить несколько симуляций, которые захватывают метрики покрытия в начале цикла проекта (то есть, до начала серьезного сбора метрик покрытия), чтобы выработать любые потенциальные проблемы в вашем потоке покрытия.
С точки зрения высокого уровня, поток покрытие кода, как правило, включает три основных этапа:
- Осуществления RTL кода для сбора покрытия
- Запуск моделирования для захвата и записи метрик покрытия
- Сообщение и анализ результатов покрытия
Часть анализа шага заключается в определении покрытия дыр, и определить, соответствует ли покрытие дыры одному из трех условий:
- Отсутствие входного воздействия, необходимого для активации непокрытого кода
- Ошибка в проекте (или в тестовой программе), которая не позволяет входному воздействию активировать непокрытой код
- Неиспользуемый код для некоторых конфигураций IP или expected unreachable code related during normal operating conditions
Первое условие требующее от Вас либо подать дополнительное входное воздействие направлен или настроить случайные ограничения для создания необходимых входных воздействий, предназначенных для непокрытого кода. Второе условие, очевидно, требует инженера исправить ошибку, которая не позволяет выполняться непокрытому коду. Третье условие можно решить, направляя инструмент покрытия, чтобы исключить неиспользуемый или недоступный код при записи покрытия и шагах сообщения. Формальные инструменты могут быть использованы для автоматизации идентификации недоступного кода, а затем автоматически генерировать файлы исключения.
Ссылки
[1] J. Miller, C. Maloney, "Systematic mistake analysis of digital computer programs." Communications of the ACM 6 (2): 58-63, February 1963.
[2] F. Fallah, S. Devadas, K. Keutzer: "OCCOM: Efficient Computation of Observability-Based Code Coverage Metrics for Functional Verification." Proceedings of the Design Automation Conference, 1998: 152-157
[3] DO-178B, "Software Considerations in Airborne Systems and Equipment Certification", RCTA, December 1992, pp.31, 74.
[4] M. Stuart, D. Dempster: Verification Methodology Manual for Code Coverage in HDL Designs - TransEDA, August 2000
