TL;DR
GHL — метод генерации тест-кейсов из требований к ПО через два промпта вместо одного. Сначала LLM извлекает подходящие техники тестирования (equivalence partitioning, boundary value analysis, state transition testing и др.) из стандарта ISO/IEC/IEEE 29119-4. Затем для каждой техники генерирует отдельный набор тест-кейсов. Весь процесс — только промпты, без создания RAG (retrieval-augmented generation).
Проблема: Когда просишь LLM "создай тест-кейсы" одним промптом (zero-shot), модель генерирует хаотично и пропускает 60-98% важных сценариев. Причина — нет структуры. LLM не понимает какие методы проверки применить, поэтому генерирует поверхностно. В индустрии используют RAG — добавляют базу знаний по каждой предметной области. Но создавать RAG для каждого типа ПО (от бухгалтерии до автомобильных систем) — трудоёмко.
Решение: Двухшаговый промпт. Шаг 1 — модель сама выбирает какие техники тестирования подходят для конкретных требований. Шаг 2 — генерирует тест-кейсы по каждой технике отдельно. Это даёт полноту охвата (recall 0.84 для Bluetooth, 0.37 для Mozilla) и экономит ~480 минут на 100 тест-кейсах (20 мин vs 500 мин вручную).
Схема метода
ШАГ 1: Извлечь test design techniques
Входы: requirements + test strategy + стандарт ISO/IEC/IEEE 29119-4
Выход: список техник (equivalence partitioning, boundary value, etc)
ШАГ 2: Для каждой техники генерировать тест-кейсы
Входы: requirements + конкретная техника из Шага 1
Выход: набор тест-кейсов для этой техники
Итого: объединение всех наборов = полный список тест-кейсовКаждый шаг — отдельный запрос к LLM. Если на Шаге 1 получили 7 техник → на Шаге 2 будет 7 запросов.
Пример применения
⚠️ Важно: Метод оптимизирован для сложных технических требований с чёткой структурой. Не для субъективных задач или творческих текстов.
Задача: Ты продакт-менеджер в финтех-стартапе. Получил требования к фиче "Регулярные платежи" для мобильного банка. Нужно проверить полноту требований — какие сценарии могут сломаться в продакшене. Вместо RAG по банковским системам используешь GHL-подход.
Промпт (Шаг 1):
Вот требования к фиче "Регулярные платежи":
[вставить текст требований]
Из стандарта ISO/IEC/IEEE 29119-4 извлеки подходящие техники тестирования для этих требований. Если не можешь определить точно — предложи наиболее популярные техники из стандарта для такого типа функциональности.Промпт (Шаг 2, повторить для каждой техники):
Вот требования к фиче "Регулярные платежи":
[вставить текст требований]
Создай максимально полный список тест-кейсов используя технику . Включи нормальные и аномальные сценарии. Результат:
На Шаге 1 модель предложит 5-7 техник: Boundary Value Analysis (граничные значения), Equivalence Partitioning (классы эквивалентности), State Transition Testing (переходы состояний), Decision Table Testing (таблицы решений), Error Guessing (предположения об ошибках).
На Шаге 2 для каждой техники получишь 10-30 тест-кейсов. Например, для Boundary Value Analysis: "Проверить платёж на сумму 0.01₽", "Проверить платёж на лимит 100,000₽", "Проверить платёж на лимит+1₽". Для State Transition: "Создать → Активировать → Пауза → Возобновить → Отменить" и все комбинации переходов.
Итого: 70-150 тест-кейсов вместо 10-20 которые придумал бы сам. Многие покроют неочевидные баги: что если пользователь меняет карту во время исполнения платежа? Что если дата платежа попадает на выходной? Что если баланс = сумме платежа - 0.01₽?
Почему это работает
Слабость LLM: В zero-shot промпте ("создай тест-кейсы") модель не понимает какую структуру использовать. Она генерирует хаотично, фокусируясь на очевидных сценариях ("проверить успешный платёж"). Пропускает методичную проверку граничных значений, комбинаций состояний, таблиц решений.
Сильная сторона LLM: Модель отлично следует методологиям если их явно назвать. Знает что такое Boundary Value Analysis, Equivalence Partitioning, State Transition Testing — это стандартизированные техники из ISO/IEC/IEEE 29119-4. Если указать конкретную технику в промпте — модель методично применит её принципы.
Как метод использует силу: Шаг 1 заставляет модель самой выбрать методологии для конкретных требований. Это активирует знания стандарта. Шаг 2 применяет каждую методологию изолированно — модель фокусируется на одном подходе, не путает разные техники. Итог: полнота (recall 0.84 для Bluetooth) вместо хаоса (recall 0.02 в zero-shot для Mozilla).
Рычаги управления:
- Количество техник на Шаге 1 → если получил 10 техник, можешь выбрать 3-5 самых важных для экономии токенов
- Формулировка Шага 2 → убери "normal and abnormal cases" чтобы фокус был только на одном типе сценариев
- Стандарт/фреймворк → замени ISO 29119-4 на свой набор методов (например, для анализа бизнес-идей: SWOT, Porter's Forces, Jobs-to-be-Done)
- Итерации → если тест-кейсов мало, попроси модель "добавь ещё 10 граничных сценариев" для конкретной техники
Шаблон промпта
Шаг 1: Извлечение методов
Вот {документ/требования}:
[вставить текст]
Из {стандарт/фреймворк/методология} извлеки подходящие методы/техники для этого документа. Если не можешь определить точно — предложи наиболее популярные методы из {стандарт}.Шаг 2: Применение каждого метода (повторить для всех)
Вот {документ/требования}:
[вставить текст]
Создай максимально полный {результат} используя метод/технику {название метода из Шага 1}. Включи {специфичные требования}.Что подставлять:
{документ/требования}— текст для анализа (спецификация, бизнес-план, договор, etc){стандарт/фреймворк}— источник методов. Для тестирования: ISO/IEC/IEEE 29119-4. Для бизнеса: "популярные бизнес-фреймворки анализа". Для текстов: "критерии качества текста".{название метода}— конкретный метод из списка Шага 1{результат}— что генерировать (тест-кейсы, риски, идеи, критика){специфичные требования}— нормальные/аномальные случаи, критичность, формат вывода
🚀 Быстрый старт — вставь в чат:
Вот шаблон GHL для двухшагового анализа. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]LLM спросит: какой документ анализируем, какие методы/фреймворки использовать, что генерировать на выходе — потому что GHL требует эти параметры для работы двухшагового процесса. Она возьмёт паттерн "сначала выбери методы → потом примени каждый" и адаптирует под задачу.
Ограничения
⚠️ Специфичность domain: Нужно знать какие стандарты/фреймворки существуют для твоей области. Для software testing — ISO 29119-4. Для финансов? Для маркетинга? Для юридических текстов? LLM предложит общие методы, но не гарантирует полноту без явного указания фреймворка.
⚠️ Низкая precision: Метод генерирует много лишнего (precision 0.17-0.60). На 100 тест-кейсов только 17-60 совпадут с "правильными". Но это нормально если планируешь автоматизацию проверки — лишние отфильтруются. Для ручной работы придётся чистить.
⚠️ Не для субъективных задач: Метод заточен под структурированные задачи с чёткими критериями (тестирование, проверка compliance, анализ рисков). Не подходит для креатива, стиля, эмоционального тона — там нет стандартизированных техник.
⚠️ Затраты токенов: Если на Шаге 1 получил 10 техник → 10 отдельных запросов на Шаге 2. Для длинных требований (100+ страниц спецификации Bluetooth) это может быть дорого.
Как исследовали
Команда из Tokyo City University и компании VeriServe (специализируется на тестировании ПО) взяла публичные датасеты с готовыми парами "требования → тест-кейсы". Bluetooth: 4 спецификации протоколов (AVRCP, BAP, HFP, VDP) — от 42 до 277 страниц, 83-119 готовых тест-кейсов. Mozilla: 4 фичи Firefox (Bookmarks, Password Manager, etc) — 5-11 страниц, 11-22 тест-кейса.
Прогнали через 3 метода: (1) zero-shot — "создай тест-кейсы" одним промптом, (2) GHL — двухшаговый с извлечением техник, (3) GHL-F — GHL + генерация комбинаций функций. Использовали GPT-4o Small, temperature=0, фиксированный seed для воспроизводимости.
Оценка: Сгенерированные тест-кейсы сравнивали с truth test cases через semantic similarity. Векторизовали тексты через text-embedding-3-small, считали cosine similarity. Порог 0.7 для совпадения (based on prior research). Например, truth: "Verify that password manager picks up the new password" vs generated: "Verify that password manager correctly updates saved passwords" → similarity 0.81 → match.
Результаты удивили: Для Bluetooth recall был высокий даже в zero-shot (0.65) — потому что спецификации Bluetooth используют строгую нотацию тест-кейсов типа AVRCP/CT/CON/BV-01-C. LLM просто копирует эту нотацию! А для Mozilla (естественный язык требований) zero-shot показал 0.02 recall — почти ничего не покрыл.
Логика: Двухшаговый подход повысил recall для Bluetooth с 0.65 до 0.84 (GHL-F), для Mozilla с 0.02 до 0.37. Почему? На Шаге 1 модель извлекла 7-14 разных техник тестирования для каждого requirement документа. Например, для Bluetooth VDP: boundary value analysis, decision table, state transition, performance testing, risk-based testing — 9 техник. Каждая техника дала свой набор тест-кейсов на Шаге 2, итого полнота выросла.
Инсайт: Precision упал (с 0.83 до 0.60 для Bluetooth), но это ожидаемо — больше техник = больше тест-кейсов = больше дублей и лишнего. Но для автоматизации тестирования это норма — лишнее отфильтруется при выполнении.
Время: Zero-shot — 2 минуты, GHL — 20 минут, GHL-F — 20 минут. Почему GHL дольше? Шаг 2 запускается для каждой техники отдельно — если 10 техник, то 10 запросов. Но даже 20 минут в 25 раз быстрее чем 500 минут вручную (5 мин на кейс × 100 кейсов).
Оригинал из исследования
GHL — Step 1: Extract test design techniques
The attached file shows requirements of the system.
Can you extract as much as possible candidate test design techniques in ISO/IEC/IEEE 29119-4:2021 for the requirements? If you can't extract the test design techniques, extract as much as possible popular test design techniques in the ISO/IEC/IEEE 29119-4:2021 in general.GHL — Step 2: For each test design technique
The attached file shows requirements of the system.
Extract test cases as much as possible, according with the technique including normal cases and abnormal cases in the test strategy. Контекст: Исследователи тестировали на requirement documents в виде PDF файлов (Bluetooth спецификации 42-277 страниц, Mozilla фичи 5-11 страниц). На Шаге 1 модель получала requirements + test strategy документ. На Шаге 2 плейсхолдер <test design> заменялся на конкретную технику из списка Шага 1 (например, "Boundary Value Analysis").
Адаптации и экстраполяции
💡 Адаптация для проверки юридических договоров
Вместо тест-кейсов — риски и несоответствия.
Шаг 1:
Вот договор аренды коммерческого помещения:
[текст договора]
Из типичных рисков и методов проверки договоров (финансовые риски, обязательства сторон, штрафы, форс-мажор, юрисдикция) извлеки подходящие категории проверки для этого договора.Шаг 2 (для каждой категории):
Вот договор аренды:
[текст договора]
Проверь максимально полно все моменты связанные с {Финансовые риски}. Включи явные и скрытые риски, упущения, противоречия.Результат: вместо общего "проверь договор" → методичная проверка по категориям (финансы, обязательства, штрафы, etc), каждая даст 5-10 пунктов.
💡 Адаптация для анализа бизнес-идеи
Шаг 1:
Вот бизнес-идея: [описание]
Из популярных бизнес-фреймворков анализа (SWOT, Porter's 5 Forces, Jobs-to-be-Done, Blue Ocean Strategy, Lean Canvas, Business Model Canvas) извлеки наиболее подходящие для оценки этой идеи.Шаг 2:
Вот бизнес-идея: [описание]
Проанализируй максимально полно используя фреймворк {SWOT}. Включи сильные/слабые стороны, возможности, угрозы — конкретно для этой идеи.🔧 Техника: Убрать "normal and abnormal cases" → фокус на одном типе
В оригинале Шаг 2:
Extract test cases as much as possible, according with the technique including normal cases and abnormal cases in the test strategy. Изменённая версия для фокуса только на граничных/аномальных сценариях:
Extract ONLY edge cases and abnormal scenarios according with the technique. Focus on what might break in production. Эффект: Меньше очевидных кейсов ("проверить успешный вход"), больше неочевидных ("что если пароль = максимальная длина + 1 символ").
🔧 Техника: Добавить приоритизацию
После Шага 2 для всех техник:
Вот все сгенерированные тест-кейсы:
[список из 100 кейсов]
Отсортируй по приоритету: критичные (могут сломать продакшен), важные (серьёзные баги), низкие (косметика). Оставь топ-30 критичных.Эффект: Решает проблему низкой precision — LLM сам отфильтрует лишнее.
Ресурсы
Generating High-Level Test Cases from Requirements using LLM: An Industry Study — Satoshi Masuda (Tokyo City University), Satoshi Kouzawa, Kyousuke Sezai, Hidetoshi Suhara, Yasuaki Hiruta, Kunihiro Kudou (VeriServe Corporation). ISO/IEC/IEEE 29119 Part 4 — международный стандарт техник тестирования ПО.