Тестирование по вариантам использования

Тестирование по вариантам использования (use case testing) - техника тестирования методом чёрного ящика, при которой тест-кейсы строятся так, чтобы задействовать поведение, описанное вариантами использования. Вариант использования (use case), в определении Ивара Якобсона (Ivar Jacobson) и Алистера Кокберна (Alistair Cockburn), - это все способы использовать систему, чтобы достичь определённой цели определённого пользователя. Тест-кейсы следуют основному успешному сценарию варианта использования и каждому из его расширений: альтернативным путям, необязательным шагам и ошибкам.

Варианты использования пришли из инженерии требований. По словам Кокберна, Якобсон придумал то, что позже назвали вариантами использования, в конце 1960-х годов, когда работал над телефонными системами в Ericsson, а в конце 1980-х представил их сообществу объектно-ориентированного программирования. Структура, описанная в этой статье, следует книге Кокберна Writing Effective Use Cases (Addison-Wesley, 2001). В 2024 году Якобсон и Кокберн опубликовали Use Case Foundation - совместное определение понятия. В тестировании силлабус ISTQB Foundation Level 2018 года описывал тестирование по вариантам использования как отдельную технику; силлабус 4.0 и его текущая версия 4.0.1 этого уже не делают. Силлабус ISTQB Advanced Level Test Analyst (версия 4.0, 2025 год) рассматривает варианты использования как модели для тестирования на основе сценариев, а ISO/IEC/IEEE 29119-4:2021 описывает тестирование сценариев (scenario testing) в разделе 5.2.9.

Какую задачу решает тестирование по вариантам использования

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

Вариант использования описывает процесс с точки зрения актора и цели. Он содержит основной путь и, шаг за шагом, условия, при которых путь отклоняется: неверный ввод, истёкшее время ожидания, отказ внешней системы. Метод Кокберна требует от авторов перебрать всё, что может пойти не так в успешном сценарии. Дефекты обработки ошибок находятся на этих путях отказа, а список функций не показывает их как пути.

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

История

В таблице - основные вехи вариантов использования в требованиях и в стандартах тестирования.

Структура варианта использования

Полный шаблон Кокберна (fully dressed) собирает всё, что должно быть верно в отношении одной цели. Поля, важные для тестирования:

Use Case Foundation называет актора, который запускает вариант использования, основным актором (primary actor), а акторов, к которым обращается система, - вспомогательными акторами (supporting actors). Актором может быть человек, организация, программа или их сочетание. По формулировке Кокберна, предусловия и гарантии говорят, что должно быть верно до и после выполнения варианта использования.

Основной успешный сценарий и расширения

Основной успешный сценарий (main success scenario) - сценарий, в котором ничего не идёт не так. Это пронумерованный список шагов, каждый из которых - действие актора или системы. Use Case Foundation описывает его как обычный успешный путь к ценности (happy path), который также называют основным потоком (basic flow).

Расширение (extension) - условие, которое может возникнуть на шаге основного сценария, вместе с шагами, которые его обрабатывают. Расширения нумеруются по шагу, на котором условие обнаружено, и букве: 3a и 3b - два разных условия на шаге 3, а 3a1, 3a2 - шаги обработки 3a. Правило Кокберна: условие говорит о том, что обнаружено, например «карта просрочена», а не о том, что актор сделал неправильно. В примере ниже одни расширения возвращают к шагу основного сценария, другие завершают вариант использования без достижения цели.

Силлабус Test Analyst различает те же части под другими названиями: основной сценарий, расширения, они же альтернативные сценарии, и исключения, которые не достигают цели из-за неожиданных действий или неверного ввода. Use Case Foundation называет расширения альтернативными потоками (alternate flows).

Формы варианта использования

Кокберн называет две формы записи. Неформальная форма (casual) «срезает» шаблон и пишется как короткое повествование. Полная форма (fully dressed) использует весь шаблон и нумерацию шагов. По Кокберну, неформальные варианты использования подходят проектам с минимумом формальностей, полные - проектам с более строгими процедурами, и ни одна форма не ошибочна.

Он также описывает четыре уровня точности, от имени актора и цели до полной обработки каждого расширения:

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

Разобранный пример

Пример - вымышленный вариант использования интернет-банка в полной форме, сокращённый до полей, нужных для тестирования.

Основной успешный сценарий:

1. Клиент выбирает счёт-источник, счёт-получатель и сумму.
2. Система проверяет перевод и показывает сводку.
3. Клиент подтверждает перевод.
4. Система отправляет одноразовый код через SMS-шлюз.
5. Клиент вводит код.
6. Система выполняет перевод и показывает подтверждение.

Расширения:

• 2a. Сумма превышает доступный остаток. 2a1. Система показывает доступный остаток. Вариант использования продолжается с шага 1.
• 2b. Сумма превышает дневной лимит. 2b1. Система показывает оставшийся лимит. Вариант использования продолжается с шага 1.
• 3a. Клиент отменяет перевод. Вариант использования завершается без перевода.
• 5a. Код неверный. 5a1. Система снова запрашивает код. 5a2. После третьего неверного кода система отменяет перевод, и вариант использования завершается.
• 5b. Срок действия кода истёк. 5b1. Система предлагает новый код. Вариант использования продолжается с шага 4.

От варианта использования к тест-кейсам

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

Сценарии UC-7 и их тест-кейсы:

Поля варианта использования переходят в части тест-кейса. Предусловие варианта использования становится предусловием тест-кейса: клиент вошёл в систему, у него два счёта. Триггер - первый шаг. Гарантии успеха - ожидаемый результат каждого тест-кейса, который достигает цели, минимальные гарантии - каждого тест-кейса, который заканчивается отказом: в UC7-4 и UC7-6 тест проверяет, что деньги не переместились и что попытка есть в журнале. Структура тест-кейса описана в статье Тест-кейс.

Вспомогательные акторы определяют тестовое окружение. SMS-шлюз в UC-7 - внешняя система; тестам 5a и 5b нужен способ получить код или тестовый двойник, который возвращает известный код и умеет делать его просроченным.

Сценарий задаёт путь, а не данные. Сумма в UC7-2 должна быть больше остатка, а граница между «в пределах остатка» и «больше остатка» проверяется значениями, выбранными по статье Классы эквивалентности и граничные значения. Поэтому один сценарий может дать несколько тест-кейсов, по одному на значение.

Покрытие варианта использования

Силлабус Test Analyst измеряет покрытие сценариев как число выполненных сценариев, делённое на число выявленных сценариев. В UC-7 выявлено семь сценариев, и семь тест-кейсов выше покрывают их все. В силлабусе Foundation Level 2018 года та же идея выражалась как число проверенных вариантов поведения варианта использования, делённое на общее число вариантов поведения.

Покрытие зависит от того, какие сценарии выявлены. Два вида путей неочевидны:

• Сочетания расширений. Клиент может превысить остаток (2a), исправить сумму, а затем ввести неверный код (5a). Покрытие каждого расширения по одному разу не покрывает таких сочетаний; силлабус рекомендует расставлять приоритеты сценариев по риску.
• Циклы. Расширение 5a - цикл. Для путей с циклами силлабус применяет простое покрытие циклов: ноль итераций, одна, больше одной и максимальное число, если это возможно. Для 5a это верный код сразу (UC7-1), один неверный код (UC7-5), два неверных кода и три неверных кода (UC7-6).

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

Варианты использования, юзер стори и критерии приёмки

Юзер стори (user story), в определении глоссария ISTQB, - требование из одного предложения на повседневном или деловом языке, которое описывает нужную пользователю функциональность и причину, по которой она нужна, вместе с критериями приёмки. Юзер стори обычно меньше варианта использования: она может описывать один шаг, одно расширение или одну вариацию. Силлабус ISTQB Foundation Level 4.0.1 помещает эту работу в раздел 4.5, подходы к тестированию на основе совместной работы: совместное написание юзер стори, критерии приёмки и разработка через приёмочные тесты (acceptance test-driven development). Кокберн опубликовал книгу о связи между ними, Unifying User Stories, Use Cases, Story Maps.

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

Сценарии Gherkin

Сценарии Gherkin - один из способов записать критерии приёмки так, чтобы их можно было ещё и выполнить. Справочник Cucumber описывает Given как приведение системы в известное состояние, When - как действие, а Then - как ожидаемый результат; шаги, общие для всех сценариев функции, помещаются в Background. Каждый сценарий варианта использования становится сценарием Gherkin. Два сценария UC-7:

Feature: Transfer money between own accounts

  Background:
    Given the customer is logged in
    And the account "Current" has a balance of 500.00 USD
    And the account "Savings" has a balance of 0.00 USD

  Scenario: Transfer within the balance
    When the customer transfers 200.00 USD from "Current" to "Savings"
    And the customer confirms the transfer with a valid one-time code
    Then the balance of "Current" is 300.00 USD
    And the balance of "Savings" is 200.00 USD
    And the transfer appears in the transaction history

  Scenario: Third wrong code cancels the transfer
    When the customer transfers 200.00 USD from "Current" to "Savings"
    And the customer enters a wrong one-time code 3 times
    Then the transfer is cancelled
    And the balance of "Current" is 500.00 USD
    And the attempt is logged

Предусловие варианта использования переходит в Background, шаги сценария - в When, гарантии - в Then. Минимальные гарантии становятся шагами Then сценария отказа. Сценарии Gherkin, выведенные не из варианта использования, а из таблицы решений, описаны в статье Таблицы решений.

Тестирование по вариантам использования и смежные техники

Несколько техник тоже работают с последовательностями или с описаниями на уровне бизнеса. Таблица сравнивает их.

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

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

Термины

Источники

• Use Case Foundation, version 1.1, I. Jacobson, A. Cockburn(откроется в новой вкладке) (на английском)
• Use Case Foundation, announcement, A. Cockburn, 15 February 2024(откроется в новой вкладке) (на английском)
• Writing Effective Use Cases, A. Cockburn, Addison-Wesley, 2001; the author's list of books(откроется в новой вкладке) (на английском)
• ISTQB Certified Tester Foundation Level Syllabus 2018 V3.1, ISTQB, 2019(откроется в новой вкладке) (на английском)
• ISTQB Certified Tester Foundation Level Syllabus v4.0.1, ISTQB, 2024(откроется в новой вкладке) (на английском)
• ISTQB Certified Tester Advanced Level Test Analyst Syllabus v4.0, ISTQB, 2025(откроется в новой вкладке) (на английском)
• Глоссарий ISTQB(откроется в новой вкладке) (на английском)
• ISO/IEC/IEEE 29119-4:2021, Software and systems engineering, Software testing, Part 4: Test techniques(откроется в новой вкладке) (на английском)
• Gherkin Reference, Cucumber(откроется в новой вкладке) (на английском)