Тестирование на основе моделей — это применение проектирования на основе моделей для проектирования и, при необходимости, выполнения артефактов для тестирования программного обеспечения или системы . Модели можно использовать для представления желаемого поведения тестируемой системы (SUT) или для представления стратегий тестирования и тестовой среды. На рисунке справа изображен первый подход.
Модель, описывающая ТРИ, обычно представляет собой абстрактное, частичное представление желаемого поведения ТРИ. Тестовые примеры, полученные на основе такой модели, представляют собой функциональные тесты на том же уровне абстракции, что и модель. Эти тестовые примеры называются абстрактным набором тестов . Набор абстрактных тестов не может быть напрямую выполнен для SUT, поскольку этот набор находится на неправильном уровне абстракции. Исполняемый набор тестов должен быть получен из соответствующего абстрактного набора тестов. Исполняемый набор тестов может напрямую взаимодействовать с тестируемой системой. Это достигается путем сопоставления абстрактных тестовых примеров с конкретными тестовыми примерами, подходящими для выполнения. В некоторых средах тестирования на основе моделей модели содержат достаточно информации для непосредственного создания исполняемых наборов тестов. В других случаях элементы абстрактного набора тестов должны быть сопоставлены с конкретными операторами или вызовами методов в программном обеспечении для создания конкретного набора тестов. Это называется решением «проблемы отображения». [1] В случае онлайн-тестирования (см. ниже) абстрактные наборы тестов существуют только концептуально, а не как явные артефакты.
Тесты могут быть получены из моделей разными способами. Поскольку тестирование обычно является экспериментальным и основано на эвристике, не существует единственного наилучшего подхода к построению тестов. Обычно все параметры, связанные с созданием теста, объединяются в пакет, который часто называют «требованиями к тесту», «целью тестирования» или даже «вариантами использования». Этот пакет может содержать информацию о тех частях модели, на которых следует сосредоточить внимание, или об условиях завершения тестирования (критерии остановки тестирования).
Поскольку наборы тестов создаются на основе моделей, а не исходного кода, тестирование на основе моделей обычно рассматривается как одна из форм тестирования «черного ящика» .
Тестирование на основе моделей для сложных программных систем все еще является развивающейся областью.
Особенно в модели-ориентированном проектировании или в модели-управляемой архитектуре Object Management Group ( OMG ) модели создаются до или параллельно с соответствующими системами. Модели также могут быть построены на основе готовых систем. Типичные языки моделирования для генерации тестов включают UML , SysML , основные языки программирования, нотации конечных машин и математические формализмы, такие как Z , B ( Event-B ), Alloy или Coq .
Существуют различные известные способы развертывания тестирования на основе моделей, которые включают онлайн-тестирование , автономную генерацию исполняемых тестов и автономную генерацию тестов, развертываемых вручную . [2]
Онлайн-тестирование означает, что инструмент тестирования на основе моделей подключается непосредственно к тестируемому устройству и тестирует его динамически.
Автономная генерация исполняемых тестов означает, что инструмент тестирования на основе моделей генерирует тестовые примеры в виде компьютерочитаемых ресурсов, которые впоследствии можно запускать автоматически; например, коллекция классов Python , воплощающая сгенерированную логику тестирования.
Автономное создание тестов, развертываемых вручную, означает, что инструмент тестирования на основе моделей создает тестовые примеры как удобочитаемые ресурсы, которые впоследствии могут помочь в ручном тестировании; например, PDF-документ на человеческом языке, описывающий сгенерированные этапы тестирования.
Эффективность тестирования на основе моделей обусловлена прежде всего возможностями автоматизации, которые оно предлагает. Если модель машиночитаема и формальна в той степени, в которой она имеет четко определенную поведенческую интерпретацию, тестовые примеры в принципе могут быть получены механически.
Часто модель переводится или интерпретируется как конечный автомат или система перехода состояний . Этот автомат представляет возможные конфигурации тестируемой системы. Чтобы найти тестовые примеры, автомат ищет пути к исполняемым файлам. Возможный путь выполнения может служить тестовым примером. Этот метод работает, если модель детерминированная или может быть преобразована в детерминированную. Ценные неноминальные тестовые примеры могут быть получены путем использования неуказанных переходов в этих моделях.
В зависимости от сложности тестируемой системы и соответствующей модели количество путей может быть очень большим из-за огромного количества возможных конфигураций системы. Чтобы найти тестовые примеры, которые могут охватывать подходящее, но конечное число путей, необходимы критерии тестирования, которые будут определять выбор. Этот метод был впервые предложен Оффуттом и Абдуразиком в статье, положившей начало тестированию на основе моделей. [3] Было разработано множество методов создания тестовых примеров, которые исследуются Рашби. [4] Критерии тестирования описаны в виде общих графиков в учебнике по тестированию. [1]
Доказательство теорем изначально использовалось для автоматического доказательства логических формул. При подходах к тестированию на основе моделей система моделируется набором предикатов , определяющих поведение системы. [5] Для получения тестовых примеров модель разбивается на классы эквивалентности по допустимой интерпретации набора предикатов, описывающих тестируемую систему. Каждый класс описывает определенное поведение системы и, следовательно, может служить тестовым примером. Простейшим разделением является подход дизъюнктивной нормальной формы, при котором логические выражения, описывающие поведение системы, преобразуются в дизъюнктивную нормальную форму .
Программирование с ограничениями можно использовать для выбора тестовых примеров, удовлетворяющих определенным ограничениям, путем решения набора ограничений для набора переменных. Система описывается посредством ограничений. [6] Решение набора ограничений может быть выполнено с помощью логических решателей (например, SAT-решателей, основанных на булевой проблеме выполнимости ) или с помощью численного анализа , такого как исключение Гаусса . Решение, найденное путем решения набора формул ограничений, может служить тестовым примером для соответствующей системы.
Программирование с ограничениями можно комбинировать с символьным выполнением. В этом подходе модель системы выполняется символически, т.е. сбор данных об ограничениях по различным путям управления, а затем использование метода программирования ограничений для решения ограничений и создания тестовых примеров. [7]
Средства проверки моделей также можно использовать для создания тестовых примеров. [8] Первоначально проверка модели была разработана как метод проверки допустимости свойства спецификации в модели. При использовании для тестирования в средство проверки модели передаются модель тестируемой системы и тестируемое свойство. В рамках процедуры доказательства, если это свойство действительно в модели, программа проверки модели обнаруживает свидетелей и контрпримеры. Свидетель — это путь, где свойство удовлетворяется, тогда как контрпример — это путь выполнения модели, где свойство нарушается. Эти пути снова можно использовать в качестве тестовых примеров.
Цепи Маркова — эффективный способ проведения тестирования на основе моделей. Тестовые модели, реализованные с помощью цепей Маркова, можно понимать как модель использования: она называется тестированием на основе использования/статистической модели. Модели использования, то есть цепи Маркова, в основном состоят из двух артефактов: конечного автомата (FSM), который представляет все возможные сценарии использования тестируемой системы, и операционных профилей (OP), которые позволяют FSM представлять, как система работает или будет работать. использоваться статистически. Первый (FSM) помогает узнать, что может быть или было протестировано, а второй (OP) помогает получить оперативные тестовые примеры. Тестирование на основе использования/статистической модели начинается с фактов, что невозможно полностью протестировать систему и что сбои могут возникать с очень низкой частотой. [9] Этот подход предлагает прагматичный способ статического построения тестовых примеров, направленных на повышение надежности тестируемой системы. Тестирование на основе статистических моделей использования было недавно расширено и теперь применимо ко встраиваемым программным системам. [10] [11]