2. Содержание
Занятие 2. Тестирование в течение жизненного
цикла разработки ПО.
1. Модели жизненного цикла разработки ПО.
2. Уровни тестирования.
3. Типы тестирования.
4. Тестирование в период сопровождения.
2
Профессиональный тестировщик, Июнь
2019 г.
4. 1. Модели жизненного цикла разработки ПО (1 из 15)
Профессиональный тестировщик, Июнь
2019 г.
4
Жизненный цикл программного обеспечения (ПО) – процессы,
происходящие в течении периода времени, который начинается с
появления общей концепции ПО и заканчивается если ПО
окончательно выведено из эксплуатации [IEC 61508].
Проектирование
Анализ требований
Разработка
Тестирование
Техническая
поддержка
5. 1. Модели жизненного цикла разработки ПО (2 из 15)
Профессиональный тестировщик, Июнь
2019 г.
5
Модель жизненного цикла – структура
процессов и видов деятельности, связанных с
жизненным циклом, которые могут быть
организованы по этапам, которая также
служит общим ориентиром для общения и
понимания [ISO/IEC 12207].
Процессы жизненного цикла ПО описаны в
стандарте ISO/IEC 12207 System and software
engineering – Software life cycle processes.
Жизненный цикл
Организационные
процессы
Основные
процессы
Вспомогательные
процессы
6. 1. Модели жизненного цикла разработки ПО (3 из 15)
Профессиональный тестировщик, Июнь
2019 г.
6
Классификация моделей жизненного цикла разработки ПО.
Модель
жизненного цикла
разработки ПО
Последовательные
модели
Итерационные
(итеративные)
модели
Инкрементальные
(инкрементные)
модели
7. 1. Модели жизненного цикла разработки ПО (4 из 15)
Профессиональный тестировщик, Июнь
2019 г.
7
Последовательная модель разработки описывает процесс
разработки ПО в качестве линейного, последовательного потока
активностей. Это означает, что любую фазу процесса разработки
следует начинать после того, как предыдущая фаза завершена.
Теоретически фазы не пересекаются друг с другом, но на практике
бывает полезным получать раннюю обратную связь от следующей
фазы. Результатом работы данной модели является ПО, которое
содержит полный набор функциональности, но для его поставки
заказчику уходят месяцы и даже годы разработки.
Модель
жизненного цикла
разработки ПО
Последовательные
модели
Итерационные
(итеративные)
модели
Инкрементальные
(инкрементные)
модели
8. 1. Модели жизненного цикла разработки ПО (5 из 15)
Профессиональный тестировщик, Июнь
2019 г.
8
Итерационная разработка используется в случае, когда
разрабатываемый функционал должен быть определен,
спроектирован, построен и протестирован в течение нескольких
этапов, зачастую с фиксированной продолжительностью каждого из
них. На выходе каждой итерации получается рабочий программный
продукт, который, по сути, является растущим набором общего
функционала, и продолжается это до тех пор, пока не будет выпущена
финальная версия этого продукта или разработка не будет
остановлена.
Модель
жизненного цикла
разработки ПО
Последовательные
модели
Итерационные
(итеративные)
модели
Инкрементальные
(инкрементные)
модели
9. 1. Модели жизненного цикла разработки ПО (6 из 15)
Профессиональный тестировщик, Июнь
2019 г.
9
Инкрементальная разработка подразумевает определение
требований, дизайн, сборку и тестирование системы по частям. Это
приводит к тому, что функциональность ПО растет постепенно. Размер
таких функциональных приращений разнится в большую или меньшую
сторону в зависимости от выбранных методов работы. Приращение
функциональности может включать всего одно изменение в
пользовательском интерфейсе или новую опцию запроса.
Модель
жизненного цикла
разработки ПО
Последовательные
модели
Итерационные
(итеративные)
модели
Инкрементальные
(инкрементные)
модели
10. 1. Модели жизненного цикла разработки ПО (7 из 15)
Профессиональный тестировщик, Июнь
2019 г.
10
Источник: https://habr.com/ru/company/edison/blog/269789/
11. 1. Модели жизненного цикла разработки ПО (8 из 15)
Профессиональный тестировщик, Июнь
2019 г.
11
Методология разработки ПО – совокупность методов,
применяемых на различных стадиях жизненного цикла ПО и имеющих
общий философский подход. Представляет собой структурированный
подход к разработке ПО.
Модель Методология Фреймворк
Каскадная (водопадная) Agile (семейство методологий) Scrum
Каскадная модель с
промежуточным контролем
(водоворот)
RUP (Rational Unified Process) -
рациональный унифицированный
процесс
MSF (Microsoft Solutions
Framework)
Итеративная и
Инкрементальная
RAD (Rapid Application Development) -
быстрая разработка приложений
SAFe (Scaled Agile
Framework)
V - модель XP (eXtreme Programming) -
экстремальная разработка
LeSS (Large-Scale Scrum)
Спиральная Канбан (метод)
12. 1. Модели жизненного цикла разработки ПО (9 из 15)
Профессиональный тестировщик, Июнь
2019 г.
12
Каскадная модель разработки ПО (водопадная)
Ройс Винстон
(1970)
13. 1. Модели жизненного цикла разработки ПО (10 из 15)
Профессиональный тестировщик, Июнь
2019 г.
13
Каскадная модель разработки ПО (водопадная)
Достоинства Недостатки
Последовательное выполнение этапов проекта в
строгом фиксированном порядке.
Низкая гибкость в управлении проектом.
Позволяет оценивать качество продукта на
каждом этапе.
Тестирование начинается только с середины
развития проекта.
Стабильность требований в течение всего
жизненного цикла разработки.
Невозможность динамического изменения
требований во всем жизненном цикле.
На каждой стадии формируется законченный
набор проектной документации.
Интеграция всех полученных результатов
происходит внезапно в завершающей стадии
работы модели.
Определенность и понятность шагов модели и
простота её применения.
Отсутствие обратных связей между этапами.
Четкое планирование сроков и затрат. До завершения процесса разработки нельзя
убедиться, качествен ли продукт.
14. 1. Модели жизненного цикла разработки ПО (11 из 15)
Профессиональный тестировщик, Июнь
2019 г.
14
V – образная модель.
Разновидности: двойная V – модель (VV - модель); расширенная V
– модель (V – модель XT).
(конец 1980-х)
Планирование проекта и
требований
Эксплуатация и
сопровождение
Анализ требований к
продукту
Системное и приемочное
тестирование
Разработка
архитектуры
Интеграционное
тестирование
Детальное
проектирование
Модульное
тестирование
Кодирование
15. 1. Модели жизненного цикла разработки ПО (12 из 15)
Профессиональный тестировщик, Июнь
2019 г.
15
V – образная модель.
Достоинства Недостатки
Модель проста в использовании. Не предусмотрено изменение требований на
разных этапах жизненного цикла.
Строгая последовательность процесса
разработки.
Тестирование требований в жизненном цикле
происходит слишком поздно.
Раннее планирование, направленное на
тестирование продукта.
Модель не учитывает итерации между фазами.
Каждому этапу разработку соответствует
определенный этап тестирования.
В модель не входят действия, направленные на
анализ рисков.
Определяет продукты, которые должны быть
получены в результате разработки.
Длительное время разработки.
Четкое планирование сроков и затрат.
16. 1. Модели жизненного цикла разработки ПО (13 из 15)
Профессиональный тестировщик, Июнь
2019 г.
16
Спиральная модель жизненного цикла ПО.
Барри Боэм
(1988)
17. 1. Модели жизненного цикла разработки ПО (14 из 15)
Профессиональный тестировщик, Июнь
2019 г.
17
Спиральная модель жизненного цикла ПО.
Достоинства Недостатки
Позволяет быстрее показать пользователям
системы работоспособный продукт.
Модель имеет усложненную структуру.
Допускает изменение требований при разработке
ПО.
Большое количество промежуточных циклов
может привести к увеличению документации.
Обеспечивается определение непреодолимых
рисков.
Необходимость в высокопрофессиональных
знаниях для оценки рисков.
В модели предусмотрена возможность гибкого
проектирования.
Спираль может продолжаться до бесконечности.
Позволяет получить более надежную и
устойчивую систему.
Использование модели может оказаться
дорогостоящим.
Разрешает пользователям активно принимать
участие при планировании и разработке.
Постоянные отзывы и реакция заказчика может
провоцировать новые итерации.
18. 1. Модели жизненного цикла разработки ПО (15 из 15)
Профессиональный тестировщик, Июнь
2019 г.
18
Для любой модели жизненного цикла разработки существуют
несколько показателей качественного тестирования:
• Для каждой активности разработки существует соответствующая
активность тестирования.
• У каждого уровня тестирования есть цели, характерные для
данного уровня.
• Анализ и проектирование тестов для определенного уровня
тестирования начинаются на стадии соответствующих активностей
разработки.
• Тестировщики должны участвовать в обсуждениях для
определения и уточнения требований и дизайна, а также
вовлекаться в рецензирование рабочих продуктов, как только будут
доступны первые их черновые версии.
20. 2. Уровни тестирования (1 из 12)
Профессиональный тестировщик, Июнь
2019 г.
20
Уровень тестирования – объединенная и совместно
управляемая группа задач тестирования. Уровни тестирования
связаны с другими активностями в рамках жизненного цикла
разработки. Примерами уровней тестирования могут служить
компонентное тестирование, интеграционное тестирование,
системное тестирование и приёмочное тестирование.
Компонентное тестирование
Интеграционное тестирование
Системное тестирование
Приемочное тестирование
21. 2. Уровни тестирования (2 из 12)
Профессиональный тестировщик, Июнь
2019 г.
21
Компонентное тестирование (также известное как модульное
тестирование) – тестирование отдельных компонентов программного
обеспечения [IEEE 610].
Компонентное
тестирование
Цели уровня Базис уровня
Снижение риска. Детальный дизайн.
Проверка функционала компонентов на
соответствие требованиям.
Код.
Укрепление уверенности в качестве компонента. Модель данных.
Обнаружение дефектов в компоненте. Спецификация компонента.
Предотвращение пропуска дефектов на более
высокие уровни тестирования.
22. 2. Уровни тестирования (3 из 12)
Профессиональный тестировщик, Июнь
2019 г.
22
Компонентное
тестирование
Объекты тестирования Типичные дефекты и отказы
Компоненты, модули. Неправильная работа функциональности.
Код и структуры данных. Проблемы с потоками данных.
Классы. Неправильные код и логика.
Модули баз данных.
Компонентное тестирование обычно выполняется разработчиком,
который написал код, но это как минимум требует доступа к
тестируемому коду. Разработчики могут чередовать разработку
компонентов с обнаружением и устранением дефектов. Разработчики
часто пишут и выполняют тесты после написания кода для
компонента.
23. 2. Уровни тестирования (4 из 12)
Профессиональный тестировщик, Июнь
2019 г.
23
Интеграционное тестирование – тестирование, выполняемое
для обнаружения дефектов в интерфейсах и во взаимодействии
между интегрированными компонентами или системами.
Интеграционное
тестирование
Интеграционное
тестирование
Компонентное
интеграционное
Системное
интеграционное
Компонентное интеграционное тестирование фокусируется на
взаимодействиях и интерфейсах между интегрированными
компонентами. Оно выполняется после компонентного и, как правило,
автоматизируется.
Системное интеграционное тестирование фокусируется на
взаимодействиях и интерфейсах между системами, пакетами и
микросервисами. Может быть выполнено после системного
тестирования или параллельно с системным тестированием.
24. 2. Уровни тестирования (5 из 12)
Профессиональный тестировщик, Июнь
2019 г.
24
Интеграционное
тестирование
Цели уровня Базис уровня
Снижение риска. Дизайн продукта и системы.
Проверка функционала интерфейсов на
соответствие требованиям.
Спецификации интерфейса и протокола связи.
Повышение уверенности в качестве
интерфейсов.
Сценарии использования системы.
Обнаружение дефектов в интерфейсах и
связанных компонентах.
Архитектура на уровне компонентов или
системы.
Предотвращение пропуска дефектов на более
высокие уровни тестирования.
Рабочие процессы.
Спецификации, описывающие внешние
интерфейсы.
25. 2. Уровни тестирования (6 из 12)
Профессиональный тестировщик, Июнь
2019 г.
25
Интеграционное
тестирование
Объекты тестирования Типичные дефекты и отказы
Подсистемы. Некорректные данные и отсутствующие данные.
Базы данных. Неверная последовательность или временные
характеристики обращения к интерфейсам.
Инфраструктура. Несовместимость интерфейсов.
Интерфейсы. Сбои связи между компонентами.
Программные интерфейсы приложения (API). Необработанные или неправильно
обработанные сбои связи между компонентами.
Микросервисы. Неправильные предположения о назначении,
единицах или границах данных, передаваемых
между компонентами.
Компонентное интеграционное тестирование часто является
обязанностью разработчиков. А системное интеграционного
тестирование, как правило, обязанность тестировщиков.
26. 2. Уровни тестирования (7 из 12)
Профессиональный тестировщик, Июнь
2019 г.
26
Системное тестирование – процесс тестирования системы в
целом с целью проверки того, что она соответствует установленным
требованиям.
Системное
тестирование
Цели уровня Базис уровня
Снижение риска. Системные требования и требования к продукту.
Проверка функционала системы на соответствие
требованиям.
Отчеты об анализе рисков.
Проверка, что система реализована полностью и
будет работать, как ожидалось.
Сценарии использования, бизнес-потребности и
пользовательские истории.
Повышение уверенности в качестве системы. Диаграммы состояний.
Обнаружение дефектов. Модели поведения системы.
Предотвращение пропуска дефектов на более
высокие уровни тестирования или среду
эксплуатации.
Системные и пользовательские руководства.
27. 2. Уровни тестирования (8 из 12)
Профессиональный тестировщик, Июнь
2019 г.
27
Системное
тестирование
Объекты тестирования Типичные дефекты и отказы
Приложения. Некорректные вычисления.
Аппаратные / программные системы. Некорректное или неожиданное функциональное
или нефункциональное поведение системы.
Тестируемая система. Некорректное управление и/или передача
данных внутри системы.
Операционные системы. Невозможность правильно и полностью
выполнить задачи конечными пользователями.
Конфигурация системы и конфигурация данных. Неспособность системы работать правильно в
среде эксплуатации.
Неспособность системы работать так, как
описано в руководствах.
Системное тестирование часто проводит независимая группа
тестировщиков.
28. 2. Уровни тестирования (9 из 12)
Профессиональный тестировщик, Июнь
2019 г.
28
Приёмочное тестирование – формальное тестирование по
отношению к потребностям, требованиям и бизнес процессам
пользователя, проводимое с целью определения соответствия
системы критериям приёмки и дать возможность пользователям,
заказчикам или иным авторизированным лицам определить,
принимать систему или нет. [IEEE 610]
Приемочное
тестирование
Приемочное
тестирование
Пользовательское
приемочное
тестирование (UAT)
Альфа-тестирование и
бета-тестирование
Эксплуатационное
приемочное
тестирование (OAT)
Контрактное и
нормативное приемочное
тестирование
Производственные
приемочные
испытания (FAT)Стороннее
приемочное
тестирование (SAT)
29. 2. Уровни тестирования (10 из 12)
Профессиональный тестировщик, Июнь
2019 г.
29
Пользовательское приемочное тестирование обычно
сосредоточено на проверке пригодности использования системы
предполагаемыми пользователями в реальной или моделируемой
рабочей среде.
Эксплуатационное приемочное тестирование обычно выполняется
пользователем и/или сотрудниками с администраторским доступом, в
рабочей среде, фокусируясь на функциональных аспектах.
Контрактное приемочное тестирование проводится в соответствии
с указанными в контракте критериями приемки специализированного
программного обеспечения.
Альфа-тестирование проводится на мощностях компании
разработчика потенциальными или существующими клиентами.
Бета-тестирование проводится потенциальными или
существующими клиентами на их собственных мощностях.
Приемочное
тестирование
30. 2. Уровни тестирования (11 из 12)
Профессиональный тестировщик, Июнь
2019 г.
30
Приемочное
тестирование
Цели уровня Базис уровня
Продемонстрировать уверенность в качестве
системы в целом.
Бизнес-процессы, пользовательские и бизнес-
требования, системные требования.
Проверить, что система завершена и будет
работать как ожидалось.
Нормативы, юридические контракты и
стандарты.
Проверить, соответствует ли функциональное и
нефункциональное поведение системы
установленным проектным требованиям.
Процедуры резервного копирования и
восстановления, процедуры восстановления
после полного отказа системы, процедуры
установки программного обеспечения.
Системная или пользовательская документация.
Сценарии использования системы.
Отчеты анализа риска, целевые показатели
производительности.
Нефункциональные требования.
31. 2. Уровни тестирования (12 из 12)
Профессиональный тестировщик, Июнь
2019 г.
31
Приемочное
тестирование
Объекты тестирования Типичные дефекты и отказы
Тестируемая система. Системные рабочие процессы не отвечают
требованиям пользователей.
Конфигурация системы и конфигурационные
данные.
Бизнес-требования некорректно реализованы.
Бизнес-процессы для полностью
интегрированной системы.
Система не соответствует контрактным и/или
нормативным требованиям.
Операционные и эксплуатационные процессы. Нефункциональные сбои, такие как уязвимости в
системе безопасности, недостаточная
производительность или неправильная работа.
Формы, отчеты.
Существующие и преобразованные
производственные данные.
Приемочное тестирование часто является обязанностью клиентов,
бизнес-пользователей, операторов системы и т.д.
33. Профессиональный тестировщик, Июнь
2019 г.
33
Тип тестирования – это совокупность активностей тестирования,
направленных на тестирование заданных характеристик системы или
ее части, основываясь на конкретных целях. К таким целям можно
отнести следующие:
• Оценку функциональных характеристик качества системы, таких
как полнота, корректность, целесообразность.
• Оценку нефункциональных характеристик качества, таких как
надежность, продуктивность работы, безопасность, совместимость
и удобство использования.
• Оценку правильности, полноты структуры или архитектуры
компонента или системы, их соответствие спецификации.
• Оценку влияния изменений, например, подтверждение того, что
дефекты были исправлены и поиск непреднамеренных изменений в
поведении, вызванных изменениями в ПО.
3. Типы тестирования (1 из 9)
34. Профессиональный тестировщик, Июнь
2019 г.
34
3. Типы тестирования (2 из 9)
Типы
тестирования
по целям
Функциональное
тестирование
Нефункциональное
тестирование
Структурное
тестирование
Тестирование
изменений
35. Профессиональный тестировщик, Июнь
2019 г.
35
Функциональное тестирование – тестирование, основанное на
анализе спецификации функциональности компонента или системы.
Функциональное тестирование системы включает тесты по оценке
функций, которые должна выполнять система. Функции системы дают
ответ на вопрос «что делает система».
Функциональное тестирование рассматривает поведение системы,
поэтому для получения тестовых условий и тестовых сценариев могут
быть использованы техники тестирования методом черного ящика.
Оценить полноту функционального тестирования можно с
использованием покрытия функциональности тестами.
Покрытие функциональности – это мера, с которой конкретный
тип элемента функциональности был охвачен тестами. Уровень
покрытия вычисляется в процентах от общего количества элементов.
3. Типы тестирования (3 из 9) Функциональное
тестирование
36. Профессиональный тестировщик, Июнь
2019 г.
36
Нефункциональное тестирование – тестирование атрибутов
компонента или системы, не относящихся к функциональности, таких
как надежность, эффективность, практичность, сопровождаемость и
переносимость.
Нефункциональное тестирование – это проверка того, «насколько
хорошо работает система».
Вопреки всеобщему заблуждению, нефункциональное
тестирование может и, чаще всего, должно выполняться на всех
уровнях тестирования, и как можно раньше.
Для получения тестовых условий и тестовых сценариев в
нефункциональном тестировании могут использоваться техники
тестирования методом черного ящика.
Проектирование и выполнение нефункциональных тестов
может потребовать специальных навыков и знаний!
3. Типы тестирования (4 из 9) Нефункциональное
тестирование
37. Профессиональный тестировщик, Июнь
2019 г.
37
3. Типы тестирования (5 из 9)
Нефункциональное
тестирование
Тестирование
пользовательского
интерфейса (UI)
Тестирование опыта
взаимодействия (UX)
Тестирование
хранилища
(Storage)
Тестирование
безопасности
(Security)
Операционное
тестирование
(Operational)
Тестирование
конфигурации
(Configuration)
Тестирование
локализации
(Localization)
Тестирование
производительности
(Performance)
Тестирование
восстановления
(Recovery)
Тестирование
совместимости
(Compatibility)
Тестирование
практичности
(Usability)
Нефункциональное
тестирование
38. Профессиональный тестировщик, Июнь
2019 г.
38
Структурное тестирование – тестирование, основанное на
анализе внутренней структуры компонента или системы
(тестирование методом белого ящика). Под внутренней структурой
подразумевается программный код, архитектура, принципы работы
и/или потоки данных внутри системы.
Полноту тестирования методом белого ящика оценивают с
помощью структурного покрытия. Структурное покрытие – это мера,
с которой какой-либо тип структурного элемента был покрыт тестами.
Структурное покрытие измеряется в процентах от общего количества
элементов, охваченного тестами.
Проектирование и выполнение тестирования методом белого
ящика может потребовать специальных навыков и знаний!
3. Типы тестирования (6 из 9) Структурное
тестирование
39. Профессиональный тестировщик, Июнь
2019 г.
39
Тестирование изменений предоставляется для обеспечения
исправления ранее исправленных ошибок и устранения ошибок,
которые могут быть случайно отображены в новой версии. В
соответствии с этими целями существуют два подтипа тестирования,
связанного с изменением: подтверждающее тестирование (повторное
тестирование) и регрессионное тестирование.
3. Типы тестирования (7 из 9)
Тестирование
изменений
Подтверждающее
тестирование
Регрессионное
тестирование
Тестирование
изменений
40. Профессиональный тестировщик, Июнь
2019 г.
40
Подтверждающее тестирование: после того
как дефект исправлен, программное обеспечение
может быть протестировано с использованием
всех тех же тестовых сценариев, которые
завершились с ошибкой из-за найденного
дефекта. Эти тестовые сценарии должны быть
повторно выполнены на новой версии
программного обеспечения. Как минимум, на
новой версии программного обеспечения должны
быть повторно выполнены шаги по
воспроизведению сбоев, вызванных дефектом.
Целью подтверждающего тестирования является
удостоверение в том, что найденный дефект был
исправлен.
3. Типы тестирования (8 из 9) Тестирование
изменений
41. Профессиональный тестировщик, Июнь
2019 г.
41
Регрессионное тестирование: может случиться так, что
изменение, внесенное в одну часть кода, будь то исправление или что-
либо другое, может случайно повлиять на поведение других частей
кода, будь то внутри одного и того же компонента, в других
компонентах одной и той же системы или даже в других системах.
Доработки могут включать изменения в среде, такие как новая версия
операционной системы или системы управления базами данных.
Такие непреднамеренные побочные эффекты называются
регрессиями. Регрессионное тестирование включает выполнение
тестов для обнаружения таких непреднамеренных побочных
эффектов.
3. Типы тестирования (9 из 9) Тестирование
изменений
Дефект Подтверждающее
тестирование
Регрессионное
тестирование
43. 4. Тестирование в период сопровождения (1 из 2)
Профессиональный тестировщик, Июнь
2019 г.
43
Сопровождение – модификация программного продукта после
его поставки с целью исправления дефектов, улучшения
производительности или других характеристик или для адаптации
продукта к изменившемуся окружению [IEEE 1219].
Тестирование в период сопровождения – тестирование
изменений в действующей системе или влияния изменений в
окружении на действующую систему.
Тестирование в период сопровождения фокусируется на
тестировании изменений в системе, а также на тестировании
неизмененных частей, на которые могли повлиять изменения.
Сопровождение может включать запланированные релизы и
незапланированные релизы (срочные исправления).
44. 4. Тестирование в период сопровождения (2 из 2)
Профессиональный тестировщик, Июнь
2019 г.
44
Необходимые условия для тестирования в период сопровождения:
• Модификации, такие как запланированные улучшения (например,
базирующиеся на графике выпуска обновлений), корректирующие и
аварийные изменения, изменения среды эксплуатации (например,
запланированные обновления операционной системы или базы
данных), обновления коммерческого готового программного
обеспечения и исправления дефектов и уязвимостей.
• Миграция, например, с одной платформы на другую, которая
может потребовать проведения эксплуатационных тестов новой
среды, а также измененного программного обеспечения или тестов
преобразования данных, когда данные будут перенесены в
поддерживаемую систему из другого приложения.
• Снятие с эксплуатации, например, когда заканчивается
жизненный цикл приложения.