← Назад к вопросам

Какие знаешь атрибуты тест кейса?

1.0 Junior🔥 241 комментариев
#Теория тестирования#Тестовая документация

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI26 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Атрибуты тест-кейса

Тест-кейс (Test Case) — это детальное описание последовательности действий для проверки конкретной функциональности. Его качество напрямую влияет на эффективность тестирования. Ниже представлены все ключевые атрибуты, которые должен содержать профессиональный тест-кейс.

Основные обязательные атрибуты:

1. Test Case ID

  • Уникальный идентификатор (TC-001, TC-002, и т.д.)
  • Позволяет быстро ссылаться на конкретный тест
  • Используется в bug reports и reports
  • Должен быть постоянным и не изменяться

2. Title (Название)

  • Краткое и понятное описание того, что тестируется
  • Начинать с глагола: Verify, Check, Validate
  • Пример: Verify that user can login with valid credentials
  • Не должно быть размытым или двусмысленным

3. Description (Описание)

  • Расширенное описание целей и контекста теста
  • Предыстория: что должно быть готово перед началом
  • Почему этот тест важен для бизнеса
  • Связь с requirements или user stories

4. Preconditions (Предусловия)

  • Состояние системы до запуска теста
  • Необходимые тестовые данные
  • Требуемые роли и права доступа
  • Необходимое окружение и конфигурация
  • Пример: User must be logged in, Database must be populated

5. Test Steps (Шаги тестирования)

  • Последовательные действия, выполняемые во время теста
  • Каждый шаг должен быть атомарным и понятным
  • Нумерация: 1, 2, 3 или 1.1, 1.2
  • Формат: Action → Expected Result

6. Expected Result (Ожидаемый результат)

  • Что должно произойти после каждого шага
  • Должно быть объективным и проверяемым
  • Конкретно: должна появиться ошибка Invalid password
  • Включает проверку UI, логов, БД, API ответов

Дополнительные важные атрибуты:

7. Test Data (Тестовые данные)

  • Конкретные значения для использования в тесте
  • Граничные значения, invalid data

8. Priority (Приоритет)

  • Critical (P0) — критичные потоки
  • High (P1) — важные функции
  • Medium (P2) — обычные функции
  • Low (P3) — косметические проблемы

9. Severity (Серьёзность)

  • Blocker — приложение не работает
  • Critical — основная функция не работает
  • Major — функция частично не работает
  • Minor — небольшое отклонение
  • Trivial — косметическое отклонение

10. Category/Type (Категория)

  • Functional, Regression, Smoke, Performance, Security, API

11. Automation Status

  • Manual only, Automated, Partially automated

12. Test Environment

  • Development, Staging, Production
  • Browser: Chrome, Firefox, Safari
  • OS: Windows, macOS, Linux
  • Device: Desktop, Tablet, Mobile

13. Author (Автор)

  • Кто написал тест-кейс
  • Дата создания

14. Assigned To

  • Кто будет выполнять тест

15. Status

  • Draft, Ready for review, Approved, Active, Deprecated

16. Coverage/Related Requirements

  • Какие requirements покрывает этот тест
  • Связь с user stories или feature requests

Лучшие практики написания тест-кейсов:

  • Один тест-кейс равно одна функциональность
  • Использовать простой и понятный язык
  • Избегать технического жаргона без объяснений
  • Быть конкретным, избегать неточностей
  • Регулярно обновлять и удалять устаревшие тесты
  • Использовать управление версиями для истории
  • Делать тесты независимыми от друг друга
  • Документировать баги при тестировании

Профессиональный тест-кейс — это основа качественного тестирования и снижения рисков выпуска багов в production.