В этом примере показано, как собрать тестовое покрытие для модели, которая реализует требования. Покрытие относится к определению полноты проверки путем анализа того, какая часть логики модели выполняется. Для проверки, основанного на требованиях, результаты покрытия могут быть сопоставлены со связанными требованиями. С помощью этого анализа вы можете оценить, покрывается ли каждый элемент модели предполагаемым тестом.
Пример показывает, как анализ результатов покрытия связанных требований может выявить как неадекватное связывание требований, так и пробелы в тестировании. Также показано, как увеличить покрытие.
Модель в этом примере cruiseControlRBTCovExample, представляющий систему круиз-контроля. Эта модель реализует и связана с требованиями. Для этого примера уже создан тестовый файл.
cruiseControlRBTCovExample
Требования к этой системе круиз-контроля были отражены в Simulink Requirements Editor. Чтобы просмотреть требования, используйте slreq.open('cruiseControlRBTCovReqs.slreqx').
Использование sltestmgr чтобы открыть диспетчер тестов.
Нажмите Open и выберите cruiseControlRBTCovTests.mldatx. Тесты были написаны, чтобы убедиться, что поведение модели соответствует заданным требованиям. Они также были настроены для записи покрытия «Решение» и «Условие». Разверните раздел «Параметры покрытия», чтобы просмотреть выбранные метрики.
Каждый тест проверяет и связан с требованием. Для примера, тест дросселя проверяет требование THROTTLE. Это требование задает, что дроссель прикладывается плавно, если скорость отличается от целевой. Тест проверяет это поведение с помощью логической оценки, которая проверяет, что скорость изменения дросселя составляет от -1 до 1 радиана в секунду, как определено в описании требования.
Запустите тест.
Щелкните Результаты на панели Результаты и программные продукты, когда тест закончит работу. Обратите внимание, что тесты проходят и что сообщается о 100% агрегированном покрытии.
На панели Агрегированные результаты покрытия щелкните Scope coverage results to linked requirements флажок. Оценка результатов означает, что каждый тест вносит вклад только в покрытие для соответствующих элементов модели, которые реализуют требование, проверенное этим тестом. Область видимости проверяет, что элементы модели охвачены предполагаемыми тестами. Результаты покрытия, которые обновляются автоматически, теперь показывают совокупное покрытие для принятия решения и выполнения на уровне 92% и 76%, соответственно.
Щелкните имя модели в столбце Анализированная модель (Analysed Model), чтобы выделить результаты покрытия в модели и отобразить детали отчета о покрытии.
В модели, если таблица Требования (Requirements) не показана ниже модели, откройте ее, щелкнув представления Перспективы (Perspectives) в правом нижнем углу полотна модели, а затем, нажав Требования (Requirements).
Откройте подсистему контроллер. Блоки, не имеющие 100% -ного покрытия, отображаются красным цветом. Два набора блоков Constant и Sum не связаны с требованиями и никогда не выполнялись.
В этом случае недостающее покрытие указывает на недостаточную связь с требованиями. Эти блоки Constant и Sum необходимы для реализации требований INCREMENT и DECLEMENT и должны быть связаны с соответствующими требованиями.
В таблице на панели Requirements разверните cruiseControlRbtCovReqs. Щелкните правой кнопкой мыши по верхнему блоку Constant и выберите Requirements > Link to Selection в Диспетчере требований. Затем щелкните по требованию ШАГ в таблице Requirements. Повторите это для верхнего блока Sum.
Для нижних блоков Constant и Sum повторите шаги связывания, но соедините с требованием DECREMENT.
Откройте ПИ-контроллер и нажмите на блок Discrete-Time Integrator. Сведения о покрытии показывают, что true решение для верхнего предела было выполнено инкрементным тестом (T4), а не дроссельным тестом (T6). Поскольку блок является частью реализации требования THROTTLE, он должен был быть протестирован испытанием Throttle Test, которое проверяет требование THROTTLE. Инкрементный тест не проверяет это требование и не вносит покрытия для этого блока, когда Scope model coverage to linked requirements параметр включен.
Чтобы разрешить недостающее покрытие для этого блока, Тест Дросселя должен быть обновлен, чтобы использовать блок Интегратор Дискретного Времени больше.
На панели Test Browser Диспетчера тестов выберите Throttle Test.В разделе Inputs выберите td_throttle_updated.mat как файл внешних входов. Этот обновленный входной файл данных о дросселе имеет несколько дополнительных секунд тестовых данных, которые увеличивают целевую скорость более агрессивно при сохранении фактической скорости.
Выберите cruiseControlRBTCovTests на панели Test Browser и повторите тест. Нажмите на Scope coverage results to linked requirements флажок. Результаты покрытия показывают 100% охват, что указывает на то, что тесты адекватно выполняют модель.
Пересмотренный тест дросселя теперь не проходит верификацию. Отказ происходит из-за того, что дроссель увеличивается слишком агрессивно и находится вне необходимых контуров, заданных в тесте. Это указывает на проблему с проектом модели. Реализация блока ПИ-контроллер должна быть обновлена, чтобы применить дроссель в требуемых пределах, в том числе, когда целевая и фактическая скорости значительно различаются.
Сводные данные, анализ результатов покрытия связанных требований может помочь выявить пробелы в проверке. Scoping достигает этого путем оценки того, что каждый элемент модели выполняется тестом, который проверяет соответствующее требование.
