Coverage Cookbook/Coverage Metrics and process (Theory)/Code Coverage Metrics/ru
|
Эта статья требует перевода на русский язык |
- Метрики и процессы покрытия (en)
- Метрики покрытия кода (en)
- Метрики функционального покрытия (en)
- Specification to testplan (en)
- Testplan to functional coverage (en)
- Coverage Examples (Practice) (en)
- Requirements Writing Guidelines (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 для определения переходов между состояниями.
Typical Code Coverage Flow
The objective of gathering and analyzing code coverage metrics is to identify portions of the source code that have not been exercised by the current verification environment. From a project perspective, it is generally best to wait until the implementation of the RTL is close to complete before seriously starting to gather and analyze code coverage results. Otherwise, you can waste a lot of cycles trying to make sense of a moving target from the changing RTL code. With that said, we recommend that you at least run a few simulations that capture coverage metrics early in the project cycle (that is, prior to seriously gathering coverage metrics) to work out any potential issues in your coverage flow.
From a high-level perspective, there are generally three main steps involved in a code coverage flow, which include:
- Instrument the RTL code to gather coverage
- Run simulation to capture and record coverage metrics
- Report and analyze the coverage results
Part of the analysis step is to identify coverage holes, and determine if the coverage hole is due to one of three conditions:
- Missing input stimulus required to activate the uncovered code
- A bug in the design (or testbench) that is preventing the input stimulus from activating the uncovered code
- Unused code for certain IP configuations or expected unreachable code related during normal operating conditions
The first condition requires you to either write additional directed stimulus or adjust random constraints to generate the required input stimulus that targets the uncovered code. The second condition obviously requires the engineer to fix the bug that is preventing the uncovered code from being exercised. The third condition can be addressed by directing the coverage tool to exclude the unused or unreachable code during the coverage recording and reporting steps. Formal tools can be used to automate the identification of unreachable code, and then automatically generate the exclusion files.
Ссылки
[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
