Нейросети для тестировщика: кейсы и эталон проверки — это порядок, при котором модель составляет таблицу тест-кейсов по фиксированному контракту, а человек сверяет каждую строку с правилом. Ниже — учебный вход, полный копируемый промпт и ручной эталон на 14 строк.
Учебный вход и ручной эталон
Работа начинается с требования, записанного так, чтобы его можно было проверить построчно. Учебная форма бронирования, сервисы и модель не запускались. Фиксированный контракт: ресурс R7; дата 2027-02-08; часовой пояс UTC+03:00; момент отправки 09:00; точность 1 минута; все старты ниже указаны в этот день и в этой зоне. У ресурса уже занято [10:00; 11:00).
Правила формулируются отдельными пунктами. R1: начало >= 09:00, равенство допустимо. R2: длительность — целое число минут от 30 до 240 включительно и кратна 30. R3: полуоткрытые интервалы не пересекаются; конец одной брони может совпадать с началом другой. R4: если все правила выполнены, запрос принят и одна бронь создана; иначе отклонён и новая бронь не создана. Точный текст сообщения задан лишь для конфликта: «Это время уже занято». Для других ошибок точные тексты и HTTP-коды не определены.
Ручной эталон — это таблица, где у каждой строки есть вход и ожидаемый итог со ссылкой на правило. Эталон строится человеком до обращения к модели, и он же служит мерой проверки ответа.
| ID | Вход start, duration | Ожидаемый итог | Правило |
|---|---|---|---|
| T01 | 11:00, 29 | отклонён | R2 |
| T02 | 11:00, 30 | принят | R1–R3 |
| T03 | 11:00, 31 | отклонён | R2 |
| T04 | 11:00, 239 | отклонён | R2 |
| T05 | 11:00, 240 | принят | R1–R3 |
| T06 | 11:00, 241 | отклонён | R2 |
| T07 | 11:00, 270 | отклонён | R2 |
| T08 | 08:59, 30 | отклонён | R1 |
| T09 | 09:00, 30 | принят | R1–R3 |
| T10 | 09:01, 30 | принят | R1–R3 |
| T11 | 10:30, 60 | отклонён, «Это время уже занято» | R3 |
| T12 | 11:00, 30 | принят, смежность | R3 |
| T13 | 11:00, 45 | отклонён | R2 |
| T14 | 11:00, 60 | принят | R1–R3 |
В каждой принятой строке создана одна бронь, в отклонённой — 0. Кейсы независимы, база сбрасывается к общей исходной броне. Значения 29/30/31 и 239/240/241 покрывают соседей обеих числовых границ, при этом часть отказов одновременно связана с кратностью. Значение 270 уже явно запрещено диапазоном, это не пробел. Для класса кратности добавлены отдельные строки T13 и T14.
Почему исходное состояние восстанавливается перед каждой строкой
Строки T02 и T12 содержат одинаковый ввод и выделяют разные проверки. T02 показывает допустимую длительность на нижней границе. T12 показывает допустимое начало сразу после окончания занятого интервала. Ожидаемый результат у них согласован: запрос принят. В рабочем наборе можно связать эти проверки с общей строкой, сохранив ссылки на оба требования.
Перед следующей строкой удаляется бронь, созданная предыдущим кейсом, и восстанавливается исходная занятость ресурса. Иначе принятый запрос изменит предусловия следующего теста, а его отказ будет вызван накопленным состоянием. Такой результат уже нельзя сравнивать с независимым эталоном из таблицы.
Для отклонённого запроса проверяйте также отсутствие новой записи. Одного текста ошибки недостаточно: по R4 отказ означает, что бронь не создана. Для принятого запроса проверяйте создание записи с указанным временем и длительностью. Эти проверки состояния дополняют ожидаемый статус и не требуют придумывать текст сообщения или HTTP-код.
Полный копируемый промпт
Промпт ниже содержит весь контракт дословно, без placeholder и многоточий. Его можно скопировать целиком и вставить в чат с моделью.
По следующему учебному контракту составь таблицу ID|предусловия|шаг|вход start,duration|ожидаемый итог|правило. В каждом кейсе выполняй один шаг: отправь форму R7 с указанными данными. Общие предусловия из контракта действуют для всех строк. Не добавляй статусы и тексты ошибок сверх контракта. Отдельно перечисли вопросы, которые не решаются данным контрактом. Контракт:
Учебная форма бронирования, сервисы/модель не запускались. Фиксированный контракт: ресурс R7; дата 2027-02-08; часовой пояс UTC+03:00; момент отправки 09:00; точность 1 минута; все нижеуказанные старты в этот день и зоне. У ресурса уже занято [10:00; 11:00). R1: начало >= 09:00, равенство допустимо. R2: длительность — целое число минут от 30 до 240 включительно и кратна 30. R3: полуоткрытые интервалы не пересекаются; конец одной брони может совпадать с началом другой. R4: если все правила выполнены, запрос принят и одна бронь создана; иначе отклонён и новая бронь не создана. Точный текст сообщения задан лишь для конфликта: «Это время уже занято». Для других ошибок точные тексты и HTTP-коды не определены.
Под себя меняются только значения внутри контракта: [ресурс], [дата], [часовой пояс], [момент отправки], [занятый интервал], а также границы и шаг кратности в R2. Вводная часть промпта остаётся неизменной: она задаёт формат таблицы, один шаг на кейс и запрет на добавление статусов сверх контракта.
Вариации той же задачи для смежных проверок:
По тому же контракту составь отрицательные кейсы для R1, R2 и R3: для каждого правила приведи по два входа, которые нарушают только выбранное правило из этой тройки. Для каждого кейса укажи правило и проверь по R4, что запрос отклонён и новая бронь не создана.
По тому же контракту составь пары кейсов на смежность: конец одной брони совпадает с началом другой. Для каждой пары укажи оба входа и ожидаемый итог.
По тому же контракту перечисли вопросы, которые не решаются его текстом, и для каждого вопроса напиши, какое уточнение у разработчика или аналитика снимет неопределённость.
По тому же контракту проверь мою таблицу: для каждой строки укажи, какое правило она проверяет, и отметь строки, где ожидаемый итог не следует из контракта.
Проверка значений по эталону
Ответ модели сверяется с эталоном построчно. Для каждой строки проверяется три вещи: вход совпадает с эталонным, ожидаемый итог совпадает, ссылка на правило указывает на то правило, которое действительно нарушено или выполнено. Строка T11 проверяется отдельно: у неё есть точный текст сообщения, и он должен совпадать с контрактом дословно.
Отрицательный пример показывает, как выглядит ошибка. Если модель отвечает на T01 «принят», это противоречит R2: длительность 29 минут меньше нижней границы 30. Если модель отвечает на T08 «принят», это противоречит R1: старт 08:59 раньше 09:00. Если модель отвечает на T11 «отклонён» без текста сообщения, строка неполна: контракт задаёт точный текст для конфликта.
| Что проверяется | Как выглядит верно | Как выглядит ошибка |
|---|---|---|
| Вход | 11:00, 29 | 11:00, 30 вместо 29 |
| Ожидаемый итог | отклонён | принят |
| Ссылка на правило | R2 | R1 |
| Текст конфликта | «Это время уже занято» | выдуманный текст или пропуск |
| Число броней | 0 в отклонённой строке | 1 в отклонённой строке |
Ручная сверка идёт по четырём условиям. Каждая строка ссылается на правило. Интервалы принятых строк не пересекают занятый интервал 10:00–11:00. Перед каждым кейсом восстанавливается один и тот же исходный state. Ни один ожидаемый итог не требует статуса «подтверждена» или текста, которого нет в контракте.
Что модель подготавливает и чего не доказывает
Нейросеть подготавливает тестовую документацию: таблицу кейсов, предусловия, шаги и ожидаемые результаты. Эта таблица сама не доказывает, что приложение работает. Она фиксирует, что именно нужно проверить, и даёт человеку основу для сверки.
В документации qTest от Tricentis описан похожий порядок: тест-кейс хранится в разделе Test Design, содержит сценарий, шаги и ожидаемые результаты, а генерация по требованию доступна через инструмент AI test case creation. Там же указано, что перед использованием функции нужно включить AI integration на уровне сайта и AI Generated Test Cases в проекте. Модель в этом сценарии готовит черновик, который затем правится вручную.
Разделение ролей выглядит так. Модель предлагает формулировки шагов и заполняет таблицу по контракту. Человек проверяет каждую строку против правил и решает, какие кейсы попадут в набор. Приложение проверяется отдельно, запуском на реальном стенде.
Пробелы требований и границы контракта
Часть вопросов контракт не решает, и модель не должна придумывать на них ответы. К таким вопросам относятся: конкурирующая одновременная запись, максимум дней вперёд для брони, доступ к ресурсу. По этим темам в контракте нет правила, поэтому ожидаемый итог для них не выводится.
Значение 270 уже явно запрещено диапазоном R2: отказ следует из верхней границы. В эталоне этот очевидный отрицательный случай сохранён как T07; дополнительного уточнения требования он не требует. Соседи границ 29/30/31 и 239/240/241 проверяют переход через границу, но часть этих отказов одновременно связана с кратностью. Для чистого класса кратности служат T13 и T14.
Отдельный список открытых вопросов — часть результата. Модель перечисляет их после таблицы, а тестировщик решает, какие из них требуют уточнения у аналитика. Так пробел требования отделяется от уже определённого отрицательного случая.
Как встроить в рабочий процесс
Порядок действий для команды:
- Зафиксировать контракт: ресурс, дату, зону, момент отправки, занятый интервал и правила R1–R4.
- Составить ручной эталон до обращения к модели: строки с входом, ожидаемым итогом и ссылкой на правило.
- Отправить полный промпт с контрактом дословно.
- Сверить ответ с эталоном построчно по входу, итогу и правилу.
- Отдельно проверить строки с точным текстом сообщения.
- Выписать открытые вопросы и передать их аналитику.
- Запустить проверку на стенде и зафиксировать фактические результаты.
Шаги 1–3 готовят документацию, шаги 4–7 проверяют её и приложение. Смешивать эти этапы не стоит: таблица кейсов и результат прогона — разные артефакты.
Частые вопросы
Нейросети для тестировщиков заменяют ручное составление кейсов?
Модель готовит черновик таблицы по контракту, а человек сверяет каждую строку с правилами. Ручной эталон строится до обращения к модели и служит мерой проверки. Замена ручной работы здесь не предполагается.
Как проверить, что модель не выдумала ожидаемый результат?
Сверьте каждую строку с эталоном по трём признакам: вход, ожидаемый итог, ссылка на правило. Строки с точным текстом сообщения проверяются отдельно. Если итог не следует из контракта, строка не принимается.
Что делать с вопросами, которые контракт не решает?
Их нужно выписать отдельным списком после таблицы. К таким вопросам относятся конкурирующая одновременная запись, максимум дней вперёд и доступ к ресурсу. Ответы по ним модель не придумывает, их уточняют у аналитика.
Зачем нужны соседи числовых границ?
Значения 29/30/31 и 239/240/241 проверяют переход через границы R2. Часть таких отказов одновременно связана с кратностью, поэтому для чистого класса кратности добавляются отдельные строки. Значение 270 уже запрещено диапазоном; в таблице оно сохранено как явный отрицательный случай T07.
Можно ли использовать этот промпт для другого требования?
Да, меняются значения внутри контракта: ресурс, дата, часовой пояс, момент отправки, занятый интервал и границы R2. Вводная часть промпта остаётся неизменной. Ручной эталон при этом составляется заново под новое требование.