Что такое динамическое тестирование?
Динамическое тестирование — процесс оценки ПО путём его выполнения. Вы подаёте входные данные работающей системе, она их обрабатывает, а вы наблюдаете, совпадают ли фактические результаты и поведение с ожидаемыми.
Каждый раз, когда вы нажимаете кнопку в приложении и проверяете, сделало ли оно то, что нужно — вы выполняете динамическое тестирование. Каждый раз, когда фреймворк автоматизации запускает браузер, заполняет форму и проверяет результат — это динамическое тестирование.
Ключевое слово — выполнение. Если код запускается — это динамическое. Если вы только читаете или анализируете код без запуска — это статическое.
Как динамическое тестирование дополняет статическое
Статическое и динамическое тестирование — не конкуренты, а партнёры. Каждый находит дефекты, недоступные другому.
Статическое находит: Нарушения стандартов, недостижимый код, потенциальные проблемы с null, паттерны безопасности, неоднозначности требований.
Динамическое находит: Реальные сбои в runtime, узкие места производительности, утечки памяти под нагрузкой, ошибки интеграции, проблемы UX, race conditions.
Взаимодополняющая связь
Статическое vs. Динамическое: Сравнение
| Параметр | Статическое | Динамическое |
|---|---|---|
| Выполнение кода | Нет | Да |
| Когда возможно | С этапа требований | С этапа реализации |
| Типичные активности | Ревью, walkthroughs, статический анализ | Юнит-тесты, интеграционные, системные |
| Нужная среда | Нет (только артефакт) | Среда выполнения |
| Типы дефектов | Нарушения стандартов, потенциальные баги | Реальные сбои, проблемы производительности |
| Стоимость поиска | Ниже (раньше в SDLC) | Выше (нужна среда, выполнение) |
| Скорость обратной связи | Быстрая (минуты для инструментов) | Варьируется (секунды для юнит, часы для E2E) |
| Находит runtime-проблемы | Нет (только прогнозирует) | Да (наблюдает напрямую) |
| Проверяет нефункциональные требования | Ограниченно | Да (производительность, юзабилити) |
Техники динамического тестирования
Динамическое тестирование охватывает множество техник:
По знанию кода:
- Black-box (Урок 2.27), White-box (Урок 2.26), Grey-box (Урок 2.28)
По уровню: Модульное, интеграционное, системное, E2E, приёмочное
По назначению: Функциональное, производительности, безопасности, юзабилити, надёжности (Урок 2.25)
По подходу: Скриптованное, исследовательское (Урок 2.32), ad hoc (Урок 2.33)
Когда начинать динамическое тестирование
Распространённое заблуждение: динамическое тестирование начинается только после сборки всего приложения. На самом деле оно должно начаться при появлении исполняемого кода:
| Фаза SDLC | Динамическая активность |
|---|---|
| Реализация | Разработчики пишут и запускают юнит-тесты |
| Интеграция | Интеграционные тесты проверяют взаимодействия |
| Системное тестирование | QA выполняет функциональные и нефункциональные тесты |
| UAT | Бизнес-пользователи валидируют в среде, подобной продакшну |
| Продакшн | Smoke-тесты, синтетический мониторинг, хаос-инженерия |
Процесс динамического тестирования
- Планирование — Определить что тестировать, выбрать техники, подготовить данные
- Проектирование — Создать тест-кейсы с входными данными и ожидаемыми результатами
- Подготовка — Настроить тестовую среду, развернуть билд
- Выполнение — Запустить тесты, наблюдать фактические результаты
- Сравнение — Сопоставить фактические результаты с ожидаемыми
- Отчётность — Задокументировать: pass, fail или blocked
- Перетестирование — После исправлений проверить устранение дефекта
Упражнение: Классифицируйте активности тестирования
Для каждой активности определите: статическое или динамическое тестирование.
- Разработчик запускает
pytestдля выполнения юнит-тестов - QA-инженер читает user story, проверяя ясность критериев приёмки
- SonarQube сканирует Java-проект и находит 15 code smells
- Тестировщик открывает веб-приложение, вводит логин и проверяет успешный вход
- Команда проводит walkthrough кода модуля платежей
- Автоматизированный тест Playwright переходит на checkout и проверяет итоговую сумму
- Инструмент SAST ищет захардкоженные API-ключи
- Инструмент нагрузочного тестирования отправляет 1000 одновременных запросов
- Разработчик читает diff пулл-реквеста и комментирует обработку ошибок
- QA использует Postman для отправки POST-запроса к /users и проверки status code
- ESLint проверяет неиспользуемые переменные в проекте
- Тестировщик устанавливает приложение на устройство и тестирует онбординг
Подсказка
Главный вопрос: «Нужно ли запускать ПО для этой активности?» Если да → динамическое. Если активность только изучает артефакт без запуска → статическое.Решение
- Динамическое —
pytestвыполняет код и проверяет фактические результаты. - Статическое — QA читает документ без выполнения ПО. Это ревью требований.
- Статическое — SonarQube анализирует исходный код без его выполнения.
- Динамическое — Тестировщик взаимодействует с работающим приложением.
- Статическое — Walkthrough — активность ревью без выполнения кода.
- Динамическое — Playwright запускает браузер, приложение выполняется.
- Статическое — SAST сканирует исходный код без выполнения.
- Динамическое — Инструмент отправляет реальные HTTP-запросы к работающему приложению.
- Статическое — Разработчик читает код и даёт обратную связь без выполнения.
- Динамическое — Postman отправляет реальный HTTP-запрос к работающему серверу.
- Статическое — ESLint читает файлы и применяет правила без выполнения.
- Динамическое — Тестировщик запускает реальное приложение на устройстве.
Итого: 1, 4, 6, 8, 10, 12 — динамические. 2, 3, 5, 7, 9, 11 — статические.
Почему важны оба: реальный пример
Рассмотрим функцию расчёта стоимости доставки:
Статический анализ может найти: высокую цикломатическую сложность, неиспользуемую переменную, всегда истинное условие.
Ревью кода может найти: отсутствие обработки международной доставки, противоречие логики скидки требованиям.
Динамический юнит-тест может найти: для заказа на $49.99 бесплатная доставка применена некорректно (баг граничного значения).
Динамический интеграционный тест может найти: сервис доставки возвращает вес в килограммах, а калькулятор ожидает фунты.
Каждая техника выявляет разные проблемы. Зависимость от одной оставляет значительные пробелы.
Ключевые выводы
- Динамическое тестирование требует выполнения ПО; статическое — нет
- Оба подхода необходимы — находят разные типы дефектов при разных затратах
- Динамическое тестирование начинается при появлении исполняемого кода, а не после завершения всего приложения
- Статическое находит потенциальные проблемы раньше и дешевле; динамическое подтверждает фактическое поведение
- Нефункциональные требования полностью валидируются только через динамическое тестирование
- Современные команды сочетают статический анализ в CI с динамическими тестами на нескольких уровнях