Модели тестирования СПС

К моделям тестирования относятся UML-профиль и lU-модель тестирования^[1].

-профиль тестирования

В основу построения модели тестирования СПС может быть положен UML-профиль тестирования (UML-ПТ), предложенный компанией OMG, который определяет язык для проектирования, визуализации, спецификации, анализа, конструирования и документирования артефактов тестовых систем. Профиль позволяет строить и повторно использовать проектные документы тестирования из самых ранних стадий ЖЦ системы и поддерживает основанное на UML тестирование, управляемое моделью (UML based model-driven testing).

Концепты UML-IIT структурированы по четырем группам:

• 1) архитектура теста — определяет понятия, касающиеся структуры и конфигурации теста;
• 2) поведение теста — определяет понятия, связанные с динамическими аспектами тестовых процедур;
• 3) данные теста — определяет понятия, касающиеся тестовых данных в процедурах тестирования (тестовых процедурах);
• 4) время тестирования — определяет квантификацию времени при выполнении тестовых процедур.

Архитектура теста (test architecture). Для спецификации структурных аспектов системы тестирования введены такие понятия:

• • тестовый контекст (test context), который позволяет пользователям группировать тестовые ситуации (test cases) для описания соответствующей тестовой конфигурации и определять диспетчера теста (test control) (для управления тестированием и контроля выполнения теста), т. е. необходимый порядок выполнения тестовых ситуаций;
• • тестированная система (System Under Test, SUT) — один или больше объектов в пределах тестовой спецификации;
• • тест-компоненты (test components) — объекты в системе тестирования (тестовой системы), которые могут «общаться» с SUT или другими компонентами для реализации работы теста (тестового поведения);
• • планировщик (scheduler) — контролирует выполнение теста и тесткомпоненты. Он отвечает за создание тестовых компонентов, синхронизированный запуск работы теста над разными тестовыми компонентами и выявление факта окончания тестовой ситуации;
• • средства (means) оценивания результатов тестирования, полученных разными объектами в пределах системы тестирования, предназначенные для выноса окончательного вердикта относительно тестовой ситуации или тестового контекста. Этот процесс оценивания называют арбитражем (arbitration). Схема арбитража может формироваться с привлечением арбитра.

Поведение теста (события теста, test behaviour). Группа понятий для спецификации действий и актов оценивания, необходимых для определения задачи теста (test objective). Задача теста описывает цель его выполнения. Для описания тестовых стимулов, наблюдений отзывов от SUT, тестовых запусков, координации действий могут быть использованы диаграммы UML — диаграммы взаимодействия (interaction diagrams), машины состояний и диаграммы активности. Дальше определяются нормативы ожидаемого поведения (событий). UML-IIT вводит также понятие для обработки непредвиденного поведения теста. Обработка непредвиденных сообщений достигается через спецификацию типичных значений (по умолчанию).

В добавление к таким понятиям, как задача теста, тестовая ситуация, вердикт, типичные значения, в профиле вводятся другие понятия, необходимые для спецификации теста, вроде:

• • действие с валидацией (validation action) — может быть выполнено локальным тестовым компонентом;
• • журнал тестирования (test log) — вместе с журналом действий (log action) является средством регистрации записей (entry) во время выполнения теста для последующего анализа;
• • действие по окончании (finish action) — для определения завершения компонентом действия (поведения) в тестовой ситуации без его остановки;
• • оператор determAlt — используется во взаимодействиях для спецификации детерминированного и последовательного оценивания предохранителей (guards) альтернативного поведения. Оператор determAlt всегда выбирает альтернативу, которая первой приобретает статус реализованной.

Данные теста (test data). UML-ПТ поддерживает заполнители (wildcards), динамические области данных (data pools), распределения данных (data partitions), селектора данных (data selectors) и правила кодировки (coding rules). Wildcards очень полезны для обработки непредвиденных событий или событий, связанных со многими разными значениями. Профиль вводит wildcards, которые позволяют проводить спецификацию любого значения (any value) за пределами набора возможных значений и любого или опущенного (попранного) значения (any or omitted values) для определения любого значения или отсутствия значения. Динамические области данных, распределения данных и селектора данных поддерживают повторное выполнение тестовых ситуаций с разными значениями данных для стимулирования SUT различными путями. Динамические области данных связываются с тестовыми контекстами и могут включать распределения (классы эквивалентности) данных и конкретные значения данных. Селекторы данных предоставляют разные стратегии для выделения и проверки данных. Профиль также поддерживает идею правил кодировки, что позволяет пользователю делать кодирование и декодирование тестовых данных при общении с SUT.

Время тестирования (test time). Новые понятия, которые пополняют простые понятия времени, определенные UML 2.0:

• • таймеры (Timers) — для манипулирования и контроля тестового поведения и гарантирования окончания тестовых ситуаций;
• • зоны времени (Time zones) — для группировки компонентов в пределах распределенной системы, позволяя таким образом сравнивать события в пределах той же зоны времени.

Введенные понятия предоставляют возможности для построения точных спецификаций тестов, используя UML 2.0. Профиль тестирования включает как структурные, так и динамические элементы и предоставляет ключевые понятия в области тестирования, которое делает тестовую спецификацию эффективной и действенной.

• [1] См.: Андон Ф. И. Основы инженерии качества программных систем. 2007.