Классы эквивалентности, границы, таблицы решений — все эти техники из предыдущих уроков проверяют одно действие: ввели значение, нажали кнопку, получили результат. Но многие объекты в системе живут дольше одного клика. Заявка на курс, которую подал пользователь, не исчезает после отправки — она проходит путь: «черновик» → «отправлена» → «на рассмотрении» → «одобрена» или «отклонена» → «оплачена». И один и тот же вопрос — «можно ли оплатить эту заявку?» — имеет разный правильный ответ в зависимости от того, где именно на этом пути заявка сейчас находится.
Чему научишься за этот урок:
— строить диаграмму состояний по описанию поведения объекта;
— покрывать переходы по нарастающей строгости: 0-switch, 1-switch;
— целенаправленно проверять недопустимые переходы, а не только разрешённые.
Состояние и переход: определения
Состояние (state) — устойчивое положение объекта, которое сохраняется до тех пор, пока не произойдёт событие. Заявка в статусе «на рассмотрении» может провисеть в этом состоянии секунду или неделю — пока администратор её не одобрит или не отклонит, ничего в этом статусе само по себе не изменится.
Переход (transition) — событие, которое меняет состояние объекта на другое. «Администратор одобрил заявку» — это переход из состояния «на рассмотрении» в состояние «одобрена». Переход всегда происходит между конкретной парой состояний и запускается конкретным событием — не бывает перехода «просто так».
Диаграмма состояний
Диаграмма состояний рисуется просто: состояния — это узлы (обычно прямоугольники), переходы — стрелки между ними, подписанные названием события. Диаграмма делает явным то, что раньше держалось в голове разработчика: из какого состояния куда вообще можно попасть. Всё, что на диаграмме не нарисовано, по умолчанию считается недопустимым — и это самое ценное свойство диаграммы для тестировщика.
СОСТОЯНИЯ ЗАЯВКИ НА КУРС +-----------+ +------------+ +------------------+ +----------+ +-----------+ | черновик | | отправлена | | на рассмотрении | | одобрена | | оплачена | +-----------+ +------------+ +------------------+ +----------+ +-----------+ +-----------+ +-----------+ | отклонена | | отменена | +-----------+ +-----------+ ПЕРЕХОДЫ (откуда -- событие --> куда): черновик -- отправить --> отправлена отправлена -- взять в работу --> на рассмотрении на рассмотрении -- одобрить --> одобрена на рассмотрении -- отклонить --> отклонена одобрена -- оплатить --> оплачена черновик -- удалить --> отменена отправлена -- отменить --> отменена на рассмотрении -- отменить --> отменена НЕДОПУСТИМЫЕ ПЕРЕХОДЫ (должны давать корректный отказ): отклонена -- оплатить --> оплачена (нельзя оплатить отказанную заявку) отправлена -- отправить --> отправлена (нельзя отправить повторно)
Зачем это тестировщику, если раньше техники уже работали
Классы эквивалентности, границы и таблицы решений проверяют одно действие в изоляции: одна форма, один набор условий, один результат. Но переход «оплатить» — не самостоятельное событие. Он корректен, только если заявка сейчас в состоянии «одобрена». Ошибка живёт не в самом действии, а в том, что действие выполнили из неподходящего состояния — а это то, что предыдущие техники просто не умеют видеть, потому что не держат в поле зрения историю объекта.
Одна и та же кнопка «Оплатить» в интерфейсе технически доступна независимо от статуса заявки, если разработчик не поставил проверку. Диаграмма состояний прямо указывает, из какого состояния этот переход разрешён — и превращает вопрос «а что если нажать не вовремя» в конкретный тест-кейс, а не в смутное подозрение.
Три уровня покрытия
- 0-switch (покрытие состояний). Минимальный уровень: каждое состояние из диаграммы достигнуто хотя бы одним тестом. Если «отменена» ни разу не была получена ни в одном сценарии — 0-switch не выполнен.
- 1-switch (покрытие переходов). Более строгий уровень: каждый ДОПУСТИМЫЙ переход из диаграммы пройден хотя бы одним тестом. Достигнуть состояния «одобрена» — не то же самое, что проверить сам переход «одобрить»: можно попасть в «одобрена» одним путём и ни разу не проверить, что переход в «оплачена» из неё действительно работает.
- Проверка недопустимых переходов. Обязательный уровень, а не опциональный: целенаправленная попытка выполнить переход, которого нет на диаграмме (оплатить отклонённую заявку, одобрить уже оплаченную), с проверкой, что система корректно отказывает, а не проваливается в неопределённое состояние.
Три уровня идут по нарастающей строгости не случайно: 0-switch дёшев и быстро даёт базовую уверенность, что все состояния вообще достижимы; 1-switch дороже, но ловит баги в конкретных переходах; проверка недопустимых переходов — отдельная категория работы, потому что именно там чаще всего находятся баги безопасности и логики, а не мелкие визуальные огрехи.
Применяем к заявке на курс на полигоне
Возьмём диаграмму заявки на курс с полигона и распишем конкретные тесты по каждому уровню покрытия.
- 0-switch: создать заявку (черновик) → отправить (отправлена) → взять в работу (на рассмотрении) → одобрить (одобрена) → оплатить (оплачена); отдельным сценарием — довести другую заявку до «отклонена»; отдельным — до «отменена». Все шесть состояний достигнуты.
- 1-switch: к предыдущим сценариям добавляем отдельные тесты на переходы «удалить» из «черновик» и «отменить» из «отправлена» и из «на рассмотрении» — эти три перехода в сквозном сценарии выше не проверялись.
- Недопустимый переход №1: взять заявку в статусе «отклонена» и попытаться выполнить «оплатить» — ожидаем понятную ошибку («заявка отклонена, оплата недоступна»), а не успешную оплату и не аварийное поведение.
- Недопустимый переход №2: отправить заявку, затем попытаться отправить её ещё раз, пока она уже в статусе «отправлена» — ожидаем отказ или отсутствие повторного действия, а не вторую параллельную заявку в базе.
Итог:
— диаграмма состояний делает видимыми переходы, которые обычно проверяют по остаточному принципу;
— 0-switch и 1-switch — это про то, что система умеет; проверка недопустимых переходов — про то, чего система не должна допустить;
— недопустимый переход — почти всегда баг безопасности или логики, а не мелочь, которую можно отложить.
Контрольный вопрос. В тестировании состояние (state) объекта — это…
Подсказка: Вспомни, чем состояние отличается от самого события, которое его меняет.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Переход (transition) в диаграмме состояний — это…
Подсказка: Переход — это то, что происходит МЕЖДУ двумя состояниями.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как называется устойчивое положение объекта в системе, которое сохраняется до тех пор, пока не произойдёт событие? Ответь одним словом.
Подсказка: Слово из заголовка этого урока, стоящее первым.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Заявка на курс находится в статусе «на рассмотрении». Согласно диаграмме состояний из урока, какие переходы допустимы из этого статуса напрямую (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Посмотри в блоке «Переходы» из урока, какие события выходят именно из статуса «на рассмотрении».
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Покрытие 0-switch (покрытие состояний) означает, что тесты…
Подсказка: 0-switch — самый базовый, минимальный уровень покрытия.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Чем покрытие 1-switch (покрытие переходов) строже, чем 0-switch?
Подсказка: Достигнуть состояния можно разными путями, не проверив при этом каждый отдельный переход в него.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Заявка в статусе «отклонена». Пользователь пытается выполнить переход «оплатить». Согласно диаграмме состояний из урока, этот переход допустимый или недопустимый?
Подсказка: Проверь блок «Недопустимые переходы» из урока — там прямо разобран этот случай.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Заявка на курс только что создана и ещё не отправлена администратору. В каком статусе она находится, согласно диаграмме из урока? Ответь одним словом, как в уроке.
Подсказка: Это самое первое состояние в диаграмме, до отправки.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Пользователь повторно нажал кнопку «Отправить заявку» на заявке, которая уже находится в статусе «отправлена», пока страница ещё не обновилась. Согласно диаграмме из урока, к какому типу переходов относится действие «отправить» из статуса «отправлена» обратно в «отправлена»? Ответь одним словом, как в уроке.
Подсказка: Сверься с разделом про то, каких переходов нет на диаграмме.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Из статуса «черновик» в диаграмме урока доступны ровно два перехода: один ведёт к статусу «отправлена», другой — к статусу «отменена». Как называется событие, которое переводит заявку из «черновик» сразу в «отменена»?
Подсказка: Это не тот переход, что ведёт к «отправлена» — ищи второй.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. На полигоне заявка на курс проходит статусы: черновик -> отправлена -> на рассмотрении -> одобрена -> оплачена, а также может уйти в «отклонена» или «отменена». Составь минимальный набор тестов для покрытия уровня 1-switch (каждый ДОПУСТИМЫЙ переход хотя бы раз) для всей диаграммы из урока, включая ветку «отклонена» и все переходы «отменить». Оформи как нумерованный список: тест — какие переходы он закрывает.
Принято, если суммарно закрыты все 8 переходов из контекста, например: (1) сквозной сценарий черновик->отправлена->на рассмотрении->одобрена->оплачена (закрывает переходы отправить, взять в работу, одобрить, оплатить); (2) отдельный сценарий на отклонение: черновик->отправлена->на рассмотрении->отклонена (закрывает отклонить); (3) отдельный тест на переход черновик->отменена (удалить); (4) отдельный тест на переход отправлена->отменена (отменить); (5) отдельный тест на переход на рассмотрении->отменена (отменить). Пять тестов покрывают все 8 допустимых переходов.
Полный список допустимых переходов из урока: черновик->отправлена (отправить), отправлена->на рассмотрении (взять в работу), на рассмотрении->одобрена (одобрить), на рассмотрении->отклонена (отклонить), одобрена->оплачена (оплатить), черновик->отменена (удалить), отправлена->отменена (отменить), на рассмотрении->отменена (отменить).
Подсказка: Всего 8 допустимых переходов из контекста — на каждый нужен минимум один тест, но несколько переходов можно закрыть одним длинным сквозным сценарием.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Задание. В диаграмме состояний из урока не показан явный переход из статуса «оплачена» ни в один другой статус — оплаченная заявка считается конечной. Тестировщик предполагает, что в реальной системе должен существовать способ вернуть заявку из «оплачена» назад, например при возврате денег администратором. Опиши одним предложением, какую проверку нужно провести в первую очередь, прежде чем тестировать такой переход.
Критерий приёмки: Нужно свериться с требованием или уточнить у аналитика/заказчика, предусмотрен ли переход «возврат» из статуса «оплачена», и только после подтверждения добавлять его в диаграмму состояний и тестировать — а не проверять как факт непроверенное предположение тестировщика.
Подсказка: Речь не про технический тест в самой системе, а про источник истины о допустимости перехода до того, как его вообще включать в диаграмму.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Что дальше
Диаграмма состояний хорошо описывает объект с одним измерением поведения — статусом заявки. Но что делать, когда параметров несколько сразу и они независимы друг от друга: браузер, устройство, роль пользователя, способ оплаты? Полный перебор всех сочетаний быстро становится нереальным. В следующем уроке разберём попарное тестирование — способ управляемо сократить комбинаторный перебор, честно называя, каким риском это сокращение оплачивается.
