Спецификация и тестирование компонентов с асинхронным интерфейсом

• Автор: Хорошилов, Алексей Владимирович
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2006
• Место защиты: Москва
• Количество страниц: 138 с. : ил.

1. Введение . .

Формальные методы и тестирование программного обеспечения

Технология ипТсБК.

Системы с асинхронным интерфейсом

Постановка задачи

2. Архитектура ипТевК для систем с синхронным интерфейсом

Основные понятия.

Модель требований и модель поведения.

Оценка корректности поведения целевой системы.

Формализация задачи.

Модель поведения

Модель требований
Программные контракты
Описание модели требований.
Описание модели поведения
Моделирование требований и поведения.
Модели требований и поведения в унифицированной архитектуре теста
Тестовые сценарии.
Генерация тестовых данных
Управляющие автоматы.
Тестовый сценарий
Автоматный механизм построения тестового сценария
Сценарные функции
Граф автоматного тестового сценария
Механизм построения тестового сценария сГзт.
Тестовый сценарий в унифицированной архитектуре теста
Модель оценки качества тестирования.
Качество тестирования
Модель оценки качества тестирования
Описание метрик покрытия .
Мсгрики покрытия в унифицированной архитектуре теста.
Управляемые метрики покрытия и оптимизация тестового набора
Унифицированная архитектура теста.
Системы с асинхронным интерфейсом.
3. Тестирование систем с асинхронным интерфейсом.
Модель требовании и модель поведения
Модель поведения.
Модель требований а .
Описание асинхронной модели требований.
Описание асинхронных взаимодействий в модели поведения.
Модель каналов.
Модель временных меток.
Описание асинхронной модели поведения
Алгоритм проверки корректности поведения.
Требования к полноте набора асинхронных реакций
Модели требований и поведения в унифицированной архитектуре асинхронного
теста
Асинхронные тестовые сценарии.
Генерация тестовых данных для асинхронных систем.
Взаимодействующие автоматы.
Асинхронные функции
Асинхронные тесты
Автоматный механизм построения асинхронного тестового сценария.
Асинхронные сценарные функции
Стационарное тестирование асинхронных систем.
Стационарный автоматный тестовый сценарий
Асинхронный тестовый сценарий .
Алгоритм обхода
Параллельные воздействия на целевую систему
Тестирование с открытым стационарным состоянием
Нарушение предусловий асинхронных воздействий
Тестовый сценарий в унифицированной архитектуре асинхронного теста.
Оценка качества тестирования систем с асинхронным интерфейсом
Качество тестирования систем с асинхронным интерфейсом.
Метрики покрытия асинхронной модели требований.
Описание асинхронных метрик покрытия.
Оценка качества тестирования в унифицированной архитектуре асинхронного теста
Унифицированная архитектура асинхронного теста.
Результаты главы.
4. Программная реализация средств тестирования систем с асинхронными интерфейсами
Процесс тестирования в технологии i
Проекция технологии i на язык программирования С.
Тестирование систем с асинхронным интерфейсом на платформе языка С.
5. Апробация метода и инструментов
Реализация протокола Iv6
Функциональность протокола i Iv6.
Протокол 2 I
Компоненты распределенной операционной системы для сенсорных сетей
Ядро операционной системы реального времени.
Прикладные бинарные интерфейсы ОС ix.
Апробация учебных материалов
Результаты апробации
Заключение.
Литература


Будем говорить, что модель поведения целевой системы V, X, у V удовлетворяет модели требовании Л V, X, У, Е , если V V,, X, у V1, с Е. Рассмотрим пример с функцией вычисления квадратного корня. Что является моделью требований к этой функции Интерфейс этой системы X, У, V был определен в предыдущем разделе. Множество переходов Е определим как все переходы е, х, у, е е V х X х У х V, для которых выполнено следующее ограничение X у2 I Погр , где Согр некоторое положительное действительное ЧИСЛО, МСНЬШСС единицы. Тогда взаимодействия С, 8Ц 0. В качестве основной модели в технологии ишТеБК выступает модель требований. Эта модель создастся первой и именно она является основой для разработки остальных моделей. Причина такого подхода заключается в том, что именно требования являются исходными данными как для процесса разработки целевой системы, так и для процесса тестирования. Для описания модели требований в технологии имТвК используется широко известный подход пршраммных контрактов . Основная идея этого подхода состоит в следующем. В целевой системе выделяется набор интерфейсных операций, то есть операций которые определяют функциональность системы. Каждая такая операция имеет набор входных и выходных параметров. И каждое взаимодействие с целевой системой рассматривается как вызов интерфейсной операции с некоторым набором значений входных параметров и получение от нее набора значении выходных параметров. Спецификация интерфейсной операции состоит из предусловия и постусловия. Предусловие операции определяет, какие значения входных параметров являются допустимыми для передачи целевой системе. Например, предусловие функции бцг может ограничивать множество допустимых значений входного параметра только неотрицательными числами. Постусловие операции определяет, какие выходные значения параметров являются корректными для данных значений входных параметров. То есть, постусловие описывает требования к целевой системе при воздействии на нее посредством данной интерфейсной операции. Если поведение целевой системы зависит от истории ее предыдущих взаимодействии, то в спецификации требований это моделируется введением так называемого модельного состояния. Модельное состояние образуется набором переменных, хранящих все необходимые данные об истории взаимодействий с целевой системой. Эти данные используются при спецификации интерфейсных операций. В этом случае предусловие операции определяет, какие параметры являются допустимыми в данном состоянии, а постусловие описывает, какие выходные значения параметров и постзиачения переменных модельного состояния являются корректными при данных значениях входных параметров и презначениях этих переменных. Презначениями переменных модельного состояния называются значения этих переменных до вызова данной интерфейсной операции, а постзначениями значения после вызова. Рассмотрим подход программных контрактов с математической точки зрения и определим способ описания модели требований, применяемый в технологии i. I х 1,. V V1 1,. I vI 0 набор переменных состояния, к которым обращается данная операция. Каждый входной параметр х может принимать значения из непустого множества допустимых значений X, каждый выходной параметр у, может принимать значения из непустого множества допустимых значений ,, а каждая переменная состояния V может принимать значения из непустого множества допустимых значений V,. Эти непустые множества допустимых значений далее будут называться типами параметров и переменных. Рассмотрим пример операции вычисления квадратного корня. Сигнатурой этой операции является тройка , у , Множеством допустимых значений единственного входного параметра х и единственного выходного параметра у является множество действительных чисел . Пустое множество переменных состояния означает, что данная операция никак не зависит ни от одной переменной состояния. Xi Xi х . V V х . VVi,если vI0, и V е ,в противном случае. Vi х Xi х i х V, называемый постусловием. Здесь, как и ранее, еПОф обозначает некоторое положительное действительное число. Спецификацией целевой системы называется непустой набор спецификаций ее интерфейсных операций 1,.