Что такое тест-кейс?
Тест-кейс – это набор действий, выполняемых для проверки определенной функции или функциональности программного приложения. Тест-кейс содержит шаги тестирования, тестовые данные, предусловия и постусловия, разработанные для конкретного тестового сценария с целью проверки какого-либо требования. Тест-кейс включает в себя данные или условия, используя которые инженер по тестированию может сравнить ожидаемые и фактические результаты, чтобы определить, функционирует ли программный продукт в соответствии с требованиями заказчика.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Содержание:
- Что такое тест-кейс?
- Тестовый сценарий и тест-кейс
- Видеоролик о тест-кейсе
- Формат стандартных тест-кейсов
- Как писать тест-кейсы при ручном тестировании
- Тест-кейсы: советы и рекомендации
- Инструменты управления тест-кейсами
- Шаблон тест-кейса
Тестовый сценарий и тест-кейс
Тестовый сценарий и тест-кейс – это два разных документа, используемых в тестировании программного обеспечения. В отличие от тест-кейса, тестовый сценарий – это более высокоуровневый документ, описывающий функциональность приложения, которую необходимо протестировать. Тестовый сценарий может содержать ссылки на тест-кейсы, в то время как сам тест-кейс представляет собой конкретный набор шагов, которые должны быть выполнены для проверки конкретной функциональности программного приложения.
Для примера, если мы говорим о проверке функциональности входа в систему, мы можем создать несколько тест-кейсов для проверки различных аспектов этой функциональности. Некоторые из возможных тест-кейсов могут включать в себя:
- Проверка результатов при вводе допустимых значений пользователя и пароля.
- Проверка результатов при вводе неверных значений пользователя и пароля.
- Проверка реакции при пустом значении пользователя и нажатии кнопки входа.
Каждый из этих тест-кейсов содержит конкретный набор шагов/действий, которые должны быть выполнены для проверки определенной функциональности программного приложения.
Видеоролик о тест-кейсе
Формат стандартных тест-кейсов
Ниже приведен пример стандартных тест-кейсов для входа в систему.
| Test Case ID | Описание тест-кейса | Шаги воспроизведения | Тестовые данные | Ожидаемые результаты | Фактические результаты | Статус прохождения |
| TU01 | Проверка правильности ввода данных для входа в систему | 1. Перейти на сайт http://demo.guru99.com 2. Введите идентификатор пользователя 3. Введите пароль 4. Нажмите кнопку “Sign in” | Userid = guru99 Password = pass99 | Пользователь должен войти в приложение | Как и ожидалось | Pass |
| TU02 | Проверка входа клиента в систему с недопустимыми данными | 1. Перейти на сайт http://demo.guru99.com 2. Введите имя пользователя 3. Введите пароль 4. Нажмите кнопку “Sign in” | Userid = guru99 Password = glass99 | Пользователь не должен входить в систему | Как и ожидалось | Pass |
Для создания этой таблицы можно воспользоваться Word, Excel или любым инструментом для управления тестированием.
Как писать тест-кейсы при ручном тестировании
Давайте по этапно создадим тест-кейс для следующего сценария : Проверка функциональности входа в систему
Шаг 1. Уникальный номер и Описание тест-кейса. Самый простой тест-кейс описывающий данный сценарий, будет выглядеть следующим образом
| Test Case # | Описание тест-кейса |
|---|---|
| 1 | Проверка ответа при вводе правильного email и пароля |
Шаг 2. Тестирование данных
Для выполнения тестового кейса потребуются тестовые данные. Добавляем их ниже
| Test Case # | Описание тест-кейса | Тестовые данные |
|---|---|---|
| 1 | Проверка ответа при вводе правильного email и пароля | Email: guru99@email.com Password: lNf9^Oti7^2h |
Идентификация тестовых данных может занять много времени, а иногда может потребовать создания тестовых данных заново. Причина этого должна быть задокументирована.
Шаг 3. Выполнение действий
Для выполнения тест-кейса тестировщик должен выполнить определенную последовательность действий. Это необходимо описывать следующим образом:
| Test Case # | Описание тест-кейса | Шаги воспроизведения | Тестовые данные |
| 1 | Проверка ответа при вводе правильного email и пароля | 1. Введите адрес электронной почты 2. Введите пароль 3. Нажмите кнопку “Sign in” | Email: guru99@email.com Password: lNf9^Oti7^2h |
Во многих случаях этапы тестирования не являются такими простыми, как описано выше, поэтому необходимо их детально описывать. Кроме того, автор тест-кейса может покинуть организацию, уйти в отпуск, заболеть либо быть занятым другими важными задачами. Недавно принятого на работу сотрудника могут попросить выполнить тест-кейс. Подробно описанные шаги воспроизведения помогут новичку, а также помогут облегчить проверку другими заинтересованными сторонами.
Шаг 4. Проверка поведения
| Test Case # | Описание тест-кейса | Тестовые данные | Ожидаемый результат |
| 1 | Проверка ответа при вводе правильного email и пароля | Email: guru99@email.com Password: lNf9^Oti7^2h | Вход в систему должен быть успешным |
Во время выполнения теста тестировщик сверяет ожидаемые результаты с фактическими и присваивает статус “пройден” или “не пройден”.
| Test Case # | Описание тест-кейса | Тестовые данные | Ожидаемый результат | Фактический результат | Pass/Fail |
|---|---|---|---|---|---|
| 1 | Проверка ответа при вводе правильного email и пароля | Email: guru99@email.com Password: lNf9^Oti7^2h | Вход в систему должен быть успешным | Вход в систему прошел успешно | Pass |
Шаг 5. Предварительные условия и постусловия. В этом разделе вашего тест-кейса может быть такое поле, как
”Предварительные условия”(Pre-Condition), в котором указывается, какие условия должны быть выполнены до запуска теста. Для нашего тест-кейса предварительным условием будет наличие установленного браузера для доступа к тестируемому сайту. Тест-кейс также может содержать поле “Постусловия” (Post-Conditions), определяющее, каким должно быть состояние системы после выполнения данного теста. Для нашего тест-кейса постусловием будет сохранение в базе данных времени и даты входа в систему.
Тест-кейсы: советы и рекомендации
1. Тест-кейсы должны быть простыми и ясными:
Создавайте максимально простые тест-кейсы. Они должны быть понятными и лаконичными, поскольку автор тест-кейса может сам их не выполнять, а тому, кто их будет выполнять, это облегчит понимание шагов теста и ускорит его выполнение.
Используйте утвердительные формулировки, например, перейдите на домашнюю страницу, введите данные, нажмите на это и т.д.
2. Создавайте тест-кейсы с учетом интересов конечного пользователя.
Конечной целью любого программного проекта является создание тест-кейсов, простых в использовании и эксплуатации и отвечающих требованиям заказчика. Тестировщик должен создавать тест-кейсы, учитывая потребности конечного пользователя.
3. Избегайте повторения тест-кейсов.
Не следует повторять тест-кейсы. Если тест-кейс необходим для выполнения какого-либо другого тест-кейса, то в столбце предусловий следует указать ссылку на тест-кейс по его ID.
4. Не предполагайте.
Не предполагайте функциональность и возможности вашего программного приложения при подготовке тест-кейса. Придерживайтесь спецификации.
5. Обеспечьте 100-процентное покрытие.
Убедитесь, что написали тест-кейсы для проверки всех требований к ПО, указанных в спецификации. Используйте матрицу трассировки, чтобы убедиться, что ни одна функция/условие не осталась непроверенной.
6. Тест-кейсы должны быть идентифицируемыми.
В качестве идентификатора для тест-кейса служит уникальный числовой или буквенно-цифровой набор символов. Лучше всего идентификатор тест-кейса следует именовать так, чтобы его можно было легко идентифицировать при отслеживании дефектов или при определении требований к ПО на более позднем этапе.
7. Применение техник тест-дизайна.
Важно отметить, что невозможно проверить каждое возможное условие в вашем программном приложении. Техники тест-дизайна помогают выбрать несколько тест-кейсов с максимальной вероятностью обнаружения дефекта.
- Анализ граничных значений – Boundary Value Analysis (BVA). Как следует из названия, это методика, определяющая тестирование границ для заданного диапазона значений.
- Разбиение на эквивалентные классы – Equivalence Partition (EP). Эта техника разбивает диапазон на равные части/группы, которые, как правило, имеют одинаковое поведение.
- Метод перехода состояний – State Transition Technique. Метод используется, когда поведение программного обеспечения изменяется от одного состояния к другому в соответствии с определенным действием.
- Предугадывание ошибок – Error Guessing Technique. Метод предполагает угадывание/предсказание ошибок, которые могут возникнуть при ручном тестировании. Этот метод не является формальным и используется тестировщиком, имеющим опыт работы с подобным приложением.
8. Возвращение тестовой среды к первоначальному состоянию.
Тест-кейс, который вы создаете, должен возвращать тестовую среду в состояние до тестирования и не должен делать тестовую среду непригодной для использования. Это особенно актуально для конфигурационного тестирования.
9. Повторяемость и автономность
Тест-кейс должен генерировать одни и те же результаты каждый раз, независимо от того, кто его тестирует.
10. Экспертная оценка
После создания тест-кейсов попросите своих коллег их просмотреть. Ваши коллеги могут обнаружить дефекты в дизайне вашего тест-кейса, которые вы могли легко упустить.
При написании тест-кейса следует включать в него следующую информацию:
- Описание того, какое требование тестируется.
- Объяснение того, как система будет протестирована.
- Настройка тестового окружения, которая включает в себя установку программного и аппаратного обеспечения, создание тестовых данных и настройку сети для выполнения тест-кейсов.
- Входные, выходные данные и ожидаемые результаты.
- Любые подтверждения шагов и результатов, приложенных во вложениях.
- Последовательность шагов/действий с использованием активной формы глагола, которые должен выполнить тестировщик. Например, вместо “Проверка должна быть выполнена” следует использовать “Выполнить проверку”.
- Тест-кейс не должен содержать более 15 шагов.
- Автоматизированный тестовый сценарий должен содержать комментарии, в которых указаны входные данные, цель и ожидаемые результаты.
Инструменты управления тест-кейсами
Инструменты управления тест кейсами – это инструменты автоматизации, помогающие управлять и поддерживать тест-кейсы. Основными функциями этого инструмента являются:
- Документирование тест-кейсов: с помощью шаблонов можно ускорить создание тест-кейсов.
- Выполнение тест-кейса и запись результатов: тест-кейс может быть выполнен с помощью инструмента, и полученные результаты могут быть легко записаны.
- Автоматизация отслеживания дефектов: неудачные тесты автоматически связываются с баг-трекером, который в свою очередь могут быть назначены разработчикам и отслеживаться по электронной почте.
- Трассируемость: возможность отслеживать связи между различными элементами проекта, такими как требования, тест-кейсы и выполнение тест-кейсов. Инструменты управления тест-кейсами позволяют связать все эти элементы между собой, что обеспечивает полное покрытие тестами и упрощает процесс тестирования.
- Защита тест-кейсов: тест-кейсы должны быть многоразовыми и защищены от потери или повреждения из-за плохого контроля версий. Инструменты управления тест-кейсами предлагают такие функции, как
- Названия и нумерация
- Версионность
- Хранение только для чтения
- Контролируемый доступ
- Резервное копирование на удаленном сервере
К популярным инструментам управления тестирования относятся: JIRA, HP Quality Center, Azure DevOps.
Шаблон тест-кейса
- Пожалуйста, обратите внимание, что используемый шаблон может отличаться от проекта к проекту. Чтобы узнать больше о шаблоне тест-кейса и важных полях, которые необходимо заполнить, рекомендуется прочитать данное руководство.
Перевод статьи «How to Write Test Cases in Software Testing with Examples».
Пингбэк: Тест-кейс и тестовый сценарий
Пингбэк: Что такое тестирование ПО? Виды, методы и инструменты тестирования