Download - TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation
![Page 1: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/1.jpg)
Технические и «нетехнические» проблемы автоматизации тестирования
Пакулин Николай Витальевич,Петренко Александр Константинович,
Институт системного программирования РАН (ИСП РАН)www.ispras.ru
http://ispras.ru/ru/se
TMPA, Кострома, 2013
![Page 2: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/2.jpg)
«Автоматизация тестирования» и«Тестирование на основе моделей» (MBT)
• Что общего?• В чем разница?• Что думают классики?
2
Bob Binder. Автор Testing Object-Oriented
Software
Любое автоматизированное тестирование это тестирование на основе моделей
![Page 3: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/3.jpg)
Примеры моделей в 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 4State 3
op2
op3
op3op3
op2op1
op3
![Page 4: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/4.jpg)
Венский метод Vienna Development Method – VDM (1)
Шаг 0-ой: объявление сорт-типов и определение сигнатур операций
Шаг 1-ый: структуры данных и спецификации для каждой операции
(имплицитные и эксплицитные),
доказательство корректности спецификаций
. . .
Шаг i-й: модификация сигнатур и структур данных и расширение
спецификаций предыдущего шага, доказательство корректности и
согласованности с предыдущим шагом.
В конце возможна трансляция в код на языке программирования.
Операционная семантика языка программирования, синтез
программ 4
Модели
Идея
Код
![Page 5: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/5.jpg)
Венский метод Vienna Development Method – VDM (2)
Имея имплицитную спецификацию <pre-Op, post-Op> и эксплицитную спецификацию Op нужно доказывать, что
" Input pre-Op(input) => post-Op(input, Op(input))
Это надо доказывать на каждом уровне детализации.
5
![Page 6: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/6.jpg)
Венский методVienna Development Method – VDM (3)
Доказательство соответствия моделей разного уровня детализации
Обозначения:• Op_mod - операция в модельном (спецификационном) пространстве• Op_impl - операция в реализационном пространстве• in, out - входные и выходные данные в реализационном пространстве• IN, OUT - входные и выходные данные в модельном пространстве• retr - восстанавливающая функция (функция абстракции)
Op_mod
Op_impl
retr retr
in out
OUT IN
6
Модельное пространство
Реализационное пространство
Функция абстракции
![Page 7: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/7.jpg)
• Пред-условия абстрактного уровня (далее будем говорить модели и использовать суффикс _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
Постановка задачи верификации. Модель и реализация заданы явно
![Page 8: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/8.jpg)
В этом случае для доказательства соответствия нужно убедиться, что для каждой уточненной функции: • Пред-условия модели функции не слабее пред-условий
реализации
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
Постановка задачи верификации. Модель неявная, реализация явная
![Page 9: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/9.jpg)
Требуется показать соответствие на тестовых примерах :
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
Постановка задачи верификации при помощи тестирования на основе
моделей
![Page 10: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/10.jpg)
Общая схема генерации тестов в UniTESK и SpecExplorer
10
Критерий полноты
Модель поведенияСтруктуры
данных
ИнвариантыПред- и
постусловия
Операции и события
Варианты исполнения
Виды состояний
Модель состояния
Обходчик автоматов
Оракулы
Виды параметров
ГенераторИтераторы
данных
Описание автомата
ДействияСостояния
Метрика покрытия
Тестируемая система
Генерация тестовой последовательности на
лету
Предусловия
Постусловия
![Page 11: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/11.jpg)
Примеры приложений 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
![Page 12: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/12.jpg)
Примеры моделей программного обеспечения встроенных систем управления
12
SCADE (Esterel Technologies) Диаграмма последовательностей (IBM/Rhapsody)
![Page 13: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/13.jpg)
Средства моделирования логики и поведения микропроцессоров
13
![Page 14: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/14.jpg)
Модель системы на языке AADL (SAE Architecture Analysis & Design Language)
14
![Page 15: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/15.jpg)
ИСП РАН AADL инструмент MASIW
15
![Page 16: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/16.jpg)
Правила безопасного программирования(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().
Неформальное описание правила
Формальная модель запрещенного поведения
Общая идея: формализация описания «анти-паттернов» корректного программирования
![Page 17: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/17.jpg)
Современные проблемы
• Возможности инструментов пока не позволяют проводить точный анализ систем реальной сложности и реальных размеров– Поиск возможностей помодульного анализа
• Реальные программно-аппаратные системы представляют собой «стек» платформ– Задача «межплатформенного» анализа
• Разработка спецификаций/моделей требований, правил корректности и безопасности
17
![Page 18: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/18.jpg)
Ближайшие перспективы
• Освоение больших вычислительных мощностей для решения задач верификации
• Комбинация различных подходов к анализу программ, включая техники на основе provers и solvers
18
![Page 19: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/19.jpg)
Каковы плюсы тестирования на основе моделей?
• Разработка моделей подталкивает к скрупулезному анализу проекта (многие ошибки выявляются еще на фазе проектирования)
• MBT достаточно легко позволяет распараллеливать выполнение тестов (легко загрузить кластер)
• Достаточно просто строить рандомизированные тесты • Поддерживать и сопровождать большую систему MBT
проще традиционных пакетов регрессионных тестов• Трудоемкость разработки MBT тестов в большом проекте
меньше по сравнению с традиционными технологиями
19
![Page 20: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/20.jpg)
«НЕТЕХНИЧЕСКИЕ» ПРОБЛЕМЫ
Минусы тестирования на основе моделей
20
![Page 21: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/21.jpg)
«Медленный старт»
• Тесты только после модели– Недели и месяцы работы без видимой отдачи– «Дублирование кода»– Отсутствие документации. «Читайте код, там всё
написано»– Модификации в коде. Незафиксированные интерфейсы!
• «Где ошибки?»– Разработка модели должна начинаться на этапе
проектирования– Ко-верификация– Непонятная модель
21
![Page 22: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/22.jpg)
Проблема планирования
• Выбор уровня качества– MBT – недешевая активность– Анализ и выбор возможностей– Постановка бизнес-целей
• «Они нас отвлекают!» vs «Молчат как партизаны!»– Построение политики взаимодействия спецификаторов и
программистов– Построение процесса разработки– Выделение ресурсов
22
![Page 23: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/23.jpg)
Сложность обучения
• «… и много других страшных слов»– иерархический расширенный конечный автомат, пред- и
постусловия, темпоральная логика, алгебра термов, переписывание, обход автомата, …
– В Индии человек с необходимым набором компетенций занимает позицию Research Director в крупной компании
• Результат или процесс?– Специалист по MBT и программист мыслят по-разному!– Модель != реализация
• Подготовка персонала– Отсутствие подготовки в ВУЗе– Трехдневный тренинг (???)
23
![Page 24: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/24.jpg)
Сложность удержания обученных кадров
• Как сохранять мотивацию высокоуровнего тестирования?– Тестировщик – «человек второго сорта»– Относительно легко говорить о мотивации разработчиков
инструментов
• Важно, чтобы каждый видел перспективу роста:– Варианты карьерного роста в компании– Высокий уровень компетенций – переход в ведущие
разработчики, архитекторы, дизайнеры, …
• Ограниченность рынка– Большая потребность в специалистах
24
![Page 25: TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation](https://reader035.vdocuments.net/reader035/viewer/2022081413/546201e4af7959fd5a8b470a/html5/thumbnails/25.jpg)
Спасибо!