Тестирование программного обеспечения: понятия, классификация и уровни

1.

■ Понятие тестирования. Классификация
тестирования

2.

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

3.

Тестирование ПО
■
Тестирование программного обеспечения (Software
Testing) - проверка соответствия между реальным и
ожидаемым поведением программы, осуществляемая на
конечном наборе тестов, выбранном определенным
образом. [IEEE Guide to Software Engineering Body of
Knowledge, SWEBOK, 2004] В более широком смысле,
тестирование - это одна из техник контроля качества,
включающая в себя активности по планированию работ
(Test Management), проектированию тестов (Test Design),
выполнению тестирования (Test Execution) и анализу
полученных результатов (Test Analysis).

4.

■
■
■
■
■
■
■
Тестирование ПО
План Тестирования (Test Plan) - это документ, описывающий весь объем работ по
тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и
окончания тестирования, до необходимого в процессе работы оборудования, специальных
знаний, а также оценки рисков с вариантами их разрешения.
Тест дизайн (Test Design) - это этап процесса тестирования ПО, на котором проектируются и
создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями
качества и целями тестирования.
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных
условий и параметров, необходимых для проверки реализации тестируемой функции или её
части.
Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или
последовательность действий приведшую к некорректной работе объекта тестирования, с
указанием причин и ожидаемого результата.
Тестовое Покрытие (Test Coverage) - это одна из метрик оценки качества тестирования,
представляющая из себя плотность покрытия тестами требований либо исполняемого кода.
Детализация Тест Кейсов (Test Case Specification) - это уровень детализации описания
тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение
времени прохождения к тестовому покрытию
Время Прохождения Тест Кейса (Test Case Pass Time) - это время от начала прохождения
шагов тест кейса до получения результата теста

5.

Классификация тестирования

6.

Основные технологии тестирования
■ Технологий тестирования существует
целое множество. Условно их можно
отнести к статическим или к
динамическим.

7.

Статическое тестирование – это процесс, который
обычно ассоциируют с анализом ПО.
■ Статическим тестированием пользуются для
верификации практически любого артефакта
разработки: программного кода компонент,
требований, системных спецификаций,
функциональных спецификаций, документов
проектирования и архитектуры программных систем и
их компонентов, и т.д.
■ Использование статических методов тестирования –
один из наиболее эффективных способов обнаружения
дефектов на ранних стадиях разработки ПО.
■ Действительно, статическое тестирование – это
единственный способ тестирования без запуска
программного кода приложения.
■

8.

■ Динамическое тестирование – процесс
тестирования, производимый над работающей
системой или подсистемой.
Оно не может быть осуществлено без запуска
программного кода приложения
Динамическое тестирование состоит из:
■ 1. запуска системы или подсистемы;
■ 2. вызова необходимых функциональных
элементов или модулей;
■ 3. сравнения через графический интерфейс
пользователя поведения системы с ожидаемым
результатом поведения.

9.

Уровни Тестирования
Программного Обеспечения
Тестирование на разных уровнях производится на
протяжении всего жизненного цикла разработки и
сопровождения программного обеспечения.
■ Уровень тестирования определяет то, над чем
производятся тесты: над отдельным модулем,
группой модулей или системой, в целом.
■ Проведение тестирования на всех уровнях системы это залог успешной реализации и сдачи проекта.
■

10.

Уровни Тестирования
■ Компонентное или Модульное тестирование
(Component Testing or Unit Testing)
■ Интеграционное тестирование (Integration
Testing)
■ Системное тестирование (System Testing)
■ Приемочное тестирование (Acceptance
Testing)

11.

Виды тестирования
Виды тестирования программного обеспечения,
в зависимости от преследуемых целей, можно условно
разделить на следующие группы:
1. Функциональные
2. Нефункциональные
3. Связанные с изменениями

12.

Функциональные виды тестирования
Функциональные тесты базируются на функциях и
особенностях, а также взаимодействии с другими
системами, и могут быть представлены на всех
уровнях тестирования:
■ компонентном или модульном (Component/Unit
testing),
■ интеграционном (Integration testing), системном
(System testing) и
■ приемочном (Acceptance testing). Функциональные
виды тестирования рассматривают внешнее
поведение системы.
■

13.

Функциональные виды тестирования
Самые распространенные виды функциональных
тестов:
■Функциональное тестирование (Functional testing)
■Тестирование безопасности (Security and Access
Control Testing)
■Тестирование взаимодействия (Interoperability
Testing)

14.

Нефункциональные виды тестирования
■ Нефункциональное тестирование
описывает тесты, необходимые для
определения характеристик
программного обеспечения, которые
могут быть измерены различными
величинами. В целом, это тестирование
того, "Как" система работает.

15.

Нефункциональные виды тестирования
Основные виды нефункциональных тестов:
■Все виды тестирования производительности:
нагрузочное тестирование (Performance and Load Testing)
стрессовое тестирование (Stress Testing)
тестирование стабильности или надежности (Stability /
Reliability Testing)
объемное тестирование (Volume Testing)
■Тестирование установки (Installation testing)
■Тестирование удобства пользования (Usability Testing)
■Тестирование на отказ и восстановление (Failover and Recovery
Testing)
■Конфигурационное тестирование (Configuration Testing)

16.

Связанные с изменениями виды
тестирования
■ После проведения необходимых изменений,
таких как исправление бага/дефекта,
программное обеспечение должно быть пере
тестировано для подтверждения того факта,
что проблема была действительно решена.

17.

Связанные с изменениями виды тестирования
Виды тестирования, которые необходимо проводить
после установки программного обеспечения, для
подтверждения работоспособности приложения или
правильности осуществленного исправления дефекта:
■Дымовое тестирование (Smoke Testing)
■Регрессионное тестирование (Regression Testing)
■Тестирование сборки (Build Verification Test)
■Санитарное тестирование или проверка
согласованности/исправности (Sanity Testing)

18.

Виды тестирования

19.

Виды тестирования
виды тестирования программного обеспечения,
в зависимости от решаемых задач, можно условно
разделить на следующие группы:
по объектам (элементам) тестирования, часто
разделение на виды тестов по данному критерию
называют разделением тестирования на уровни;
по глубине тестирования, то есть разделение
тестовых испытаний на типы проводится в зависимости
от количества времени и объема тестируемых
компонент программного продукта

20.

Классификация видов тестирования

21.

Виды тестирования
Модульное тестирование (Автономное или Unit-тестирование)
■Входные требования — Архитектура компонентов или модель
“нижнего уровня” системы (Component Design или Low Level Design)
■Объект тестирования — Разработанные компоненты
■Определение: На данном уровне тестируются по отдельности
небольшие элементы системы, максимально отделенные от других
элементов и, в то же время, пригодные для тестирования. Такое
тестирование обычно проводится сразу же вслед за разработкой
каждого из элементов и направлено на оценку соответствия
функциональности каждого из компонентов спроектированной “модели
компонентов”.

22.

Комплексное тестирование (Сборочное тестирование,
integration testing или interface testing)
■Входные требования — Архитектура системы или модель
“верхнего уровня” системы (System Design или High Level
Design)
■Объект тестирования — Собранная из компонентов система
или подсистема
■Определение: На данном уровне тестируются объединенные
элементы (компоненты или подсистемы) общей системы, чаще
всего некоторая взаимодействующая между собой группа
элементов.
Комплексное тестирование направлено не на проверку
функционирования каждого из компонентов, а на проверку
взаимодействия компонентов в соответствии с «Архитектурой
системы».

23.

Системное тестирование (system testing)
Входные требования — Системные спецификации (System
Specification)
Объект тестирования — Разработанная система
Определение: После того, как система собрана из
составляющих компонентов, она должна быть протестирована
на соответствие “Системным спецификациям” – реализованы
ли все функциональные и нефункциональные требования к
разрабатываемой системе.
На данном уровне тестируется приложение или система (одно
или более приложений) целиком.

24.

Приемочное тестирование (Приемо-сдаточное тестирование
или acceptance testing)
Входные требования — Требования (Requirements)
Объект тестирования — Разработанная система
Определение: На данном уровне завершенное приложение
(система) тестируется Заказчиком, конечными пользователями
или соответствующими уполномоченными с целью
определения соответствия системы “Требованиям Заказчика” и
готовности системы к внедрению. Приемосдаточные
испытания оформляют процесс передачи продукта от
Разработчика Заказчику. В зависимости от особенностей
продукта и от требований Заказчика они могут проводиться в
различной форме. Например, в виде альфа- или бетатестирования.

25.

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

26.

Операционное тестирование (Release Testing)
Входные требования — Бизнес модель (Business Case или
Business Model)
Объект тестирования — Разработанная система
Определение: Даже если система удовлетворяет всем
требованиям, важно убедиться в том, что она удовлетворяет
нуждам пользователя и выполняет свою роль в среде своей
эксплуатации, как это было определено в бизнес-модели
системы. Следует учесть, что и Бизнес модель может
содержать ошибки. Поэтому так важно провести
операционное тестирование как финальный шаг Валидации.

27.

Инсталляционное тестирование (Installation testing)
Определение: В процессе инсталляционного тестирования
проверяется корректность установки и деинсталляции
программного продукта в среде максимально приближенной к
эксплуатационной. Проверка правильности установки
программного продукта должна быть обязательным
элементом проекта по тестированию любого продукта.
Цель: Основная цель состоит в том, чтобы убедиться, что
продукт может быть установлен/деинсталлирован при
различных условиях – таких как: новая инсталляция,
усовершенствование системы (upgrade), установка по
умолчанию, полная установка, установка по выбору.

28.

Дымное тестирование (проверка на дым, Smoke testing)
Определение: Первый прогон программы (после написания
или после внесения существенных изменений). Как правило,
используется для определения, готова ли программа для
проведения более обширного тестирования.
Цель: Выявление проблем «лежащих на поверхности» –
тестируется чаще всего основная бизнес логика программы
Короткий тест, проверяющий основную
функциональность программного продукта и
его работоспособность, ограниченный по
времени, по результатам которого ведущий
инженер по тестированию принимает
решение о приемке версии ПП на
тестирование.

29.

Функциональное тестирование (Functional testing)
Определение: Проверка соответствия продукта
функциональным требованиям и спецификациям
Цель: Проверка соответствия продукта функциональным
требованиям и спецификациям

30.

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

31.

Интеграционное тестирование (Integration testing)
Определение: Проверка скомбинированных компонентов
прикладной программы с целью определения корректности их
совместного функционирования
Цель: Выявление потенциальных проблем в совместном
функционировании компонент
Тестирование графического интерфейса пользователя
(User Interface testing)
Определение: Тестирование интерфейса – экранов, кнопок и
т.д. Большая часть функциональности ПО реализуется, как
правило, через пользовательский интерфейс.
Цель: Обнаружение ошибок в интерфейсе и поиск ошибок в
функциональности посредством интерфейса

32.

Тестирование производительности (Performance
testing)
Определение: Проверка скорости работы системы
(время отклика, частота транзакций и другие
зависящие от времени) в имитационной и реальной
средах
Цель: Установить реальную производительность
программного продукта

33.

Нагрузочное тестирование (Load testing)
Определение: Это те же тесты производительности, при
которых система подвергается различным нагрузкам; при этом
цель этого тестирования – оценить способность системы
правильно функционировать при некотором превышении
планируемых нагрузок при реальной эксплуатации (система
имеет некоторый «запас прочности»)
Цель: Убедиться в том, что система работает соответственно
ожидаемым рабочим нагрузочным параметрам (какой предел
работоспособности)

34.

Стресс тестирование (Stress testing)
Определение: Является одним из разновидностей
тестирования на производительность. Проверяется поведение
системы при недостатке ресурсов (дискового пространства,
обрывов сети и т.д.).
Цель: Проверка того, что система адекватно реагирует на те
или иные стрессовые ситуации

35.

Стрессовое тестирование
(Stress testing)
Один из видов тестирования программного обеспечения,
которое оценивает надёжность и устойчивость системы в
условиях превышения пределов нормального
функционирования. Стресс-тестирование особенно
необходимо для «критически важного» ПО, однако также
используется и для остального ПО.
35
GDC © 2015

36.

Конфигурационное тестирование (Configuration testing)
Определение: Конфигурационное тестирование – тестирование
работы на различных платформах. Различные варианты
аппаратной конфигурации, версии операционной системы и
окружения.
Цель: Проверить работоспособность системы при различных
конфигурациях

37.

Тестирование надежности (reliability) ПО производится с
целью проверки нефункциональных требований, что
приложение работает, как и ожидалось, устойчиво к падениям и
т.п. Здесь применяются интеграционные тесты, тесты
структуры, стрессовые тесты и другие.
Тестирование удобства использования (usability) ПО
(нефункциональные требования) производится с целью
удостовериться в том, что приложение удобно для
использования его конечным пользователям. Включает в себя
тесты на человеческий фактор, эстетику интерфейса и его
непротиворечивость, наличие и качество оперативной и
контекстной помощи, руководств и учебных материалов.

38.

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

39.

Приемочный тест (Smoke test) – первый и самый короткий
тест, призванный проводить проверку основных элементов
программного продукта и его работоспособности в целом. В
случае функционального тестирования – проверяется основной
функционал приложения. Тест занимает 1-4 часа в зависимости
от сложности тестируемого продукта. На основе результатов
данного теста принимается решение о приемке версии
программного продукта и продолжении тестирования текущей
версии продукта более серьезными тестовыми испытаниями.

40.

Критический тест (Critical path test) – основной тип тестовых
испытаний, во время которого значимые элементы и функции
приложения проверяются на предмет правильности работы при
стандартном их использовании. Как правило, на данном уровне
тестирования проверяется основная масса требований к
продукту.
Расширенный тест (Extended test) – вид углубленного
тестирования, при котором проверяется нестандартное
использование программного продукта, границы переполнения
массивов данных, ввод специальных символов и т.п.

41.

Практическое задание
1. Составление плана тестирования: Разработать фрагмент плана тестирования для
гипотетического приложения, включая цели, стратегию, ресурсы и расписание.
2. Создание тест-кейсов: Написать 3 тест-кейса для функционального тестирования
модуля “Регистрация пользователя”.
3. Анализ дефекта: На основе описания сценария ошибки составить баг-репорт по
заданному шаблону.
4. Сравнение видов тестирования: Сопоставить функциональное и нефункциональное
тестирование в таблице с примерами.
5. Разработка чек-листа для дымового тестирования: Составить список основных
проверок для smoke-тестирования веб-приложения.
6. Сценарий регрессионного тестирования: Описать шаги для проведения регрессионного
тестирования после исправления критического бага.
7. Проектирование теста производительности: Определить метрики и сценарии для
нагрузочного тестирования онлайн-магазина.
8. Классификация тестов: Распределить предложенные виды тестирования по группам: по
объекту, по знанию системы, по степени автоматизации.
9. Ситуационная задача по выбору вида тестирования: Определить, какие виды
тестирования следует провести при добавлении новой функции в мобильное
приложение.
10. Разработка сценария приемочного тестирования: Составить сценарий UAT для