Нейросеть для тестировщика: тест-кейсы, чек-листы и баг-репорты

Тестировщик тратит заметную часть времени на текст: читает требования, пишет тест-кейсы, оформляет баги. Именно с текстом модели справляются хорошо, но с оговоркой: они уверенно дописывают то, чего в требованиях нет. Ниже разберём, как использовать нейросеть для тестировщика так, чтобы она ускоряла рутину, а полноту проверок по-прежнему гарантировали вы.

Все примеры работают через OpenAI-совместимый API с адресом https://api.zukko.pro/v1 и ключом fetch_.... Модель и промпты можно подставить в любой клиент, а в конце есть скрипт для пакетной обработки.

Что отдавать модели, а что оставлять себе

Модель хорошо перечисляет и форматирует. Решение о том, что важно проверять в вашей системе, остаётся за человеком.

Тест-кейсы из требований

Главный приём: жёстко ограничить модель текстом требований и попросить явно помечать допущения.

Колонка «Ссылка на пункт требования» нужна для контроля: кейс без ссылки либо выдуман, либо относится к неописанному поведению, и его стоит разобрать отдельно. Раздел «Вопросы» превращается в список уточнений для аналитика, а это полезный побочный результат.

Если в проекте есть скриншоты макетов, можно приложить их к запросу: модели, у которых в таблице стоит «картинки на вход: да» (например claude-sonnet-5-5, gpt-6.1-sol), принимают изображения. Отдельно про это написано в статье Анализ скриншотов для QA↗.

Как проверять полноту покрытия

Самое слабое место при генерации кейсов — пропущенные ветки. Три способа проверки:

1. Обратная трассировка. Попросите отдельным запросом выписать из требования все проверяемые утверждения, пронумеровать их, а затем сопоставить с ID кейсов. Утверждения без кейсов — дыры.
2. Техники тест-дизайна. Явно запросите разбиение на классы эквивалентности и граничные значения по каждому полю ввода, а затем сверьте с кейсами.
3. Второй проход «найди пробелы». Передайте требование и готовый набор кейсов и спросите, какие сценарии не покрыты: отказы внешних сервисов, одновременные действия, права доступа, повторная отправка формы. Ответ не истина, а подсказка для вашей ревизии.

Хорошая практика — делать генерацию и проверку разными запросами, а при желании и разными моделями: так у проверки больше шансов заметить то, что пропустила генерация.

Чек-листы и баг-репорты

Чек-лист для релиза или новой фичи модель собирает быстро, если дать ей контекст: тип продукта, платформы, что менялось. Просите группировать пункты по приоритету и помечать те, что можно автоматизировать.

Для баг-репортов дайте сырые заметки и шаблон:

Строка «не добавляй» важна: без неё модель с удовольствием домыслит версию браузера или шаг воспроизведения. Серьёзность модель только предлагает, решение за вами.

Анализ кода и автотесты

Если вы пишете автотесты, модель может помочь и с кодом. Передайте функцию или diff и спросите, какие поведения стоит проверить: ветки условий, обработка пустых значений, исключения. Для автоматической проверки кода в пайплайне есть отдельный разбор AI code review↗, а генерацию тестов агентом в репозитории разбирает статья Генерация тестов в Claude Code↗.

Сгенерированные автотесты обязательно запускайте и читайте: тест, который проходит всегда, хуже отсутствия теста.

Скрипт для пакетной обработки

Вот минимальный пример: на вход файл с требованием, на выходе таблица кейсов.

import sys
from openai import OpenAI

client = OpenAI(base_url="https://api.zukko.pro/v1", api_key="fetch_...")

PROMPT = open("prompt_testcases.txt", encoding="utf-8").read()

def make_cases(requirement: str) -> str:
    resp = client.chat.completions.create(
        model="claude-sonnet-5-5",
        messages=[
            {"role": "system", "content": PROMPT},
            {"role": "user", "content": requirement},
        ],
    )
    print("токены:", resp.usage.prompt_tokens, resp.usage.completion_tokens, file=sys.stderr)
    return resp.choices[0].message.content

if __name__ == "__main__":
    text = open(sys.argv[1], encoding="utf-8").read()
    print(make_cases(text))

Запускать так: python make_cases.py requirement.md > cases.md. Для регулярной работы модели имеет смысл вынести промпт в файл и версионировать его вместе с проектом.

Сколько это стоит

Допустим (условные объёмы для примера), требование занимает 2000 токенов, а ответ с таблицей кейсов 3000 токенов. Цены на 18 октября 2026, $ за 1M токенов:

Пятьдесят таких требований: примерно $0.34 на claude-sonnet-5-5 и $0.007 на deepseek-v4.1-flash. Какая модель лучше справится с вашими требованиями, не скажет ни таблица цен, ни индекс силы: возьмите три реальных требования и сравните результаты на глаз. Актуальные цены — GET https://api.zukko.pro/v1/models.

Что нельзя отдавать модели

• Реальные персональные данные пользователей и содержимое боевых баз. Для тестовых данных используйте синтетические наборы, см. Генерация тестовых данных↗.
• Закрытый код и требования, которые нельзя отправлять третьим лицам по политике вашей компании. Свериться с политикой стоит до начала.

Чтобы попробовать, создайте ключ в кабинете, подставьте его в скрипт и прогоните одно своё требование.

Частые вопросы

Заменит ли нейросеть тестировщика?

Нет. Она ускоряет написание черновиков, но определять риски, понимать контекст продукта и принимать решение «релизим или нет» по-прежнему должен человек. Модель не знает, как система ведёт себя на самом деле.

Какую нейросеть для проверки кода выбрать?

Начните с недорогой модели и проверьте на своём коде: у каждой свои сильные стороны, а утверждать здесь что-то заранее нельзя. Ориентируйтесь на цену, размер контекста и результат на ваших примерах.

Как не получить выдуманные тест-кейсы?

Ограничьте модель текстом требований, требуйте ссылку на пункт для каждого кейса и просите выносить недостающую информацию в отдельный список вопросов. Кейсы без ссылки разбирайте вручную.

Можно ли генерировать кейсы по скриншоту макета?

Да, если выбрана модель с поддержкой изображений на вход. Опишите в запросе, что именно проверять, и сверьте результат с макетом: детали интерфейса модель иногда читает неточно.