use case в тестировании что такое
Что такое Юзкейс (Use Case) или «Сценарий Использования» в Тестировании ПО?
Юзкейс (Use Case) — это перечень действий, сценарий по которому пользователь взаимодействует с приложением, программой для выполнения какого-либо действия для достижения конкретной цели. Тестирование по юзкейсам проводится для того чтобы обнаружить дополнительные логические дыры и баги в приложении, которые сложно найти в тестировании индивидуальных модулей, частей приложения отдельно друг от друга. Юзкейс тестирование может проводится как часть Приемочного тестирования. Для удобства визуального восприятия Use Case часто рисуют в виде диаграмм с переходами.
Пример Юзкейсов (Use Cases)
для разных типов пользователей онлайновой системы:
Перед тестированием любого приложения или программы стоит поинтересоваться у заказчика чтобы тот предоставил хотя бы несколько Юзкейсов пользователей, какой набор сценариев используется чаще всего и отталкиваясь от этого составить тест кейсы таким образом, чтобы все сценарии были покрыты и имели наибольший приоритет и которые стоит покрыть автотестами в первую очередь.
Если же такой информации не предоставляют, то нужно провести анализ приложения самостоятельно для выявления Юзкейсов, сценарии по которым предположительно зачастую будут использовать будущие пользователи тестируемой программы или приложения.
Use case в тестировании что такое
Use Case (вариант использования, ВИ, Прецедент, юскейс) — это сценарная техника описания взаимодействия. С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни.
В общем случае, с помощью Use Case может описываться взаимодействие двух или большего количества участников, имеющее конкретную цель:
В разработке ПО эту технику часто применяют для проектирования и описания взаимодействия пользователя и системы, поэтому название Use Case часто воспринимает как синоним требования человека-пользователя к решению определенной задачи в системе. В статье мы будем рассматривать использование Use Case для описания взаимодействия пользователя с системой.
Исторически требования к функционированию системы описывались в виде отдельных функций. Ивар Якобсон в середине 1990-х годов предложил Use Case как альтернативу и дополнение описания функциональности системы. Описание требований к системе не в виде отдельных функций, а в виде описания контекста и последовательности действий пользователя помогает сформировать набор функциональных требований, который будет обеспечивать полноту и неизбыточность требований.
Мы можем сформулировать набор функциональных требований:
FRQ1 Система должна предоставить пользователю возможность ввести код бронирования
FRQ2 Система должна сохранить сведения о регистрации пассажира на рейс
FRQ3 Система должна предоставить пользователю возможность распечатать посадочный талон
Пока это разрозненные требования, мы не можем проверить их набор на полноту и соответствие целям пользователей, так как мы не видим:
1) контекста выполнения этих функций,
2) роли пользователя, которому должна быть доступна функция,
3) целей этого пользователя при использовании системы.
Use Case задаёт формат, в котором все эти важные факторы описываются и учитываются. И перечисленные выше функциональные требования можно объединить в один Use Case, описывающий цель пользователя.
Пример базовой части Use Case.
Регистрация пассажира на рейс
Описание решения задачи пользователя в системе в виде Use Case должно определять:
Основной поток действий Use Case описывает успешную последовательность событий, необходимую для достижения конкретной цели основного действующего лица.
Предусловие — условия, которые должны выполняться, чтобы сценарий вообще мог начаться. Мы не будем проверять это условие в процессе работы сценария, так как мы предварительно договорились, что оно истинно.
Результат — или «гарантия успеха» — след, который оставляет сценарий. Наличие результата говорит нам, что и Пассажир достиг своей цели.
Этот Use Case пишется для проектирования решения, его потребителем будет команда разработки.
Назначение Use Case для разных участников проекта
Конечно, для разработки функциональных требований к системе мы пишем целый набор Use Case, учитывающих цели пользователей нескольких ролей. Этот набор позволяет обеспечить полноту требований пользователей к системе. Набор Use Case является набором требований более высокого уровня абстракции, чем набор отдельных функциональных требований, и в то же время полностью покрывает пользовательские требования к функциональности. Поэтому он более удобен в работе.
Рассмотрим преимущество работы с набором Use Case для людей, выполняющих разные роли в проекте.
Use Case для руководителя проекта
Сам по себе Use Case — это естественный способ описывать диалог, он понятен человеку без подготовки, Use Case обычно не содержит деталей реализации и пишется на языке целей пользователей. Поэтому Use Case удобно согласовывать с Заказчиком как «единицу поставки»: элемент планирования работы над системой и сдачи проекта.
В отличие от планирования работы и сдачи результатов в виде отдельных функций (сохранять, предоставлять доступ) или элементов архитектуры (платформа, подсистема хранения данных, подсистема обработки данных, подсистема пользовательского интерфейса), согласование работ на основе Use Case гораздо прозрачнее для заказчика. Во-первых, каждый Use Case несет конечную бизнес-ценность, понятную заказчику, во-вторых, даже технически неподкованный заказчик может убедиться в наличии реализации того или иного Use Case в системе, в отличие от наличия отдельных подсистем или функций, никак не отображающихся на пользовательском интерфейсе.
То, что набор Use Case состоит из меньшего количества элементов — обычно от 5 до 20, — чем набор отдельных функциональных требований, экономит время на согласование проекта с заказчиком, а то, что заказчику понятна бизнес-ценность каждого Use Case, сильно упростит выставление приоритетов между ними.
Use Case для тестировщика
Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев — test case, — так как они описывают в каком контексте должно производиться каждое действие пользователя. Use Case, по умолчанию, являются тестируемыми требованиями так как в них всегда указана цель, которой нужно достигнуть и какие шаги надо для этого воспроизвести.
Use Case для аналитика и менеджера продукта
Для аналитика и менеджера продукта, как наиболее частых авторов, Use Case это отличный инструмент:
В процессе проектирования взаимодействия с системой в виде Use Case и согласования их с заказчиком, аналитик и руководитель проекта узнают много сопутствующей информации: роли пользователей, внутренние правила работы потенциальных пользователей, которые влияют на логику Use Case и являются бизнес-правилами. В процессе расстановки приоритетов и выявления критичности тех или других Use Case формируются требования к пользовательскому интерфейсу. При определении частоты выполнения того или иного действия пользователя в системе, описанного в виде Use Case, формируются требования к производительности системы.
Так как Use Case полностью покрывают набор таких функциональных требований, и в то же время согласуются с бизнес-целями заказчика, они позволяют проследить связь от бизнес-целей заказчика до отдельной функции и связанных нефункциональных требований, т.е. обеспечить трассировку.
Use Case не обеспечивают полноту всех функциональных требований, если в систему должна быть заложена сложная бизнес-логика, т.е. обработка информации в системе зависит не только и не столько от действий пользователей, сколько от внутренних правил взаимодействия объектов.
Например, работа с системами типа «тасктрекер» задается достаточно простыми и стандартными Use Case: «Создать задачу», «Назначить задачу», «Пометить задачу, как выполненную». Однако тасктрекеров существует огромное множество, и это оправдано тем, что в каждом есть свои возможности по заданию жизненных циклов задач, их типов и взаимосвязей. И эту внутреннюю логику работы с задачами нет смысла описывать в виде Use Case.
То же касается бухгалтерских программ, систем поддержки принятия решения, профессиональных систем для проектирования и дизайна. Use Case важны для них, но не покроют и пятой части требований к функциональности.
Если эта техника вас заинтересовала, ознакомьтесь с материалами от классиков Use Case:
Use case в тестировании что такое
Что пишут в блогах
Продолжу хвастаться статусом книги.
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Андрей Козлов
Часто приходится видеть, как подчас даже опытные тестировщики спотыкаются на известных граблях – на составлении тест-планов. Хочу рассказать о модели ведения тест-планов, основанной на сценариях использования.
Про необходимость тест-планов писать не буду, скажу лишь, что тест-план – и это не преувеличение – является основным инструментом в работе тестировщика. Он может вестись на бумаге, в голове, в текстовом файле или в баг-трекере, но он должен быть. Хотя бы для того, чтобы сказать потом начальству, что было проверено, а что нет. На моей памяти тестирование не одного проекта было сорвано из-за отсутствия тест-планов или неудобства работы с ними.
Я предлагаю модель, которая помогает существенно снизить риски неадекватного планирования. Суть её сводится к выделению сценариев использования приложения и наполнению их конкретными данными.
Введение
Юз-кейс – сценарий использования. Последовательность действий, которую мы можем осуществлять с помощью приложения или системы. (http://ru.wikipedia.org/wiki/Сценарий_использования)
Тест-кейс – тестовый сценарий. Последовательность действий (юз-кейс) с определёнными входными данными.
Приоритет – сравнительная оценка важности юз-кейса или тест-кейса для процесса тестирования.
Тест-план – в нашем узком смысле, – это список юз-кейсов и тест-кейсов с расставленными приоритетами. Всего того, что касается оформления плана и подготовки тестовой среды мы касаться не будем.
Для наглядности пояснения я буду строить тест-план на абстрактном приложении, которое нужно для ведения базы данных домашних животных.
Предположим, что у нас есть спецификация, которая гласит, что мы должны иметь возможность через интерфейс приложения делать выборки из базы на основе фильтра по типам животных и по их именам, и мы должны иметь возможность добавлять новые записи в таблицу. Приложение должно состоять из двух форм. На первой у нас выставляются значения фильтра, и по нажатию кнопки «Найти» выводится таблица в соответствии с фильтром. На ней есть кнопка «Добавить» по нажатию на которую, появляется вторая форма, где мы выбираем вид животного, вписываем его имя и сохраняем данные. Для начала хватит.
Функциональные требования естественным образом можно поделить на части. Для начала на отдельных приложений или крупные компоненты, а затем на юз-кейсы. Наши требования – не исключение. Приложение у нас ровно одно, а в нём ы можем выделить два юз-кейса: фильтрацию и добавление. Можно сказать, что кроме этого приложение должно корректно запускаться, корректно закрываться, и это тоже будут юз-кейсы, но мы их пока в расчёт не берём из-за их неспецифичности.
Часть первая. Юз-кейсы и тест-кейсы
Для начала зафиксируем наши юз-кейсы:
Теперь в нашем тест-плане есть полноценные юз-кейсы, нужно наполнить их данными, чтобы получить тест-кейсы. Для того, чтобы понимать, что мы получим на выходе, мы должны знать, чем мы располагаем на момент начала тестирования. Это относится как к тестовому окружению, так и к содержимому базы данных на момент начала тестирования.
В юз-кейсе 1 мы варьируем как входные данные вид животного (комбо-бокс) и его имя (текст-бокс). Для каждого из вариантов имеется определённый ожидаемый результат. Для удобства составим таблицу данных. Не буду вдаваться в правила использования типов данных и граничных значений, так как большинство читателей с ними знакомо.
