Что такое системное тестирование?
Системное тестирование — это процесс тестирования полного, интегрированного программного приложения для проверки соответствия заданным требованиям. В отличие от модульного тестирования (фокус на отдельных функциях) и интеграционного (фокус на взаимодействии компонентов), системное тестирование оценивает всё приложение целиком — так, как с ним взаимодействовал бы пользователь или внешняя система.
На этом уровне вы рассматриваете систему как чёрный ящик. Вас не интересует внутренняя структура кода, схемы базы данных или способы соединения модулей. Вас интересуют входы и выходы: при данном действии система выдаёт ожидаемый результат?
Рассмотрим приложение интернет-банкинга. Системное тестирование проверит:
- Пользователь может войти с валидными данными и получает отказ с невалидными
- Балансы счетов отображаются корректно после переводов
- Запланированные платежи исполняются в нужные даты
- Таймауты сессий работают согласно требованиям безопасности
- Приложение корректно работает с несколькими валютами
Системное тестирование vs другие уровни
| Аспект | Интеграционное | Системное | E2E |
|---|---|---|---|
| Масштаб | Взаимодействие компонентов | Полное приложение | Полные пользовательские сценарии |
| Перспектива | Разработчик/Техническая | QA/На основе требований | Пользователь/Бизнес |
| Окружение | Dev/CI | Staging (подобие продакшена) | Полный стек, подобие продакшена |
| Фокус | Модули работают вместе? | Приложение соответствует требованиям? | Весь рабочий процесс работает? |
| Основа тестов | Документы проектирования, спеки API | Требования, user stories | Бизнес-процессы, use cases |
Различие между системным и E2E тестированием тонкое, но важное. Системное тестирование проверяет, что ваше приложение работает корректно. E2E тестирование проверяет, что весь бизнес-процесс работает, что может охватывать несколько приложений и сторонних сервисов.
Функциональные системные тесты
Функциональные тесты проверяют что делает система — её функции и поведение, определённые в требованиях.
Тестирование функций
Проверка работоспособности каждой функции согласно спецификации:
- Вход/регистрация со всеми методами аутентификации
- Функциональность поиска с фильтрами, сортировкой и пагинацией
- Операции корзины покупок (добавление, удаление, изменение количества)
- Обработка платежей различными способами оплаты
- Генерация отчётов с корректными данными и форматированием
Валидация бизнес-правил
Проверка корректного применения бизнес-правил:
- Правила скидок (например, 10% на заказы свыше $100, без комбинации с купонами)
- Контроль доступа (менеджеры одобряют возвраты до $500, директора до $5000)
- Валидация данных (формат email, телефона, обязательные поля)
- Правила рабочего процесса (заказ не отправляется до подтверждения оплаты)
Целостность данных
Проверка корректного хранения, извлечения и отображения данных:
- Записи, сохранённые через UI, корректно отображаются при извлечении
- Вычисления (итоги, налоги, скидки) точны
- Данные не теряются и не повреждаются при операциях
- Исторические данные сохраняются после обновлений
Нефункциональные системные тесты
Нефункциональные тесты проверяют как работает система — атрибуты качества помимо функциональной корректности.
Производительность
- Время отклика при нормальной нагрузке
- Пропускная способность (транзакции в секунду)
- Использование ресурсов (CPU, память, диск)
Безопасность
- Применение аутентификации и авторизации
- Защита от распространённых уязвимостей (SQL injection, XSS)
- Шифрование данных при передаче и хранении
- Управление сессиями и поведение таймаутов
Удобство использования
- Интуитивность навигации
- Ясность сообщений об ошибках
- Соответствие требованиям доступности (WCAG)
- Консистентность между страницами
Надёжность
- Среднее время между отказами (MTBF)
- Восстановление после сбоев и ошибок
- Функциональность резервного копирования и восстановления
- Плавная деградация под нагрузкой
Совместимость
- Кросс-браузерное тестирование (Chrome, Firefox, Safari, Edge)
- Кросс-устройственное тестирование (десктоп, планшет, мобильный)
- Кросс-платформенное тестирование (Windows, macOS, Linux, iOS, Android)
- Совместимость версий API
Требования к окружению
Системное тестирование требует окружения, близкого к продакшену:
Ключевые аспекты окружения:
- Паритет конфигурации: Те же настройки приложения, что в продакшене
- Объём данных: Достаточно данных для тестирования пагинации, поиска и производительности
- Сетевая топология: Схожая сетевая конфигурация (файрволы, балансировщики)
- Сторонние сервисы: Подключение к sandbox/staging-версиям внешних API
Кто выполняет системное тестирование?
Системное тестирование обычно выполняют QA-инженеры, независимые от команды разработки. Эта независимость критична:
- У разработчиков есть предвзятость. Они знают, как работает код, и неосознанно тестируют happy path.
- Свежий взгляд находит другие дефекты. Человек, незнакомый с реализацией, попробует то, что разработчик никогда не рассматривал.
- Фокус на требованиях. QA-инженеры тестируют против требований и user stories, а не против кода.
Проектирование системных тест-кейсов
Системные тест-кейсы выводятся из требований, а не из кода:
- Анализ требований — Прочитать user stories, критерии приёмки и спецификации
- Определение условий тестирования — Какие аспекты каждого требования нуждаются в тестировании?
- Проектирование тест-кейсов — Какие входы, действия и результаты проверяют каждое условие?
- Приоритизация — Какие тест-кейсы покрывают наибольший риск?
Упражнение: Создайте сценарии системных тестов из требований
Вы получаете следующие требования для системы управления библиотекой:
REQ-001: Зарегистрированные пользователи могут искать книги по названию, автору или ISBN. REQ-002: Пользователи могут бронировать доступные книги на срок до 7 дней. REQ-003: Пользователь может иметь не более 5 активных бронирований одновременно. REQ-004: Если забронированная книга не забрана в течение 7 дней, бронирование автоматически отменяется. REQ-005: Пользователи с просроченными книгами не могут делать новые бронирования до возврата.
Создайте тестовые сценарии для REQ-001 — REQ-005. Для каждого укажите: цель, предусловия, шаги и ожидаемый результат.
Подсказка
Для каждого требования подумайте о: нормальном случае (happy path), границах (что происходит на пределе — например, ровно 5 бронирований), ошибочных случаях (что должно быть предотвращено) и взаимодействии между требованиями (REQ-003 и REQ-005 взаимодействуют).Решение
REQ-001: Поиск книг
Тест 1: Поиск по названию
- Предусловие: В БД есть книга «Clean Code» Роберта Мартина, ISBN 978-0132350884
- Шаги: Ввести «Clean Code» в поле поиска, выбрать фильтр «Название», нажать «Поиск»
- Ожидаемо: «Clean Code» в результатах с корректным автором и ISBN
Тест 2: Частичный поиск
- Предусловие: В БД есть «Clean Code» и «Clean Architecture»
- Шаги: Искать «Clean» по названию
- Ожидаемо: Обе книги в результатах
Тест 3: Поиск без результатов
- Шаги: Искать «XYZНЕСУЩЕСТВУЮЩЕЕ» по названию
- Ожидаемо: Сообщение «Ничего не найдено»
REQ-002: Бронирование книг
Тест 4: Бронирование доступной книги
- Предусловие: Пользователь авторизован, «Clean Code» в статусе «Доступна»
- Шаги: Нажать «Забронировать» на «Clean Code»
- Ожидаемо: Статус «Забронирована», срок истечения — через 7 дней
Тест 5: Нельзя забронировать недоступную книгу
- Предусловие: «Clean Code» забронирована другим пользователем
- Ожидаемо: Кнопка «Забронировать» недоступна, статус «Забронирована»
REQ-003: Максимум 5 бронирований
Тест 6: Пятое бронирование успешно
- Предусловие: У пользователя 4 активных бронирования
- Шаги: Забронировать пятую книгу
- Ожидаемо: Бронирование успешно, теперь 5 активных
Тест 7: Шестое бронирование отклонено
- Предусловие: У пользователя 5 активных бронирований
- Шаги: Попытка забронировать шестую книгу
- Ожидаемо: Ошибка «Достигнут максимум бронирований (5/5)»
REQ-004: Автоотмена через 7 дней
Тест 8: Бронирование автоматически отменено
- Предусловие: Пользователь забронировал книгу 7 дней назад, не забрал
- Шаги: Проверить статус бронирования
- Ожидаемо: Статус «Отменено — Не забрано», книга снова доступна
REQ-005: Блокировка за просрочку
Тест 9: Пользователь с просроченной книгой не может бронировать
- Предусловие: У пользователя есть книга с истекшим сроком возврата
- Шаги: Попытка забронировать новую книгу
- Ожидаемо: Ошибка «У вас есть просроченные книги. Верните их для новых бронирований.»
Тест 10: Блокировка снимается после возврата
- Предусловие: Пользователь вернул просроченную книгу
- Шаги: Попытка забронировать новую книгу
- Ожидаемо: Бронирование успешно
Межтребовательное взаимодействие (REQ-003 + REQ-005):
Тест 11: 5 бронирований И просроченная книга
- Предусловие: 5 активных бронирований, одно возвращено, но есть просроченная книга
- Шаги: Попытка забронировать после возврата одного бронирования
- Ожидаемо: Блокировка — просроченная книга не даёт бронировать независимо от свободных слотов
Стратегии выполнения системных тестов
Тестирование на основе рисков
Не все функции несут одинаковый риск. Приоритизируйте на основе:
- Бизнес-влияние: Функции, влияющие на выручку, безопасность или комплаенс
- Сложность: Функции со сложной логикой или множеством точек интеграции
- Частота изменений: Области кода, которые часто меняются
- История дефектов: Модули с предыдущими багами вероятно будут иметь ещё
Матрица трассировки
Сопоставьте каждое требование с его тест-кейсами. Это гарантирует:
- Ни одно требование не осталось непротестированным
- Ни один тест-кейс не существует без соответствующего требования
- Покрытие тестами можно количественно оценить для стейкхолдеров
Профессиональные советы
Совет 1: Системное тестирование находит другие баги, чем интеграционное. Интеграционные тесты ловят несоответствия данных и нарушения контрактов. Системные — ошибки бизнес-логики, проблемы UI/UX и конфликты между функциями.
Совет 2: Используйте данные, похожие на продакшен. Санитизированные реальные данные выявляют проблемы, которые синтетические не обнаруживают — проблемы кодировки, граничные случаи в реальных адресах, необычные комбинации.
Совет 3: Отслеживайте покрытие требований, а не кода. На системном уровне code coverage бессмысленно. Важно, протестировано ли каждое требование позитивными, негативными и граничными сценариями.
Ключевые выводы
- Системное тестирование проверяет полное приложение на соответствие требованиям
- Включает функциональные тесты (что делает система) и нефункциональные (как работает)
- Тестовое окружение должно быть максимально похоже на продакшен
- Независимые QA-инженеры привносят свежий взгляд и фокус на требования
- Тест-кейсы выводятся из требований систематическими техниками проектирования
- Приоритизация на основе рисков обеспечивает тестирование наиболее критичных функций