Граничные значения, тест-кейсы, покрытие ветвей и баг-репорты. Сначала изучите теорию и интерактивные модели, затем выполните три практических задания и тест внизу страницы. Всё сохраняется в этом браузере автоматически.
Тест — это не произвольный набор нажатий. У хорошего теста есть исходное состояние, входные данные, действие, ожидаемый результат и фактический результат. Проверку можно повторить, а дефект — воспроизвести.
Преподаватель вводит итоговый балл студента от 0 до 100. API принимает целое число включительно в диапазоне 0…100, сохраняет его, а при неверном типе или значении возвращает ошибку валидации без записи в БД. Отправка требует роль teacher.
Оракул тестирования — источник, позволяющий определить ожидаемый результат. Здесь это явно заданное правило балла и контроля доступа, а не субъективное впечатление от интерфейса.
| Уровень | Что проверяем | Пример |
|---|---|---|
| Модульный | Маленькую функцию изолированно | validate_score(101) возвращает ошибку |
| Интеграционный | Связь компонентов | API передаёт значение в БД |
| Системный | Систему целиком | Преподаватель выставляет оценку в интерфейсе |
| Приёмочный | Готовность к бизнес-задаче | Методист проверяет сценарий ведомости |
Функциональные проверки исследуют бизнес-правила. Нефункциональные — свойства вроде задержек, устойчивости и безопасности. Регрессионное тестирование повторно проверяет, не сломали ли изменения ранее работавшие функции. Smoke-проверка быстро выявляет блокирующие проблемы в новой сборке; она не заменяет полный регресс.
При тестировании «чёрным ящиком» мы отталкиваемся от спецификации, не зная внутреннего кода. Для оценки 0…100 можно выделить класс корректных значений, значения меньше нуля, больше ста, дробные числа, строки и отсутствие значения.
| Класс входа | Пример | Ожидаемое поведение |
|---|---|---|
| Нижняя граница | 0 | Принять |
| Ниже границы | −1 | Отклонить |
| Внутри допустимого | 57 | Принять |
| Верхняя граница | 100 | Принять |
| Выше границы | 101 | Отклонить |
| Неправильный тип | "отлично" | Отклонить |
| Отсутствует значение | null | Отклонить |
Введите значение так, как оно пришло бы в текстовом поле формы. Учебный валидатор принимает только запись неотрицательного целого числа от 0 до 100 без пробелов и без ведущих нулей (кроме «0»). Дополнительное правило записи введено специально для этого упражнения; у реального API его нужно согласовать.
Правило для строки и правило для JSON-числа — разные уровни системы: реальная серверная схема может разобрать данные иначе. Всегда фиксируйте формат запроса в тест-кейсе.
При тестировании «белым ящиком» мы видим внутреннюю структуру. Например, функция сначала проверяет тип, потом диапазон, затем роль. Проверка ветвей требует тестов, при которых каждое решение принимает разные исходы. Покрытие кода не означает отсутствие дефектов — оно лишь показывает, какие элементы были исполнены.
Чтобы проверить обе стороны каждого решения, нужны входы: строка вместо числа, целое вне диапазона, корректное число с ролью student и корректное число с ролью teacher. Это учебная функция: bool в Python не принимается из-за строгой проверки type(score) is int.
Покрытие строк, ветвей и условий — разные метрики. Не используйте их как взаимозаменяемые.
| Поле тест-кейса | Пример |
|---|---|
| ID | SCORE-006 |
| Предусловия | Пользователь вошёл с ролью teacher |
| Шаги | Отправить POST /scores с score=101 |
| Ожидаемый результат | Ответ 4xx по контракту; запись в БД не изменена |
| Фактический результат | Заполняется после выполнения |
| Статус | Passed / Failed / Blocked |
В баг-репорте полезны заголовок, окружение, шаги воспроизведения, ожидаемый/фактический результат, степень серьёзности и подтверждение. Severity описывает масштаб влияния дефекта, priority — срочность исправления; они могут различаться.
Заголовок: При балле 101 сервис сохраняет запись вместо ошибки.
Условия: версия 1.4.2, учебная БД, роль teacher.
Шаги: открыть форму → ввести 101 → сохранить.
Ожидалось: сообщение о неверном диапазоне, запись без изменений.
Фактически: значение 101 сохранено.
Коды 400, 422 и другие зависят от API-контракта. В тесте не следует произвольно требовать конкретный код, если его не определили заранее.
Поле score должно находиться в диапазоне, но этого мало: сохранить оценку может только авторизованный преподаватель. Для сочетания условий удобна таблица решений. Она показывает, какие комбинации дают разрешение и отказ.
| Роль | Балл | Токен | Ожидаемый итог |
|---|---|---|---|
| teacher | 80 | действителен | Принять и сохранить |
| student | 80 | действителен | Запретить запись |
| teacher | 101 | действителен | Отклонить неверный балл |
| teacher | 80 | отсутствует | Не допустить неавторизованную запись |
Негативный тест должен проверять не только код HTTP-ответа, но и отсутствие побочного эффекта: отвергнутый запрос не меняет БД. Для этого до запроса фиксируют значение, выполняют действие, затем повторно читают запись в тестовом окружении.
Один и тот же запрос может формально вернуть 403, но ошибочно изменить данные перед ответом — такая реализация будет дефектной. Хороший тест проверяет контракт и состояние.
Даже корректная функция может стать бесполезной при массовом использовании. Нагрузочное тестирование измеряет поведение при ожидаемой интенсивности, стресс-тестирование исследует выход за обычные пределы, а длительные испытания помогают обнаруживать деградацию во времени.
Проверки безопасности не ограничиваются правильностью пароля. В «Кампусе» важно проверить, что студент не может изменить оценку другого пользователя, даже если подставит чужой идентификатор в URL. Нужны безопасные тестовые учётные записи и специально подготовленная среда.
Автоматизация нужна там, где проверки повторяют часто и результат можно сопоставить с правилом. Для учебного валидатора можно написать несколько параметризованных тестов. Они должны выполняться быстро, независимо и давать понятное сообщение при ошибке.
Здесь функция valid_score специально не реализована: студент должен сопоставить спецификацию с тем, как её проверять. Для настоящего тестирования потребуется функция проекта, а не копирование фрагмента без окружения.
Flaky test — тест с нестабильным результатом без соответствующего изменения проверяемого поведения. Причинами могут быть гонки, зависимость от времени, общая БД или непредсказуемая сеть. Систематическое исправление таких тестов важнее, чем бесконечные перезапуски до «зелёного» статуса.
Выберите один ответ в каждом вопросе и нажмите «Проверить тест». После проверки появятся разборы. Практические задания и развёрнутые вопросы проверяет преподаватель — в процентах они не учитываются.
Эти вопросы оценивает преподаватель. Не копируйте определения: приведите собственный аргумент и, где необходимо, расчёт или пример.
Теоретические сведения адаптированы для обучения. Интерактивные расчёты и сценарии — учебные модели, не измерения работающей инфраструктуры. Внешние ссылки нужны только для дополнительного чтения: сама работа открывается без интернета.
Нажмите «Отправить работу — сохранить PDF» и в диалоге печати выберите «Сохранить как PDF». В PDF попадут ФИО, ответы, результат тестирования и задания. Никакие данные не отправляются на сервер.