Александр Петренко, ИСП РАН Профессор, доктор физико-математических наук, заведующий отделом технологий программирования Института системного программирования (ИСП РАН), профессор ВМК МГУ. Основные работы в областях: формализация требований, генерация тестов на основе формализованных требований и формальных моделей (model based testing – MBT). Приложения: тестирование операционных систем и распределенных систем, тестирование компиляторов, верификация дизайна микропроцессоров, формализация стандартов на API операционных систем и телекоммуникационных протоколов. Сопредседатель оргкомитетов International MBT workshop (http://www.mbrworkshop.org/), Spring Young Researcher Colloquium on Software Engineering – SYRCoSE (http://syrocose.ispras.ru), городского семинара по технологиям разработки и анализа программ ТРАП/SDAT (http://sdat.ispras.ru/). Тема доклада Модели в профессиональной инженерии и тестировании программ. Тезисы Model Based Software Engineering (MBSE) является расширением подхода к разработке программ на основе моделей. В MBSE в отличие, например, от MDA (Model Driver Architecture) существенное внимание уделяется не только задачам собственно проектирования и разработки кода, но и задачам других фаз жизненного цикла – анализу требований, верификации и валидации, управлению требованиями на всех фазах жизненного цикла. Model Based Testing (MBT) хронологически возник гораздо раньше, чем MBSE и MDA, однако его место в разработке программ в полной мере раскрылось вместе с развитием MBSE. По этой причине MBT и MBSE следует рассматривать в тесной связке. В докладе будут рассмотрены концепции MBSE-MDA-MBT, основные источники и виды моделей, которые используются в этих подходах, методы генерации тестов на основе моделей, известные инструменты для

1. Модели в профессиональной инженерии
и тестировании программ
Д.ф.-м.н., Александр Константинович ПЕТРЕНКО,
Заведующий отделом Технологий программирования ИСП РАН
petrenko@ispras.ru
http://ispras.ru/~petrenko
YaC, 19 сентября 2011 года

2. MBT – Model Based Testing.
Где это используется?
Участники Число докладов
Встроенные и real-time (Siemens и 6
др.)
Microsoft 5
Телеком (Nokia, Ericsson, Alcatel- 5
Lucent, Siemens)
Стандартизация 3
Information systems (SAP и др.) 2 2

3. История возникновения моего
интереса к этой теме
• 1974-1984 – разработка системного ПО, в частности,
для космических программ
• 1985-1993 – разработка и тестирование компилятора
для кораблей типа «Буран»
• 1994 – автоматизация тестирования ОС, компиляторы,
телеком. протоколы, микропроцессоры,
математические функции (Nortel, Microsoft, Intel,
Daimler Chrysler, Motorola, Linux Foundation, Nokia,
Google, Вымпелком, НИИСИ, МЦСТ, ГосНИИАС,
«Русские Системы»)
3

4. Протестировать компилятор
• 1974-1984 – разработка системного ПО, в частности, для космических программ
• 1985-1993 – разработка и тестирование компилятора
для кораблей типа «Буран»
• 1994 – автоматизация тестирования ОС, компиляторы, телеком. протоколы,
микропроцессоры, математические функции (Nortel, Microsoft, Intel, Daimler
Chrysler, Motorola, Linux Foundation, Nokia, Google, Вымпелком, НИИСИ, МЦСТ,
ГосНИИАС, «Русские Системы»)
Пусть надо протестировать компилятор:
-Что надо проверить и каковы критерии корректности?
-Когда надо остановиться?
- Как сэкономить – писать минимум и получать максимум?
4

5. Задача – спроектировать набор
тестов для программного модуля
Структура реализации - граф control flow.
Задача генератора тестов - перебор путей теста по структуре control flow
в реализации
Подход практические не применим
к большим системам, к компиляторам,
в частности.
5

6. Протестировать компилятор (2)
• 1974-1984 – разработка системного ПО, в частности, для космических программ
• 1985-1993 – разработка и тестирование компилятора
для кораблей типа «Буран»
• 1994 – автоматизация тестирования ОС, компиляторы, телеком. протоколы,
микропроцессоры, математические функции (Nortel, Microsoft, Intel, Daimler
Chrysler, Motorola, Linux Foundation, Nokia, Google, Вымпелком, НИИСИ, МЦСТ,
ГосНИИАС, «Русские Системы»)
Предложенный ответ:
-Что надо проверить? -Описать формальную модель целевого языка
(синтаксис и семантику)
- Когда остановиться? - Проверить все конструкции и альтернативы в этих моделях
- Как сэкономить - Вручную написать собственно модель и генератор
покрытия конструкций и альтернатив
6

7. Протестировать компилятор (3)
Модель - грамматика:
<assign> ::= <id> “:=” <expr>
<expr> ::= <intexp> | <boolexp>

8. Протестировать компилятор (4).
Перебор путей теста по грамматике
1.
<assign> ::= <id> “:=” <expr>
<expr> ::= <intexp> | <boolexp>
2.
<assign> ::= <id> “:=” <expr>
<expr> ::= <intexp> | <boolexp>

9. Протестировать операционную систему
• 1974-1984 – разработка системного ПО, в частности, для космических программ
• 1985-1993 – разработка и тестирование компилятора для кораблей типа «Буран»
• 1994 – автоматизация тестирования ОС, компиляторы,
телеком. протоколы, микропроцессоры, математические функции (Nortel,
Microsoft, Intel, Daimler Chrysler, Motorola, Linux Foundation, Nokia, Google,
Вымпелком, НИИСИ, МЦСТ, ГосНИИАС, «Русские Системы»)
?????????????????????:
-Что можно использовать в качестве моделей для тестирования
операционных систем, протоколов, ….. ?
- Что нужно извлекать из моделей для построения теста?
9

10. Виды моделей программ
op2
FSM / State1 Грамматика
op1
FA op2 State 2
<assign> ::= <id> “:=” <expr>
op3
op3 <expr> ::= <intexp> | <boolexp>
State 3
State op3
4
op3 Программный контракт
class ArrayList { public virtual void
Insert(int index , object value)
MSC 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]};
SDL ensures Forall{int i in index : old(Count);
old(this[i]) == this[i + 1]};
{...}
10

11. Какие задачи помогают решать
модели?
• Уточнение понимания (требований, проекта/дизайна,
критериев корректности, угроз, рисков, источников
проблем)
• В тестировании:
– систематический перебор входных данных/тестовых
воздействий
– Проблемы создания генератора ожидаемых результатов;
альтернатива – генератор оракулов
– оценка полноты проверки
• поведения внешней среды (по модели окружения)
• поведения системы (модель реализации и/или модель потока
результатов)
11

12. Процесс тестирования на основе моделей
Подпроцесс Требования
Подпроцесс
верификации реализации
Фаза 1
Модели, например, Дизайн
программный архитектуры и Проектная
контракт интерфейсов документация
Фаза 2
Разработка
Модель окружения, тестовой Реализация Реализация
модель тестовых системы (исходный код)
воздействий
Фаза 3
Анализ
Bug reports результатов Error free software
тестирования

13. Тестирование на основе моделей
Генератор
воздействий
12%
36%
87%
57%
Критерий Метрика
полноты покрытия
Тестируемая
система
Модель Модель
Модель состояния Тестовый
поведения + оракул
состояния оракул
09.10.2011 13

14. Виды
моделей-систем-задач тестирования
Модель Целевая система Задача тестирования
Граф control-flow СУБД Генерация тестовых данных
Граф data-flow База данных Генерация тестовых воздействий
Конечный автомат (FSM), Компилятор Оценка корректности реализации
система переходов (LTS)
Программный контракт Библиотека функций Оценка полноты тестового покрытия
Система аксиом, Реактивная система Связка реализации и моделей
темпоральные
спецификации (CTL/LTL)
Сеть Петри Телеком. протокол Транспорт и хранение воздействий и
реакций
MSC (Sequence diagram) Модель Распараллеливание тестов, re-play,
микропроцессора контрольные точки
14
… … …

15. Инструменты MBT в практике
• Авионика:
– SCADE (Esterel Technologies)
– Rhapsody (i-Logic / IBM)
• Телеком: Rational Tau (Telelogic / IBM)
• Общего назначения:
– SpecExplorer (Microsoft Research),
– Test Design (Conformiq),
– UniTESK (ИСПРАН)
– Code Contract (Microsoft Research)
15

16. Унифицированный язык
тестирования – TTCN-3
• Происхождение - Телеком
• Основные игроки:
– Европейские программы стандартизации в областях:
• Автомобилестроение, авионика, здравоохранение
• IBM (Telelogic/Rational tools)
• WWW.OMG.ORG Open Management Group
– UML Testing Profile (UTP)
MBT?
В основе концепции лежит модель теста,
но не модель целевой системы
16

17. Пример большого проекта:
MS Interoperability Initiative
• 2002 год.
• Требование US Department of Justice Европейской
комиссии к Microsoft:
– Опубликовать документацию достаточную для использования
сторонними разработчиками для создания клиентских и
серверных программ.
• => Microsoft Interoperability Initiative
– 60,000 страниц API документации.
– > 50,000 дефектов.
– Размер команды > 200 специалистов, срок > 4-х лет.
• Основной инструмент - SpecExplorer
17

18. MS Interoperability Initiative
18

19. MS Interoperability Initiative
19

20. ПРИМЕРЫ ИНСТРУМЕНТОВ
20

21. SCADE (Esterel Technologies)
21

22. TAU(Telelogic/IBM)
• SDL/UML модель поведения
• MSC (UML sequence diagram)
модель поведения теста
• TTCN-3 (UML Testing Profile - UTP)
модель архитектуры теста
22

23. SpecExplorer (Microsoft)
• Программный контракт
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]};
{...}
23

24. QTRONIC / Test Design (Conformiq)
24

25. UniTESK (ИСПРАН)
• CTESK (UniTESK для C)
• JavaTESK (UniTESK для Java)
• C++TESK, MicroTESK (для микропроцессоров)
25

26. UniTESK (ИСПРАН)
Пример спецификации в JavaTESK (программный контракт):
specification int withdraw(int sum) {
pre { return sum > 0; }
post {
if (balance > 0)
mark "Withdrawal from account with positive balance";
else if (balance == 0)
mark "Withdrawal from empty account";
else
mark "Withdrawal from account with negative balance";
if(balance < sum - maximumCredit)
{
branch TooLargeSum;
return balance == pre balance && withdraw == 0 ;
}
else
{
branch Normal;
return balance == pre balance – sum && withdraw == sum ;
}}} 26

27. Отчет о покрытии
27

28. Как сгенерировать последовательность
вызовов операций?
Пример спецификации в JavaTESK:
op2
specification int withdraw(int sum) {
pre { return sum > 0; } State1
post { op1
if (balance > 0)
mark "Withdrawal from account with positive State 2
balance";
op2
else if (balance == 0)
mark "Withdrawal from empty account"; op3
else
mark "Withdrawal from account with negative op3
balance";
if(balance < sum - maximumCredit)
{
branch TooLargeSum; State 3
return balance == pre balance && withdraw == 0 ;
op3
} State 4
else
{
branch Normal; op3
return balance == pre balance – sum && withdraw ==
sum ;
}}} 28

29. Пример отчета.
Граф обхода конечного автомата
29

30. Пример спецификации с использованием
библиотеки CodeContract
(Microsoft Research)
using System;
using System.Diagnostics .Contracts;
…
class Math
{
public static double Sqrt ( double x )
{
Contract.Requires( x > 0 );
Contract.Ensures (
Contract.Result<double>()*Contract.Result<double>() == x);
...
}
}
30

31. Обсуждение.
Где полезно применение MBT?
31

32. Спасибо!
А.К.Петренко
petrenko@ispras.ru
http://ispras.ru/~petrenko
32

33. Запасные слайды
33

34. MS Interoperability Initiative
34

35. Соотношение MBT и MBSE
MBT - Model Based Testing
• Тестирование на основе моделей – это
часть общего подхода MBSE
MBSE – Model Based Software (Systems)
Engineering
35

36. ПРИМЕРЫ MBSE КОМПЛЕКСОВ
36

37. Boeing OSEE
Open System Engineering Environment is
an integrated, extensible tool environment
for large engineering projects
 Разработан Boeing для поддержки разработки системы
управления полетом Apache Attack Helicopter
 Разрабатывается с 2004 года
 С 2007 года опубликован под Eclipse Public License как проект
Eclipse Foundation

38. TOPCASED