Для комиссии фраза «всё работает» не является доказательством: в 70% случаев студенты заваливают техническую часть защиты из-за отсутствия количественных метрик тестирования. Чтобы подтвердить работоспособность сервиса, нужно перевести субъективное «окей» в объективные показатели Response Time, Error Rate и покрытие кода тестами.
Функциональное тестирование и тест-кейсы
Функциональный тест в дипломе — это не случайный клик по кнопкам, а матрица соответствия ТЗ. Каждый пункт из раздела, где вы описывали, как составить техническое задание (ТЗ) на веб-сервис для диплома, должен иметь минимум один позитивный и один негативный тест-кейс. Например, если форма регистрации принимает email, тест-кейс должен проверять не только корректный ввод, но и реакцию системы на строку без символа @ или длину более 254 символов.
Оптимальный объем тестов для дипломного проекта: 15–30 детальных сценариев. Кейс: при тестировании модуля оплаты студентом была пропущена проверка «нулевой суммы заказа», что привело к ошибке 500 на защите. Правильный подход — фиксация ожидаемого результата (Expected Result) и фактического (Actual Result) в таблице с вердиктом Pass/Fail.
Экспертный вывод: используйте таблицу с колонками «ID | Шаги | Ожидаемый результат | Статус». Это единственный формат, который комиссия принимает как доказательство системного подхода к проверке.
Нагрузочное тестирование: метрики производительности
Для учебного проекта не нужны тысячи пользователей, но демонстрация работы при 10–50 одновременных сессиях обязательна. Используйте инструмент JMeter или k6 для замера Response Time (времени отклика). Нормой для дипломного веб-сервиса считается ответ сервера в пределах 200–500 мс для простых запросов и до 2 секунд для сложных вычислений или тяжелых выборок из БД.
Пример: при тестировании API на Python/FastAPI время отклика выросло с 150 мс до 1.2 сек при 20 пользователях из-за неоптимизированного SQL-запроса (отсутствие индекса в таблице). Исправление индекса снизило время до 180 мс. Такие цифры в пояснительной записке поднимают оценку с «хорошо» до «отлично», так как показывают работу с производительностью.
Экспертный вывод: замеряйте метрику Error Rate. Если при 50 запросах в секунду процент ошибок превышает 1%, сервис считается нестабильным. В дипломе укажите: «Пропускная способность системы составляет X запросов/сек при среднем времени отклика Y мс».
Тестирование API и валидация данных
Если ваш сервис использует REST или GraphQL, тестирование фронтенда недостаточно. Необходимо проверить эндпоинты через Postman или Insomnia. Основной фокус — коды ответов: 200 (OK), 201 (Created), 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found) и 500 (Internal Server Error). Отсутствие обработки 404-й ошибки при запросе несуществующего ID объекта — типичный «баг новичка».
Мини-кейс: интеграция внешних API в дипломный веб-сервис часто становится узким местом. При тестировании API погоды выяснилось, что сервис «падает» при получении пустого JSON-ответа от сервера. Решение: внедрение блока try-catch и дефолтных значений, что сократило количество критических сбоев с 5% до 0%.
Экспертный вывод: обязательно приложите к диплому скриншоты из Postman с успешными ответами и JSON-телами. Это доказывает, что логика сервера отделена от интерфейса и работает корректно.
Логирование и фиксация ошибок
Логи — это «черный ящик» вашего сервиса. Вместо вывода ошибок в консоль браузера, настройте системное логирование (например, через библиотеку logging в Python или Winston в JS). В дипломе следует продемонстрировать структуру лог-файла: Timestamp | Level (INFO/WARN/ERROR) | Message. Это показывает, что вы предусмотрели мониторинг приложения в реальном времени.
Практический пример: при развертывании сервиса на бесплатном хостинге возникла ошибка подключения к БД. Благодаря логам в файле error.log было установлено, что проблема в неверном порте подключения, а не в коде. Время поиска ошибки сократилось с 2 часов до 5 минут.
Экспертный вывод: не удаляйте логи перед защитой. Покажите комиссии, как вы отслеживаете события в системе. Это переводит проект из разряда «курсовой работы» в разряд «профессионального продукта».
Автоматизация: Unit-тесты и покрытие кода
Написание Unit-тестов (PyTest, Jest, JUnit) — самый сильный аргумент в пользу качества кода. Стремитесь к покрытию (Code Coverage) в 60–80% для бизнес-логики. Тестировать 100% кода бессмысленно и дорого, но проверка ключевых функций (например, расчета стоимости заказа или валидации пароля) обязательна.
Сравнение: ручное тестирование одной функции занимает 30 секунд, но при каждом изменении кода его нужно повторять. Автотест отрабатывает за 10 мс. В проекте с 10 функциями экономия времени при итеративной разработке составляет около 5–10 рабочих часов за весь цикл разработки.
Экспертный вывод: используйте отчеты по покрытию (Coverage Report). Скриншот с процентом покрытия кода в тексте диплома — это железобетонное доказательство надежности вашего решения.
Вывод
Для успешной защиты забудьте о словах «сервис работает стабильно» — используйте только цифры. Начните с составления таблицы из 20 тест-кейсов, замерьте Response Time через k6 (цель < 500 мс) и добейтесь покрытия Unit-тестами ключевых функций не менее чем на 60%. Избегайте тестирования «на глаз» и отсутствия логов. Самая выигрышная стратегия: показать скриншот из Postman, таблицу с результатами тестов и отчет по Code Coverage — это закроет любые вопросы комиссии по техническому качеству проекта.
