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