1. Технические и «нетехнические»
проблемы автоматизации тестирования
Пакулин Николай Витальевич,
Петренко Александр Константинович,
Институт системного программирования РАН (ИСП РАН)
www.ispras.ru
http://ispras.ru/ru/se
TMPA, Кострома, 2013

2. «Автоматизация тестирования» и
«Тестирование на основе моделей» (MBT)
• Что общего?
• В чем разница?
• Что думают классики?
2
Bob Binder.
Автор Testing Object-Oriented
Software
Любое автоматизированное
тестирование это
тестирование на основе моделей

3. Примеры моделей в
Model Based Testing (MBT)
3
RSL
MSC
FSM /
FA
Грамматика
<assign> ::= <id> “:=” <expr>
<expr> ::= <intexp> | <boolexp>
Программный контракт
(UniTESK, SpecExplorer)
class ArrayList { public virtual void
Insert(int index , object value)
requires 0 <= index && index <= Count;
requires !IsReadOnly && !IsFixedSize;
ensures Count == old(Count) + 1;
ensures value == this[index ];
ensures Forall{int i in 0 : index ; old(this[i])
== this[i]};
ensures Forall{int i in index : old(Count);
old(this[i]) == this[i + 1]};
{ . . . }
axiom  s : S, e : Nat :-
first(add(s, e)) ≡
if e > 10 then 2 * first(s)
elsif e > 5 then first(s)
else 0 end
State 2
State1
State 4
State 3
op2
op3
op3
op3
op2
op1
op3

4. Венский метод
Vienna Development Method – VDM (1)
Шаг 0-ой: объявление сорт-типов и определение сигнатур операций
Шаг 1-ый: структуры данных и спецификации для каждой операции
(имплицитные и эксплицитные),
доказательство корректности спецификаций
. . .
Шаг i-й: модификация сигнатур и структур данных и расширение
спецификаций предыдущего шага, доказательство корректности и
согласованности с предыдущим шагом.
В конце возможна трансляция в код на языке программирования.
Операционная семантика языка программирования, синтез
программ
4
Модели
Идея
Код

5. Венский метод
Vienna Development Method – VDM (2)
Имея имплицитную спецификацию <pre-Op, post-Op> и
эксплицитную спецификацию Op нужно доказывать, что
 Input
pre-Op(input) => post-Op(input, Op(input))
Это надо доказывать на каждом уровне детализации.
5

6. Венский метод
Vienna Development Method – VDM (3)
Доказательство соответствия моделей разного уровня детализации
Обозначения:
• Op_mod - операция в модельном (спецификационном) пространстве
• Op_impl - операция в реализационном пространстве
• in, out- входные и выходные данные в реализационном пространстве
• IN, OUT - входные и выходные данные в модельном пространстве
• retr - восстанавливающая функция (функция абстракции)
Op_mod
Op_impl
retr retr
in out
OUTIN
6
Модельное пространство
Реализационное пространство
Функция абстракции

7. • Пред-условия абстрактного уровня (далее будем говорить
модели и использовать суффикс _mod) не слабее пред-
условий уточненного уровня (далее будем говорить
реализации и использовать суффикс _impl):
pre-Op_mod(retr(in)) => pre-Op_impl(in)
• При условии, что предусловия не нарушены, результат
выполнения функции Op_mod эквивалентен результату
функции Op_impl, преобразованного функцией retr:
pre-Op_mod(retr(in)) =>
eq(retr(Op_impl(in)), Op_mod(retr(in))),
где eq – функция, задающая определение эквивалентности
значений из области значений функции Op_mod.
7
Постановка задачи верификации.
Модель и реализация заданы явно

8. В этом случае для доказательства соответствия нужно убедиться,
что для каждой уточненной функции:
• Пред-условия модели функции не слабее пред-условий
реализации
pre-Op_mod(retr(in)) => pre-Op_impl(in)
• пост-условие модели выполняется по отношению к
входным данным, полученным трансформацией входных
данных реализации и результатам, полученным
трансформацией выходных данных реализации (при
условии, что пред-условие для модели выполняется)
 in: pre-Op_mod(retr(in)) =>
post-Op_mod(retr(in), retr(Op_impl(in)))
8
Постановка задачи верификации.
Модель неявная, реализация явная

9. Требуется показать соответствие на тестовых примерах :
pre-Op_mod(retr(in)) =>
post-Op_mod(retr(in), retr(Op_impl(in)))
или
pre-Op_mod(retr(in)) =>
eq(retr(Op_impl(in)), Op_mod(retr(in)))
При этом надо ответить на вопрос – сколько и каких входных данных
будет достаточно для выполнения качественного тестирования.
9
Постановка задачи верификации при
помощи тестирования на основе
моделей

10. Общая схема генерации тестов в
UniTESK и SpecExplorer
10
Критерий полноты
Модель поведения
Структуры
данных
Инварианты
Пред- и
постусловия
Операции и
события
Варианты исполнения
Виды
состояний
Модель
состояния
Обходчик
автоматов
Оракулы
Виды
параметров
Генератор
Итераторы
данных
Описание автомата
ДействияСостояния
Метрика
покрытия
Тестируемая
система
Генерация тестовой
последовательности на
лету
Предусловия
Постусловия

11. Примеры приложений UniTESK
 OS Kernel Verification (Nortel Networks) - 1994–1999
 CleanDocs – Requirements management
based on formalization (Nortel Networks) - 1999
 UniTESK origination - 1999
 IPv6 implementation testing (Microsoft Research) - 2001-2003
 Compiler testing (Intel) - 2001–2004
 Billing system infrastructure (VimpelCom) - 2005-2011
 Linux Standard Base – OLVER (Ministry of Science RF) - 2005-2006
 ARINC-653 testing (NIISI et al) - 2007-2013
 CRM system testing (Luxoft/Deutsche Bank) - 2003
 Tiny OS testing (Luxoft) - 2004
 Simulink optimizer (Daimler Chrysler) - 2005
 LSB Infrastructure (Linux Foundation, Nokia) - 2007-2011
 Hardware design testing (NIISI, MCST) - 2005-2013
 IPsec formalization and testing (RFBR) - 2007-2009
 Math library testing (NIISI) - 2007-2011
 Linux driver verification (RFBR, Ministry of Science RF) - 2007-2013
 Avionics tool chain (GosNIIAS) - 2009-2013
 Critical avionics testing (Rusys, Lasex) - 2010-2012
 DOM formalization and testing (Microsoft) - 2009-2011
 Race detection in Linux kernel – KEDR (Google) - 2011-2012

12. Примеры моделей программного обеспечения
встроенных систем управления
12
SCADE (Esterel Technologies) Диаграмма последовательностей
(IBM/Rhapsody)

13. Средства моделирования логики и
поведения микропроцессоров
13

14. Модель системы на языке AADL
(SAE Architecture Analysis & Design Language)
14

15. ИСП РАН AADL инструмент MASIW
15

16. Правила безопасного программирования
(safety rules)
16
ID 0029: Memory cannot be allocated from an
unexisted memory pool
GOALS:
To avoid potential crashes related to incorrect usage
of pool functions: dma_pool_alloc() cannot be
called before a successful creation of pool using
dma_pool_create().
Неформальное описание правила
Формальная модель
запрещенного поведения
Общая идея: формализация описания
«анти-паттернов» корректного программирования

17. Современные проблемы
• Возможности инструментов пока не позволяют
проводить точный анализ систем реальной
сложности и реальных размеров
– Поиск возможностей помодульного анализа
• Реальные программно-аппаратные системы
представляют собой «стек» платформ
– Задача «межплатформенного» анализа
• Разработка спецификаций/моделей требований,
правил корректности и безопасности
17

18. Ближайшие перспективы
• Освоение больших вычислительных
мощностей для решения задач
верификации
• Комбинация различных подходов к
анализу программ, включая техники
на основе provers и solvers
18

19. Каковы плюсы тестирования на
основе моделей?
• Разработка моделей подталкивает к скрупулезному анализу
проекта (многие ошибки выявляются еще на фазе
проектирования)
• MBT достаточно легко позволяет распараллеливать
выполнение тестов (легко загрузить кластер)
• Достаточно просто строить рандомизированные тесты
• Поддерживать и сопровождать большую систему MBT
проще традиционных пакетов регрессионных тестов
• Трудоемкость разработки MBT тестов в большом проекте
меньше по сравнению с традиционными технологиями
19

20. «НЕТЕХНИЧЕСКИЕ»
ПРОБЛЕМЫ
Минусы тестирования на основе моделей
20

21. «Медленный старт»
• Тесты только после модели
– Недели и месяцы работы без видимой отдачи
– «Дублирование кода»
– Отсутствие документации. «Читайте код, там всѐ
написано»
– Модификации в коде. Незафиксированные интерфейсы!
• «Где ошибки?»
– Разработка модели должна начинаться на этапе
проектирования
– Ко-верификация
– Непонятная модель
21

22. Проблема планирования
• Выбор уровня качества
– MBT – недешевая активность
– Анализ и выбор возможностей
– Постановка бизнес-целей
• «Они нас отвлекают!» vs «Молчат как
партизаны!»
– Построение политики взаимодействия спецификаторов и
программистов
– Построение процесса разработки
– Выделение ресурсов
22

23. Сложность обучения
• «… и много других страшных слов»
– иерархический расширенный конечный автомат, пред- и
постусловия, темпоральная логика, алгебра термов,
переписывание, обход автомата, …
– В Индии человек с необходимым набором компетенций
занимает позицию Research Director в крупной компании
• Результат или процесс?
– Специалист по MBT и программист мыслят по-разному!
– Модель != реализация
• Подготовка персонала
– Отсутствие подготовки в ВУЗе
– Трехдневный тренинг (???)
23

24. Сложность удержания
обученных кадров
• Как сохранять мотивацию высокоуровнего
тестирования?
– Тестировщик – «человек второго сорта»
– Относительно легко говорить о мотивации разработчиков
инструментов
• Важно, чтобы каждый видел перспективу роста:
– Варианты карьерного роста в компании
– Высокий уровень компетенций – переход в ведущие
разработчики, архитекторы, дизайнеры, …
• Ограниченность рынка
– Большая потребность в специалистах
24

25. Спасибо!