Modern QA2026Шаблоны промптов для генерации тестов
Join

Course › 02 AI-Augmented Test Design

Cutting-edge · Chapter 02

Шаблоны промптов для генерации тестов

Updated Jul 2026

Зачем нужны шаблоны

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

Этот файл содержит четыре проверенных на практике шаблона, покрывающих наиболее распространённые сценарии генерации тестов. В каждом шаблоне есть заполнители, обозначенные {фигурными_скобками}, которые вы заполняете для каждой функциональности.

Шаблон 1: Требования-в-тесты

Используйте этот шаблон, когда у вас есть пользовательская история с критериями приёмки и нужен полный набор тестов.

You are a senior QA engineer. Given the following user story and acceptance
criteria, generate a comprehensive test suite.

**User Story:**
{paste user story here}

**Acceptance Criteria:**
{paste AC here}

**Technical Context:**
- Frontend: {framework and version, e.g., React 18 with React Testing Library}
- API: {API style, e.g., REST endpoints at /api/v2/*}
- Auth: {auth mechanism, e.g., JWT tokens in Authorization header}

**Generate:**
1. Unit tests for the component logic (no API calls)
2. Integration tests for the API layer (mock HTTP)
3. E2E test scenarios (describe steps, no code)

**For each test, include:**
- Test name following the pattern: "should [expected behavior] when [condition]"
- Arrange/Act/Assert structure
- Explicit assertions (not just "expect something")

**Coverage requirements:**
- All acceptance criteria must have at least one test
- Include at least 2 negative/error cases per AC
- Include 1 boundary value test where numeric limits exist

Когда использовать

  • Планирование спринта: генерация начального списка тестов из историй
  • Уточнение историй: выявление недостающих критериев приёмки путём обзора сгенерированных тестов
  • Онбординг: новые члены команды используют шаблон, чтобы понять ожидания к тестированию

Пример заполнения

You are a senior QA engineer. Given the following user story and acceptance
criteria, generate a comprehensive test suite.

**User Story:**
As a store manager, I want to set a maximum discount percentage per product
category so that sales staff cannot give discounts beyond the allowed limit.

**Acceptance Criteria:**
1. Admin can set max discount (0-100%) per category via the settings page
2. Attempting to apply a discount above the max shows an error toast
3. The max discount persists across browser sessions (stored server-side)
4. Categories with no max set allow any discount (backward compatible)

**Technical Context:**
- Frontend: React 18 with React Testing Library
- API: REST endpoints at /api/v2/settings/discount-limits
- Auth: JWT tokens in Authorization header, requires "admin" role

**Generate:**
1. Unit tests for the DiscountLimitForm component
2. Integration tests for the discount limit API endpoint
3. E2E test scenarios (describe steps, no code)

**For each test, include:**
- Test name following the pattern: "should [expected behavior] when [condition]"
- Arrange/Act/Assert structure
- Explicit assertions (not just "expect something")

**Coverage requirements:**
- All 4 acceptance criteria must have at least one test
- Include at least 2 negative/error cases per AC
- Include boundary value tests for 0%, 1%, 99%, 100%, 101%, and -1%

Шаблон 2: API-схема-в-тесты

Используйте этот шаблон, когда у вас есть OpenAPI/Swagger-схема и нужны тесты для эндпоинтов.

Analyze the following OpenAPI 3.0 schema and generate a test suite for the
{endpoint_name} endpoint.

**Schema:**
```json
{paste OpenAPI schema excerpt}

Generate tests for:

  1. Every HTTP method defined on this endpoint
  2. Every required field -- test with missing, null, empty string, wrong type
  3. Every optional field -- test with present and absent
  4. Every enum value -- test each valid value plus one invalid
  5. Response codes -- test conditions that trigger each documented status code
  6. Auth -- test with valid token, expired token, missing token, wrong role

Framework: {test framework, e.g., pytest + httpx} Base URL variable: {env var name, e.g., BASE_URL (from environment)} Auth helper: {auth fixture, e.g., Use get_test_token(role="user"|"admin") fixture}

Output as a single {language} file with clear test class grouping.


### Советы по использованию этого шаблона

1. **Вставляйте только релевантный эндпоинт**, а не всю спецификацию. Если ваш OpenAPI-файл занимает 5000 строк, извлеките 50-100 строк для тестируемого эндпоинта.

2. **Включайте раздел components/schemas** для всех ссылок `$ref`. LLM не может разрешить `$ref: '#/components/schemas/Product'`, если вы не включили схему Product.

3. **Укажите вашу фикстуру аутентификации точно.** Если у вас есть вспомогательная функция вроде `get_test_token(role="admin")`, назовите её в промпте. Иначе LLM изобретёт свой собственный механизм аутентификации.

4. **Запрашивайте параметризованные тесты** для полей с перечислениями, чтобы результат был DRY:

For enum fields, use @pytest.mark.parametrize to test all valid values in a single test function, plus a separate test for one invalid value.



## Шаблон 3: Промптинг через TDD

Этот шаблон переворачивает подход: вы описываете желаемое поведение, а LLM генерирует и тесты, и реализацию. Полезен для рабочих процессов TDD и демонстрации на собеседованиях.

I need a function called {function_name} with this behavior:

  • Accepts: {input signature}
  • Returns: {output signature}
  • Rules: {list all business rules, one per line}

Generate:

  1. FIRST: A complete test file covering every rule, including boundary values ({list specific boundary values}) and every {category, e.g., destination category}.
  2. THEN: The implementation that makes all tests pass.

### Полный пример

I need a function called calculate_shipping_cost with this behavior:

  • Accepts: { weight_kg: number, destination_country: string, is_express: boolean }
  • Returns: { cost_usd: number, estimated_days: number }
  • Rules:
    • Base rate: $5 + $2 per kg
    • Express multiplier: 1.5x cost, halves estimated days (round up)
    • Domestic (US): 5 days standard
    • Canada/Mexico: 7 days standard
    • Europe: 10 days standard
    • All other: 14 days standard
    • Max weight: 30kg. Over 30kg raises ValueError.
    • Negative weight raises ValueError.
    • Zero weight is valid (just the base rate).

Generate:

  1. FIRST: A complete test file covering every rule, including boundary values (0kg, 30kg, 30.01kg, -1kg) and every destination category.
  2. THEN: The implementation that makes all tests pass.

### Почему этот паттерн эффективен

Этот паттерн эффективен на собеседованиях, потому что демонстрирует, что вы мыслите **от спецификации**, а не от кода. Он также создаёт естественную пару «тест-реализация», которая документирует сама себя. Тесты служат исполняемой спецификацией функции.

На практике этот паттерн лучше всего работает для:
- Чистых функций с ясным контрактом ввода/вывода
- Утилитарных функций, используемых по всей кодовой базе
- Бизнес-логики с чётко определёнными правилами
- Функций преобразования и валидации данных


## Шаблон 4: Генерация тестов с учётом мутаций

Этот продвинутый шаблон создаёт тесты с более высокой способностью обнаружения ошибок за счёт внедрения концепций мутационного тестирования непосредственно в промпт.

For the following {language} function, generate tests that would survive mutation testing. For each test:

  1. State the specific line of code or condition you are targeting
  2. Explain what mutation (change) would break this test
  3. Write the test with a tight assertion that catches the mutation

Function under test:

{paste function code}

Requirements:

  • Each test must target a specific branch, condition, or calculation
  • Assertions must be precise enough that changing any operator (+, -, *, /), comparison (>, <, >=, <=, ==, !=), or constant would cause the test to fail
  • Include boundary values for every conditional
  • Do NOT write tests that only verify "no exception is thrown"

Example of a LOW mutation-score test (avoid this):

def test_create_user():
    response = client.post("/users", json={"name": "Alice"})
    assert response.status_code == 200
    # If the name is not saved, this test still passes. Low mutation score.

Example of a HIGH mutation-score test (aim for this):

def test_create_user():
    response = client.post("/users", json={"name": "Alice"})
    assert response.status_code == 200
    user = response.json()
    assert user["name"] == "Alice"   # Catches missing name persistence
    assert "id" in user              # Catches missing ID generation


### Когда использовать этот шаблон

- Когда вы внедряете тесты в устаревший код и нужна высокая уверенность
- Когда ваша команда отслеживает показатели мутационного тестирования
- Когда вы хотите продемонстрировать глубину тестирования на собеседованиях
- Когда критически важная функция (платежи, аутентификация, миграция данных) требует безупречного покрытия


## Хранение и версионирование шаблонов

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

tests/ prompts/ requirements-to-tests.prompt.md api-schema-to-tests.prompt.md tdd-prompt.prompt.md mutation-aware.prompt.md test_users.py test_orders.py


Версионируйте их в git. Когда вы дорабатываете шаблон на основе обратной связи из ревью, фиксируйте изменение с сообщением, объясняющим, что улучшилось. Это создаёт институциональные знания об эффективной генерации тестов.


## Ключевой вывод

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