Войти
Общие настройки тестирования на основе модели Тестирование на основе моделей - это приложение, основанное на дизайне на основе моделей, для проектирования и, при необходимости, выполнения артефактов для выполнения тестирования программного обеспечения или тестирования системы. Модели могут использоваться для представления желаемого поведения тестируемой системы (SUT) или для представления стратегий тестирования и тестовой среды. На картинке справа изображен первый подход.
Модель, описывающая SUT, обычно является абстрактным частичным представлением желаемого поведения SUT. Тестовые примеры, полученные из такой модели, являются функциональными тестами на том же уровне абстракции, что и модель. Эти тестовые примеры в совокупности известны как абстрактный набор тестов. Набор абстрактных тестов не может быть выполнен напрямую для SUT, потому что набор находится на неправильном уровне абстракции. Исполняемый тестовый пакет должен быть получен из соответствующего абстрактного тестового набора. Исполняемый набор тестов может напрямую связываться с тестируемой системой. Это достигается путем сопоставления абстрактных тестовых примеров с конкретными тестовыми примерами, подходящими для выполнения. В некоторых средах тестирования на основе моделей модели содержат достаточно информации для непосредственного создания исполняемых наборов тестов. В других случаях элементы абстрактного набора тестов должны быть сопоставлены с конкретными операторами или вызовами методов в программном обеспечении для создания конкретного набора тестов. Это называется решением «проблемы отображения». В случае онлайн-тестирования (см. Ниже) абстрактные наборы тестов существуют только концептуально, но не как явные артефакты.
Тесты можно выводить из моделей по-разному. Поскольку тестирование обычно является экспериментальным и основано на эвристиках, не существует единого наилучшего подхода к получению тестов. Обычно все параметры, связанные с созданием тестов, объединяются в пакет, который часто называют «требованиями к тестированию», «целью тестирования» или даже «сценариями использования». Этот пакет может содержать информацию о тех частях модели, на которых следует сосредоточиться, или условиях завершения тестирования (критерии остановки теста).
Поскольку наборы тестов являются производными от моделей, а не из исходного кода, тестирование на основе моделей обычно рассматривается как одна из форм тестирования методом черного ящика.
Тестирование сложных программных систем на основе моделей все еще находится в стадии развития.
Модели строятся до или параллельно с соответствующими системами, особенно в проектировании на основе моделей или в управляемой моделями архитектуре Группы управления объектами ( OMG ). Модели также могут быть построены из готовых систем. Типичные языки моделирования для генерации тестов включают UML, SysML, основные языки программирования, нотации конечных машин и математические формализмы, такие как Z, B ( Event-B ), Alloy или Coq.
Пример рабочего процесса тестирования на основе модели (создание автономного тестового случая). IXIT относится к дополнительной информации о реализации и относится к информации, необходимой для преобразования абстрактного набора тестов в исполняемый. Обычно IXIT содержит информацию о тестовой системе, сопоставлениях данных и конфигурации SUT. Существуют различные известные способы развертывания тестирования на основе моделей, которые включают онлайн-тестирование, автономную генерацию исполняемых тестов и автономную генерацию тестов, развертываемых вручную.
Онлайн-тестирование означает, что инструмент тестирования на основе моделей напрямую подключается к SUT и тестирует его динамически.
Автономное создание исполняемых тестов означает, что инструмент тестирования на основе моделей генерирует тестовые примеры в виде машиночитаемых ресурсов, которые впоследствии могут быть запущены автоматически; например, набор классов Python, который воплощает сгенерированную логику тестирования.
Автономная генерация тестов, развертываемых вручную, означает, что инструмент тестирования на основе моделей генерирует тестовые примеры в виде удобочитаемых ресурсов, которые впоследствии могут помочь в ручном тестировании; например, документ PDF на человеческом языке, описывающий сгенерированные шаги теста.
Эффективность тестирования на основе моделей в первую очередь связана с возможностью автоматизации, которую оно предлагает. Если модель является машиночитаемой и формальной в той степени, в которой она имеет четко определенную поведенческую интерпретацию, тестовые примеры в принципе могут быть получены механически.
Часто модель переводится или интерпретируется как конечный автомат или система перехода состояний. Этот автомат представляет возможные конфигурации тестируемой системы. Чтобы найти тестовые примеры, автомат ищет исполняемые пути. Возможный путь выполнения может служить тестовым примером. Этот метод работает, если модель детерминирована или может быть преобразована в детерминированную. Ценные нестандартные тестовые примеры могут быть получены путем использования неопределенных переходов в этих моделях.
В зависимости от сложности тестируемой системы и соответствующей модели количество путей может быть очень большим из-за огромного количества возможных конфигураций системы. Чтобы найти тестовые примеры, которые могут охватывать подходящее, но конечное количество путей, необходимы критерии тестирования, которые будут определять выбор. Этот метод был впервые предложен Оффуттом и Абдуразиком в статье, в которой началось тестирование на основе моделей. Рашби разработал несколько методов генерации тестовых примеров. Критерии тестирования описаны в виде общих графиков в учебнике по тестированию.
Изначально доказательство теорем использовалось для автоматического доказательства логических формул. Для подходов к тестированию на основе моделей система моделируется набором предикатов, определяющих поведение системы. Для получения тестовых примеров модель разбивается на классы эквивалентности в соответствии с действительной интерпретацией набора предикатов, описывающих тестируемую систему. Каждый класс описывает определенное поведение системы и, следовательно, может служить тестовым примером. Простейшее разделение - это подход с дизъюнктивной нормальной формой, при котором логические выражения, описывающие поведение системы, преобразуются в дизъюнктивную нормальную форму.
Программирование с ограничениями может использоваться для выбора тестовых примеров, удовлетворяющих определенным ограничениям, путем решения набора ограничений по набору переменных. Система описывается с помощью ограничений. Решение набора ограничений может быть выполнено с помощью логических решателей (например, SAT-решателей, основанных на проблеме логической выполнимости ) или путем численного анализа, например, методом исключения Гаусса. Решение, найденное путем решения набора формул ограничений, может служить тестовым примером для соответствующей системы.
Программирование в ограничениях можно комбинировать с символьным исполнением. В этом подходе модель системы выполняется символически, т. Е. Собирает ограничения данных по различным путям управления, а затем использует метод программирования ограничений для решения ограничений и создания тестовых примеров.
Средство проверки моделей также можно использовать для генерации тестовых примеров. Первоначально проверка модели была разработана как метод проверки допустимости свойства спецификации в модели. При использовании для тестирования проверяющей модели предоставляется модель тестируемой системы и свойство для тестирования. В рамках процедуры проверки, если это свойство допустимо в модели, средство проверки модели обнаруживает свидетелей и контрпримеры. Свидетель - это путь, на котором свойство удовлетворяется, тогда как контрпример - это путь в исполнении модели, где свойство нарушается. Эти пути снова можно использовать в качестве тестовых примеров.
Цепи Маркова - эффективный способ проведения тестирования на основе моделей. Тестовые модели, реализованные с помощью цепей Маркова, можно понимать как модель использования: она называется тестированием на основе использования / статистической модели. Модели использования, то есть цепи Маркова, в основном состоят из двух артефактов: конечного автомата (FSM), который представляет все возможные сценарии использования тестируемой системы, и рабочих профилей (OP), которые квалифицируют FSM для представления того, как система работает или будет использоваться статистически. Первый (FSM) помогает узнать, что может быть или было протестировано, а второй (OP) помогает получить операционные тестовые примеры. Тестирование на основе использования / статистической модели начинается с того факта, что невозможно полностью протестировать систему и что сбой может возникать с очень низкой частотой. Этот подход предлагает прагматический способ статического получения тестовых примеров, которые направлены на повышение надежности тестируемой системы. Тестирование на основе использования / статистической модели недавно было расширено и теперь может применяться к встроенным программным системам.
