Тест-кейс

Тест-кейс (test case) - описание одной проверки продукта: состояние, с которого проверка начинается, выполняемые действия, ожидаемые результаты и состояние после проверки. Глоссарий ISTQB определяет тест-кейс как совокупность предусловий, входных данных, действий (если они нужны), ожидаемых результатов и постусловий, разработанную на основе условий тестирования.

Структуру тест-кейса описывает международный стандарт документации тестирования ISO/IEC/IEEE 29119-3 (текущая редакция 2021 года) в составе документа «спецификация тест-кейсов» (test case specification). До 2013 года ту же роль играл стандарт IEEE 829 о документации тестирования программного обеспечения. В системе управления тестированием тест-кейс - центральная сущность: наборы тестов группируют тест-кейсы, тестовые прогоны их выполняют, результаты и дефекты на них ссылаются. Система в целом описана в статье Что такое система управления тестированием.

Зачем нужен тест-кейс

Незаписанная проверка существует только в голове того, кто её выполняет. Другой человек не сможет повторить её так же, её нельзя проверить до выполнения, а её результат нельзя сравнить с результатом прошлого релиза.

Записанный тест-кейс решает эти задачи:

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

Структура тест-кейса

Определение ISTQB перечисляет части тест-кейса. Системы управления тестированием добавляют к ним идентификатор, название и атрибуты.

Идентификатор и название

Идентификатор уникален в пределах проекта и не меняется при правке тест-кейса: на него ссылаются результаты, дефекты и связи с требованиями. Название говорит, что проверяется, в терминах поведения: «Оплата просроченной картой отклоняется», а не «Тест оплаты 3».

Цель и трассируемость

Цель указывает, какое условие тестирования проверяет тест-кейс. Условие тестирования (test condition) в глоссарии ISTQB - проверяемый аспект компонента или системы, выбранный как основа для тестирования. Цель записывается как связь с требованием, юзер стори, критерием приёмки или риском. Эти связи - основа трассируемости требований, описанной в статье Трассируемость и покрытие требований.

Предусловия

Предусловие (precondition) - необходимое состояние объекта тестирования и тестового окружения перед выполнением теста. К предусловиям относятся версия продукта, конфигурация окружения, существующие данные и состояние пользователя: «Пользователь вошёл в систему. В корзине один товар. К учётной записи привязана сохранённая карта со сроком действия 01/2025».

Предусловие записывают так, чтобы его можно было проверить и создать. «Система в нормальном состоянии» проверить нельзя. «Список заказов пользователя пуст» - можно.

Шаги и ожидаемые результаты

Шаг теста (test step) - одно взаимодействие участника с объектом тестирования: входные данные, действие и ожидаемый результат. Ожидаемый результат (expected result) - наблюдаемое предсказанное поведение объекта тестирования в заданных условиях, основанное на базисе тестирования.

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

Пример ниже - тест-кейс из трёх шагов:

Отдельный ожидаемый результат нужен не каждому шагу. Шаг, который только готовит следующий («Ввести сумму 100»), можно объединить с шагом, результат которого проверяется.

Постусловия

Постусловие (postcondition) - ожидаемое состояние объекта тестирования и его окружения в конце выполнения тест-кейса. Постусловия описывают, что остаётся после теста, например созданные записи или изменённые настройки, и что нужно убрать, чтобы следующий тест начинался с известного состояния.

Тестовые данные

Тестовые данные - значения, которые использует тест-кейс: учётные записи, суммы, даты, файлы. Их записывают в самом тест-кейсе, в отдельной таблице или в наборе данных, на который ссылается тест-кейс. Тестовые данные, которые зависят от окружения (учётная запись, которая есть только на одном стенде), указывают явно, иначе тест-кейс нельзя выполнить в другом окружении.

Высокоуровневые и низкоуровневые тест-кейсы

Глоссарий ISTQB различает два уровня детализации. У высокоуровневого тест-кейса (high-level test case) абстрактные предусловия, входные данные, ожидаемые результаты и действия: «Оплатить просроченной картой». У низкоуровневого тест-кейса (low-level test case) конкретные значения и подробное описание действий: номер карты, дата, точный текст сообщения.

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

Атомарность

Атомарный тест-кейс проверяет одно условие тестирования, и у него одна причина не пройти. Тогда у статуса его результата одно значение: «не пройден» указывает на одно поведение.

У тест-кейса, который проверяет сразу несколько условий («регистрация, вход и смена пароля»), несколько проблем:

• если не проходит вторая проверка, третья не выполняется, и её состояние остаётся неизвестным;
• статус «не пройден» не говорит, какое из поведений сломано;
• покрытие завышается: один пройденный результат засчитывается трём требованиям, хотя выполнена могла быть только часть тест-кейса.

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

Параметризация

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

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

В автоматизации тот же подход называется тестированием на основе данных (data-driven testing): тестовые данные и ожидаемые результаты хранятся отдельно от тестового сценария. Тестовые фреймворки поддерживают его напрямую. В pytest, например, одна тестовая функция выполняется для каждого набора параметров:

import pytest


@pytest.mark.parametrize(
    ("amount", "accepted"),
    [("100.00", True), ("0.00", False)],
)
def test_payment_amount(checkout, amount, accepted):
    result = checkout.pay(amount)
    assert result.accepted is accepted

Как выбрать значения параметров, чтобы небольшое число строк покрывало значимые случаи, описано в серии о тест-дизайне: Классы эквивалентности и граничные значения и Попарное тестирование.

Приоритет

Приоритет определяет порядок выполнения тест-кейсов, когда выполнить все нельзя или когда самые важные нужны первыми. Силлабус ISTQB Foundation Level (версия 4.0.1) называет три распространённых подхода к приоритизации:

• на основе рисков: первыми выполняются тест-кейсы, которые проверяют самые высокие риски;
• на основе покрытия: первыми выполняются тест-кейсы, которые дают наибольшее покрытие;
• на основе требований: порядок следует приоритетам требований, которые задали заинтересованные стороны.

На порядок влияют и зависимости между тест-кейсами: тест-кейс, которому нужны данные, созданные другим, выполняется после него.

Приоритет тест-кейса - отдельный атрибут, не равный приоритету дефекта. Первый относится к порядку выполнения, второй - к порядку исправления. Оба разобраны отдельно в статье Отчёт о дефекте.

Статусы жизненного цикла

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

Статус тест-кейса и статус его результата - разные вещи. «Актуален» говорит, что описанием можно пользоваться. «Пройден» или «не пройден» говорит, что произошло при одном выполнении.

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

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

Пользовательские свойства

Системы управления тестированием позволяют командам добавлять к тест-кейсу свои поля - пользовательские свойства (custom properties). Типичные примеры - компонент, платформа, вид теста (функциональный, производительности, безопасности), статус автоматизации (ручной, автоматизирован, к автоматизации) и уровень риска.

Пользовательские свойства служат трём целям: фильтрации при сборке прогона (например, все актуальные тест-кейсы компонента «Оплата» для Android), группировке в отчётах и сопоставлению данных при переносе тест-кейсов между системами. Последняя цель описана в статье Миграция между системами управления тестированием.

Тест-кейс и другие формы описания тестов

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

Чек-лист и тестовый устав оставляют действия на усмотрение тестировщика. Поэтому их быстрее писать, но они менее повторяемы: два выполнения одного пункта чек-листа могут различаться. Тест-кейс фиксирует действия и даёт одинаковый результат независимо от исполнителя.

У сценария Gherkin те же части, что и у тест-кейса: Given соответствует предусловиям, When - действиям, Then - ожидаемым результатам.

Feature: Payment

  Scenario: Payment with an expired card is rejected
    Given the user is signed in
    And a saved card with the expiry date 01/2025 is linked to the account
    When the user pays for the cart with the saved card
    Then the message "Card expired" is shown
    And no order is created

Автотест часто пишут по тест-кейсу, и тест-кейс остаётся его описанием. Связь между ними хранится в системе управления тестированием: результат автотеста записывается как результат тест-кейса.

Термины

Источники

• ISTQB Certified Tester Foundation Level Syllabus v4.0.1, ISTQB, 2024(откроется в новой вкладке) (на английском)
• Глоссарий ISTQB(откроется в новой вкладке) (на английском)
• ISO/IEC/IEEE 29119-3:2021, Software testing, Part 3: Test documentation(откроется в новой вкладке) (на английском)
• IEEE 829-2008, Standard for Software and System Test Documentation(откроется в новой вкладке) (на английском)
• How to parametrize fixtures and test functions, документация pytest(откроется в новой вкладке) (на английском)
• Gherkin reference, Cucumber(откроется в новой вкладке) (на английском)