Статическое и динамическое тестирование
Статическое и динамическое тестирование
Введение
Большинство новичков думают, что тестирование начинается тогда, когда есть что запустить. На самом деле — нет. Часть тестирования можно и нужно делать ещё до того, как написана первая строчка кода. Именно это называется статическим тестированием.
Динамическое тестирование
Динамическое тестирование — это то, что большинство людей представляют под словом «тестирование»: программу запускают и проверяют её поведение.
Ключевой признак: код выполняется. Тестировщик взаимодействует с работающей системой.
Примеры динамического тестирования:
- Открыть форму регистрации и проверить, сохраняются ли данные
- Запустить API-запрос и проверить ответ
- Нажать кнопку оформления заказа и проверить, создался ли заказ
- Запустить автотест, который кликает по элементам страницы
Динамическое тестирование — основной вид тестирования на большинстве этапов разработки. Оно находит ошибки в поведении системы.
Статическое тестирование
Статическое тестирование — анализ артефактов проекта без запуска кода. Это проверка документов, кода, требований, дизайн-макетов.
Ключевой признак: программа не запускается. Тестировщик (или разработчик) читает и анализирует.
Что проверяют при статическом тестировании:
- Требования (requirements) — полнота, противоречия, неоднозначности
- Дизайн-документы и архитектурные схемы
- Исходный код (без выполнения)
- Тест-кейсы и тестовую документацию
- Пользовательская документация
Основные техники статического тестирования
Ревью (Review) — коллеги читают документ или код и находят проблемы:
- Неформальное ревью — просто попросил коллегу посмотреть
- Walkthrough — автор ведёт группу через документ, объясняя его
- Инспекция (Inspection) — формальный процесс с ролями, чеклистом, метриками
Статический анализ кода — инструменты (линтеры, анализаторы) проверяют код по правилам без запуска. Например, ESLint для JavaScript.
Почему статическое тестирование важно: «правило 10x»
Чем позже найден дефект, тем дороже его исправить. Это называют правилом 10x:
| Этап обнаружения дефекта | Относительная стоимость исправления |
|---|---|
| Требования | 1x |
| Дизайн | 5x |
| Разработка | 10x |
| Тестирование | 20x |
| Продакшн | 100x |
Если тестировщик находит противоречие в требованиях на этапе написания ТЗ — это стоит в 100 раз дешевле, чем исправить ошибку в продакшне.
Примеры статического тестирования в реальной работе
Пример 1: Ты читаешь требование: «Пользователь может войти по email». Задаёшь вопрос: «А что если email не подтверждён? А если аккаунт заблокирован?» — это статическое тестирование требований.
Пример 2: Разработчик просит посмотреть код функции валидации. Ты видишь, что граничный случай (пустая строка) не обрабатывается. Это статическое тестирование кода.
Пример 3: Дизайнер показывает макет. Ты замечаешь, что нет состояния ошибки для формы. Это статическое тестирование дизайна.
Сравнение
| Аспект | Статическое | Динамическое |
|---|---|---|
| Код запускается? | Нет | Да |
| Когда | До/во время разработки | После разработки |
| Что проверяет | Документы, код, требования | Поведение системы |
| Находит | Логические ошибки, неясности | Ошибки выполнения, баги |
| Стоимость исправления | Дёшево | Дороже |
Распространённые ошибки
- «Это работа разработчиков, не тестировщиков». Тестировщик участвует в ревью требований — это одна из важнейших его задач.
- «Зачем читать требования, если потом всё равно тестировать вживую?» Раннее обнаружение дефекта сэкономит время всей команды.
- «Статический анализ кода — это уже тестирование». Да, это форма статического тестирования, хотя многие относят её к инструментам разработки.
Что запомнить
- Статическое тестирование — без запуска программы (ревью, анализ документов)
- Динамическое тестирование — с запуском программы (обычное тестирование)
- Статическое тестирование дешевле, потому что находит дефекты раньше
- Тестировщик должен участвовать в ревью требований с самого начала проекта