exponenta event banner

Подготовка конфигурации шашек для анализа обнаружения ошибок Polyspace

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

В широком смысле, конфигурация анализа Bug Finder состоит из двух частей:

  • Конфигурация построения, включая источники и конечный объект

  • Конфигурация шашек

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

Определить шашки для включения

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

  • Придерживайтесь внешнего стандарта кодирования.

    Если Bug Finder поддерживает стандарт кодирования, можно выбрать стандарт и предопределенный или пользовательский набор правил из стандарта.

    Polyspace поддерживает эти внешние стандарты напрямую. Для этих стандартов просто включите стандарт в конфигурации и запустите анализ.

    • MISRA C ®: 2004

    • MISRA C:2012

    • MISRA ® C++

    • JSF AV C++

    • AUTOSAR C++ 14 (только для поиска ошибок)

    • CERT ® C (только для поиска ошибок)

    • CERT C++ (только для поиска ошибок)

    • ISO ®/IEC TS 17961 (только для поиска ошибок)

    • Рекомендации (только для поиска ошибок)

    См. раздел Проверка нарушений стандартов кодирования.

  • Разработка набора внутренних правил кодирования на основе внешних стандартов и выявленных ранее проблем.

    Узнайте, можно ли автоматизировать проверку этих правил с помощью проверки дефектов Bug Finder и/или стандартной проверки внешнего кодирования.

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

    1. Поиск таких ключевых слов, как variadic или va_arg и уточните результаты поиска по продукту до Bug Finder, а затем по категории до Review Analysis Results > Polyspace Bug Finder Results.

    2. Определите все шашки, связанные с различными функциями. Запишите шашки, которые вы хотите включить. Проверьте, есть ли перекрытие между шашками и устраните дубликаты.

    Можно записывать каждую включенную или отключенную проверку дефектов в соответствии с требованиями процесса. Вы можете начать с электронной таблицы шашки в polyspaceroot\polyspace\resources\. В столбце Ваши заметки обратите внимание на обоснование включения или отключения проверки.

  • Проверьте только дефекты (ошибки), которые могут привести к ошибкам во время выполнения.

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

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

    • Сначала выберите дефектные шашки с высоким ударом. Эти шашки могут найти проблемы, которые могут иметь серьезные последствия.

      См. также Классификация дефектов по воздействию.

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

    См. также раздел Выбор средств проверки дефектов для поиска ошибок.

    Можно следовать аналогичной стратегии с помощью шашек для внешних стандартов кодирования. Например, для C:2012 MISRA можно начать с обязательных или обязательных инструкций, а затем выбрать расширение позже.

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

Создание файлов конфигурации Checkers

Конфигурация анализа Finder™ ошибки Polyspace представляет собой список параметров анализа, заданных с помощью флагов командной строки. Можно сохранить всю конфигурацию в одном файле опций, например текстовом файле с именем allOptions.txtи укажите файл с помощью -options-file вот так:

polyspace-bug-finder -options-file allOptions.txt

Или вот так:

polyspace-bug-finder-server -options-file allOptions.txt

Для удобства можно разделить конфигурацию на три части:

  • Конфигурация построения (источники, цели и т. д.).

    Предположим, что все параметры, связанные с построением, сохранены в файле buildOptions.txt. Этот файл можно создать вручную или автоматически с помощью команды build (makefile).

    Дополнительные сведения о создании этого файла см. в разделе Определение целевой среды и поведения компилятора.

  • Конфигурация дефектных шашек.

    Предположим, что в файле указаны проверки дефектов defectCheckers.txt.

  • Стандартная конфигурация внешнего кодирования.

    Предположим, что в файле указан стандарт кодирования и связанные с ним шашки externalRuleCheckers.txt.

Можно объединить файлы в одну команду запуска следующим образом:

polyspace-bug-finder -options-file buildOptions.txt -options-file defectCheckers.txt -options-file externalRuleCheckers.txt

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

Затем необходимо создать текстовые файлы, определяющие шашки, которые необходимо включить:

  • Файл defectCheckers.txt содержит -checkers за которым следует разделенный запятыми список чекеров дефектов, которые необходимо включить. Например:

    -checkers INT_ZERO_DIV, FLOAT_ZERO_DIV, INT_CONV_OVFL, UINT_CONV_OVFL, SIGN_CHANGE, ...

    См. также:

  • Файл externalRuleCheckers.txt содержит стандарты кодирования, которые требуется включить, а затем ссылается на отдельный XML-файл для определенных правил из стандартов.

    Например, текстовый файл, разрешающий определенные правила из стандарта MISRA C:2012 и AUTOSAR C++ 14, содержит следующие опции:

    -misra3 from-file
    -autosar-cpp14 from-file 
    -checkers-selection-file externalRuleCheckers.xml
    

    XML-файл externalRuleCheckers.xml которая включает или отключает шашки для правил из конкретных стандартов имеет следующую структуру:

    <polyspace_checkers_selection>
      <standard name="MISRA C:2004" state="off"/>
      <standard name="MISRA AC AGC" state="off"/>
      <standard name="MISRA C:2012" state="off"/>
      <standard name="MISRA C++:2008" state="off"/>
      <standard name="JSF AV C++" state="off"/>
      <standard name="SEI CERT C" state="off"/>
      <standard name="SEI CERT C++" state="off"/>
      <standard name="ISO/IEC TS 17961" state="off"/>
      <standard name="AUTOSAR C++14">
        <section name="0 Language independent issues">
          <check id="M0-1-1" state="on"/>
          <check id="M0-1-2" state="on"/>
          <check id="M0-1-3" state="off"/>
          <check id="M0-1-4" state="on">
            <comment>Not implemented</comment>
          </check>
          <check id="A0-1-1" state="on">
            <comment>Not implemented</comment>
          </check>
          <check id="A0-1-2" state="on"/>
          <check id="M0-1-8" state="on">
            <comment>Not implemented</comment>
          </check>
    		.
    		.
    	     </section>
    	  </standard>
    </polyspace_checkers_selection>
    

    Дополнительные сведения о создании XML-файла см. в разделе Проверка нарушений стандартов кодирования.

Можно создать эти файлы и использовать окончательную команду запуска Polyspace в сценариях. Например:

  • При построении Дженкинса можно указать команду run в сценарии построения вместе с другими выполняемыми инструментами. После отправки кода анализ Polyspace может выполняться на только что представленном коде с помощью скриптов построения.

  • В IDE разработчика команду run можно указать с помощью пункта меню, в котором выполняются внешние инструменты. Разработчики могут выполнять анализ Polyspace во время кодирования с помощью внешних инструментов.

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

Связанные темы