TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation
Download as PPTX, PDF2 likes733 views
Документ рассматривает автоматизацию тестирования и тестирование на основе моделей, подчеркивая их общие аспекты и различия. Обсуждаются методологии, такие как венский метод разработки и различные подходы к верификации моделей и реализаций программного обеспечения. Также рассматриваются преимущества и недостатки тестирования на основе моделей, включая вопросы планирования и сложности подготовки кадров.
![Примеры моделей в
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](https://image.slidesharecdn.com/petrenkopakulin-tmpa-2013-131011170002-phpapp01/85/TMPA-2013-Petrenko-Pakulin-Technical-Solutions-and-Non-Technical-Challenges-of-Test-Automation-3-320.jpg)
TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation
- 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. Спасибо!