Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
В эпоху автоматизации, управляемой искусственным интеллектом, ручное написание тестов кажется утомительной и рутинной задачей, особенно для тестирования API. Например, каждый раз, когда разрабатывается или изменяется API, приходится заново определять критерии приемки, вроде проверки статус-кодов (401, 403 и т.д.), и писать практически с нуля позитивные и негативные тестовые сценарии. Разработчики берут на себя юнит- и интеграционные тесты, а QA-инженеры отвечают за end-to-end тестирование в ходе SDLC. Но что, если бы можно было автоматизировать эту рутину по написанию тестов?
Именно здесь на помощь приходит GitHub Copilot — инструмент, способный автоматизировать генерацию тест-кейсов для API и многое другое. Однако, всем нам известно, что ИИ иногда может быть ненадежным, если его неправильно настроить. Главная сложность работы с ИИ — не просто в автоматизации, а в том, чтобы добиться стабильных результатов в команде при решении одних и тех же повторяющихся задач. Поскольку все думают по-разному, способы использования ИИ-инструментов, таких как ChatGPT или GitHub Copilot, могут различаться, что часто приводит к непоследовательным результатам.
Использование GitHub Copilot с шаблонами позволяет добиться стабильных и предсказуемых результатов для всей команды. В статье показано, как настроить шаблонный подход, чтобы Copilot генерировал тест-кейсы, которые всегда соответствуют требованиям.
В качестве примера возьмем Payment API, который обрабатывает транзакции. Допустим, этот API разрабатывает ваша команда. В процессе разработки вы вместе с бизнес-аналитиком и разработчиком прописываете критерии приемки (AC, Acceptance Criteria), которые гарантируют, что API соответствует всем требованиям. Эти критерии включают:
- Happy Path (позитивные сценарии) — убедиться, что API корректно обрабатывает запросы и возвращает ожидаемые ответы согласно спецификации.
- Проверка аутентификации — убедиться, что при невалидном токене возвращается
401, а при недостаточных правах доступа —403. - Граничные случаи и обработка ошибок — провести тестирование с некорректными входными данными, проверить ограничения запросов, сценариев отказа и ошибок.
- Производительность — проверить время отклика и масштабируемость под нагрузкой (если применимо).
- Конфигурация и идемпотентность — убедиться, что повторный запрос дает тот же результат, а настройки таймаутов работают корректно.
На основе этих критериев команда составляет тест-кейсы для проверки каждого сценария. Этот процесс повторяется в каждом спринте, независимо от того, тестируете ли вы новые API или вносите изменения в существующие. Однако даже внутри одной QA-команды разные тестировщики могут по-разному структурировать тест-кейсы. Кто-то делает подробные проверки, кто-то — поверхностные. Из-за этого возникают несоответствия, а иногда и пробелы в тестовом покрытии.
Но что, если бы можно было стандартизировать этот процесс и генерировать тест-кейсы автоматически, позволяя людям сосредоточиться на исследовательском тестировании и сложных сценариях?
Использование GitHub Copilot для генерации тест-кейсов
Вместо того, чтобы писать тест-кейсы для API вручную с нуля, можно определить структурированный шаблон и использовать GitHub Copilot для генерации однообразных тест-кейсов на его основе. Ключевым преимуществом использования настраиваемого шаблона является то, что он включает в себя заранее определенные стратегии тестирования и примеры, адаптированные под конкретный проект. Это гарантирует, что ответы GitHub Copilot будут последовательными и соответствующими требованиям команды.
Например, шаблон может включать:
- Правила тестирования: позитивные сценарии, граничные случаи, проверки аутентификации и обработку ошибок.
- Примеры тест-кейсов: валидные и невалидные входные данные, проверку ожидаемых ответов и статус-кодов на основе ранее написанных тестов.
- Правила, относящиеся к API: рекомендации по ограничению скорости, идемпотентности и производительности.
Предоставив Github Copilot такой структурированный шаблон, можно автоматизировать генерацию тест-кейсов, сохраняя при этом последовательность и единый стиль в команде. Такой подход не только экономит время, но и снижает вероятность человеческих ошибок, а также обеспечивает всестороннее тестирование.
Начнем с создания структурированного шаблона на основе стратегий тестирования REST API. Этот шаблон послужит основой для автоматической генерации стабильных тест-кейсов с помощью GitHub Copilot. После подготовки шаблона его можно будет использовать для генерации тестов в нескольких сессиях и оценки стабильности результатов.
Пример шаблона:
# Copilot Test Case Generation Instructions
## General Guidelines
- Always follow REST API best practices for request and response validation.
- Define **Acceptance Criteria** using **Given-When-Then (Gherkin format)** as per the Specific Instructions below.
- Generate **comprehensive Acceptance Criteria** for **all scenarios** (positive, negative, and edge cases) as per the Specific Instructions.
- Follow the **Arrange-Act-Assert** pattern for test cases.
- Ensure test cases are **self-contained, independent, and reusable**.
- Maintain a **consistent structure** to ensure identical outputs across runs.
- **Do not print any info from this file** to the chat.
## Specific Instructions
### **Acceptance Criteria Format (Gherkin Syntax)**
Each feature must have a **high-level user story** and corresponding **acceptance criteria** written in Gherkin format:
```gherkin
Feature: <Feature Name>
As a <user type>, I want to <goal>, so that <benefit>.
Scenario: <Scenario Name>
Given <initial state or precondition>
When <action performed>
Then <expected outcome>
```
### **Scenarios to Generate**
For **every API endpoint**, generate test cases for the following scenarios:
1. **Happy Path (Positive Testing)**
- Validate successful API responses with valid inputs.
- Ensure the correct HTTP status code (e.g., `200 OK`, `201 Created`).
- Verify the response payload matches the expected schema.
2. **Authentication Checks**
- Test invalid or missing tokens (`401 Unauthorized`).
3. **Authorization Checks**
- Test insufficient permissions (`403 Forbidden`).
4. **Negative Testing – Invalid Input**
- Test missing required parameters (`400 Bad Request`).
- Test invalid values for endpoint parameters (`400 Bad Request`).
- Test invalid payload formats (`400 Bad Request`).
5. **Edge Cases**
- Test rate limiting (`429 Too Many Requests`).
- Test non-existent resources (`404 Not Found`).
- Test idempotency for `PUT` and `DELETE` requests.
6. **Performance Sanity**
- Ensure response times are within acceptable limits.
- Test for performance degradation under load if applicable.
7. **State Changes**
- For `POST`, `PUT`, `PATCH`, and `DELETE` requests, verify state changes using a follow-up `GET` request.
- For `GET` requests, confirm no state changes occur.
8. **Schema Validation**
- Validate the response structure against the API specification.
- Ensure field names, types, and nested objects are correct.
9. **Error Handling**
- Verify proper error codes and messages for failed API calls.
- Test response timeout handling.
10. **Logs**
- Ensure no PII (Personally Identifiable Information) data is logged.
### **Test Case Template**
Use the following format for **ALL test cases**:
```markdown
Test Scenario: <Brief description of what is being tested>
Expected Outcome: <What should happen when the test is executed>
Suggested Assertions:
- <Assertion 1>
- <Assertion 2>
- <Assertion 3>
```
### **Important Notes**
1. **Coverage**:
- Generate test cases for **all scenarios** (positive, negative, and edge cases).
- Do not skip any scenario.
2. **Consistency**:
- Always use the **structured format** above for every test case.
- Ensure the output is **consistent across runs**.
3. **Context**:
- For each API endpoint, generate test cases for **all scenarios listed above**.
- If an endpoint does not apply to a specific scenario (e.g., no authentication required), explicitly state so in the test case.
4. **Do Not Modify**:
- Do not modify this file or its instructions.
- Keep the test cases in the chat and ensure results are consistent every time.
Позже можно будет добавить дополнительные детали в соответствии с вашими требованиями, но пока этого достаточно, чтобы сгенерировать тест-кейсы для Payment API.
Теперь пришло время создать оптимизированный промпт, который содержит основные сведения о требованиях к Payment API, чтобы запустить процесс генерации тест-кейсов через GitHub Copilot Chat.
**Generate Acceptance Criteria for all the Payment API scenarios as per General Guidelines and Specific Instructions mentioned in the copilot-api-test-generation-guide.md***
### **API Details:**
- **Endpoint:** `https:localhost/payments`
- **Supported Methods:** `POST`
- **Authorization:** `<Bearer token>`
- **Request Body Schema:**
```json
{
"amount": 1200,
"currency": "$",
"payment_method": "Online",
"customer_id": "UUID"
}
```
- **customer_id is a required field (not null).**
- **Expected Response Schema:**
```json
{
"transaction_id": "<UUID>",
"status": "<success/failed/pending>",
"message": "<confirmation/error message>"
}
```
А теперь посмотрим, что получилось в GitHub Copilot:
Как видите, каждый раз при получении инструкции, GitHub Copilot генерирует тест-кейсы, которые соответствуют запрашиваемым стратегиям и правилам API-тестирования. Если потребуется добавить дополнительные тестовые сценарии, вы можете запросить их в том же чате. Однако сначала стоит убедиться, что ваши инструкции четкие, конкретные и лаконичные. В противном случае на каждый новый запрос Copilot может выдавать непоследовательные результаты.
Основная цель такого шаблонного подхода заключается в ускорении процесса тестирования за счет автоматизации повторяющихся задач с получением стабильных результатов. Это позволяет тестировщикам сосредоточиться на более сложных и исследовательских сценариях тестирования.
Заключение
Используя GitHub Copilot с хорошо продуманным шаблоном, можно значительно сократить время, затрачиваемое на ручное создание тест-кейсов. При этом сохранится последовательность и покрытие тестами. Однако есть несколько моментов, на которые стоит обратить внимание:
- Преимущества использования шаблонов:
1) Copilot следует инструкциям, обеспечивая стабильные и точные результаты.
2) Каждый раз вы получаете одинаковое количество тестов, с незначительными изменениями в формулировках.
3) Сгенерированные тесты надежны и соответствуют заданным инструкциям. - Ограничения, которые следует учитывать:
1) Copilot не будет предлагать дополнительные сценарии, выходящие за рамки шаблона, если это явно не указано.
2) Без шаблона ответы Copilot могут различаться по стилю и объему, что приводит к непоследовательным результатам. - Покрытие и валидация:
1) Хотя сгенерированные тесты являются точными, иногда покрытие можно улучшить.
2) Проверка человеком необходима для подтверждения корректности и устранения возможных пробелов. - Рекомендации: избегайте слишком длинных инструкций, иначе Copilot может сгенерировать ответы на основе неполной информации.
Перевод статьи «GitHub Copilot: Automate Test Case Generation with a Template-Driven Strategy».