1 Тестирование в гибких технологиях разработки Материалы: E-mail: pta-ipm@yandex.rupta-ipm@yandex.ru. - презентация

1 1 Тестирование в гибких технологиях разработки Материалы:

2 Павловская Т.А. (НИУ ИТМО) 2 Содержание курса 1 Введение. Разработка через тестирование 2 Тестирование в экстремальном программировании и в методологии SCRUM 3 Системы автоматизации тестирования

3 Что должен знать тестировщик ПО Павловская Т.А. (НИУ ИТМО) 3 Тестирование программ можно использовать для того, чтобы показать наличие ошибок, и никогда для того чтобы показать их отсутствие! Эдсгер Дейкстра

4 Литература – 1/3 Р. Савин. Тестирование dot com, или Пособие по жестокому обращению с багами в интернет-стартапах. М.: Дело, с. С. Канер, Д. Фолк, Е. Нгуен. Тестирование программного обеспечения. К.: Диасофт, с. Павловская Т.А. (НИУ ИТМО) 4 Р. Калбертсон, К. Браун, Г. Кобб. Быстрое тестирование. М: Вильямс, С. Макконнелл. Совершенный код. СПб: «Питер», с. Г. Майерс. Искусство тестирования программ. М.: «Финансы и статистика», с.

5 Павловская Т.А. (НИУ ИТМО) 5 Литература – 2/3 Л. Тамре. Введение в тестирование программного обеcпечения M.: «Вильямс», с. Л. Криспин, Дж. Грегори. Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд. М.:Вильямс, с. Г. Майерс. Надежность программного обеспечения. М.: «Мир», с. Б. Бейзер. Тестирование черного ящика. СПб: «Питер», с. Э. Брауде. Технология разработки программного обеспечения. СПб: «Питер», с. С. Орлов. Технологии разработки программного обеспечения. СПб: «Питер», с. Тестирование производительности Web-приложений Microsoft.NET/ Пер. с англ. М.: Издательско-торговый дом Русская Редакция, с.

6 Павловская Т.А. (НИУ ИТМО) 6 Литература – 3/3 И. Винниченко. Автоматизация процессов тестирования. СПб: «Питер», с. К. Бек. Экстремальное программирование. СПб: «Питер», К. Ауэр, Р. Миллер. Экстремальное программирование. СПб: «Питер», с. Д. Бентли. Жемчужины программирования. СПб: «Питер», с. С. Бобровский. Технологии Пентагона на службе российских программистов. СПб: «Питер», с. А. Якобсон, Г. Буч, Д. Рамбо. Унифицированный процесс разработки программного обеспечения. СПб: «Питер», с. Р. Мартин. Чистый код: создание, анализ и рефакторинг. СПб: «Питер», с.

7 Павловская Т.А. (НИУ ИТМО) 7 Ресурсы pta-ipm.narod.ru - – разделы «Тестир-е и «Введ-е в технологии» pta-ipm.narod.ru - «Тестир-е и «Введ-е в технологии» sorlik.ru/swebok-ru/ (SWEBOK - Software Engineering Body of Knowledge) sorlik.ru/swebok-ru/ software-testing.ru – библиотека, статьи, … software-testing.ru wiki.agiledev.ru/doku.php – гибкая разработка и тестирование wiki.agiledev.ru/doku.php ru.wikipedia.org – Тестирование ПО, ISO 9126 ru.wikipedia.org - курсы лекций карта сайта. Смотреть: Термины тестирования ПО; Термины, относящиеся к качеству Метрики кода; Тест Джоэла, … (Б.Майер, 7 принципов тестирования ПО)

8 Павловская Т.А. (НИУ ИТМО) 8 Объекты тестирования Тестировать можно все: работу программы спецификацию качество ее кода и понятность комментариев быстродействие устойчивость под большой нагрузкой расход ресурсов (памяти, диска, потери этих ресурсов) взаимодействие с другими программами стабильность работы возможность работы на других платформах удобство интерфейса документацию к программе (смысловые и грамматические ошибки, понятность и полноту) работу через сеть, работу аппаратного обеспечения и т.п.

9 Важность тестирования Павловская Т.А. (НИУ ИТМО) 9

10 Виды обнаруживаемых ошибок Фирма Hewlett-Packard использовала классификацию Буча, установив процентное соотношение ошибок, обнаруживаемых в ПО на разных стадиях разработки Павловская Т.А. (НИУ ИТМО) 10

11 Павловская Т.А. (НИУ ИТМО) 11 Стоимость ошибки Пример через 40 сек. после запуска ракеты-носителя Ariane 5 произошёл автоподрыв 50-метровой ракеты (оборудование стоило полмиллиарда долларов, не говоря об упущенной выгоде). Причина - некорректный перенос из ПО Ariane 4 в ПО Ariane 5 спецификации программного модуля, выполнявшего преобразование из double в WORD. Ракета Ariane 4 успешно запускалась более 100 раз. Ошибки в ПО - все возможные несоответствия между демонстрируемыми характеристиками его качества и сформулированными или подразумеваемыми требованиями и ожиданиями пользователей.

12 Сложность тестирования Современные методы разработки ПО позволяют создавать системы объемом в десятки млн строк кода (20 лет назад - на уровне десятков тысяч строк). Техники создания тестов за это время увеличили свою масштабируемость лишь примерно на порядок. Расхождение между масштабами систем, которые мы можем создать, и систем, которые мы в состоянии аккуратно проверить, растет. Примеры: MS Word XP 35 тыс. тестов Windows XP более 2 млн. Windows NT 4.0: 800 разработчиков, 700 тестировщиков; Windows 2000: 1400 разработчиков, 1700 тестировщиков. Павловская Т.А. (НИУ ИТМО) 12

13 Павловская Т.А. (НИУ ИТМО) 13 Основная терминология Тестирование – процесс выявления фактов расхождений с требованиями (ошибок). Отладка (debug, debugging) – процесс поиска, локализации и исправления ошибок в программе [IEEE Std ] Как правило, на фазе тестирования осуществляется и исправление идентифицированных ошибок, включающее: локализацию ошибок нахождение причин ошибок корректировку программы. Судить о правильности результатов выполнения программы можно только сравнивая спецификацию функции с результатами ее вычисления. Основная проблема тестирования - определение достаточности множества тестов для истинности вывода о правильности реализации программы, а также нахождения множества тестов, обладающего этим свойством. Validation: did we make the right thing? Verification: did we make the thing right?

14 Павловская Т.А. (НИУ ИТМО) 14 Определения тестирования по стандарту Процесс выполнения ПО системы или компонента при заданных условиях с анализом или записью результатов и оценкой некоторых свойств тестируемого объекта. The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component. Процесс анализа ПО с целью фиксации различий между существующим состоянием ПО и требуемым (что свидетельствует о проявлении ошибки) и оценки свойств тестируемого ПО. The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate features of software items [IEEE Std ]. Контролируемое выполнение программы на конечном множестве тестовых данных и анализ результатов этого выполнения для поиска ошибок [IEEE Std ].

15 Павловская Т.А. (НИУ ИТМО) 15 Статическое и динамическое тестирование Статическое тестирование выявляет неверные конструкции или неверные отношения объектов программы (ошибки формального задания) формальными методами анализа без выполнения тестируемой программы: С помощью специальных инструментов контроля кода Обзоры (Reviews) Инспекции (Inspections) Сквозные просмотры (Walkthroughs) Аудиты (Audits) Тестирование требований, спецификаций, документации. Динамическое тестирование осуществляет выявление ошибок на выполняющейся программе. Тестирование заканчивается, когда выполнилось или "прошло" (pass) успешно достаточное количество тестов в соответствии с выбранным критерием тестирования.

16 Павловская Т.А. (НИУ ИТМО) 16 Критерии качества ПО Внешние характеристики корректность наличие/отсутствие дефектов в спецификации, проекте и реализации практичность легкость изучения и использования эффективность степень использования системных ресурсов надежность способность системы выполнять необходимые функции; интервал между отказами целостность способность предотвращать неавторизованный или некорректный доступ адаптируемость возможность использования в других областях и средах правильность степень безошибочности данных, выдаваемых системой живучесть способность продолжать работу при недопустимых данных или в напряженных условиях Внутренние характеристики удобство сопровождения тестируемость удобочитаемость гибкость портируемость возможность повторного использования понятность

17 Павловская Т.А. (НИУ ИТМО) 17 Источник: С. Макконнелл

18 Павловская Т.А. (НИУ ИТМО) 18 Методики повышения качества ПО Контроль качества – планомерная и систематичная программа действий, призванная гарантировать, что система обладает желательными характеристиками Явное определение целевых характеристик (внутренних и внешних) – эффективная методика Разработка стратегии тестирования. Выполнить задачи оценки и повышения качества только путем тестирования невозможно. Неформальные и формальные технические обзоры инспекция обзор аудит Контроль изменений Оценка результатов выполнения плана контроля качества Прототипирование

19 Павловская Т.А. (НИУ ИТМО) 19 Эффективность методик Методика устранения дефектаMin-max, %Сред., % Неформальные обзоры проекта Формальные инспеции проекта Неформальные обзоры кода Формальные обзоры кода Моделирование или прототипирование Самостоятельная проверка кода Блочное тестирование Тестирование новых функций Интеграционное тестирование Регрессионное тестирование Тестирование системы Ограниченное бета-тестирование (< 10) Масштабное бета-тестирование (> 1000)

20 Павловская Т.А. (НИУ ИТМО) 20 Рекомендуемая комбинация методик Формальные инспекции всех требований, всех аспектов архитектуры и всех проектов критических частей системы Моделирование или прототипирование Чтение или инспекции кода Тестирование выполнения программы

21 Павловская Т.А. (НИУ ИТМО) 21 Главный закон контроля качества ПО Забота о повышении качества системы снижает общие расходы на ее разработку IEEE Std планирование контроля качества IEEE Std методологии метрик качества IEEE Std стандарт обзоров ПО IEEE Std (R1993) стандарт блочного тестирования IEEE Std стандарт документации тестирования ПО

22 Павловская Т.А. (НИУ ИТМО) 22 Capability Maturity Model (CMM) Зрелость процесса разработки ПО – степень его определенности, управляемости, измеряемости и эффективности

23 Павловская Т.А. (НИУ ИТМО) 23 Взаимосвязь наиболее признанных и применяемых в мире стандартов в области разработки программного обеспечения Картинка для устрашения

24 Виды и методы тестирования на разных стадиях разработки ПО

25 Уровни и виды тестирования Модульное тестирование (component testing) Интеграционное тестирование (integration testing) Системное тестирование (system testing) Приемочное тестирование (acceptance testing) – польз-ли smoke testing регрессионное тестирование См. с. 144 Савина.

26 Взаимосвязь разработки и тестирования (V-диаграмма)

27

28 Павловская Т.А. (СПбГУ ИТМО) 28

29 Модульное тестирование (Unit testing) Модульное тестирование - это тестирование программы на уровне отдельно взятых модулей, функций или классов. Цель модульного тестирования состоит в выявлении локализованных в модуле ошибок в реализации алгоритмов, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. Модульное тестирование чаще всего проводится по принципу "белого ящика. Модульное тестирование обычно подразумевает создание вокруг каждого модуля определенной среды

30 Обнаруживаемые ошибки На уровне модульного тестирования проще всего обнаружить дефекты, связанные с алгоритмическими ошибками и ошибками кодирования алгоритмов. Ошибки, связанные с неверной трактовкой данных, некорректной реализацией интерфейсов, совместимостью, производительностью и т.п. обычно выявляются на более поздних стадиях тестирования. (белый и черный ящик)

31 Интеграционное тестирование Интеграционное тестирование (тестирование сборки) - тестирование части системы, состоящей из двух и более модулей. Основная задача - поиск дефектов, связанных с ошибками в реализации и интерпретации взаимодействия между модулями. Так же, как и модульное тестирование, оперирует интерфейсами модулей и подсистем и требует создания тестового окружения Основная разница между модульным и интеграционным тестированием состоит в типах обнаруживаемых дефектов. В частности, на уровне интеграционного тестирования часто применяются методы, связанные с покрытием интерфейсов Интеграционное тестирование использует модель "белого ящика" на модульном уровне.

32 Методы сборки модулей Монолитный, характеризующийся одновременным объединением всех модулей в тестируемый комплекс. Для замены неразработанных к моменту тестирования модулей необходимо дополнительно разрабатывать драйверы (test driver) и/или заглушки (stub) Инкрементальный, характеризующийся помодульным наращиванием комплекса программ с пошаговым тестированием собираемого комплекса. В инкрементальном методе выделяют две стратегии добавления модулей: "Сверху вниз" (нисходящее тестирование) "Снизу вверх" (восходящее тестирование) «Сэндвич»

33 Сравнение методов Монолитное тестирование требует больших трудозатрат, связанных с дополнительной разработкой драйверов и заглушек и со сложностью идентификации ошибок, проявляющихся в пространстве собранного кода. Монолитное тестирование предоставляет большие возможности распараллеливания работ, особенно на начальной фазе тестирования. Пошаговое тестирование связано с меньшей трудоемкостью идентификации ошибок за счет постепенного наращивания объема тестируемого кода и соответственно локализации добавленной области тестируемого кода.

34 Недостатки нисходящего тестирования Проблема разработки достаточно "интеллектуальных" заглушек, т.е. заглушек, способных к использованию при моделировании различных режимов работы комплекса, необходимых для тестирования Сложность организации и разработки среды для реализации исполнения модулей в нужной последовательности Параллельная разработка модулей верхних и нижних уровней приводит к не всегда эффективной реализации модулей из-за подстройки (специализации) еще не тестированных модулей нижних уровней к уже оттестированным модулям верхних уровней

35 Недостатки восходящего тестирования Запаздывание проверки концептуальных особенностей тестируемого комплекса Необходимость в разработке и использовании драйверов

36 Системное тестирование Основная задача системного тестирования - выявление дефектов, связанных с работой системы в целом: отсутствующая или неверная функциональность неверное использование ресурсов системы непредусмотренные комбинации данных пользовательского уровня несовместимость с окружением непредусмотренные сценарии использования неудобство в применении и тому подобное. Системное тестирование производится над проектом в целом с помощью метода «черного ящика».

37 Категории тестов системного тестирования 1. Полнота решения функциональных задач. 2. Тестирование целостности (соответствие документации, комплектность). 3. Проверка инсталляции и конфигурации на разных платформах. 4. Оценка производительности. 5. Стрессовое тестирование - на предельных объемах нагрузки входного потока. 6. Корректность использования ресурсов (утечка памяти, возврат ресурсов). 7. Эффективность защиты от искажения данных и некорректных действий. 8. Корректность документации и т.д. Объемы данных на этом уровне таковы, что обычно более эффективным подходом является полная или частичная автоматизация тестирования

38 Другой пример разделения на категории: Функциональное тестирование (functional testing) Тестирование производительности (performance testing) Стрессовое тестирование (stress testing) Нагрузочное тестирование (load testing) HP LoadRunner Тестирование удобства использования (usability testing) Тестирование интерфейса пользователя (UI testing) Тестирование безопасности (security testing) Тестирование локализации (localization testing) Тестирование совместимости (compatibility testing)

39 Регрессионное тестирование Регрессионное тестирование - цикл тестирования, который производится при внесении изменений на фазе системного тестирования или сопровождения продукта. Главная проблема регрессионного тестирования - выбор между полным и частичным перетестированием и пополнение тестовых наборов. При частичном перетестировании контролируются только те части проекта, которые связаны с измененными компонентами.

40 Исправление дефекта Получив отчет об ошибке, программист анализирует исходный код, находит ошибку, исправляет ее и модульно или интеграционно тестирует результат. В свою очередь тестировщик, проверяя внесенные программистом изменения, должен: Проверить и утвердить исправление ошибки. Для этого необходимо выполнить указанный в отчете тест, с помощью которого была найдена ошибка. Попробовать воспроизвести ошибку каким-нибудь другим способом. Протестировать последствия исправлений. Возможно, что внесенные исправления привнесли ошибку (наведенную ошибку) в код, который до этого исправно работал.

41 Комбинирование уровней тестирования В каждом конкретном проекте должны быть определены задачи, ресурсы и технологии для каждого уровня тестирования. Задача тестировщиков и менеджеров - оптимально распределить ресурсы между тремя уровнями тестирования так, чтобы каждый из возможных типов дефектов был «адресован» (в наборе тестов должны иметься тесты, направленные на выявление дефектов этого типа). Например, перенесение усилий на поиск фиксированного типа дефектов из области системного в область модульного тестирования может существенно снизить сложность и стоимость всего процесса тестирования.

42 Модульное Интеграцион ное Системное Типы дефектов Локальные дефекты Интерфейсные дефекты Отсутствующая функциональность, ошибки совместимости, документации, переносимости, проблемы производительности, инсталляции и т.п. Необходимость в системе тестирования Да Нет * Цена разработки системы тестирования Низкая Низкая до умеренной Умеренная до высокой или неприемлемой Цена процесса тестирования Низкая Высокая

43 Приемочное тестирование Unit Testing Integration Testing System Testing Acceptance Testing Приемочное тестирование (Acceptance testing) - тестирование готового продукта конечными пользователями в реальном окружении. Приемочные тесты разрабатываются пользователями (обычно в виде сценариев).

44 Эвристические методы создания тестов

45 Простейший пример Программа выполняет ввод трех целых чисел и выводит сообщение о том, является ли треугольник с такими сторонами неравносторонним, равнобедренным или равносторонним 1. правильный неравносторонний 2. правильный равносторонний 3. правильный равнобедренный 4. по крайней мере 3 теста, представляющих правильные равнобедренные, полученные как переставновки двух разных сторон 5. длина одной из сторон 0 6. длина одной из сторон

46 Подход к созданию тестов на примере Программа вводит два числа и выводит их сумму. В каждом из чисел 1 или 2 цифры Ввод каждого числа завершается Enter Ввод каждого числа отображается на экране После ввода числе выводится сумма. Программа запускается командой ADDER

47 Первый тест - базовый Проблемы: Ввод запрашивается с помощью знака «?» - ош-ка пр-я: нет сопровод. инф-и, что вводить как остановить что за программа - ош-ка кодир-я: ответ в стороне от исх. дан

48 большое первое может повлиять на интерпр-ю второго и ( каждая цифра встречается 1 раз)

49 Классы тестов Классом можно назвать группу значений, которые программа обрабатывает одним и тем же способом. Граничные значения класса – те входные данные, на которых программа меняет свое поведение Не всегда программа меняет свое поведение там, где предполагается Границу нужно протестировать с двух сторон

50 серия недопустимых значений серия проверки редактирования (стрелки, BS, Del) граничные условия цифра ли: коды от 48 до 57 (мб опечатка 75). границы / (47) 0 9 : (58) Фантазии: Enter + Enter ___2 (пробелы – до и после числа) 1,2 + 5 a + b Ctrl-A + Ctrl-B F1 + esc

51 Характеристики хорошего теста существует обоснованная вероятность выявления тестом ошибок не избыточен тестовый набор дб наилучшим в своей категории не дб слишком простым или слишком сложным Некорректное поведение программы должно проявляться с достаточной очевидностью Дорогие друзья! Взращивайте и лелейте в себе неисправимый пессимизм в отношении идеи о коде, свободном от багов. Смотрите на код как на виртуальную вещь, которая в процессе тестирования послужит еще одним доказательством постулата о несовершенстве мира. (Р. Савин)

52 Классы эквивалентности граничные условия тестирование переходов между состояниями все меню и опции (трудно) => все вероятные последовательности действий пользователей Условия гонок и другие временн Ые зависимости запуск параллельно многих задач нажатие клавиш не вовремя тестирование производительности нагрузочное тестирование прогнозирование ошибок (не явл. границами, но могут вызвать сбой; интуиция) – error-guess testing

53 Виды тестов Базовый тест -- smoke test (простой тестовый пример) Инвентаризация (определить различные категории данных и создать тесты для каждого элемента категории) Комбинированные тесты (скомбинировать различные входные данные) Граничные оценки (оценить поведение программы при граничных значениях данных) Ошибочные данные (оценить отклик системы на ввод неправильных данных) Нагрузочные тесты, создание напряжений (попытаться вывести систему из строя)

54 Из Савина: Методы генерирования тестов: 1. Черновик-чистовик (dirty list-white list); 2. Матричная раскладка (matrices); 3. Блок-схемы (flowchart). Методы отбора тестов: 1. Оценка риска (risk estimate); 2. Эквивалентные классы (equivalent classes); 3. Пограничные значения (boundary values).