# Тест-кейс (Test Case)

### Содержание:

* [Что такое тест-кейс](#what-is-test-case)
* [Из чего состоит тест-кейс](#what-is-test-case-1)
* [Чем отличается тест-кейс и чек-лист](#test-case-vs-check-list)
* [Позитивный, негативный, деструктивный тест-кейс](#test-case-types)

### **Что такое тест-кейс и зачем он нужен** <a href="#what-is-test-case" id="what-is-test-case"></a>

Тест-кейс — это четкое описание действий, которые нужно выполнить для проверки отдельной функции вашего приложения.

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

### Из чего состоит тест-кейс? <a href="#what-is-test-case" id="what-is-test-case"></a>

**ID тест-кейса.** У каждого тест-кейса должен быть уникальный ID. В этом идентификаторе может быть зашифрован тип тестов (в соответствии с соглашениями). Например, “TC\_UI\_1” означает “Тест пользовательского интерфейса № 1”.

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

**Заголовок или Название теста.** Название тест-кейса. Например, проверка страницы входа в систему с действительным именем пользователя и паролем.

**Резюме/описание теста.** Краткое описание предназначения теста.

**Предварительные условия.** Любые предварительные условия, которые должны быть соблюдены перед выполнением данного варианта теста.

**Зависимости.** Укажите любые зависимости от других тест-кейсов или требований к тестам.

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

**Тестовые данные.** Тестовые данные, которые используются в качестве входных для данного тест-кейса. Вы можете предоставить различные наборы данных с точными значениями.

**Ожидаемый результат.** Какими должны быть выходные данные или поведение системы после выполнения теста? Подробно опишите ожидаемый результат, включая сообщение/ошибку, которая должна быть выведена на экран.

**Фактический результат.** Фактический результат теста должен быть заполнен после его выполнения. Опишите поведение системы после выполнения теста.

**Постусловие.** Каким должно быть состояние системы после выполнения данного тест-кейса?

**Статус (пройден/не пройден).** Если фактический результат не соответствует ожидаемому, отметьте этот тест как неудачный. В противном случае отметьте его как пройденный.

#### Дополнительные поля

При необходимости добавьте следующие поля:

**Идентификатор дефекта/ссылка.** Если тест не пройден, то укажите ссылку на журнал дефектов или укажите номер дефекта.

**Тип теста/ключевые слова.** Это поле можно использовать для классификации тестов по типам. Например, функциональные, юзабилити, бизнес-правила и т.д.

**Требования.** Требования, для которых пишется данный тест-кейс. Желательно указать точный номер раздела в документе с требованиями.

**Приложения/ссылки.** Это поле полезно для сложных сценариев тестирования, чтобы объяснить шаги теста или ожидаемые результаты, используя диаграмму Visio в качестве ссылки. Укажите ссылку или местоположение фактического пути к диаграмме или документу.

**Автоматизация (Да/Нет).** Автоматизирован ли данный тест-кейс. Когда тест-кейсы автоматизированы, полезно отслеживать статус автоматизации.

### **Чем отличаются тест-кейс и чек-лист** <a href="#test-case-vs-check-list" id="test-case-vs-check-list"></a>

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

Чек-лист  — это список того, что нужно протестировать. Благодаря ему процесс тестирования проходит более четко и аккуратно.

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

### **Позитивные, негативные и деструктивные тест-кейсы** <a href="#test-case-types" id="test-case-types"></a>

В **позитивных тест-кейсах** используются корректные входные данные и сценарии ожидаемой работы системы. Цель здесь — убедиться, что программный продукт выполняет то, что должен делать, и что система не выдаст ошибку, если это не предусмотрено.&#x20;

В целом позитивное тестирование гарантирует, что система соответствует требованиям при позитивных сценариях нормального использования.&#x20;

Например, если поле пароля принимает десять символов, пользователь должен иметь возможность создать такой пароль.

**Негативные тест-кейсы** используют некорректные входные данные и проверяют, не делает ли программа того, чего не должна делать. Негативное тестирование призвано гарантировать, что при получении некорректных входных данных система не будет работать по нормальному сценарию (например, выбросит ошибку).&#x20;

Если вернуться к нашему примеру, пользователь не должен иметь возможность создать пароль, состоящий из 11 символов.

**Деструктивные тест-кейсы** создаются, чтобы узнать предел прочности системы. Нагрузочное тестирование — распространенный вариант деструктивного тестирования.&#x20;

Для деструктивного тестирования QA-специалисты могут применять следующие методы:

* создание большой нагрузки на систему, чтобы это привело к ее отказу;
* злонамеренное внедрение JavaScript в веб-форму;
* фаст-кликинг в попытках взломать веб-страницу и т. д.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://qabook.gitbook.io/start/teoriya-testirovaniya/testovaya-dokumentaciya/test-keis-test-case.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.