Технологии тестирования ИСП РАН

Технологии
тестирования
ИСП РАН
В. Кулямин
[email protected]
Что такое тестирование
Оценка соответствия системы требованиям к ней
на основе результатов наблюдения за ее работой
в конечном наборе специально подготовленных
ситуаций
SWEBOK (2004), IEEE 610 (1991)




Система в ходе тестирования должна работать
Нужно готовить специальные (тестовые) ситуации
Оценивается соответствие – ищем ошибки
Нужна общая оценка – нужно подготовить конечный
(небольшой) набор ситуаций, позволяющий ее дать
2 / 26
Как выполняется тестирование

Воздействуем на тестируемую
систему

Наблюдаем ее реакцию

Проверяем, такая ли реакция
должна быть

Повторяем, пока не
исчерпаются все существенно
различные ситуации
3 / 26
Тестирование на основе моделей

Распознавание ошибки
– ментальная модель правильной работы
Math.abs(-2147483648 = -231) = -2147483648

= 231 (mod 232)
Полнота набора ситуаций
– ментальная модель всех важных ситуаций
abs(x) = (x >= 0)?x:-x (mod 232)  {0,1,-1,231-1,-231,-231+1}

Управление построением тестов
– ментальная модель устройства тестовых воздействий
Один вызов или несколько
Параллелизм, синхронизация обращений
При тестировании на основе моделей
модели выделяются явно и заранее
4 / 26
Отличия от традиционного подхода
Обычное тестирование
1.
2.
3.
4.
5.
Придумываем ситуацию
Оформляем ее в виде сценария
взаимодействия теста с системой
Понимаем, как должна система
вести себя в его рамках
Дополняем сценарий проверкой
правильности
Получается тестовый вариант
(test case)
Оцениваем достаточность
имеющегося набора ситуаций:
достаточно – конец, нет – идем в 1
Тестирование на основе моделей
1.
2.
3.
4.
Строим модель поведения
системы (в нужном аспекте)
Определяем общую процедуру
оценки правильности работы
системы – оракул (используя
модель)
Определяем критерий полноты
тестирования (используя модель)
Строим набор ситуаций
(автоматизированно), чтобы
удовлетворить критерию полноты
5 / 26
Создание тестов и тестирование
Генератор
воздействий
12%
36%
87%
57%
Критерий
полноты
Метрика
покрытия
Тестируемая
система
Модель
поведения
Модель
Модель
состояния
состояния
+ оракул
6 / 26
Pro et contra
 Систематичность
 Строгость




( формальность)
Абстрактность
Автоматизация
Быстрая подготовка
тестов (часто до самой
тестируемой системы)
Тесты более высокого
качества
− Сложность
− Повышенные
требования к
разработчикам тестов



Образование
Абстрактное мышление
Умение программировать
− Трудность интеграции в
обычную разработку
7 / 26
Модели в UniTESK

Описание требований




Критерии полноты



Структура данных – простые структуры, шаблоны, грамматики
Поведение
– контрактные спецификации
Параллелизм
ll – семантика чередования
Варианты элементов структуры данных
Варианты возможного поведения системы
Построение тестов



Генераторы простых данных
Генераторы данных заданной структуры
Построение конечных автоматов, обеспечивающих полноту
покрытия ситуаций, и их автоматический обход
8 / 26
Структуры данных

BNF или шаблоны

Генерация корректных данных
– покрытие всех вариантов, комбинаций и итераций на заданную глубину

Генерация некорректных данных
– покрытие всех неправильных в данном контексте вариантов

Контекстные условия и ограничения

Нацеленная генерация
– ссылочная целостность, единственность в данном контексте


Фильтрация
Учет зависимости поведения от структуры
9 / 26
Генерация тестовых программ (1)
Критерий полноты
Шаблоны
Зависимости
Эквивалентность
Варианты
исполнения
Модель поведения
Типы
Структура
данных
процессора
Модель
Инструкции
исполнения
Генератор
Итератор
комбинаций
Итератор
зависимостей
Итераторы
данных
Итератор
ситуаций
Модель
исполнения
Привязка
инструкций
Тестовые
программы
10 / 26
Генерация тестовых программ (2)
Критерий полноты
Комбинации
Зависимости
Генератор
Итератор
комбинаций
Итераторы
данных
Ограничения сложности
Модель поведения
Алгоритм обработки
Блоки и
связи
Целевой
язык
Привязка
блоков
Тестовые
программы
if(…)…else …
for(…;…;…)
11 / 26
Генерация тестовых программ
12 / 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
13 / 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() );
}
}
}
}
14 / 26
Описание асинхронного поведения


Интерфейс компонента состоит из операций
и событий
События тоже описываются при помощи
контракта
 Постусловие
события определяет корректность
его наступления и изменения состояния
компонента
eMailSent:
post
pre mails.size() != 0
&& mails.size() == pre mails.size()-1
15 / 26
Семантика чередования
~
16 / 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)
}
17 / 26
Построение конечного автомата
область
определения
операции
параметры
2
3
1
варианты
исполнения
состояния
18 / 26
Построение одного воздействия
параметры
2
3
1
состояния
текущее состояние
19 / 26
Тестирование асинхронности
11
s12
21
s11
s21
21
Тестируемая
система
r11
11
r12
31
12
r21
12
r22
s31
Время



Время
22
Используется мультипоследовательность воздействий
Воздействия и реакции образуют частично упорядоченное
множество
При проверке корректности это множество вытягивается в
последовательность
20 / 26
Тестирование компонентов
Генератор
Описание автомата
Состояния
Действия
Критерий полноты
Варианты исполнения
Виды
параметров
Виды
состояний
Модель поведения
Структуры
Операции и
данных
события
Пред- и
Инварианты
постусловия
Обходчик
автоматов
Итераторы
данных
Метрика
покрытия
Предусловия
Генерация тестовой
последовательности
на лету
Тестируемая
система
Модель
состояния
Постусловия
Оракулы
21 / 26
Тестирование компонентов
22 / 26
Применение UniTESK


Тесты ядра ОС телефонной станции
Реализации IPv6






Оптимизаторы компиляторов Intel
Тестовый набор для IPsec
Пилотные проекты





Компоненты CRM-системы (Luxoft)
Оптимизатор трансляции граф. моделей
2000-2001
2002-2003
2002
2001-2003
2004-…
2004
2005
Тестовый набор для Linux Standard Base


Microsoft Research
Мобильный IPv6 (в Windows CE 4.1)
Октет
1994-1997
Core 3.1
Другие части
Компоненты биллинговой системы и EAI
НИИСИ



Тестовый набор для ОС 2000
Тесты для процессора Комдив 64 СМП
Тесты для процессора Комдив 64
2005-…
2006-...
2005-…
2005-...
2006-...
2007-...
23 / 26
Литература
1.
2.
3.
4.
5.
6.
7.
8.
9.
И. Бурдонов, А. Косачев, В. Кулямин. Использование конечных автоматов для
тестирования программ. Программирование, 26(2):61-73, 2000
I. Bourdonov, A. Kossatchev, V. Kuliamin, A. Petrenko. UniTesK Test Suite Architecture. Proc.
of FME 2002, LNCS 2391, pp. 77-88, Springer-Verlag, 2002
В. Кулямин, А. Петренко, А. Косачев, И. Бурдонов. Подход UniTesK к разработке
тестов. Программирование, 29(6):25-43, 2003
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, 2003
С. Зеленов, С. Зеленова, А. Косачев, А. Петренко. Генерация тестов для компиляторов
и других процессоров формальных текстов. Программирование, 29(2):104-111, 2003
А. Баранцев и др. Подход UniTesK к разработке тестов: достижения и перспективы.
Труды ИСП РАН, т. 5, с. 121-156, 2004
V. Kuliamin, A. Petrenko. Applying Model Based Testing in Different Contexts. Proc. of seminar
on Perspectives of Model Based Testing, Dagstuhl, Germany, September 2004.
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. 68-83, Springer-Verlag, 2005
В. Иванников, А. Камкин, А. Косачев, В. Кулямин, А. Петренко. Использование
контрактных спецификаций для представления требований и функционального
тестирования аппаратуры. Программирование, 33(5):47-61, 2007
24 / 26
Контакты


Группа RedVerst
Сайт:
Сайт UniTESK:
Linux Testing:
e-mail:
Телефон:
Факс:
www.ispras.ru/groups/rv/rv.html
www.unitesk.com
www.linuxtesting.org
[email protected]
(8-495)-9125317
(8-495)-9121524
Докладчик
Сайт:
e-mail:
www.ispras.ru/~kuliamin
[email protected]
25 / 26
Спасибо за внимание!
26 / 26
Проверка корректности
Тестовая
программа
Тестируемый
компилятор
Эталон
?
==
27 / 26
Пример: простые выражения
Test
stmts
1..*
Statement
xi = Expr
expr
1
var 1
Expression
Variable
id : string
xi
Constant
value : int
17
BinaryExpr
op : {+,-,*,/}
left
1
right 1
Expr1 + Expr2
28 / 26
Неявное описание автомата
29 / 26
Проверка корректности
Семантика чередования






✕

30 / 26
Область применимости
Тестируемые интерфейсы должны быть четко определены
Сложность
интерфейса
Компиляторы
Библиотеки
Протоколы
Информационные
системы
Web-приложения
Наблюдаемая
сложность состояния
31 / 26