Подготовьте настройку средств проверки к анализу Polyspace Bug Finder

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

Вообще говоря аналитическая настройка Средства поиска Ошибки состоит из двух частей:

  • Конфигурация сборки включая источники и цель

  • Настройка средств проверки

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

Идентифицируйте средства проверки, чтобы включить

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

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

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

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

    • MISRA C®: 2004

    • MISRA C: 2012

    • MISRA® C ++

    • JSF AV C++

    • AUTOSAR C++ 14 (Только Средство поиска ошибки)

    • CERT® C (Только Средство поиска ошибки)

    • CERT C++ (Только Средство поиска ошибки)

    • ISO®/IEC TS 17961 (Только Средство поиска ошибки)

    Смотрите проверку на кодирование стандартных нарушений.

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

    Смотрите, можно ли автоматизировать проверку тех правил через средства проверки дефекта Средства поиска Ошибки и/или внешние кодирующие стандартные средства проверки.

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

    1. Ищите ключевые слова, такие как variadic или va_arg и совершенствуйте результаты поиска продуктом к Средству поиска Ошибки и затем по категориям к Review Analysis Results> Polyspace Bug Finder Results.

    2. Идентифицируйте все средства проверки, связанные с функциями variadic. Запишите средства проверки, которые вы хотите включить. Смотрите, существует ли перекрытие между средствами проверки, и устраните копии.

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

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

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

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

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

      См. также Классификацию Дефектов Ударом (Polyspace Bug Finder Access).

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

    См. также Выбирают Specific Bug Finder Defect Checkers.

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

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

Создайте конфигурационные файлы средств проверки

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

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

Или как это:

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

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

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

    Предположим, что вы сохраняете все опции, связанные с вашей сборкой в файле buildOptions.txt. Можно создать этот файл вручную или автоматически от команды сборки (make-файл).

    Для получения дополнительной информации о том, как создать этот файл, смотрите, Готовят Скрипты к Анализу Polyspace.

  • Дефектная настройка средств проверки.

    Предположим, что вы задаете дефектные средства проверки в файле 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 и C++ AUTOSAR 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 в скриптах. Например:

  • В сборке Дженкинса можно задать команду выполнения в скрипте сборки, наряду с другими инструментами, которые вы запускаете. После представления кода анализ Polyspace может работать на недавно представленном коде через сборку scipts.

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

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

Похожие темы