Генерация тест-кейсов полезна, когда требования сформулированы, но команде трудно увидеть пропущенные ситуации. Нейросеть быстро предлагает варианты, однако количество сценариев не равно покрытию. Десятки проверок успешного входа могут оставить без внимания блокировку аккаунта. Начните с матрицы требований и требуйте связи каждого теста с конкретным правилом.
Подготовьте требования
Разбейте описание на утверждения с идентификаторами. Например, R1 задаёт допустимый диапазон количества, R2 описывает скидку, R3 определяет реакцию на отсутствие товара. Отдельно перечислите роли, состояния системы и внешние ограничения. Слова «быстро», «удобно» и «корректно» ещё не являются ожидаемыми результатами: их необходимо уточнить до генерации тестов.
Попросите модель сначала найти противоречия. Если одно правило разрешает гостевой заказ, а другое требует зарегистрированного пользователя на любом этапе, тестировщик не должен самостоятельно выбирать трактовку. Сохраните вопрос владельцу продукта и пометьте зависимые тесты как заблокированные. Это предотвращает появление уверенного, но выдуманного поведения.
Соберите покрытие
- Для каждого требования выделите обычный успешный сценарий.
- Добавьте границы допустимых значений и соседние недопустимые значения.
- Проверьте пустые поля, неверные типы и отсутствующие зависимости.
- Для состояния системы опишите допустимые и запрещённые переходы.
- Добавьте повторную отправку и частичный сбой, если они относятся к функции.
- Укажите приоритет по последствиям ошибки, а не по простоте выполнения.
Пример количества товара
Все числа учебные. Требование разрешает заказать от 1 до 10 единиц включительно. Полезный набор содержит 0, 1, 10 и 11, пустое значение и дробное 1,5, если поле должно быть целым. Значения 3, 4 и 5 не дают такого же прироста покрытия, как границы. Но диапазон ничего не говорит о складском остатке: этот вопрос требует отдельного требования.
Для теста с 11 единицами недостаточно написать «появляется ошибка». Укажите, что заказ не создаётся, остаток не уменьшается, значение сохраняется для исправления и показывается согласованное сообщение. Если детали не определены, перечислите их как предлагаемые критерии, которые должен подтвердить владелец продукта.
Промпт
Создай матрицу покрытия требований. Сначала перечисли неоднозначности, ничего не додумывай. Для каждого теста нужны ID требования, предусловия, данные, действие, наблюдаемый результат и приоритет. Покрой границы, запрещённые переходы и повторное действие. Отдельно покажи требования без тестов и тесты без основания. Не повторяй одинаковый сценарий с косметически другими данными.Проверьте ожидаемые результаты
Ожидание должно быть наблюдаемым и независимым от реализации. «Вызывается функция validate» обычно слабее, чем «недопустимый заказ не сохраняется». Внутренние вызовы нужны там, где они являются контрактом. Разделите проверки интерфейса, API и бизнес-логики: один огромный браузерный тест труднее диагностировать, чем проверки на подходящих уровнях.
Если требования описаны API-контрактом, используйте конкретные схемы и обязательные поля. Спецификация OpenAPI определяет структуру такого описания, но не заменяет бизнес-требования. Наличие кода ответа в документе не доказывает, что сервер действительно ведёт себя указанным образом.
Выберите по одному сценарию каждой категории и выполните вручную. Другой человек должен понимать предусловия без переписки с автором. Проверьте очистку данных и независимость порядка запуска. Для дат, случайных значений и внешних сервисов укажите управляемые условия, иначе тест будет давать разные результаты без изменения продукта.
Сохраните версию требований рядом с набором. При изменении правила обновите связанные тесты и проверьте соседние сценарии. Не удаляйте проверку только потому, что она стала падать: сначала выясните, изменился контракт или появилась регрессия. В отчёте различайте «не запускали», «заблокирован», «пройден» и «обнаружена ошибка».
Частые вопросы
Сколько тестов достаточно?
Универсального числа нет. Важны покрытые правила, риски и классы данных. Небольшой осмысленный набор полезнее сотни однотипных примеров.
Можно ли сразу генерировать автотесты?
Да, после согласования поведения. Иначе автоматизация закрепит ошибочную интерпретацию требований. Сначала проверьте один сценарий и подход к тестовым данным, затем расширяйте набор.
Кто определяет приоритет?
Команда, учитывая ущерб и частоту сценария. ИИ может предложить аргументы, но не знает реальные обязательства продукта без предоставленного контекста.
Гайд подготовлен для Tarasov Code — проекта Ильи Тарасова и TarasovWeb.