Технологии тестирования ИСП РАН В. Кулямин kuliamin@ispras.ru. - презентация

1 Технологии тестирования ИСП РАН В. Кулямин

2 2 / 26 Что такое тестирование Оценка соответствия системы требованиям к ней на основе результатов наблюдения за ее работой в конечном наборе специально подготовленных ситуаций SWEBOK (2004), IEEE 610 (1991) Система в ходе тестирования должна работать Нужно готовить специальные (тестовые) ситуации Оценивается соответствие – ищем ошибки Нужна общая оценка – нужно подготовить конечный (небольшой) набор ситуаций, позволяющий ее дать

3 3 / 26 Как выполняется тестирование Воздействуем на тестируемую систему Наблюдаем ее реакцию Проверяем, такая ли реакция должна быть Повторяем, пока не исчерпаются все существенно различные ситуации

4 4 / 26 Тестирование на основе моделей Распознавание ошибки – ментальная модель правильной работы Math.abs( = ) = Полнота набора ситуаций – ментальная модель всех важных ситуаций abs(x) = (x >= 0)?x:-x (mod 2 32 ) Управление построением тестов – ментальная модель устройства тестовых воздействий Один вызов или несколько Параллелизм, синхронизация обращений При тестировании на основе моделей модели выделяются явно и заранее = 2 31 (mod 2 32 ) {0,1,-1, ,-2 31, }

5 5 / 26 Отличия от традиционного подхода 1.Придумываем ситуацию 2.Оформляем ее в виде сценария взаимодействия теста с системой 3.Понимаем, как должна система вести себя в его рамках 4.Дополняем сценарий проверкой правильности Получается тестовый вариант (test case) 5.Оцениваем достаточность имеющегося набора ситуаций: достаточно – конец, нет – идем в 1 1.Строим модель поведения системы (в нужном аспекте) 2.Определяем общую процедуру оценки правильности работы системы – оракул (используя модель) 3.Определяем критерий полноты тестирования (используя модель) 4.Строим набор ситуаций (автоматизированно), чтобы удовлетворить критерию полноты Обычное тестированиеТестирование на основе моделей

6 6 / 26 Тестируемая система Создание тестов и тестирование Модель состояния + оракул Модель поведения Генератор воздействий Метрика покрытия 12% Критерий полноты 36%57%87% Модель состояния

7 7 / 26 Pro et contra Систематичность Строгость ( формальность) Абстрактность Автоматизация Быстрая подготовка тестов (часто до самой тестируемой системы) Тесты более высокого качества Сложность Повышенные требования к разработчикам тестов Образование Абстрактное мышление Умение программировать Трудность интеграции в обычную разработку

8 8 / 26 Модели в UniTESK Описание требований Структура данных – простые структуры, шаблоны, грамматики Поведение – контрактные спецификации Параллелизм ll – семантика чередования Критерии полноты Варианты элементов структуры данных Варианты возможного поведения системы Построение тестов Генераторы простых данных Генераторы данных заданной структуры Построение конечных автоматов, обеспечивающих полноту покрытия ситуаций, и их автоматический обход

9 9 / 26 Структуры данных BNF или шаблоны Генерация корректных данных – покрытие всех вариантов, комбинаций и итераций на заданную глубину Генерация некорректных данных – покрытие всех неправильных в данном контексте вариантов Контекстные условия и ограничения Нацеленная генерация – ссылочная целостность, единственность в данном контексте Фильтрация Учет зависимости поведения от структуры

10 10 / 26 Критерий полноты Генерация тестовых программ (1) Тестовые программы Модель поведения Типы данных Инструкции Модель исполнения Структура процессора Зависимости Варианты исполнения Шаблоны Модель исполнения Итератор комбинаций Итератор зависимостей Итератор ситуаций Привязка инструкций Эквива- лентность Генератор Итераторы данных

11 11 / 26 Генерация тестовых программ (2) if(…)…else … for(…;…;…) Критерий полноты Модель поведения Алгоритм обработки Блоки и связи Целевой язык Зависимости Ограничения сложности Комбинации Тестовые программы Итератор комбинаций Итераторы данных Привязка блоков Генератор

12 12 / 26 Генерация тестовых программ

13 13 / 26 Контрактные спецификации Тестируемая система разбивается на компоненты Каждый компонент имеет внутренние данные и набор операций Поведение операции определяется ее контрактом Предусловие описывает область определения операции sqrt(x): pre x 0 Постусловие описывает ограничения на правильные результаты операции sqrt(x): post sqrt*sqrt == x Инварианты компонента описывают условия целостности его данных Triangle: double x,y,z : x+y>z & x+z>y & y+z>x

14 14 / 26 Пример specification class ClientManager { specification Client addClient ( String name ) { post { if ( name == null || clients.containsKey(name) ) { branch "Client cannot be created"; return addClient == null && clients.equals( pre clients.clone() ); } else { branch "Client can be created"; HashMap oldClients = (HashMap)clients.clone(); oldClients.remove(name); return addClient != null && addClient.name.equals(name) && addClient.parent == null && addClient.children.isEmpty() && clients.get(name) == addClient && oldClients.equals( pre clients.clone() ); }

15 15 / 26 Описание асинхронного поведения Интерфейс компонента состоит из операций и событий События тоже описываются при помощи контракта Постусловие события определяет корректность его наступления и изменения состояния компонента Sent: post pre mails.size() != 0 && mails.size() == pre mails.size()-1

16 16 / 26 Семантика чередования ~

17 17 / 26 Критерии полноты тестирования post { if ( f(a, b) || g(a) ) … else if( h(a, c) && !g(b) ) … else … } !f(a, b) && !g(a) && !h(a, c) || !f(a, b) && !g(a) && g(b)

18 18 / 26 Построение конечного автомата состояния параметры область определения операции варианты исполнения

19 19 / 26 Построение одного воздействия текущее состояние параметры состояния

20 20 / 26 Тестирование асинхронности s 11 Тести- руемая система s 21 s 12 s 31 Используется мультипоследовательность воздействий Воздействия и реакции образуют частично упорядоченное множество При проверке корректности это множество вытягивается в последовательность r 12 r 22 r 11 r 21 Время Время

21 21 / 26 Тестирование компонентов Критерий полноты Модель поведения Структуры данных Инварианты Пред- и постусловия Операции и события Варианты исполнения Виды состояний Модель состояния Обходчик автоматов Оракулы Виды параметров Генератор Итераторы данных Описание автомата ДействияСостояния Метрика покрытия Тестируемая система Генерация тестовой последовательности на лету Предусловия Постусловия

22 22 / 26 Тестирование компонентов

23 23 / 26 Применение UniTESK Тесты ядра ОС телефонной станции Реализации IPv6 Microsoft Research Мобильный IPv6 (в Windows CE 4.1) Октет2002 Оптимизаторы компиляторов Intel Тестовый набор для IPsec 2004-… Пилотные проекты Компоненты CRM-системы (Luxoft)2004 Оптимизатор трансляции граф. моделей2005 Тестовый набор для Linux Standard Base Core … Другие части Компоненты биллинговой системы и EAI 2005-… НИИСИ Тестовый набор для ОС Тесты для процессора Комдив 64 СМП Тесты для процессора Комдив

24 24 / 26 Литература 1.И. Бурдонов, А. Косачев, В. Кулямин. Использование конечных автоматов для тестирования программ. Программирование, 26(2):61-73, I. Bourdonov, A. Kossatchev, V. Kuliamin, A. Petrenko. UniTesK Test Suite Architecture. Proc. of FME 2002, LNCS 2391, pp , Springer-Verlag, В. Кулямин, А. Петренко, А. Косачев, И. Бурдонов. Подход UniTesK к разработке тестов. Программирование, 29(6):25-43, A. Kossatchev, A. Petrenko, S. Zelenov, S. Zelenova. Using Model-Based Approach for Automated Testing of Optimizing Compilers. Proc. Intl. Workshop on Program Undestanding, Gorno-Altaisk, С. Зеленов, С. Зеленова, А. Косачев, А. Петренко. Генерация тестов для компиляторов и других процессоров формальных текстов. Программирование, 29(2): , А. Баранцев и др. Подход UniTesK к разработке тестов: достижения и перспективы. Труды ИСП РАН, т. 5, с , V. Kuliamin, A. Petrenko. Applying Model Based Testing in Different Contexts. Proc. of seminar on Perspectives of Model Based Testing, Dagstuhl, Germany, September V. Kuliamin, N. Pakoulin, A. Petrenko. Practical Approach to Specification and Conformance Testing of Distributed Network Applications. Proc. of 2-nd International Service Availability Symposium, LNCS 3694, pp , Springer-Verlag, В. Иванников, А. Камкин, А. Косачев, В. Кулямин, А. Петренко. Использование контрактных спецификаций для представления требований и функционального тестирования аппаратуры. Программирование, 33(5):47-61, 2007

25 25 / 26 Контакты Группа RedVerst Сайт: Сайт UniTESK: Linux Testing: Телефон:(8-495) Факс:(8-495) Докладчик Сайт:

26 26 / 26 Спасибо за внимание!

27 27 / 26 Проверка корректности Тестовая программа == ? Тестируемый компилятор Эталон

28 28 / 26 Пример: простые выражения Test Expression BinaryExpr op : {+,-,*,/} Variable id : string Constant value : int stmts 1..* left 1 right 1 Statement var 1 expr 1 x i = Expr xixi 17Expr 1 + Expr 2

29 29 / 26 Неявное описание автомата

30 30 / 26 Проверка корректности Семантика чередования

31 31 / 26 Область применимости Тестируемые интерфейсы должны быть четко определены Сложность интерфейса Наблюдаемая сложность состояния Компиляторы Библиотеки Протоколы Информационные системы Web-приложения