Права и условия: строим таблицу решений
Проверяем сочетания сессии, команды, роли, состояния и данных без случайного перебора.
- Построить таблицу решений из контрактного порядка проверок.
- Убрать невозможные сочетания, сохранив различимые результаты.
- Не смешивать права чтения и публикации.
Почему одного позитивного и одного негативного сценария мало
Публикация зависит от нескольких условий. Тот же title может успешно публиковаться у автора и давать отказ у обычного участника. Даже правильные права не заменяют корректное состояние. ИИ часто перечисляет отдельные проверки «нет входа», «плохая строка», «нет прав», но теряет их приоритет: какой ответ ожидается, если одновременно нет прав и неверны данные? Таблица решений делает такие ожидания явными.
В OD-1 порядок R7 специально зафиксирован для обучения. Сначала нужна сессия, затем существование объекта в команде, затем право publish, состояние и данные. Чтение и создание имеют отдельный контракт R8; R7 не используется для вывода их кодов. В другом API порядок и способ маскировки объектов могут отличаться. Не переносите учебный 403 или 404 в рабочую систему как универсальную норму. Сначала найдите её контракт и согласуйте политику раскрытия существования.
Сокращённая таблица OD-1
| Сессия | Объект в команде | Автор или editor | Draft | Данные публикации | Ответ |
|---|---|---|---|---|---|
| Нет | — | — | — | — | 401 |
| Да | Нет | — | — | — | 404 |
| Да | Да | Нет | — | — | 403 |
| Да | Да | Да | Нет | — | 409 |
| Да | Да | Да | Да | Нет | 422 |
| Да | Да | Да | Да | Да | 200, published |
Что означает прочерк
Прочерк означает, что условие не влияет на результат данного правила из-за более ранней проверки. Это не разрешение заменить все оставшиеся значения одним случайным примером навсегда: при отдельной задаче о диагностике ошибок могут потребоваться дополнительные сочетания. Для текущей модели достаточно воспроизвести каждую различимую ветвь и добавить варианты участников, которые ловят ошибки выражения «автор ИЛИ редактор».
Разделите успешную строку минимум на три примера: автор-user, автор-editor и чужой editor той же команды. Добавьте чужого user с отказом 403. Так вы обнаружите реализацию, в которой ошибочно требуется одновременно быть автором и editor. При этом чтение чужого draft для editor остаётся запрещённым по R4. Использование одинакового пользователя для всех запросов скроет эту разницу.
Проверяем таблицу модели
Попросите ИИ объяснить, почему каждая строка выполнима, какие правила она покрывает и чем отличается от соседней. Затем ищите противоречие вручную. «Неавтор, но автор» — невозможное сочетание; «сессии нет, роль editor» — роль запроса ещё не установлена. Исключайте невозможные строки с пояснением, а не молча. Учебный endpoint publish намеренно задаёт отдельную политику от endpoint read.
Для проверки отказа недостаточно увидеть код. Сравните состояние задачи до и после:403,409 и 422 не должны скрытно переводить её в published. В успешной строке получите задачу повторным разрешённым чтением и убедитесь, что автор и title не изменились. Это связывает ветвь решения с бизнес-эффектом, а не только с интерфейсом.
Итог урока
Хорошая таблица компактна потому, что вы понимаете правила свёртки, а не потому, что выбрали удобное число тестов. Сохраните рядом версию контракта, фикстуры акторов и состояния. Если команда позже разрешит editor читать черновики, изменится R4 и набор read; из этого не следует автоматическая смена publish. Именно такая прослеживаемость делает таблицу полезной при изменениях.
ЗАДАЧА Построй сокращённую таблицу решений для publish. КОНТЕКСТ OD-1, последовательные проверки R7; отдельно проверь выражение author OR editor. ВХОДНЫЕ ДАННЫЕ Учебный продукт OrbitDesk, версия правил OD-1. Все имена и данные вымышлены. R1: title — строка от 1 до 80 кодовых точек Unicode включительно. При сохранении пробелы автоматически не удаляются. R2: description — строка от 0 до 2000 кодовых точек. Пустая строка разрешена, null не является строкой. R3: новая задача получает состояние draft и автора из серверной сессии. R4: читать draft может только автор; published виден всем вошедшим участникам той же команды. Роль editor сама по себе не открывает чужой draft. R5: опубликовать draft может автор или editor из той же команды. При публикации title.trim() не должен быть пустым. trim — поведение JavaScript String.prototype.trim; сохранённое значение не изменяется. R6: публикация переводит draft в published. Повторная публикация published отклоняется с 409, состояние не меняется. R7: в учебном API проверки публикации идут в порядке: сессия 401 → существование/команда 404 → права 403 → состояние 409 → данные 422 → успех 200. Это контракт кейса, не универсальное правило API. R8: создание (create): без сессии — 401; неверный тип или длина title/description — 422 без создания; переданные клиентом authorId, teamId или state отклоняются с 422; успех — 201 и одна новая задача draft с новым ID, автором из сессии и исходными строками без trim. Чтение (read): без сессии — 401; неизвестный объект, чужая команда или чужой draft — 404 без содержимого задачи; разрешённое чтение — 200 с объектом. R9: отказ в create/read/publish не меняет объекты; read не меняет данные. Успешный publish меняет только состояние существующей задачи, сохраняя ID, автора, title и description; дополнительная задача не создаётся. Акторы и фикстуры: Анна — user, автор t1, команда A; Борис — user, не автор t1, команда A; Вера — editor, не автор t1, команда A; Глеб — editor, команда B. Дина — editor и автор отдельной задачи t2 команды A для проверки сочетания автор-editor. Если не указано иное, t1 — draft с title="Проверить экспорт" и description="". Обозначения t1/t2 — учебные псевдонимы фактически полученных ID, а не требование к генератору ID. Перед независимым тестом фикстура восстанавливается. ОГРАНИЧЕНИЯ Укажи невозможные сочетания. Прочерк объясни. Не смешивай read и publish. Проверяй эффект операции вместе с кодом. ОЖИДАЕМЫЙ ФОРМАТ Таблица условий и исходов; выполнимые тестовые примеры; риски свёртки.
Используйте разрешённый ИИ-сервис. Не отправляйте рабочие секреты и персональные данные.
Источники и проверка фактов
ISTQB — CTFL v4.0, программа и материалыРазделы анализа и проектирования тестов; курс использует собственные учебные примеры, не является подготовкой к сертификации.OWASP API 1: Broken Object Level AuthorizationПрава нужно проверять для конкретного объекта и действия на сервере; скрытая кнопка не является проверкой доступа.Авторский учебный материал · Редакция QA Orbit · версия 2026-10-28.1