exponenta event banner

Сбор метрик по моделям тестирования артефактов программно

В этом примере показано, как программно оценивать статус и качество операций тестирования на основе требований в проекте. При разработке компонентов программного обеспечения с помощью модуля Model-Based Design для проверки моделей используется тестирование на основе требований. Можно оценить статус тестирования одного компонента с помощью метрического API для сбора метрических данных об отслеживаемости между требованиями и тестовыми случаями и о состоянии результатов тестирования. Метрики измеряют характеристики полноты и качества тестирования на основе требований, которые отражают отраслевые стандарты, такие как ISO 26262 и DO-178. После сбора результатов метрики можно получить доступ к результатам или экспортировать их в файл. Запустив сценарий, который собирает эти метрики, можно автоматически проанализировать статус тестирования проекта, например, для проектирования системы непрерывной интеграции. Результаты используются для контроля полноты тестирования или для обнаружения последствий тестирования на последующих этапах при внесении изменений в артефакты в проекте.

Открыть проект

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

dashboardCCProjectStart

Сбор результатов метрики

Создать metric.Engine для текущего проекта.

metric_engine = metric.Engine();

Чтобы указать метрики, которые требуется собрать, создайте массив со списком идентификаторов метрик. В этом примере соберите результаты для всех метрик. Некоторые метрики, возвращающие результаты для каждого отдельного артефакта, выполняются автоматически зависящими от них метриками агрегации, поэтому их не нужно включать в массив. Например, TestCasesPerRequirementDistribution автоматически запускает метрику TestCasesPerRequirementпоэтому не нужно включать вторую метрику в массив. Список метрик и их идентификаторов см. в разделе Метрики тестирования модели.

metric_IDs = {
    'RequirementWithTestCaseDistribution',... 
    'RequirementWithTestCasePercentage',... 
    'RequirementsPerTestCaseDistribution',... 
    'TestCaseStatusDistribution',... 
    'TestCaseStatusPercentage',... 
    'TestCaseTagDistribution',... 
    'TestCaseTypeDistribution',... 
    'TestCaseWithRequirementDistribution',... 
    'TestCaseWithRequirementPercentage',... 
    'TestCasesPerRequirementDistribution',... 
    'ConditionCoverageBreakdown',... 
    'DecisionCoverageBreakdown',... 
    'ExecutionCoverageBreakdown',... 
    'MCDCCoverageBreakdown'};

При сборе результатов метрики можно собирать результаты для каждого компонента проекта или для одного компонента одновременно. При сборе и просмотре результатов для компонента метрики возвращают данные для артефактов, отслеживающих модель. Для этого примера соберите метрики для db_DriverSwRequest. Создайте массив, определяющий путь к файлу модели в проекте и имя модели.

component = {fullfile(pwd,'models','db_DriverSwRequest.slx'),'db_DriverSwRequest'};

Соберите результаты для метрик, выполнив обработчик. Использовать аргумент ArtifactScope для указания компонента, для которого требуется собрать результаты. Обработчик запускает метрики только для артефактов, отслеживающих указанную модель. Для сбора результатов по этим показателям требуется лицензия Simulink ® Test™, лицензия Simulink Requirements™ и лицензия Simulink Coverage™.

execute(metric_engine, metric_IDs, 'ArtifactScope', component)

Результаты доступа

Создайте файл отчета, содержащий результаты для всех компонентов проекта. В этом примере укажите формат HTML-файла и имя отчета. MetricResultsReport.html.

execute(metric_engine, metric_IDs);
reportLocation = fullfile(pwd, 'myResultsReport.html');
generateReport(metric_engine,'Type','html-file','Location',reportLocation);
Сохранение результатов метрики в файле отчета позволяет получать результаты без открытия проекта и панели мониторинга. Можно также открыть панель мониторинга для просмотра результатов и изучения артефактов.
modelTestingDashboard

Чтобы получить программный доступ к результатам, используйте getMetrics функция. Функция возвращает значение metric.Result объекты, содержащие данные результата для указанного компонента и метрики. Для этого примера сохраните результаты для метрик TestCaseStatus и TestCasesPerRequirementDistribution в соответствующих массивах.

results_TestCasesPerReqDist = getMetrics(metric_engine,'TestCasesPerRequirementDistribution');
results_TestStatus = getMetrics(metric_engine, 'TestCaseStatus');

Просмотр распределения ссылок тестовых примеров в соответствии с требованиями

Метрика TestCasesPerRequirementDistribution возвращает распределение количества тестовых случаев, связанных с каждым функциональным требованием для модели. Просмотрите края ячейки и количество ячеек распределения, которые являются полями в Value области metric.Result объект. На левом краю каждой ячейки отображается количество звеньев тестового случая, а количество ячеек показывает количество требований, связанных с этим количеством тестовых случаев. Шестой край ячейки - 18446744073709551615, который является верхним пределом количества тестовых случаев на требование, который показывает, что пятое складское место содержит требования, которые имеют четыре или более тестовых случаев.

disp(['Component:  ', results_TestCasesPerReqDist(1).Artifacts(1).Name])
disp(['  Tests per Requirement:  ', num2str(results_TestCasesPerReqDist(1).Value.BinEdges)])
disp(['  Requirements:  ', num2str(results_TestCasesPerReqDist(1).Value.BinCounts)])
Component:  db_DriverSwRequest
  Tests per Requirement:  0   1   2   3  4  18446744073709551615
  Requirements:  12   9   0   0   0

Этот результат показывает, что для компонента db_DriverSwRequest существует 12 требований, не связанных с тестовыми случаями, и 9 требований, связанных с одним тестовым случаем. Каждое требование должно быть связано, по крайней мере, с одним испытательным случаем, который проверяет соответствие модели требованию. Распределение также позволяет проверить, имеет ли потребность гораздо больше тестовых случаев, чем другие требования, что может указывать на то, что потребность является слишком общей и что ее следует разбить на более детализированные требования.

Просмотр результатов состояния тестового случая

Метрика TestCaseStatus оценивает состояние тестирования каждого тестового случая для компонента и возвращает один из следующих числовых результатов:

  • 0 - Не удалось

  • 1 - Пройдено

  • 2 - Отключено

  • 3 - Непроверенные

Отображение имени и состояния каждого тестового случая.

for n=1:length(results_TestStatus)

   disp(['Test Case: ', results_TestStatus(n).Artifacts(1).Name])
   disp([' Status: ', num2str(results_TestStatus(n).Value)])

end
Test Case: Set button
 Status: 3
Test Case: Decrement button hold
 Status: 3
Test Case: Cancel button
 Status: 3
Test Case: Resume button
 Status: 3
Test Case: Decrement button short
 Status: 3
Test Case: Increment button short
 Status: 3
Test Case: Enable button
 Status: 3
Test Case: Increment button hold
 Status: 3

В этом примере тесты не были выполнены, поэтому каждый тестовый случай возвращает статус 3.

См. также

| |

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