В этом примере показано, как использовать модель спецификации, чтобы выполнить основанное на требованиях тестирование. В этом примере вы следуете за систематическим подходом, чтобы проверить вашу модель проекта по требованиям. Для подробного описания модели спецификации смотрите то, Что Модель Спецификации?.
Этот пример использует контроллер автопилота крена, RollAutopilotMdlRef который является моделью проекта, которая управляет креном самолета. Контроллер автопилота крена действует в двух высокоуровневых режимах:
1. Крен содержит режим: Этот режим или обеспечивает текущий крен самолета или изменяет его согласно заданному пользователями углу.
2. Заголовок содержит режим: Этот режим или обеспечивает текущий заголовок или прокручивает самолет, чтобы достигнуть заданного пользователями направляющегося значения. Для получения дальнейшей информации на Контроллере Автопилота Крена система, смотрите Основанное на требованиях Тестирование на Разработку моделей (Simulink Test).
Для контроллера автопилота требования описывают системные интерфейсы, высокоуровневые системные режимы и ожидаемое поведение контроллера. Эти требования созданы в Редакторе Требований и сохраненные в AP_Controller.slreqx файл. Для получения дополнительной информации о Редакторе Требований смотрите работу с Требованиями в Редакторе Simulink (Simulink Requirements). Чтобы просмотреть требования, откройте Редактор Требований путем ввода:
slreq.open('AP_Controller');
Редактор Требований отображает требования высокого уровня для режимов Roll Hold и Heading Hold. Когда вы нажимаете на каждое требование, вкладка перечисляет детали для требования.
Когда вы создаете модель спецификации, необходимо рассмотреть несколько факторов, таких как тип требований, выбор блоков модели и уровень abstraction.Follow инструкции описанный в Создании Модели Спецификации.
Откройте sldvexSpecPartial модель спецификации, которая покрывает набор требований автопилота:
spec_model = 'sldvexSpecPartial';
open_system(spec_model);
sldvexSpecPartial модель состоит из интерфейсов ввода и вывода. Таблица истинности получает требования.
Открыть таблицу истинности, введите:
open_system('sldvexSpecPartial/AP Controller Requirements');
Выполните эти шаги, чтобы соединить требования с моделью спецификации.
1. Щелкните правой кнопкой по таблице истинности под названием AP Controller Requirements в модели спецификации. В контекстном меню нажмите Requirements> Select для соединения с Simulink.
2. Откройте требования в Редакторе Требований. Щелкните правой кнопкой по требованию, которое вы хотите соединить с таблицей истинности и нажать Link from AP Controller Requirements (Truth Table). Если вы имеете несколько таблиц истинности, каждый задающий группу требований, соединяете их также.
Используйте sldvoptions сгенерировать тесты для модели спецификации. Каждое требование было сопоставлено с отдельной целью генерации тестов использование sldv.test().
opts = sldvoptions; opts.Mode = 'TestGeneration'; opts.ModelCoverageObjectives = 'None'; [~, files] = sldvrun(spec_model,opts,true);
После того, как анализ завершается, отображения окна Results Summary, которым шесть из шести из целей удовлетворяют.
Модель спецификации контроллера автопилота и модель проекта имеют различные интерфейсы, что означает, что тесты, сгенерированные на шаге 4, не поддерживаются для выполнения симуляции на модели проекта.
Например, Крен Самолета имеет тип области значений перечисления в спецификации, но имеет двойной тип в модели проекта.
Во время тестового процесса преобразования, если значение сигналов, такое как RA_Horizontal, является областью значений, можно выбрать любое значение, которое падает в той области значений. Может использоваться различная эвристика, такая как средняя точка (где можно выбрать среднюю точку области значений), граничное значение (где можно выбрать нижнюю или верхнюю границу области значений), или даже случайная стратегия (где вы выбираете случайное значение в области значений). Для контроллера автопилота, подсистема sldvexDesignHarness/Test Conversion реализует стратегию средней точки в модели тестовой обвязки как показано ниже:
design_model = 'sldvexDesignHarness'; load_system(design_model); open_system('sldvexDesignHarness/Test Conversion');
Модель проекта разрабатывается независимо при помощи документа требований. Чтобы проверить проект, создайте модель тестовой обвязки, которая содержит эти четыре подсистемы:
(i) Модель спецификации.
(ii) Модель проекта.
(iii) Тестовая подсистема преобразования описана на шаге 5.
(iv) Блок верификации во время выполнения. Это проверки блока, является ли значение сигналов проекта в диапазоне, указанном моделью спецификации.
Запустите тесты от шага 5 на модели проекта при помощи sldvruntest и сгенерируйте отчет покрытия модели.
cvopts = sldvruntestopts;
cvopts.coverageEnabled = true;
[~, initCov] = sldvruntest(design_model,files.DataFile,cvopts);
cvhtml('InitialCov',initCov);
Результаты анализа сообщают, что полный охват не достигается для roll_ap_mod, и покрытие подсистемы достигается для модели проекта.
Добавьте требование в sldvexSpecFull модель спецификации для анализа.
spec_model = 'sldvexSpecFull';
open_system(spec_model);
Используйте sldvoptions сгенерировать тесты.
opts = sldvoptions; opts.Mode = 'TestGeneration'; opts.ModelCoverageObjectives = 'None'; [~, files] = sldvrun(spec_model,opts,true);
Откройте sldvexDesignHarness модель, которая содержит модель проекта, модель спецификации и тестовую подсистему преобразования.
design_model = 'sldvexDesignHarness';
open_system(design_model);
Симулируйте тесты при помощи sldvruntest и сгенерируйте отчет покрытия модели.
cvopts = sldvruntestopts;
cvopts.coverageEnabled = true;
[~, FinalCov] = sldvruntest(design_model,files.DataFile,cvopts);
cvhtml('FinalCov', FinalCov);
Отчет покрытия показывает, что полный охват достигается модели проекта.
bdclose('all');
slreq.clear;