Учебники

Дизайн теста

Что такое контрольный пример?

TEST СЛУЧАЙ представляет собой набор действий , выполняемых для проверки конкретной функции или функциональности вашего приложения. Тестовый набор содержит шаги теста, данные теста, предварительное условие, постусловие, разработанное для конкретного тестового сценария для проверки любого требования. Тестовый пример включает в себя конкретные переменные или условия, с помощью которых инженер-тестировщик может сравнить ожидаемые и фактические результаты, чтобы определить, функционирует ли программный продукт в соответствии с требованиями заказчика.

Тестовый сценарий против тестового примера

Тестовые сценарии довольно расплывчаты и охватывают широкий спектр возможностей. Тестирование — это очень специфично.

Для тестового сценария : Проверьте функциональность входа в систему существует много возможных тестовых случаев:

  • Контрольный пример 1: проверка результатов при вводе действительного идентификатора пользователя и пароля
  • Контрольный пример 2. Проверка результатов при вводе неверного идентификатора пользователя и пароля
  • Тестовый пример 3: Проверьте ответ, когда идентификатор пользователя пуст и нажата кнопка входа, и многое другое

Это всего лишь тестовый пример.

Нажмите здесь, если видео не доступно

Как создать тестовый набор

Давайте создадим тестовый сценарий для сценария: Проверка функциональности входа

Тестовый анализ V Модель тестирования

Шаг 1) Простой тестовый сценарий для сценария будет

Прецедент # Описание теста
1 Проверьте ответ при вводе действительного адреса электронной почты и пароля

Шаг 2) Чтобы выполнить тестовый пример, вам понадобятся тестовые данные. Добавляя это ниже

Прецедент # Описание теста Тестовые данные
1 Проверьте ответ при вводе действительного адреса электронной почты и пароля Электронная почта: guru99@email.com Пароль: lNf9 ^ Oti7 ^ 2h

Идентификация тестовых данных может занимать много времени и иногда может потребовать создания тестовых данных заново. Причину этого нужно документировать.

Шаг 3) Чтобы выполнить тестовый пример, тестер должен выполнить определенный набор действий над AUT. Это задокументировано как ниже:

Прецедент # Описание теста Тестовые шаги Тестовые данные
1 Проверьте ответ при вводе действительного адреса электронной почты и пароля

1) Введите адрес электронной почты

2) Введите пароль

3) Нажмите Войти

Электронная почта: guru99@email.com

Пароль: lNf9 ^ Oti7 ^ 2h

Часто тестовые шаги не так просты, как указано выше, поэтому им нужна документация. Кроме того, автор тестового примера может покинуть организацию или уйти в отпуск, он болен и не работает, или очень занят другими важными задачами. Недавно нанятого человека могут попросить выполнить контрольный пример. Документированные шаги помогут ему, а также облегчат обзоры другими заинтересованными сторонами.

Шаг 4) Целью тестовых случаев является проверка поведения AUT на ожидаемый результат. Это должно быть задокументировано как ниже

Прецедент # Описание теста Тестовые данные ожидаемый результат
1 Проверьте ответ при вводе действительного адреса электронной почты и пароля Электронная почта: guru99@email.com
Пароль: lNf9 ^ Oti7 ^ 2h
Логин должен быть успешным

Во время выполнения теста, тестер будет проверять ожидаемые результаты по сравнению с реальными результатами и назначать статус прохождения или сбоя

Прецедент # Описание теста Тестовые данные ожидаемый результат Фактический результат Pass / Fail
1 Проверьте ответ при вводе действительного адреса электронной почты и пароля Электронная почта: guru99@email.com Пароль: lNf9 ^ Oti7 ^ 2h Логин должен быть успешным Вход был успешным Проходить

Шаг 5) Кроме того, в вашем тестовом случае может быть поле типа Pre-Condition, в котором указаны вещи, которые должны быть выполнены до запуска теста. Для нашего тестового примера предварительным условием было бы установить браузер для доступа к тестируемому сайту. Тестовый набор также может включать в себя постусловия, в которых указывается все, что применяется после его завершения. Для нашего тестового примера постусловием будет время и дата входа в систему, хранящиеся в базе данных.

Формат стандартных тестовых случаев

Ниже приведен формат стандартного логина Test case

Идентификатор теста Тестовый сценарий Тестовые шаги Тестовые данные Ожидаемые результаты Фактические результаты Pass / Fail
TU01 Проверьте логин клиента с действительными данными
  1. Перейти на сайт http://demo.guru99.com
  2. Введите идентификатор пользователя
  3. Введите пароль
  4. Нажмите Отправить
ID пользователя = guru99 Пароль = pass99 Пользователь должен войти в приложение Как и ожидалось Проходить
TU02 Проверьте логин клиента с неверными данными
  1. Перейти на сайт http://demo.guru99.com
  2. Введите идентификатор пользователя
  3. Введите пароль
  4. Нажмите Отправить
ID пользователя = guru99 Пароль = glass99 Пользователь не должен Войти в приложение Как и ожидалось Проходить

Вся эта таблица может быть создана в Word, Excel или любом другом инструменте управления тестированием. Вот и все, чтобы проверить дизайн корпуса

При составлении контрольного примера, чтобы включить следующую информацию

  • Описание того, что требование проверяется
  • Объяснение того, как система будет тестироваться
  • Настройка теста, такая как версия тестируемого приложения, программное обеспечение, файлы данных, операционная система, оборудование, доступ к безопасности, физическая или логическая дата, время дня, предварительные условия, такие как другие тесты, и любая другая информация о настройке, относящаяся к тестируемым требованиям.
  • Входы и выходы или действия и ожидаемые результаты
  • Любые доказательства или вложения
  • Используйте активный язык кейсов
  • Тестовый кейс не должен быть более 15 шагов
  • Скрипт автоматизированного теста комментируется с входными данными, целью и ожидаемыми результатами
  • Установка предлагает альтернативу предварительным тестам
  • С другими тестами это должен быть неправильный порядок бизнес-сценария

Лучшая практика для написания хорошего примера теста.

1. Тестовые случаи должны быть простыми и прозрачными:

Создайте тестовые случаи, которые настолько просты, насколько это возможно. Они должны быть четкими и краткими, поскольку автор теста не может выполнить их.

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

2. Создайте контрольный пример, помня конечного пользователя

Конечная цель любого программного проекта — создать тестовые наборы, которые отвечают требованиям клиентов, просты в использовании и эксплуатации. Тестер должен создавать контрольные примеры с учетом перспективы конечного пользователя

3. Избегайте повторения тестовых случаев.

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

4. Не предполагайте

Не принимайте во внимание функциональность и возможности вашего программного приложения при подготовке тестового примера. Придерживайтесь спецификации документов.

5. Обеспечить 100% охват

Убедитесь, что вы пишете контрольные примеры, чтобы проверить все требования к программному обеспечению, упомянутые в документе спецификации. Используйте Traceability Matrix, чтобы гарантировать, что никакие функции / условия не останутся непроверенными.

6. Тестовые случаи должны быть опознаваемыми.

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

7. Внедрить методы тестирования

Невозможно проверить все возможные условия в вашем программном приложении. Методы тестирования программного обеспечения помогут вам выбрать несколько тестовых случаев с максимальной вероятностью обнаружения дефекта.

  • Анализ граничных значений (BVA). Как следует из названия, это метод, который определяет тестирование границ для указанного диапазона значений.
  • Разделение эквивалентности (EP): этот метод разбивает диапазон на равные части / группы, которые имеют одинаковое поведение.
  • Техника перехода между состояниями : этот метод используется, когда поведение программного обеспечения изменяется от одного состояния к другому после определенного действия.
  • Техника угадывания ошибок: это угадывание / ожидание ошибки, которая может возникнуть при выполнении ручного тестирования. Это не формальный метод и использует опыт тестера с приложением

8. Самоочищающийся

Созданный вами тестовый пример должен вернуть тестовую среду в состояние предварительного тестирования и не должен делать тестовую среду непригодной для использования. Это особенно верно для тестирования конфигурации.

9. Повторяемость и самостоятельность

Тестовый пример должен давать одинаковые результаты каждый раз, независимо от того, кто его тестирует

10. Рецензирование.

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

Инструменты управления тест-кейсами

Инструменты управления тестами — это инструменты автоматизации, которые помогают управлять и поддерживать тестовые случаи. Основные характеристики инструмента управления тестовыми сценариями:

  1. Для документирования тестовых случаев: с помощью инструментов вы можете ускорить создание тестового набора с использованием шаблонов
  2. Выполните контрольный пример и запишите результаты: контрольный пример можно выполнить с помощью инструментов, а полученные результаты легко записать.
  3. Автоматизация отслеживания дефектов. Неудачные тесты автоматически связываются с системой отслеживания ошибок, которая, в свою очередь, может быть назначена разработчикам и отслеживаться посредством уведомлений по электронной почте.
  4. Прослеживаемость: требования, тестовые случаи, выполнение тестовых случаев — все они связаны через инструменты, и каждый случай может быть прослежен друг к другу, чтобы проверить покрытие теста.
  5. Защита тестовых случаев: тестовые случаи должны быть многоразовыми и должны быть защищены от потери или повреждения из-за плохого контроля версий. Инструменты управления тест-кейсами предлагают такие функции, как
  • Соглашения об именах и нумерации
  • Versioning
  • Хранение только для чтения
  • Контролируемый доступ
  • Резервное копирование вне сайта

Популярные инструменты управления тестированием: Quality Center и JIRA

Ресурсы

  • Обратите внимание, что используемый шаблон будет отличаться от проекта к проекту. Прочтите это руководство, чтобы изучить шаблон тестового примера с объяснением важных полей.

Загрузите приведенный выше шаблон тестового примера Excel (.xls)