Технические и «нетехнические» проблемы автоматизации тестирования

Пакулин Николай Витальевич,Петренко Александр Константинович,

Институт системного программирования РАН (ИСП РАН)www.ispras.ru

http://ispras.ru/ru/se

TMPA, Кострома, 2013

«Автоматизация тестирования» и«Тестирование на основе моделей» (MBT)

• Что общего?• В чем разница?• Что думают классики?

2

Bob Binder. Автор Testing Object-Oriented

Software

Любое автоматизированное тестирование это тестирование на основе моделей

Примеры моделей в 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

Венский метод Vienna Development Method – VDM (1)

Шаг 0-ой: объявление сорт-типов и определение сигнатур операций

Шаг 1-ый: структуры данных и спецификации для каждой операции

(имплицитные и эксплицитные),

доказательство корректности спецификаций

. . .

Шаг i-й: модификация сигнатур и структур данных и расширение

спецификаций предыдущего шага, доказательство корректности и

согласованности с предыдущим шагом.

В конце возможна трансляция в код на языке программирования.

Операционная семантика языка программирования, синтез

программ 4

Модели

Идея

Код

Венский метод Vienna Development Method – VDM (2)

Имея имплицитную спецификацию <pre-Op, post-Op> и эксплицитную спецификацию Op нужно доказывать, что

" Input pre-Op(input) => post-Op(input, Op(input))

Это надо доказывать на каждом уровне детализации.

5

Венский метод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

Модельное пространство

Реализационное пространство

Функция абстракции

• Пред-условия абстрактного уровня (далее будем говорить модели и использовать суффикс _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

Постановка задачи верификации. Модель и реализация заданы явно

В этом случае для доказательства соответствия нужно убедиться, что для каждой уточненной функции: • Пред-условия модели функции не слабее пред-условий

реализации

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

Постановка задачи верификации. Модель неявная, реализация явная

Требуется показать соответствие на тестовых примерах : 

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

Постановка задачи верификации при помощи тестирования на основе

моделей

Общая схема генерации тестов в UniTESK и SpecExplorer

10

Критерий полноты

Модель поведенияСтруктуры

данных

ИнвариантыПред- и

постусловия

Операции и события

Варианты исполнения

Виды состояний

Модель состояния

Обходчик автоматов

Оракулы

Виды параметров

ГенераторИтераторы

данных

Описание автомата

ДействияСостояния

Метрика покрытия

Тестируемая система

Генерация тестовой последовательности на

лету

Предусловия

Постусловия

Примеры приложений 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

SCADE (Esterel Technologies) Диаграмма последовательностей (IBM/Rhapsody)

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

13

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

14

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

15

Правила безопасного программирования(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

Ближайшие перспективы

• Освоение больших вычислительных мощностей для решения задач верификации

• Комбинация различных подходов к анализу программ, включая техники на основе provers и solvers

18

Каковы плюсы тестирования на основе моделей?

• Разработка моделей подталкивает к скрупулезному анализу проекта (многие ошибки выявляются еще на фазе проектирования)

• MBT достаточно легко позволяет распараллеливать выполнение тестов (легко загрузить кластер)

• Достаточно просто строить рандомизированные тесты • Поддерживать и сопровождать большую систему MBT

проще традиционных пакетов регрессионных тестов• Трудоемкость разработки MBT тестов в большом проекте

меньше по сравнению с традиционными технологиями

19

«НЕТЕХНИЧЕСКИЕ» ПРОБЛЕМЫ

Минусы тестирования на основе моделей

20

«Медленный старт»

• Тесты только после модели– Недели и месяцы работы без видимой отдачи– «Дублирование кода»– Отсутствие документации. «Читайте код, там всё

написано»– Модификации в коде. Незафиксированные интерфейсы!

• «Где ошибки?»– Разработка модели должна начинаться на этапе

проектирования– Ко-верификация– Непонятная модель

21

Проблема планирования

• Выбор уровня качества– MBT – недешевая активность– Анализ и выбор возможностей– Постановка бизнес-целей

• «Они нас отвлекают!» vs «Молчат как партизаны!»– Построение политики взаимодействия спецификаторов и

программистов– Построение процесса разработки– Выделение ресурсов

22

Сложность обучения

• «… и много других страшных слов»– иерархический расширенный конечный автомат, пред- и

постусловия, темпоральная логика, алгебра термов, переписывание, обход автомата, …

– В Индии человек с необходимым набором компетенций занимает позицию Research Director в крупной компании

• Результат или процесс?– Специалист по MBT и программист мыслят по-разному!– Модель != реализация

• Подготовка персонала– Отсутствие подготовки в ВУЗе– Трехдневный тренинг (???)

23

Сложность удержания обученных кадров

• Как сохранять мотивацию высокоуровнего тестирования?– Тестировщик – «человек второго сорта»– Относительно легко говорить о мотивации разработчиков

инструментов

• Важно, чтобы каждый видел перспективу роста:– Варианты карьерного роста в компании– Высокий уровень компетенций – переход в ведущие

разработчики, архитекторы, дизайнеры, …

• Ограниченность рынка– Большая потребность в специалистах

24

Спасибо!