SlideShare ist ein Scribd-Unternehmen logo
1 von 28
Метод редукции тестового набора для интеграционного тестирования Д.Ю.Кичигин Научный руководитель: д.ф.-м.н.  А.К.Петренко Институт системного программирования Российской академии наук
*   ANSI/IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Technology. The Institute of Electrical and Electronics Engineers, New York, 1990. Интеграционное тестирование  –  тестирование взаимодействия между интегрируемыми компонентами программного обеспечения. * Регрессионное тестирование  –  повторное тестирование ПО с целью убедиться что внесенные изменения не привели к неожидаемым эффектам.* Особенность регрессионного интеграционного тестирования: Проблема отбора тестов Регрессионное интеграционное тестирование   ПО
Регрессионное интеграционное тестирование   ПО *   ANSI/IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Technology. The Institute of Electrical and Electronics Engineers, New York, 1990. Интеграционное тестирование  –  тестирование взаимодействия между интегрируемыми компонентами программного обеспечения. * Регрессионное тестирование  –  повторное тестирование ПО с целью убедиться что внесенные изменения не привели к неожидаемым эффектам.* Особенность регрессионного интеграционного тестирования: Проблема отбора тестов
Регрессионное интеграционное тестирование   ПО *   ANSI/IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Technology. The Institute of Electrical and Electronics Engineers, New York, 1990. Интеграционное тестирование  –  тестирование взаимодействия между интегрируемыми компонентами программного обеспечения. * Регрессионное тестирование  –  повторное тестирование ПО с целью убедиться что внесенные изменения не привели к неожидаемым эффектам.* Особенность регрессионного интеграционного тестирования: Проблема отбора тестов
Задача редукции набора тестов ,[object Object],[object Object],[object Object],[object Object],[object Object]
Существующие методы ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Цель работы ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Рассматриваемые взаимодействия  и интеграционные ошибки ,[object Object],*  Delamaro, M. E., Maldonado, J. C., and Mathur, A. P., Interface Mutation: an   approach to integration testing, IEEE TSE, Vol. 27, No. 3, March 2001, pp228-247. ,[object Object],[object Object],[object Object],[object Object],F G Некорректные данные Некорректный вывод F G Некорректные данные Некорректный вывод F G Некорректные данные Некорректный вывод Некорректные данные Корректные данные ( a) ( b) ( c)
Предложенный метод редукции ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Модель взаимодействия ,[object Object],fopen fread fread fread fread fwrite fclose fopen fread fread fread fread fread fread fread fread fread fread fwrite fread fread fwrite fclose fopen fread fread fread  fread fwrite fclose fopen  fread fread fread fread  fwrite fclose fopen fread  fread fread fread fwrite  fclose fopen fread fread  fread fread fwrite fclose … FILE* fp = fopen(…); for (int i=0; i<4; i++) { fread(fp,…); } fwrite(fp, …); fclose(fp); … Трасса взаимодействия “ Скользящее окно ”  размера  K   = 4 Модель взаимодействия
Сравнение моделей Теорема :   Выражение (*) есть отношение эквивалентности на множестве моделей взаимодействия Свойства:   Адаптивность для учета значений параметров других типов (*) Учет значений параметров функций: Скалярные номинальные :  eq ( x , y )  =    ( x , y ),  где    - отношение равенства Скалярные числовые: eq ( x , y )  =   ( interval( x ) , interval( y ) )   Указатели:   eq ( x , y )  =  1,  если  x = y = NULL;  либо  x != NULL,  y != NULL Другие типы: eq ( x , y )   ≡   1
Схема работы метода редукции да нет Выбрать следующий тест   t   из исходного набора Построить модель   M  на выбранном тесте  t да да результат  := сокращенный набор нет 1 ) поместить тест  t   в сокращенный набор 2 ) поместить модель в пул моделей нет Модель  M   пуста  ? Есть ли в Пуле моделей модель, эквивалентная  M ? Исходный набор пройден? Сокращенный набор тестов  :=   Пул моделей  :=  
Вычислительная сложность метода ,[object Object],[object Object],B A B B A B B A B B A B B A B C A B C B B   C   B   C Оптимизация: древовидная структура для хранения модели: Сложность алгоритма:   Объем памяти: T   - количество тестов K  -   размер окна N -  кол-во интерфейсных функций ROOT B A B B C A B B A C A B B B C C B Хеш-таблицы, сложность поиска  O  ( log ( N ))
Технологический процесс применения метода Инструмен-тация модулей 1. Первоначальное тестирование:  построение моделей взаимодействия Запуск ПО на исходном  наборе тестов Сбор трасс Построение моделей  Модели  взаимодействий Исходный  набор тестов 2. Регрессионное тестирование:  редукция набора тестов Модели  взаимодействий Список измененных  модулей + Редукция  набора  тестов Сокращенный набор тестов Тестируемое ПО + Фильтрация трасс
Архитектура и схема работы Особенности реализации : -  Возможность адаптации для учета других типов параметров -  Возможность адаптации к различным средам выполнения Объект  тестирования Выполнение объекта Модуль анализа  взаимодействий Модели  взаимодействий Исходный  тестовый набор Трассы  вызовов функций Сокращенный  набор тестов Консоль Экспериментальная  система редукции  набора тестов Классификатор параметров Сенсор
Экспериментальное исследование ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],*  Rothermel,G.,Harrold,M.J.Analyzing regression test selection techniques. IEEE TSE. 22/8. 1996. **  Епифанов Н.А., Методы Реализации Регрессионного Тестирования по Расширенным Тестовым Наборам, Диссертация на соискание учёной степени кандидата технических наук, СПГПУ, 2003.
Точность и полнота -  Интегрируемые модули:  GNU  Ассемблер  v 2.1 7   и стандартная библиотека языка Си -  Взаимодействие через функции ввода / вывода ( stdio.h) 100% в ср. на 52% предложенный метод в ср. 80% метод случайной редукции 100% в ср. на 10% метод редукции пустых трасс Обнаружение ошибок  (от кол-ва обнаруженных исх. н.т.) Сокращение
Универсальность (1) ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Экспериментальная  система редукции  набора тестов Пример :  адаптация метода к строковым параметрам Объект  тестирования Модуль анализа  взаимодействий Модели  взаимодействий Консоль Классификатор параметров Сенсор Шаг 2. Адаптация экспериментальной системы: Шаг 1. Отношение эквивалентности для строк: Реализация отношения эквивалентности для строк
Универсальность  ( 2 ) ,[object Object],[object Object],[object Object],[object Object],0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10 30 50 70 90 110 130 150 170 190 Размер исходного набора % сокращения набора 0% 20% 40% 60% 80% 100% 120% 10 30 50 70 90 110 130 150 170 190 Размер исходного набора % обнаружения ошибок Все в ср. на 79% ,[object Object],в ср. 91% в ср. на 8 8 % ,[object Object],Обнаружение ошибок Сокращение
Эффективность: оценка ресурсозатрат и влияние параметра  K Интегрируемые модули:  GNU  Ассемблер  v 2.18  и стандартная библиотека языка Си Взаимодействие через функции ввода / вывода ( stdio.h) 15.3   12.2   10.6   9.8   9.7   9.6   Объем используемой памяти (в Мб) 6.5 мин   1.2 мин   27 сек   9 сек   5 сек   2 сек   Время работы 100%   100%   100%   100%   99%   92%   Коэфф. обнаружения ошибок 45%   52%   54%   57%   61%   74%   Коэфф. сокращения 15 10 6 3 2 1 Индикатор Длина  K
Экспериментальное исследование на тестовом наборе  LSB Application Battery Исходный набор:  LSB Application Battery v3.1 ,  15  приложений, 81 тест Интегрируемые модули: библиотека  X11  и стандартная библиотека языка Си Эксперимент проводился в среде  SUS Е  Linux v10.2 1 час 47 минут  / 10.8  раз Выигрыш по времени 1 минута Время работы метода 11.8 раз Коэфф. сокращения времени 10 минут 1 час 58 минут Время выполнения 0% Изменение уровня обнаружения 6 6 Кол-во обнаруженных ошибок 9 раз Коэффициент сокращения 9 81 Размер набора   Сокр. набор Исх. набор Индикатор
Данные по программной реализации и проведенным экспериментам ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Основные результаты ,[object Object],[object Object],[object Object],[object Object],[object Object]
Доклады ,[object Object],[object Object],[object Object],[object Object],[object Object]
Публикации ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Спасибо !
Примеры интеграционных ошибок ,[object Object],[object Object],[object Object],Тип ошибки Исходный код Код с добавленной ошибкой A char sz[16]; printf(“%s”, sz); char sz[16]; printf(“% d ”, sz); B char szParam[16]; char szResult[16]; sprintf(“%s”, szResult, szParam); char szParam[16]; char szResult[16]; sprintf(“% d ”, szResult, szParam); C char sz[30]; FILE* fp = fopen( &quot;file.txt&quot;, “r+t&quot; ); … fread( sz, sizeof( char ), 25, fp ); char sz[30]; FILE* fp = fopen( &quot;file.txt&quot;, &quot; w +t&quot; ); … fread( sz, sizeof( char ), 25, fp );
Возможные направления будущих исследований ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]

Weitere ähnliche Inhalte

Was ist angesagt?

Тестирование осень 2013 лекция 2
Тестирование осень 2013 лекция 2Тестирование осень 2013 лекция 2
Тестирование осень 2013 лекция 2Technopark
 
вспомогательные алгоритмы
вспомогательные алгоритмывспомогательные алгоритмы
вспомогательные алгоритмыЕлена Ключева
 
C++ осень 2013 лекция 8
C++ осень 2013 лекция 8C++ осень 2013 лекция 8
C++ осень 2013 лекция 8Technopark
 
Тестирование лекция 2 весна 2014
Тестирование лекция 2 весна 2014Тестирование лекция 2 весна 2014
Тестирование лекция 2 весна 2014Technopark
 
Тестирование весна 2013 лекция 2
Тестирование весна 2013 лекция 2Тестирование весна 2013 лекция 2
Тестирование весна 2013 лекция 2Technopark
 
C++ осень 2013 лекция 4
C++ осень 2013 лекция 4C++ осень 2013 лекция 4
C++ осень 2013 лекция 4Technopark
 
Регрессионное тестирование
Регрессионное тестированиеРегрессионное тестирование
Регрессионное тестированиеMarat Akhin
 
ПРИМЕНЕНИЕ ГЕНЕТИЧЕСКИХ АЛГОРИТМОВ К ГЕНЕРАЦИИ ТЕСТОВ ДЛЯ АВТОМАТНЫХ ПРОГРАММ
ПРИМЕНЕНИЕ ГЕНЕТИЧЕСКИХ АЛГОРИТМОВ К ГЕНЕРАЦИИ ТЕСТОВ ДЛЯ АВТОМАТНЫХ ПРОГРАММПРИМЕНЕНИЕ ГЕНЕТИЧЕСКИХ АЛГОРИТМОВ К ГЕНЕРАЦИИ ТЕСТОВ ДЛЯ АВТОМАТНЫХ ПРОГРАММ
ПРИМЕНЕНИЕ ГЕНЕТИЧЕСКИХ АЛГОРИТМОВ К ГЕНЕРАЦИИ ТЕСТОВ ДЛЯ АВТОМАТНЫХ ПРОГРАММITMO University
 
C++ осень 2013 лекция 7
C++ осень 2013 лекция 7C++ осень 2013 лекция 7
C++ осень 2013 лекция 7Technopark
 
C++ осень 2013 лекция 6
C++ осень 2013 лекция 6C++ осень 2013 лекция 6
C++ осень 2013 лекция 6Technopark
 
апкс 2011 05_verilog
апкс 2011 05_verilogапкс 2011 05_verilog
апкс 2011 05_verilogIrina Hahanova
 
паттерны программирования
паттерны программированияпаттерны программирования
паттерны программированияguestfc8ae0
 
Тест-дизайн в тестировании ПО. Задача "Треугольник"
Тест-дизайн в тестировании ПО. Задача "Треугольник"Тест-дизайн в тестировании ПО. Задача "Треугольник"
Тест-дизайн в тестировании ПО. Задача "Треугольник"OdessaQA
 
тестирование черного и белого ящиков презентация
тестирование черного и белого ящиков презентациятестирование черного и белого ящиков презентация
тестирование черного и белого ящиков презентацияРоман Растопшин
 
C++ осень 2012 лекция 6
C++ осень 2012 лекция 6C++ осень 2012 лекция 6
C++ осень 2012 лекция 6Technopark
 
Метрики кода программного обеспечения
Метрики кода программного обеспеченияМетрики кода программного обеспечения
Метрики кода программного обеспеченияTatyanazaxarova
 
C# Desktop. Занятие 16.
C# Desktop. Занятие 16.C# Desktop. Занятие 16.
C# Desktop. Занятие 16.Igor Shkulipa
 

Was ist angesagt? (20)

Тестирование осень 2013 лекция 2
Тестирование осень 2013 лекция 2Тестирование осень 2013 лекция 2
Тестирование осень 2013 лекция 2
 
вспомогательные алгоритмы
вспомогательные алгоритмывспомогательные алгоритмы
вспомогательные алгоритмы
 
C++ осень 2013 лекция 8
C++ осень 2013 лекция 8C++ осень 2013 лекция 8
C++ осень 2013 лекция 8
 
Тестирование лекция 2 весна 2014
Тестирование лекция 2 весна 2014Тестирование лекция 2 весна 2014
Тестирование лекция 2 весна 2014
 
Тестирование весна 2013 лекция 2
Тестирование весна 2013 лекция 2Тестирование весна 2013 лекция 2
Тестирование весна 2013 лекция 2
 
C++ осень 2013 лекция 4
C++ осень 2013 лекция 4C++ осень 2013 лекция 4
C++ осень 2013 лекция 4
 
лр7
лр7лр7
лр7
 
Регрессионное тестирование
Регрессионное тестированиеРегрессионное тестирование
Регрессионное тестирование
 
ПРИМЕНЕНИЕ ГЕНЕТИЧЕСКИХ АЛГОРИТМОВ К ГЕНЕРАЦИИ ТЕСТОВ ДЛЯ АВТОМАТНЫХ ПРОГРАММ
ПРИМЕНЕНИЕ ГЕНЕТИЧЕСКИХ АЛГОРИТМОВ К ГЕНЕРАЦИИ ТЕСТОВ ДЛЯ АВТОМАТНЫХ ПРОГРАММПРИМЕНЕНИЕ ГЕНЕТИЧЕСКИХ АЛГОРИТМОВ К ГЕНЕРАЦИИ ТЕСТОВ ДЛЯ АВТОМАТНЫХ ПРОГРАММ
ПРИМЕНЕНИЕ ГЕНЕТИЧЕСКИХ АЛГОРИТМОВ К ГЕНЕРАЦИИ ТЕСТОВ ДЛЯ АВТОМАТНЫХ ПРОГРАММ
 
Авиком
АвикомАвиком
Авиком
 
C++ осень 2013 лекция 7
C++ осень 2013 лекция 7C++ осень 2013 лекция 7
C++ осень 2013 лекция 7
 
C++ осень 2013 лекция 6
C++ осень 2013 лекция 6C++ осень 2013 лекция 6
C++ осень 2013 лекция 6
 
апкс 2011 05_verilog
апкс 2011 05_verilogапкс 2011 05_verilog
апкс 2011 05_verilog
 
паттерны программирования
паттерны программированияпаттерны программирования
паттерны программирования
 
Тест-дизайн в тестировании ПО. Задача "Треугольник"
Тест-дизайн в тестировании ПО. Задача "Треугольник"Тест-дизайн в тестировании ПО. Задача "Треугольник"
Тест-дизайн в тестировании ПО. Задача "Треугольник"
 
тестирование черного и белого ящиков презентация
тестирование черного и белого ящиков презентациятестирование черного и белого ящиков презентация
тестирование черного и белого ящиков презентация
 
C++ осень 2012 лекция 6
C++ осень 2012 лекция 6C++ осень 2012 лекция 6
C++ осень 2012 лекция 6
 
10 инф
10 инф10 инф
10 инф
 
Метрики кода программного обеспечения
Метрики кода программного обеспеченияМетрики кода программного обеспечения
Метрики кода программного обеспечения
 
C# Desktop. Занятие 16.
C# Desktop. Занятие 16.C# Desktop. Занятие 16.
C# Desktop. Занятие 16.
 

Ähnlich wie Predzazhita 2009 v16

ВЫБОР ТОЧКИ ВНЕДРЕНИЯ ДЛЯ ФАЗЗИНГА В ПАМЯТИ
ВЫБОР ТОЧКИ ВНЕДРЕНИЯ ДЛЯ ФАЗЗИНГА В ПАМЯТИВЫБОР ТОЧКИ ВНЕДРЕНИЯ ДЛЯ ФАЗЗИНГА В ПАМЯТИ
ВЫБОР ТОЧКИ ВНЕДРЕНИЯ ДЛЯ ФАЗЗИНГА В ПАМЯТИblagodarenko
 
Полнота тестирования ПО
Полнота тестирования ПОПолнота тестирования ПО
Полнота тестирования ПОMarat Akhin
 
ук 03.007.02 2011
ук 03.007.02 2011ук 03.007.02 2011
ук 03.007.02 2011etyumentcev
 
TMPA-2013 Itsykson: Java Program Analysis
TMPA-2013 Itsykson: Java Program AnalysisTMPA-2013 Itsykson: Java Program Analysis
TMPA-2013 Itsykson: Java Program AnalysisIosif Itkin
 
Getting Tested: методология интеграционного тестирования
Getting Tested: методология интеграционного тестированияGetting Tested: методология интеграционного тестирования
Getting Tested: методология интеграционного тестированияAlexander Byndyu
 
По ту сторону ООП: PEAK-Rules и PyProtocols
По ту сторону ООП: PEAK-Rules и PyProtocolsПо ту сторону ООП: PEAK-Rules и PyProtocols
По ту сторону ООП: PEAK-Rules и PyProtocolsSergey Schetinin
 
лабораторная работа № 7
лабораторная работа № 7лабораторная работа № 7
лабораторная работа № 7Gulnaz Shakirova
 
Отладка и оптимизация многопоточных OpenMP-программ
Отладка и оптимизация многопоточных OpenMP-программОтладка и оптимизация многопоточных OpenMP-программ
Отладка и оптимизация многопоточных OpenMP-программTatyanazaxarova
 
Building Open Source Test Automation Frameworks. Watir based automation case ...
Building Open Source Test Automation Frameworks. Watir based automation case ...Building Open Source Test Automation Frameworks. Watir based automation case ...
Building Open Source Test Automation Frameworks. Watir based automation case ...Aliaksandr Ikhelis
 
Программное обеспечение для автоматизации испытаний сложных программно-аппара...
Программное обеспечение для автоматизации испытаний сложных программно-аппара...Программное обеспечение для автоматизации испытаний сложных программно-аппара...
Программное обеспечение для автоматизации испытаний сложных программно-аппара...SQALab
 
Алексей Баранцев -- Какое дело тестировщикам до исходного кода?
Алексей Баранцев -- Какое дело тестировщикам до исходного кода?Алексей Баранцев -- Какое дело тестировщикам до исходного кода?
Алексей Баранцев -- Какое дело тестировщикам до исходного кода?sqadays8
 
Практические аспекты нагрузочного тестирования
Практические аспекты нагрузочного тестированияПрактические аспекты нагрузочного тестирования
Практические аспекты нагрузочного тестированияAlexey Kachalin
 
Опыт разработки сложных клиент-серверных приложений на TypeScript и ASP.NET
Опыт разработки сложных клиент-серверных приложений на TypeScript и ASP.NETОпыт разработки сложных клиент-серверных приложений на TypeScript и ASP.NET
Опыт разработки сложных клиент-серверных приложений на TypeScript и ASP.NETGoSharp
 
Современный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтерыСовременный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтерыcorehard_by
 
Sqadays 8-barancev
Sqadays 8-barancevSqadays 8-barancev
Sqadays 8-barancevAlexei Lupan
 
Реклама PVS-Studio - статический анализ кода на языке Си и Си++
Реклама PVS-Studio - статический анализ кода на языке Си и Си++Реклама PVS-Studio - статический анализ кода на языке Си и Си++
Реклама PVS-Studio - статический анализ кода на языке Си и Си++Andrey Karpov
 

Ähnlich wie Predzazhita 2009 v16 (20)

пр 15.docx
пр 15.docxпр 15.docx
пр 15.docx
 
ВЫБОР ТОЧКИ ВНЕДРЕНИЯ ДЛЯ ФАЗЗИНГА В ПАМЯТИ
ВЫБОР ТОЧКИ ВНЕДРЕНИЯ ДЛЯ ФАЗЗИНГА В ПАМЯТИВЫБОР ТОЧКИ ВНЕДРЕНИЯ ДЛЯ ФАЗЗИНГА В ПАМЯТИ
ВЫБОР ТОЧКИ ВНЕДРЕНИЯ ДЛЯ ФАЗЗИНГА В ПАМЯТИ
 
прак 15.docx
прак 15.docxпрак 15.docx
прак 15.docx
 
Полнота тестирования ПО
Полнота тестирования ПОПолнота тестирования ПО
Полнота тестирования ПО
 
Test design print
Test design printTest design print
Test design print
 
ук 03.007.02 2011
ук 03.007.02 2011ук 03.007.02 2011
ук 03.007.02 2011
 
TMPA-2013 Itsykson: Java Program Analysis
TMPA-2013 Itsykson: Java Program AnalysisTMPA-2013 Itsykson: Java Program Analysis
TMPA-2013 Itsykson: Java Program Analysis
 
Getting Tested: методология интеграционного тестирования
Getting Tested: методология интеграционного тестированияGetting Tested: методология интеграционного тестирования
Getting Tested: методология интеграционного тестирования
 
По ту сторону ООП: PEAK-Rules и PyProtocols
По ту сторону ООП: PEAK-Rules и PyProtocolsПо ту сторону ООП: PEAK-Rules и PyProtocols
По ту сторону ООП: PEAK-Rules и PyProtocols
 
лабораторная работа № 7
лабораторная работа № 7лабораторная работа № 7
лабораторная работа № 7
 
Отладка и оптимизация многопоточных OpenMP-программ
Отладка и оптимизация многопоточных OpenMP-программОтладка и оптимизация многопоточных OpenMP-программ
Отладка и оптимизация многопоточных OpenMP-программ
 
Building Open Source Test Automation Frameworks. Watir based automation case ...
Building Open Source Test Automation Frameworks. Watir based automation case ...Building Open Source Test Automation Frameworks. Watir based automation case ...
Building Open Source Test Automation Frameworks. Watir based automation case ...
 
Программное обеспечение для автоматизации испытаний сложных программно-аппара...
Программное обеспечение для автоматизации испытаний сложных программно-аппара...Программное обеспечение для автоматизации испытаний сложных программно-аппара...
Программное обеспечение для автоматизации испытаний сложных программно-аппара...
 
Алексей Баранцев -- Какое дело тестировщикам до исходного кода?
Алексей Баранцев -- Какое дело тестировщикам до исходного кода?Алексей Баранцев -- Какое дело тестировщикам до исходного кода?
Алексей Баранцев -- Какое дело тестировщикам до исходного кода?
 
Практические аспекты нагрузочного тестирования
Практические аспекты нагрузочного тестированияПрактические аспекты нагрузочного тестирования
Практические аспекты нагрузочного тестирования
 
Опыт разработки сложных клиент-серверных приложений на TypeScript и ASP.NET
Опыт разработки сложных клиент-серверных приложений на TypeScript и ASP.NETОпыт разработки сложных клиент-серверных приложений на TypeScript и ASP.NET
Опыт разработки сложных клиент-серверных приложений на TypeScript и ASP.NET
 
Современный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтерыСовременный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтеры
 
Sqadays 8-barancev
Sqadays 8-barancevSqadays 8-barancev
Sqadays 8-barancev
 
Tbb лр1
Tbb   лр1Tbb   лр1
Tbb лр1
 
Реклама PVS-Studio - статический анализ кода на языке Си и Си++
Реклама PVS-Studio - статический анализ кода на языке Си и Си++Реклама PVS-Studio - статический анализ кода на языке Си и Си++
Реклама PVS-Studio - статический анализ кода на языке Си и Си++
 

Predzazhita 2009 v16

  • 1. Метод редукции тестового набора для интеграционного тестирования Д.Ю.Кичигин Научный руководитель: д.ф.-м.н. А.К.Петренко Институт системного программирования Российской академии наук
  • 2. * ANSI/IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Technology. The Institute of Electrical and Electronics Engineers, New York, 1990. Интеграционное тестирование – тестирование взаимодействия между интегрируемыми компонентами программного обеспечения. * Регрессионное тестирование – повторное тестирование ПО с целью убедиться что внесенные изменения не привели к неожидаемым эффектам.* Особенность регрессионного интеграционного тестирования: Проблема отбора тестов Регрессионное интеграционное тестирование ПО
  • 3. Регрессионное интеграционное тестирование ПО * ANSI/IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Technology. The Institute of Electrical and Electronics Engineers, New York, 1990. Интеграционное тестирование – тестирование взаимодействия между интегрируемыми компонентами программного обеспечения. * Регрессионное тестирование – повторное тестирование ПО с целью убедиться что внесенные изменения не привели к неожидаемым эффектам.* Особенность регрессионного интеграционного тестирования: Проблема отбора тестов
  • 4. Регрессионное интеграционное тестирование ПО * ANSI/IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Technology. The Institute of Electrical and Electronics Engineers, New York, 1990. Интеграционное тестирование – тестирование взаимодействия между интегрируемыми компонентами программного обеспечения. * Регрессионное тестирование – повторное тестирование ПО с целью убедиться что внесенные изменения не привели к неожидаемым эффектам.* Особенность регрессионного интеграционного тестирования: Проблема отбора тестов
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11. Сравнение моделей Теорема : Выражение (*) есть отношение эквивалентности на множестве моделей взаимодействия Свойства: Адаптивность для учета значений параметров других типов (*) Учет значений параметров функций: Скалярные номинальные : eq ( x , y ) =  ( x , y ), где  - отношение равенства Скалярные числовые: eq ( x , y ) =  ( interval( x ) , interval( y ) ) Указатели: eq ( x , y ) = 1, если x = y = NULL; либо x != NULL, y != NULL Другие типы: eq ( x , y ) ≡ 1
  • 12. Схема работы метода редукции да нет Выбрать следующий тест t из исходного набора Построить модель M на выбранном тесте t да да результат := сокращенный набор нет 1 ) поместить тест t в сокращенный набор 2 ) поместить модель в пул моделей нет Модель M пуста ? Есть ли в Пуле моделей модель, эквивалентная M ? Исходный набор пройден? Сокращенный набор тестов :=  Пул моделей := 
  • 13.
  • 14. Технологический процесс применения метода Инструмен-тация модулей 1. Первоначальное тестирование: построение моделей взаимодействия Запуск ПО на исходном наборе тестов Сбор трасс Построение моделей Модели взаимодействий Исходный набор тестов 2. Регрессионное тестирование: редукция набора тестов Модели взаимодействий Список измененных модулей + Редукция набора тестов Сокращенный набор тестов Тестируемое ПО + Фильтрация трасс
  • 15. Архитектура и схема работы Особенности реализации : - Возможность адаптации для учета других типов параметров - Возможность адаптации к различным средам выполнения Объект тестирования Выполнение объекта Модуль анализа взаимодействий Модели взаимодействий Исходный тестовый набор Трассы вызовов функций Сокращенный набор тестов Консоль Экспериментальная система редукции набора тестов Классификатор параметров Сенсор
  • 16.
  • 17. Точность и полнота - Интегрируемые модули: GNU Ассемблер v 2.1 7 и стандартная библиотека языка Си - Взаимодействие через функции ввода / вывода ( stdio.h) 100% в ср. на 52% предложенный метод в ср. 80% метод случайной редукции 100% в ср. на 10% метод редукции пустых трасс Обнаружение ошибок (от кол-ва обнаруженных исх. н.т.) Сокращение
  • 18.
  • 19.
  • 20. Эффективность: оценка ресурсозатрат и влияние параметра K Интегрируемые модули: GNU Ассемблер v 2.18 и стандартная библиотека языка Си Взаимодействие через функции ввода / вывода ( stdio.h) 15.3 12.2 10.6 9.8 9.7 9.6 Объем используемой памяти (в Мб) 6.5 мин 1.2 мин 27 сек 9 сек 5 сек 2 сек Время работы 100% 100% 100% 100% 99% 92% Коэфф. обнаружения ошибок 45% 52% 54% 57% 61% 74% Коэфф. сокращения 15 10 6 3 2 1 Индикатор Длина K
  • 21. Экспериментальное исследование на тестовом наборе LSB Application Battery Исходный набор: LSB Application Battery v3.1 , 15 приложений, 81 тест Интегрируемые модули: библиотека X11 и стандартная библиотека языка Си Эксперимент проводился в среде SUS Е Linux v10.2 1 час 47 минут / 10.8 раз Выигрыш по времени 1 минута Время работы метода 11.8 раз Коэфф. сокращения времени 10 минут 1 час 58 минут Время выполнения 0% Изменение уровня обнаружения 6 6 Кол-во обнаруженных ошибок 9 раз Коэффициент сокращения 9 81 Размер набора Сокр. набор Исх. набор Индикатор
  • 22.
  • 23.
  • 24.
  • 25.
  • 27.
  • 28.

Hinweis der Redaktion

  1. Здравствуйте. Меня зовут Кичигин Дмитрий, я работаю под научным руководством Александра Константиновича Петренко, тема моей работы называется «Метод редукции тестового набора для интеграционного тестирования».
  2. Областью моего исследования является регрессионное интеграционное тестирование программного обеспечения. Начну с определений: Интеграционное тестирование – тестирование взаимодействия между интегрируемыми компонентами программного и / или аппаратного обеспечения. Регрессионное тестирование – повторное тестирование системы или компонента с целью убедиться что внесенные изменения не привели к неожидаемым эффектам, и что система или компонент продолжает удовлетворять своей спецификации. Заметим, что основным отличием регрессионного тестирования от тестирования, проводящегося во время разработки ПО, является наличие существующего набора тестов. Также заметим, что п ри переходе к интеграционному тестированию предполагается, что модульное тестирование, в основном, завершено. Это позволяет сфокусироваться на ошибках взаимодействия модулей. Поэтому д ля проведения интеграционного тестирования используются специализированные интеграционные тесты, целью которых является проверка взаимодействия модулей. Разработка таких тестов является достаточно дорогой процедурой и если при разработке ПО от нее никуда не деться, то на этапе сопровождения, для проведения регрессионного интеграционного тестирования, можно воспользоваться существующим набором тестов, изначально созданным для модульного или системного тестирования. Такой подход позволяет сэкономить ресурсы, однако является неэффективным : так как используемые в этом случае регрессионные тесты не создавались специально для интеграционного тестирования, на практике только часть таких запускаемых тестов тестирует взаимодействие между интегрируемыми модулями, а оставшаяся часть тестов работает «вхолостую», лишь потребляя ресурсы. Например, &lt; обращаясь к диаграмме &gt; допустим у нас есть ПО с несколькими модулями и изображенными связями между ними... &lt; следующий слайд &gt; ...где изменился один модуль... &lt; следующий слайд &gt; ... В этом случае для нас важны тесты, которые затрагивают взаимодействия с измененным модулем, т.е. лишь 4 взаимодействия из 8-ми. Вследствие этого возникает проблема отбора тестов для регрессионного тестирования таким образом, чтобы запускать только те тесты, которые проверяют взаимодействия между измененными модулями Заметим, что в случае современного программного обеспечения, нужно уметь работать и с текстовыми и с объектными модулями. Причем объектные модули вносят определенные сложности, такие как отсутствие исходного текста, но возможность работы с ними является важной. Мы учтем этот момент далее в презентации.
  3. ...где изменился один модуль...
  4. ... &lt; заканчивая пример &gt; ... В этом случае для нас важны тесты, которые затрагивают взаимодействия с измененным модулем, т.е. лишь 4 взаимодействия из 8-ми. Вследствие этого возникает проблема отбора тестов для регрессионного тестирования таким образом, чтобы запускать только те тесты, которые проверяют взаимодействия между измененными модулями Заметим, что в случае современного программного обеспечения, нужно уметь работать и с текстовыми и с объектными модулями. Причем объектные модули вносят определенные сложности, такие как отсутствие исходного текста, но возможность работы с ними является важной. Мы учтем этот момент далее в презентации.
  5. Для решения проблемы отбора тестов используется подход, известный как редукция набора тестов, и заключающийся в выборе из исходного набора подмножества тестов, специально фокусирующегося на тестировании межмодульных взаимодействий. Редукция набора тестов ставит своей целью отбор набора тестов меньшего размера для тестирования выбранного взаимодействия между модулями, но при этом, желательно, с такой же, как и у исходного набора тестов, способностью обнаруживать интеграционные ошибки в выбранном взаимодействии. В контексте рассматриваемой задачи такая редукция позволяет: Отобрать тесты, концентрирующиеся на тестировании нужных взаимодействий Вследствие этого, уменьшить затраты на проведение регрессионого интеграционного тестирования.
  6. Существующие методы редукции набора тестов используют метрики покрытия и заключаются в построении тестового набора меньшего размера, но эквивалентного исходному в терминах выбранной метрики . Заметим, что метрики покрытия делятся на 2 группы: основанные на спецификациях и на внутреннем устройстве программы , которые являются взаимодополняющими подходами. В данной работе рассматриваются метрик и основанные на внутреннем устройстве программы . Существующие методы проводят предварительный статический анализ исходного текста программы, затем инструментирование и динамический анализ выполнения программы на наборе тестов для сбора информации о достигнутом покрытии, по результатам которого происходит редукция набора тестов. За счет этого, они позволяют хорошо сокращать наборы тестов, но обладают рядом существенных недостатков, ограничивающих их использование для современного программного ообеспечения, характеризующегося большим объемом и гетерогенностью внутреннего устройства, включая использование разнообразных языков программирования, внутренних компонент и сред выполнения: Во первых, они непрактичны для использования для программного обеспечения большого объема. Инструментирование исходного кода большого количества модулей, есть очень сложная и затратная процедура. Во вторых, невозможность применения для тестирования бинарных компонент. Примером таких компонент являются повторно используемые программные компоненты, которые разрабатываются независимыми разработчиками и поставляются без исходного кода в бинарном виде. Такие компоненты являются все более популярными при разработке современного ПО, и поэтому указанное ограничение является серьезным. Во третьих, опять вследствие применения анализа исходного кода, существующие методы сильно зависимы от конкретного языка программирования, и, также, сильно зависимы от среды выполнения и операционного окружения. «повышенные требования к адаптивности к различным языкам программирования и технологической простоте применения на разных платформах / средах» Вследствие этого, существующие методы, использующие метрики основанные на внутреннем устройстве программы, оказываются неадекватны требованиям задачи редукции набора тестов для интеграционного тестирования современного программного обеспечения. Это обстоятельство делает актуальной разработку новых методов, способных работать без доступа к исходному коду ПО, что обусловило цель данной работы, а именно -&gt; переход к следующему слайду
  7. а именно - &gt; далее по тексту слайда Заметим, что в качестве полигона для экспериментов были выбраны системы, реализованные на языке С. Это было обусловлено широкой распространенностью таких систем и тем, что много важных, иногда критичных по безопасности систем написаны на С. Такой выбор существенно ограничил технические возможности реализации метода, так как современные ОО языки и средства их поддержки могли бы дать дополнительные возможности для реализации метода, тем не менее аспект практической вожности систем был определяющим при выборе полигона для реализации и экспериментов.
  8. Перед описанием метода определим класс рассматриваемых взаимодействий и опишем используемое понятие интеграционной ошибки. В данной работе рассматриваются межмодульные взаимодействия удовлетворяющие следующим условиям: 1. Во-первых, рассматриваются попарные взаимодействия модулей типа “ вызывающий / вызываемый ”; 2. Во-вторых, взаимодействия осуществляются только через интерфейс функций, общих данных нет ; 3. И, наконец, взаимодействия осуществляются синхронно в одном потоке / процессе . Для обзора интеграционных ошибок воспользуемся классификацией предложенной в работе Delamaro . Данная классификация основывается на определении интеграционной ошибки как ошибки возникающей при передаче некорректного значения между модулями. Выделяются три типа ошибок: (Ошибка 1 типа) Во время вызова модуля G из модуля F , в модуль G передаются некорректные значения, что приводит к ошибке в этом модуле; (Ошибка 2 типа) В модуль G передаются некорректные значения, в результате модуль G также возвращает набор некорректных значений, которые приводят к ошибке в модуле F; (Ошибка 3 типа) В модуль G передаются корректные значения, но из G возвращаются некорректные значения, которые приводят к ошибке в модуле F после выхода из G . Заметим, что в данной классификации не предусматривается случай, когда в модуль G поступают корректные значения, но дефект в G приводит к ошибке до возвращения из G . В этом случае ошибка не является интеграционной, т.к. не связана с взаимодействием между F и G , и должна была быть обнаружена на предыдущем этапе модульного тестирования.
  9. В результате проведенной работы был предложен новый метод редукции набора тестов. Ключевым отличием данного метода редукции от методов, реализующих традиционный подход, является отсутствие этапа статического анализа исходного кода программного обеспечения. За счет этого метод не требует доступа к исходному коду интегрируемых модулей ПО. В остальном метод использует некоторые идеи существующих методов, и состоит из двух этапов: На первом этапе производится запуск ПО на наборе тестов и сбор информации о покрытии точек взаимодействия между интегрируемыми модулями. На втором этапе, исходя из собранной информации, осуществляется редукция набора тестов. Для проведения редукции используется эвристический алгоритм минимизации исходного набора тестов. Данный алгоритм базируется на предположении, что, если покрытие точек взаимодействия между интегрируемыми модулями на двух тестах одинаково, то возможности этих тестов по выявлению интеграционных ошибок между модулями также одинаковы. В частности, если тесты вообще не задействуют точки взаимодействия между модулями, то такие тесты не представляют пользы при тестировании взаимодействия. Метод основан на этих предположениях и состоит в «отсеивании» тех тестов, которые создают эквивалентные покрытия точек взаимодействия модулей. Описание метода состоит из трех частей: вначале мы опишем модель процесса взаимодействия, используемую для анализа покрытия точек взаимодействия; затем опишем способ сравнения моделей, который необходим для проведения редукции; в конце опишем алгоритм редукции, использующий модели взаимодействия и предложенный способ сравнения моделей для принятия решения какой тест следует «отсеять» из исходного тестового набора, а какой – нет.
  10. В качестве точек взаимодействия принимаются интерфейсные функции интегрируемых модулей. Для описания модели введем несколько определений: Интерфейсной функцией называется функция, входящая в состав программного интерфейса модуля. Трассой взаимодействия между двумя модулями на тесте t называется последовательность вызовов интерфейсных функций вызываемого модуля при выполнении программного обеспечения на тесте t . Последовательностью функций длины K называется любая последовательность следующих друг за другом вызовов длины K , встречающаяся в трассе взаимодействия. Используя эти определения, модель поведения взаимодействия определяется как множество последовательностей вызовов интерфейсных функций длины К , выполненных во время тестирования взаимодействия. На данном рисунке представлен пример построения модели, для чего используется техника «скользящего окна». &lt; Далее по рисунку &gt; Замечание: в следствие ограниченности места на данном рисунке вызовы функций представлены только их именами. Тем не менее, при работе метода вызовы функций также включают значения переданных параметров .
  11. В качестве способа сравнения моделей взаимодействия было предложено отношение, учитывающее значения параметров функций, переданных во время выполнения тестируемой программы на тесте, и определяемое с помощью формулы &lt; на слайде &gt; . Для данного выражения была сформулирована и доказана теорема о том, что оно является отношением эквивалентности, а именно, удовлетворяет свойствам рефлексивности, симметричности и транзитивности, в дальнейшем используемым в алгоритме редукции. Данная формула означает, что: Модели эквивалентны тогда и только тогда, когда эквивалентны множества последовательностей и, соответственно, сами последовательности вызовов функций Последовательности эквивалентны тогда и только тогда, попарно эквивалентны элементы, т.е. вызовы функций, которые эквивалентны, когда Совпадают имена функций Значения параметров эквивалентны В качестве отношений эквивалентности для значений параметров функций используются следующие отношения &lt; на слайде &gt; . Важным достоинством предложенного отношения эквивалентности является его адаптивность: оно позволяет задавать любые способы учета значений параметров интерфейсных функций, которые могут быть представлены в виде отношения эквивалентности. В частности, предложенное отношение эквивалентности можно использовать и для того, чтобы различать другие (т.е. не скалярные и не-указатели) типы параметров функций.
  12. Алгоритм редукции заключается в последовательном переборе тестов из исходного набора, для каждого из которых принимается решение поместить данный тест в сокращенный набор или нет, и состоит из следующих шагов: На первом шаге выбирается очередной тест из исходного набора и на нем запускается тестируемое программное обеспечение. Во время работы программного обеспечения происходит сбор трассы взаимодействия интегрируемых модулей и построение модели их взаимодействия. Если построенная модель оказывается пустой, то это означает, что на данном тесте интегрируемые модули не взаимодействовали и, в таком случае, данный тест пропускается (не помещается в сокращенный набор тестов) и алгоритм возвращается к первому шагу. В противном случае, если построенная модель не пуста, то происходит ее сравнение с моделями, построенными на предыдущих итерациях алгоритма. В случае если обнаруживается модель, построенная на одном из предыдущих шагов и эквивалентная текущей модели, то это означает, что текущий тест повторяет один из предыдущих тестов в тестировании взаимодействия между модулями и, следовательно, также пропускается. Если же, наоборот, среди моделей, построенных на предыдущих шагах, не находится модели эквивалентной текущей, то такой тест заносится в сокращенный набор. После этого алгоритм возвращается к первому шагу. Когда исходный набор оказывается пройденным, алгоритм завершает свою работу и сокращенный тестовый набор считается построенным.
  13. Описанный выше алгоритм редукции обладает вычислительной сложностью, максимальная оценка которой составляет &lt; по слайду &gt; где: T - количество тестов; K – длина последовательности интерфейсных функций; N - количество интерфейсных функций. При этом максимальный объем памяти, используемой для хранения модели в памяти компьютера, составляет &lt; по слайду &gt; . Для улучшения этих показателей была проведена оптимизация метода, заключающаяся в том, что табличное представление модели взаимодействия было заменено древовидным, при котором модель взаимодействия представляется в форме дерева, где каждой последовательности вызовов интерфейсных функций соответствует путь в дереве от корня до одного из листовых узлов. Такое представление позволило уменьшить сложность алгоритма примерно в N в степени K раз до &lt; указать на слайде &gt; , а максимальный объем используемой памяти примерно в К раз до &lt; указать на слайде &gt; .
  14. Процесс регрессионного тестирования с использованием предложенного метода состоит из следующих этапов: На первом этапе осуществляется сбор трасс взаимодействий во время первоначального тестирования программного обеспечения на полном наборе тестов. Для сбора трасс учитываются вызовы всех интерфейсных функций всех модулей программного обеспечения. На втором этапе, перед регрессионным тестированием взаимодействий измененных модулей, происходит редукция набора тестов которая состоит из следующих шагов: Сначала происходит фильтрация трасс чтобы оставить только вызовы функций измененных модулей. Эта фильтрация производится инженером, проводящим тестирование, на основе списка измененных модулей &lt; и модулей, вызываемых измененными &gt; . После этого проводится редукция исходного набора тестов. Во время проведения редукции, метод редукции осуществляет построение моделей взаимодействия, и использует их для сокращения исходного набора тестов; Замечание (не произносится, на случай вопросов) . Описанная методика регрессионного тестирования с применением предложенного метода редукции подразумевает участие инженера, в задачи которого входит определение интерфейсов измененных, либо вызываемых измененными модулями, модулей программного обеспечения и фильтрация трасс взаимодействий перед использованием метода редукции. Также в задачи инженера входит экспертная оценка анализируемых интерфейсов на предмет того, насколько отношения эквивалентности между значениями параметров, используемые в методе редукции, отражают фактическую логику использования значений параметров интерфейсных функций и, в случае необходимости, настройка метода редукции для анализа взаимодействий через такие интерфейсы. Таким образом, в случае, если по оценкам инженера, существующие отношения эквивалентности являются неадекватными конкретным интерфейсам, то может быть принято решении об использовании специализированных отношений эквивалентности. Напомним, что метод достаточно легко адаптируем для использования специальных отношений эквивалентности. Например, как было показано в предыдущем разделе для строковых параметров, хоть и представляющихся в языке Си в виде указателей, использование специализированного отношения эквивалентности может давать лучшие результаты.
  15. Архитектура и схема работы экспериментальной системы редукции набора тестов выглядит следующим образом &lt; слайд &gt; . Система состоит из следующих компонент: Сенсор / Классификатор параметров в задачи которого входят: Регистрация вызовов интерфейсных функций во время работы программного обеспечения на тесте. Для этого используется механизм функций-оберток, предоставляемый линкером ld входящим в состав пакета Binutils ; Классификация параметров функций по классам эквивалентности согласно отношению эквивалентности, определенному в предложенном методе редукции; Результатом работы модуля является файл, содержащий трассу взаимодействий, который затем поставляется на вход модулю анализа взаимодействий. Модуль анализа взаимодействий - компонента, производящая анализ трасс взаимодействий, построение моделей взаимодействий и построение сокращенного набора тестов; Управляющая консоль - приложение Microsoft Windows ® позволяющая пользователю в визуальном режиме производить редукцию набора тестов. Работа экспериментальной системы состоит из следующих этапов: На первом этапе происходит запуск объекта тестирования на исходном тестовом наборе и сбор трасс взаимодействия интегрируемых модулей; После этого, трассы взаимодействия направляются на вход модулю анализа взаимодействий; Модуль анализа взаимодействий считывает трассы взаимодействий, строит модели взаимодействий соответствующие тестам из исходного набора тестов, и, в процессе обработки трасс, производит редукцию набора тестов. Можно не говорить : Нужно заметить, что реализация модуля анализа взаимодействий собирать трассы взаимодействий интегрируемых модулей за один проход, во время первоначального тестированияпрограммного обеспечения на исходном наборе тестов. При регрессионном интеграционном тестировании достаточно часто встречается ситуация, когда меняется не один, а сразу несколько модулей, что требует проверки нескольких разных взаимодействий между модулями. В этом случае, возможность единовременного сбора трасс взаимодействий на полном наборе тестов позволяет значительно сократить издержки при построении регрессионных наборов для последующих регрессионных тестирований разных взаимодействий.
  16. &lt; Начать свежим голосом &gt; Для оценки основных характеристик метода и его сравнения с методами случайной редукции и редукции пустых трасс была проведена серия экспериментов. Основными характеристиками, по которым осуществляется анализ методов редукции, являются полнота, точность, эффективность и универсальность: Полнота отражает меру отбора тестов, способных обнаруживать ошибки, появившиеся после модификации программного обеспечения. Т.е. Те на которых результат выполнения изменённой программы отличен от результата выполнения исходной программы. Метод, полный на 100%, называется безопасным. Точность измеряет способность метода избегать выбора тестов, неспособных обнаруживать ошибки. Точный метод отбирает только те тесты, на которых результат выполнения измененной программы отличается от результата выполнения первоначальной программы. Чем менее точен метод, тем больше лишних тестов выбрано и тем ближе объём выбранного набора к объёму исходного набора тестов. Эффективность отражает оценку вычислительных затрат на работу метода редукции. Для оценки затрат в основном используется объем используемой памяти и время работы метода. Универсальность отражает способность метода к применению в широком диапазоне ситуаций, встречающихся на практике. Для проведения экспериментов было выбрано взаимодействие между GNU Assembler и стандартной библиотекой языка Си, осуществляемое через подмножество функций библиотеки, реализующих операции ввода/вывода и объявленных в файле stdio . h . Использовались версии ассемблера GNU Assembler 2.17 и 2.18. В качестве существующего набора регрессионных тестов был взят набор, входящий в состав GNU Assembler .
  17. Для измерения и оценки точности и полноты предложенного метода, и его сравнения с методами случайной редукции и редукции пустых трасс, использовались к оэффициент сокращения набора и коэффициент обнаружения ошибок. Предложенный метод оказался более точным чем метод редукции пустых трасс: коэффициент сокращения набора для предложенного метода в среднем составил 52 %, что на 42% выше аналогичного показателя для метода редукции пустых трасс. В то же время, хотя предложенный метод и не является безопасным, тем не менее, метод обнаружил все ошибки, обнаруживаемые исходным набором тестов, что совпало с результатом для метода редукции пустых трасс и на 20% превысило результат метода случайной редукции. Таким образом, результаты показали что предложенный метод не уступил методам случайной редукции и редукции пустых трасс, а по совокупности характеристик и превзошел их.
  18. Для оценки универсальности метода был проведен эксперимент, проверяющий адаптируемость метода для учета параметров других типов данных (т.е. не скалярных и не указателей). Напомним, для адаптации метода для учета значений параметров других типов данных необходимо предложить отношение эквивалентности для таких параметров, и встроить его в отношение эквивалентности между моделями. Сам метод при этом менять не надо. Для проведения эксперимента в качестве примера выбран строковый тип параметров и была построена модификация метода, где в дополнение к скалярным параметрам и указателям также учитывались значения строковых параметров. Адаптация метода включала два шага: 1. Было предложено отношение эквивалентности между строками, определенное как отношение равенства между их длинами. Заметим, задание отношения экивалентности экивалентно разбитию множества значений на непересекающиеся классы эквивалентности. 2. Модификация экспериментальной системы. Для учета нового отношения эквивалентсности достаточно поменять лишь один компонент, а именно классификатор параметров. Данный классификатор отображает значения параметров в классы эквивалентности согласно предложенному отношению эквивалентности. После таких шагов мы получаем новую систему, которая в дополнение к скалярным параметрам и указателям учитывает значения строковых параметров.
  19. Для сравнения характеристик метода до и после адаптации была проведена серия экспериментов, где тестировалось взаимодействие, большинство функций которого содержало строковые параметры. Результаты данного эксперимента подтвердили хорошую адаптируемость метода. В результате проведения адаптации коэффициент обнаружения ошибок значительно повысился и составил 100%, т.е. сокращенные тестовые наборы обнаруживали столько же ошибок, сколько и исходные наборы. В то же время коэффициент сокращения наборов тестов уменьшился, что является ожидаемым результатом, так как, вследствие учета значений дополнительных типов параметров, адаптированный метод способен лучше различать процессы взаимодействия, и, поэтому, размеры построенных им наборов оказываются не меньше, чем размеры наборов, построенных оригинальным методом.
  20. Третья серия экспериментов была направлена на оценку эффективности метода: оценку затрат ресурсов и на оценку влияния длины последовательности интерфейсных функций K на работу метода. Длина последовательностей интерфейсных функций K является важным параметром предложенного метода редукции: бОльшая длина последовательностей повышает полноту (способность обнаруживать ошибки), но уменьшает точность метода (метод отсеивает меньше лишних вариантов). Меньшая длина последовательностей, соответственно, уменьшает полноту, но повышает точность. Также большая длина последовательности увеличивает затраты ресурсов. На слайде приводятся результаты сравнения характеристик различных модификаций метода, со значениями K , равными 1,2,3,6,10, и 15. Результаты эксперимента подтвердили зависимость точности, полноты и ресурсозатрат от параметра K : большие значения увеличивают полноту, уменьшают точность и увеличивают затраты. Результаты показали, что при значениях K больше 6, таких как 10 и 15, использование метода становится непрактичным: значительно возрастают временные затраты на проведение редукции, что, однако, не приводит к увеличению уровня обнаружения ошибок, так как коэффициент обнаружения ошибок уже достиг 100%. Также было замечено, что для тестируемых программ коэффициент обнаружения ошибок достигает 100% уже при К = 3, однако бОльшие значения K , такие как 6, добавляют «запас прочности» методу при незначительном увеличении затрат ресурсов.
  21. Результаты предыдущих экспериментов показали что метод может успешно использоваться на реальном ПО и показывать неплохие результаты. Однако в предыдущих экспериментах не рассматривался вопрос какой выигрыш в потреблении ресурсов дает применение метода. Это обуславливалось в частности тем что выполнение исходного тестового набора происходило достаточно быстро и занимало примерно 5-7 минут. Чтобы ответить на этот вопрос было проведено экспериментальное исследование метода на тестовом наборе LSB Application Battery v3.1, который представляет собой коллекцию из 15 общеиспользуемых приложений. Проведение тестирования с помощью этого набора занимает около 2 часов. При проведении исследования, в дополнение к основным характеристикам, также был оценен выигрыш временных затрат, который дает применение метода. Для эксперимента использовалось взаимодействие между библиотекой X 11 и стандартной библиотекой. Эксперимент проводился в SUS Е Linux v10.2 . Результаты эксперимента подтвердили высокую практическую ценность метода: в результате работы метода было достигнуто сокращение исходного тестового набора в 9 раз, что привело к сокращению времени тестирования в 11.8 раз (до 10 минут). Затраты на работу метода редукции составили 1 минуту, таким образом суммарная экономия времени от использования метода редукции составила 1 час 47 минут или 10.7 раз от времени тестирования с помощью исходного набора тестов. При этом способность тестового набора обнаруживать ошибки не уменьшилась: сокращенный тестовый набор обнаруживал столько же ошибок, сколько и исходный тестовый набор.
  22. На данном слайде представлены данные по проведенной работе &lt; далее по слайду &gt; АП: количественные характеристики затрат нужно показать более выпукло: Код такого-то типа Вспомогательные библиотеки *** Организация хранилища *** - и так далее Трудоемкость по разработке инфраструктуры - трудоемкость проведения экспериментов
  23. В результате работы &lt; далее по слайду &gt; Разработанный метод редукции тестового набора значительно расширяет область применения методов редукции наборов тестов, делая их применимыми при регрессионном тестировании взаимодействий с участием готовых программных компонент, поставляемых без исходного кода. Проведенное экспериментальное исследование предложенного метода на наборе тестов, использующихся для тестирования индустриального программного обеспечения показало, что метод обеспечивает существенное сокращение размеров тестового набора без потери качества тестирования.
  24. По теме работы были сделаны следующие доклады включая: Доклад на международной конференции PSI’09 в Новосибирске Доклад на секции Software Testing международной конференции SYRCoSE 2007 3 доклада на научном семинаре Института Системного Программирования Доклад на научном семинаре университета Loughborough
  25. Также были опубликованы 4 работы, включая: Публикация в журнале РАН «Программирование» входящая в список ВАК Публикации в результате докладов на конференциях PSI и SYRCoSE И публикация в с борнике трудов Института Системного Программирования
  26. На этом доклад закончен. Спасибо за внимание. Готов ответить на ваши вопросы.
  27. Concerning the last example (error type C). We look at the call of fread function in isolated way, i.e. not taking into account the previous call to fopen function. In this case we see that we passed correct parameters to fread [as a spec for this function we take MSDN2001, where there are no words saying that fp should be opened for reading or for writing], but the function behaved incorrectly. That’s why we classify this case as of an error type C.