Слайд 2
![15. ПИРАМИДА ТЕСТИРОВАНИЯ](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-1.jpg)
15. ПИРАМИДА ТЕСТИРОВАНИЯ
Слайд 3
![ПИРАМИДА ТЕСТИРОВАНИЯ Пирамида тестирования, также часто говорят уровни тестирования, это](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-2.jpg)
ПИРАМИДА ТЕСТИРОВАНИЯ
Пирамида тестирования, также часто говорят уровни тестирования, это группировка тестов
по уровню детализации и их назначению. Эту абстракцию придумал Майк Кон и описал в книге «Scrum: гибкая разработка ПО» (Succeeding With Agile. Software Development Using Scrum).
Пирамиду разбивают на 4 уровня (снизу вверх), например,
по ISTQB:
• модульное тестирование (юнит);
• интеграционное тестирование;
• системное тестирования;
• приемочное тестирование.
Слайд 4
![ПИРАМИДА ТЕСТИРОВАНИЯ Но можно встретить варианты, где 3 уровня. В](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-3.jpg)
ПИРАМИДА ТЕСТИРОВАНИЯ
Но можно встретить варианты, где 3 уровня. В этой модели объединяют интеграционный и
системный уровни:
Unit — тесты на отдельную мелкую функцию (посчитать одну ячейку отчета)
API — тесты на конкретный функционал, который состоит из отдельных функций (загрузить весь отчет)
GUI — честный тест через графический интерфейс, «как это делал бы пользователь» (открыть браузер, войти в систему, перейти в отчеты, и наконец вызвать отчет).
Слайд 5
![ПИРАМИДА ТЕСТИРОВАНИЯ Можно сказать, что разработка ПО - это движение](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-4.jpg)
ПИРАМИДА ТЕСТИРОВАНИЯ
Можно сказать, что разработка ПО - это движение по пирамиде
снизу вверх. Важно отметить:
1. Тест (ручной, на высоких уровнях, или автотест, на низких уровнях), должен быть на том же уровне, что и тестируемый объект. Например, модульный тест (проверяющий функции, классы, объекты и т.п.) должен быть на компонентном уровне. Это неправильно, если на приемочном уровне запускается тест, который проверят минимальную единицу кода.
Тесты уровнем выше не проверяют логику тестов
уровнем/уровнями ниже.
3. Чем выше тесты уровнем, тем они:
• сложней в реализации, и соответственно, дороже в
реализации;
• важнее для бизнеса и критичней для пользователей;
• замедляют скорость прохождения тестовых наборов, например, регресса.
Слайд 6
![КОМПОНЕНТНЫЙ УРОВЕНЬ Чаще всего называют юнит тестированием. Реже называют модульным](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-5.jpg)
КОМПОНЕНТНЫЙ УРОВЕНЬ
Чаще всего называют юнит тестированием. Реже называют модульным тестированием. На
этом уровне тестируют атомарные части кода. Это могут быть классы, функции или методы классов.
Тест на компонентном уровне:
1. Всегда автоматизируют.
2. Модульных тестов всегда больше, чем тестов с других уровней.
3. Юнит тесты выполняются быстрее всех и требуют меньше ресурсов.
Практически всегда компонентные тесты не зависят от других модулей (на то они и юнит тесты) и UI системы.
В 99% разработкой модульных тестов занимается разработчик, при нахождении ошибки на этом уровне не создается баг-репортов.
На модульном уровне разработчик (или автотестер) использует метод белого ящика. Он знает, что принимает и отдает минимальная единица кода, и как она работает.
Слайд 7
![КОМПОНЕНТНЫЙ УРОВЕНЬ Пример: твоя компания разрабатывает приложение "Калькулятор", которое умеет](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-6.jpg)
КОМПОНЕНТНЫЙ УРОВЕНЬ
Пример: твоя компания разрабатывает приложение "Калькулятор", которое умеет складывать и
вычитать. Каждая операция это одна функция. Проверка каждой функции, которая не зависит от других, является юнит тестированием.
Слайд 8
![ИНТЕГРАЦИОННЫЙ УРОВЕНЬ Проверят взаимосвязь компонентов, которые проверяли на модульном уровне,](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-7.jpg)
ИНТЕГРАЦИОННЫЙ УРОВЕНЬ
Проверят взаимосвязь компонентов, которые проверяли на модульном уровне, с другой или другими
компонентами, а также интеграцию компонентов с системой (проверка работы с ОС, сервисами и службами, базами данных, железом и т.д.). Часто в английских статьях называют service test или API test.
В интеграционном тестировании, выполняются как функциональные (проверка по ТЗ), так и нефункциональные проверки (нагрузка на связку компонент). На этом уровне используется либо серый, либо черный ящик.
Компоненты ПО или системы взаимодействуют с тестируемым модулем с помощью интерфейсов. Тут начинается участие тестирования. Это проверки API, работы сервисов
Слайд 9
![ИНТЕГРАЦИОННЫЙ УРОВЕНЬ В интеграционном тестировании есть 3 основных способа тестирования:](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-8.jpg)
ИНТЕГРАЦИОННЫЙ УРОВЕНЬ
В интеграционном тестировании есть 3 основных способа тестирования:
Снизу вверх (Bottom Up Integration): все
мелкие части модуля собираются в один модуль и тестируются. Далее собираются следующие мелкие модули в один большой и тестируется с предыдущим и т.д.
Сверху вниз (Top Down Integration): сначала проверяем работу крупных модулей, спускаясь ниже добавляем модули уровнем ниже. На этапе проверки уровней выше данные, необходимые от уровней ниже, симулируются.
Большой взрыв ("Big Bang" Integration): собираем все реализованные модули всех уровней, интегрируем в систему и тестируем. Если что-то не работает или недоработали, то фиксим или дорабатываем.
Слайд 10
![СИСТЕМНЫЙ УРОВЕНЬ Стоит отметить: Системный уровень проверят взаимодействие тестируемого ПО](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-9.jpg)
СИСТЕМНЫЙ УРОВЕНЬ
Стоит отметить:
Системный уровень проверят взаимодействие тестируемого ПО с системой по
функциональным и нефункциональным требованиям.
Важно тестировать на максимально приближенном окружении, которое будет у конечного пользователя.
Тест-кейсы на этом уровне подготавливаются:
По требованиям.
По возможным способам использования ПО.
На системном уровне выявляются такие дефекты, как неверное использование ресурсов системы, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т.д.
На этом уровне используют черный ящик. Интеграционный уровень позволяет верифицировать требования (проверить соответствие ПО прописанным требованиям).
Слайд 11
![ПРИЕМОЧНОЕ ТЕСТИРОВАНИЕ Также часто называют E2E тестами (End-2-End) или сквозными.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-10.jpg)
ПРИЕМОЧНОЕ ТЕСТИРОВАНИЕ
Также часто называют E2E тестами (End-2-End) или сквозными. На этом уровне происходит
валидация требований.
Проверка требований производится на наборе приемочных тестов. Они разрабатываются на основе требований и возможных способах использования ПО.
Приемочные тесты проводят, когда (1) продукт достиг необходимо уровня качества и (2) заказчик ПО ознакомлен с планом приемки.
Приемку проводит либо внутреннее тестирование (необязательно тестировщики) или внешнее тестирование (сам заказчик и необязательно тестировщик).
Важно помнить, что E2E тесты автоматизируются сложнее, дольше, стоят дороже, сложнее поддерживаются и трудно выполняются при регрессе. Значит таких тестов должно быть меньше.
Слайд 12
![ПРОСТЫЕ ПРИМЕРЫ В качестве аналогии давайте рассмотрим создание платья. Вот](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-11.jpg)
ПРОСТЫЕ ПРИМЕРЫ
В качестве аналогии давайте рассмотрим создание платья.
Вот я заказала
себе платье по фигуре. Мастер выслушает мои пожелания, снимет мерки, а потом приступит за работу. Сначала он сделает выкройку и раскроит ткань. Если проверять каждую деталь, сравнивая с выкройкой — это будут юнит-тесты.
Слайд 13
![ПРОСТЫЕ ПРИМЕРЫ Проверили каждую деталь отдельно? Теперь тестируем вместе. Обметали](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-12.jpg)
ПРОСТЫЕ ПРИМЕРЫ
Проверили каждую деталь отдельно? Теперь тестируем вместе. Обметали и смотрим
— ровно? Криво? Может, что-то подправить?
Это аналог api-тестов — платье еще не готово, это не конечный продукт. Но мы соединили отдельные детали вместе и смотрим, как они работают.
Слайд 14
![ПРОСТЫЕ ПРИМЕРЫ Если всё хорошо, можно шить! А дальше следует](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-13.jpg)
ПРОСТЫЕ ПРИМЕРЫ
Если всё хорошо, можно шить! А дальше следует аналог UI-тестов — последняя
проверка, когда платье уже готово.
Нигде не накосячили? Когда все вместе собрано и рукав к попе пришит, переделывать уже очень трудно и дорого, такие проблемы лучше обнаружить заранее.
Слайд 15
![ПРОСТЫЕ ПРИМЕРЫ А еще одну аналогию можно провести с танцами](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-14.jpg)
ПРОСТЫЕ ПРИМЕРЫ
А еще одну аналогию можно провести с танцами
Начинаем с основ.
Сначала надо отработать движение, чтобы потом внедрять его в танец. Каждое конкретное движение — аналог unit-тестов.
Слайд 16
![ПРОСТЫЕ ПРИМЕРЫ Следующий этап — связать отдельные функции вместе. Зная](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-15.jpg)
ПРОСТЫЕ ПРИМЕРЫ
Следующий этап — связать отдельные функции вместе. Зная 5 разных
движений, мы начинаем связывать их под музыку. Это аналог api-тестов
Каждую часть танца мы разрабатываем отдельно (как и разные куски api в программе).
Слайд 17
![ПРОСТЫЕ ПРИМЕРЫ А потом уже соединяем всё вместе. И получается готовый танец. Аналог UI-тестов.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-16.jpg)
ПРОСТЫЕ ПРИМЕРЫ
А потом уже соединяем всё вместе. И получается готовый танец. Аналог UI-тестов.
Слайд 18
![ПРОСТЫЕ ПРИМЕРЫ А потом уже соединяем всё вместе. И получается готовый танец. Аналог UI-тестов.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-17.jpg)
ПРОСТЫЕ ПРИМЕРЫ
А потом уже соединяем всё вместе. И получается готовый танец. Аналог UI-тестов.
Слайд 19
![ВЫВОД В блоге Мартина Фаулера есть хорошее объяснение от Хэма](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-18.jpg)
ВЫВОД
В блоге Мартина Фаулера есть хорошее объяснение от Хэма Вока, касаемо пирамиды тестирования:
«Несмотря на
то, что концепция тестовой пирамиды существует довольно давно, команды все еще пытаются воплотить ее на практике».
Так почему же у команд возникают проблемы с практической реализацией стратегии QA? Ответ кажется простым: нельзя протестировать все, что имеет смысл.
Слайд 20
![ТЕСТИРОВЩИК ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ КУРС «РУЧНОЕ ТЕСТИРОВАНИЕ»](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/576392/slide-19.jpg)
ТЕСТИРОВЩИК ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
КУРС «РУЧНОЕ ТЕСТИРОВАНИЕ»