Сбор метрик при тестировании модели Программные продукты программно

Этот пример показов, как программно оценить статус и качество основанных на потребностях проверок операций в проекте. Когда вы разрабатываете компоненты программного обеспечения с помощью Модельно-ориентированное Проектирование, вы используете основанное на требованиях проверку, чтобы проверить свои модели. Можно оценить статус проверки одного компонента с помощью метрического 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.

См. также

generateReport | metric.Engine | Метрики тестирования модели

Документация