Тестирование на основе моделей - Model-based testing

Общие настройки тестирования на основе модели

Тестирование на основе модели это приложение модельно-ориентированный дизайн для проектирования и, возможно, также выполнения артефактов для выполнения тестирование программного обеспечения или же системное тестирование. Модели могут быть использованы для представления желаемого поведения тестируемая система (SUT), или для представления стратегий тестирования и тестовой среды. Картинка справа изображает первый подход.

Модель, описывающая SUT, обычно является абстрактным частичным представлением желаемого поведения SUT. Тестовые примеры, производные от такой модели, представляют собой функциональные тесты на том же уровне абстракции, что и модель. Эти тестовые примеры в совокупности известны как набор абстрактных тестов Набор абстрактных тестов не может быть выполнен напрямую для SUT, потому что набор находится на неправильном уровне абстракции. исполняемый набор тестов должен быть получен из соответствующего абстрактного набора тестов. Исполняемый набор тестов может напрямую связываться с тестируемой системой. Это достигается путем сопоставления абстрактных тестовых примеров с конкретными тестовыми примерами, подходящими для выполнения. В некоторых средах тестирования на основе моделей модели содержат достаточно информации для непосредственного создания исполняемых наборов тестов, в других - элементы в набор абстрактных тестов должны быть сопоставлены с конкретными операторами или вызовами методов в программном обеспечении для создания конкретный набор тестов. Это называется решением «проблемы отображения».[1]В случае онлайн-тестирования (см. Ниже) абстрактные наборы тестов существуют только концептуально, но не как явные артефакты.

Тесты можно выводить из моделей разными способами. Поскольку тестирование обычно является экспериментальным и основано на эвристике, не существует известного единого наилучшего подхода для получения результатов тестирования. Обычно все параметры, связанные с созданием тестов, объединяются в пакет, который часто называют «требованиями тестирования», «целью тестирования» или даже прецедент (ы) ». Этот пакет может содержать информацию о тех частях модели, на которых следует сосредоточиться, или условиях завершения тестирования (критерии остановки теста).

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

Тестирование сложных программных систем на основе моделей - все еще развивающаяся область.

Модели

Особенно в Модельно-ориентированная инженерия или в группе управления объектами (мой Бог s) управляемая моделями архитектура, модели строятся до или параллельно с соответствующими системами. Модели также могут быть построены из готовых систем. Типичные языки моделирования для генерации тестов включают: UML, SysML, основные языки программирования, нотации конечных машин и математические формализмы, такие как Z, B (Событие-B ), Сплав или же Coq.

Развертывание тестирования на основе моделей

Пример рабочего процесса тестирования на основе модели (создание автономного тестового случая). IXIT относится к дополнительная информация о реализации и относится к информации, необходимой для преобразования абстрактного набора тестов в исполняемый. Обычно IXIT содержит информацию о тестовой проводке, сопоставлениях данных и конфигурации SUT.

Существуют различные известные способы развертывания тестирования на основе моделей, в том числе: онлайн-тестирование, автономная генерация исполняемых тестов, и автономная генерация тестов, развертываемых вручную.[2]

Онлайн-тестирование означает, что инструмент тестирования на основе моделей напрямую подключается к SUT и тестирует его динамически.

Автономное создание исполняемых тестов означает, что инструмент тестирования на основе моделей генерирует тестовые примеры в виде машиночитаемых ресурсов, которые впоследствии могут быть запущены автоматически; например, коллекция Python классы, которые воплощают сгенерированную логику тестирования.

Автономное создание тестов, развертываемых вручную, означает, что инструмент тестирования на основе моделей генерирует тестовые примеры в виде удобочитаемых ресурсов, которые впоследствии могут помочь в ручном тестировании; например, PDF-документ на человеческом языке, описывающий сгенерированные шаги теста.

Алгоритмическое получение тестов

Эффективность тестирования на основе моделей в первую очередь связана с возможностью автоматизации, которую оно предлагает. Если модель является машиночитаемой и формальной в той степени, в которой она имеет четко определенную поведенческую интерпретацию, тестовые примеры в принципе могут быть получены механически.

Из конечных автоматов

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

В зависимости от сложности тестируемой системы и соответствующей модели количество путей может быть очень большим из-за огромного количества возможных конфигураций системы. Чтобы найти тестовые примеры, которые могут охватывать подходящее, но конечное количество путей, необходимы критерии тестирования, которые будут определять выбор. Этот метод был впервые предложен Оффуттом и Абдуразиком в статье, в которой началось тестирование на основе моделей.[3] Рашби разработал множество методов для генерации тестовых примеров.[4] Критерии тестирования описаны в виде общих графиков в учебнике по тестированию.[1]

Доказательство теорем

Доказательство теорем первоначально использовался для автоматического доказательства логических формул. Для подходов к тестированию на основе моделей система моделируется набором предикаты, определяя поведение системы.[5] Чтобы получить тестовые примеры, модель разбивается на классы эквивалентности над правильной интерпретацией набора предикатов, описывающих тестируемую систему. Каждый класс описывает определенное поведение системы и, следовательно, может служить тестовым примером. Простейшее разбиение осуществляется с помощью подхода дизъюнктивной нормальной формы, в котором логические выражения, описывающие поведение системы, преобразуются в дизъюнктивная нормальная форма.

Программирование логических ограничений и символьное выполнение

Ограниченное программирование может использоваться для выбора тестовых примеров, удовлетворяющих определенным ограничениям, путем решения набора ограничений по набору переменных. Система описывается с помощью ограничений.[6] Решение набора ограничений может быть выполнено с помощью логических решателей (например, SAT-решателей на основе Проблема логической выполнимости ) или числовой анализ, словно Гауссово исключение. Решение, найденное путем решения набора формул ограничений, может служить тестовым примером для соответствующей системы.

Программирование в ограничениях можно комбинировать с символьным исполнением. В этом подходе модель системы выполняется символически, то есть собирает ограничения данных по различным путям управления, а затем использует метод программирования ограничений для решения ограничений и создания тестовых примеров.[7]

Проверка модели

Модельные шашки также может использоваться для генерации тестовых примеров.[8] Первоначально проверка модели была разработана как метод проверки допустимости свойства спецификации в модели. При использовании для тестирования проверяющей модели предоставляется модель тестируемой системы и свойство для тестирования. В рамках процедуры проверки, если это свойство действительно в модели, средство проверки модели обнаруживает свидетелей и контрпримеры. Свидетель - это путь, на котором свойство удовлетворяется, тогда как контрпример - это путь в исполнении модели, где свойство нарушается. Эти пути снова можно использовать в качестве тестовых примеров.

Генерация тестового примера с использованием тестовой модели цепи Маркова

Цепи Маркова являются эффективным способом проведения модельно-ориентированного тестирования. Тестовые модели, реализованные с помощью цепей Маркова, можно понимать как модель использования: она называется тестированием на основе использования / статистической модели. Модели использования, то есть цепи Маркова, в основном состоят из двух артефактов: Конечный автомат (FSM), который представляет все возможные сценарии использования тестируемой системы, и рабочие профили (OP), которые квалифицируют FSM для представления того, как система используется или будет использоваться статистически. Первый (FSM) помогает узнать, что может быть или уже было протестировано, а второй (OP) помогает получить операционные тестовые примеры. Тестирование на основе использования / статистической модели начинается с фактов, которые невозможно полностью протестировать и которые отказ может появиться с очень низкой частотой.[9] Этот подход предлагает прагматический способ статического получения тестовых примеров, которые направлены на повышение надежности тестируемой системы. Тестирование на основе использования / статистической модели недавно было расширено для применения во встроенных программных системах.[10][11]

Смотрите также

Рекомендации

  1. ^ а б Пол Амманн и Джефф Оффатт. Введение в тестирование программного обеспечения. Издательство Кембриджского университета, 2008.
  2. ^ Практическое тестирование на основе моделей: инструментальный подход В архиве 2012-08-25 в Wayback Machine, Марк Аттинг и Бруно Легерд, ISBN  978-0-12-372501-1, Морган-Кауфманн 2007
  3. ^ Джефф Оффутт и Айнур Абдуразик. Создание тестов на основе спецификаций UML. Вторая международная конференция по унифицированному языку моделирования (UML ’99), страницы 416-429, Форт-Коллинз, Колорадо, октябрь 1999 г.
  4. ^ Джон Рашби. Автоматизированное создание тестов и проверенное программное обеспечение. Проверенное программное обеспечение: теории, инструменты, эксперименты: первая конференция IFIP TC 2 / WG 2.3, VSTTE 2005, Цюрих, Швейцария, 10–13 октября. стр. 161-172, Springer-Verlag
  5. ^ Brucker, Achim D .; Вольф, Буркхарт (2012). «О проверке, основанной на программе доказательства теорем». Формальные аспекты вычислений. 25 (5): 683–721. CiteSeerX  10.1.1.208.3135. Дои:10.1007 / s00165-012-0222-y.
  6. ^ Джефферсон Оффатт. Автоматическая генерация тестовых данных на основе ограничений. IEEE Transactions по разработке программного обеспечения, 17: 900-910, 1991
  7. ^ Антти Хуима. Внедрение Conformiq Qtronic. Тестирование программного обеспечения и коммуникационных систем, Конспект лекций по информатике, 2007 г., том 4581/2007, 1-12, DOI: 10.1007 / 978-3-540-73066-8_1
  8. ^ Гордон Фрейзер, Франц Вотава и Пол Э. Амманн. Тестирование с помощью модельных шашек: опрос. Тестирование, проверка и надежность программного обеспечения, 19 (3): 215–261, 2009. URL: [1]
  9. ^ Элен Ле Гуен. Validation d'un logiciel par le test statistique d'usage: de la modelisation de la solution à la livraison, 2005. URL:ftp://ftp.irisa.fr/techreports/theses/2005/leguen.pdf
  10. ^ Бёр, Франк (2011). «Статистическое тестирование встроенных систем на основе моделей». 2011 Четвертая международная конференция IEEE по тестированию, верификации и валидации программного обеспечения, семинары. С. 18–25. Дои:10.1109 / ICSTW.2011.11. ISBN  978-1-4577-0019-4.
  11. ^ https://www.amazon.de/Model-Based-Statistical-Continuous-Concurrent-Environment/dp/3843903484/ref=sr_1_1?ie=UTF8&qid=1334231267&sr=8-1

дальнейшее чтение