TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation

586 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
586
On SlideShare
0
From Embeds
0
Number of Embeds
133
Actions
Shares
0
Downloads
3
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

TMPA-2013 Petrenko Pakulin: Technical Solutions and Non-Technical Challenges of Test Automation

  1. 1. Технические и «нетехнические» проблемы автоматизации тестирования Пакулин Николай Витальевич, Петренко Александр Константинович, Институт системного программирования РАН (ИСП РАН) www.ispras.ru http://ispras.ru/ru/se TMPA, Кострома, 2013
  2. 2. «Автоматизация тестирования» и «Тестирование на основе моделей» (MBT) • Что общего? • В чем разница? • Что думают классики? 2 Bob Binder. Автор Testing Object-Oriented Software Любое автоматизированное тестирование это тестирование на основе моделей
  3. 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. 4. Венский метод Vienna Development Method – VDM (1) Шаг 0-ой: объявление сорт-типов и определение сигнатур операций Шаг 1-ый: структуры данных и спецификации для каждой операции (имплицитные и эксплицитные), доказательство корректности спецификаций . . . Шаг i-й: модификация сигнатур и структур данных и расширение спецификаций предыдущего шага, доказательство корректности и согласованности с предыдущим шагом. В конце возможна трансляция в код на языке программирования. Операционная семантика языка программирования, синтез программ 4 Модели Идея Код
  5. 5. Венский метод Vienna Development Method – VDM (2) Имея имплицитную спецификацию <pre-Op, post-Op> и эксплицитную спецификацию Op нужно доказывать, что  Input pre-Op(input) => post-Op(input, Op(input)) Это надо доказывать на каждом уровне детализации. 5
  6. 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. 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. 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. 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. 10. Общая схема генерации тестов в UniTESK и SpecExplorer 10 Критерий полноты Модель поведения Структуры данных Инварианты Пред- и постусловия Операции и события Варианты исполнения Виды состояний Модель состояния Обходчик автоматов Оракулы Виды параметров Генератор Итераторы данных Описание автомата ДействияСостояния Метрика покрытия Тестируемая система Генерация тестовой последовательности на лету Предусловия Постусловия
  11. 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. Примеры моделей программного обеспечения встроенных систем управления 12 SCADE (Esterel Technologies) Диаграмма последовательностей (IBM/Rhapsody)
  13. 13. Средства моделирования логики и поведения микропроцессоров 13
  14. 14. Модель системы на языке AADL (SAE Architecture Analysis & Design Language) 14
  15. 15. ИСП РАН AADL инструмент MASIW 15
  16. 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. Современные проблемы • Возможности инструментов пока не позволяют проводить точный анализ систем реальной сложности и реальных размеров – Поиск возможностей помодульного анализа • Реальные программно-аппаратные системы представляют собой «стек» платформ – Задача «межплатформенного» анализа • Разработка спецификаций/моделей требований, правил корректности и безопасности 17
  18. 18. Ближайшие перспективы • Освоение больших вычислительных мощностей для решения задач верификации • Комбинация различных подходов к анализу программ, включая техники на основе provers и solvers 18
  19. 19. Каковы плюсы тестирования на основе моделей? • Разработка моделей подталкивает к скрупулезному анализу проекта (многие ошибки выявляются еще на фазе проектирования) • MBT достаточно легко позволяет распараллеливать выполнение тестов (легко загрузить кластер) • Достаточно просто строить рандомизированные тесты • Поддерживать и сопровождать большую систему MBT проще традиционных пакетов регрессионных тестов • Трудоемкость разработки MBT тестов в большом проекте меньше по сравнению с традиционными технологиями 19
  20. 20. «НЕТЕХНИЧЕСКИЕ» ПРОБЛЕМЫ Минусы тестирования на основе моделей 20
  21. 21. «Медленный старт» • Тесты только после модели – Недели и месяцы работы без видимой отдачи – «Дублирование кода» – Отсутствие документации. «Читайте код, там всѐ написано» – Модификации в коде. Незафиксированные интерфейсы! • «Где ошибки?» – Разработка модели должна начинаться на этапе проектирования – Ко-верификация – Непонятная модель 21
  22. 22. Проблема планирования • Выбор уровня качества – MBT – недешевая активность – Анализ и выбор возможностей – Постановка бизнес-целей • «Они нас отвлекают!» vs «Молчат как партизаны!» – Построение политики взаимодействия спецификаторов и программистов – Построение процесса разработки – Выделение ресурсов 22
  23. 23. Сложность обучения • «… и много других страшных слов» – иерархический расширенный конечный автомат, пред- и постусловия, темпоральная логика, алгебра термов, переписывание, обход автомата, … – В Индии человек с необходимым набором компетенций занимает позицию Research Director в крупной компании • Результат или процесс? – Специалист по MBT и программист мыслят по-разному! – Модель != реализация • Подготовка персонала – Отсутствие подготовки в ВУЗе – Трехдневный тренинг (???) 23
  24. 24. Сложность удержания обученных кадров • Как сохранять мотивацию высокоуровнего тестирования? – Тестировщик – «человек второго сорта» – Относительно легко говорить о мотивации разработчиков инструментов • Важно, чтобы каждый видел перспективу роста: – Варианты карьерного роста в компании – Высокий уровень компетенций – переход в ведущие разработчики, архитекторы, дизайнеры, … • Ограниченность рынка – Большая потребность в специалистах 24
  25. 25. Спасибо!

×