Введение в тестовый сценарий
Тестовый сценарий - это комбинация двух слов, то есть теста и сценария. Тест представляет собой акт проверки или подтверждения, а сценарий представляет собой путешествие пользователя. Любая тестируемая функциональность называется сценарием тестирования. Сценарий тестирования может быть описан как проверка или подтверждение правильности поездки пользователя. Он будет в форме документов, содержащих все тестовые примеры, подробно написанные для проверки сквозной функциональности приложений. Это одна из высокоуровневых категорий требований, которые можно проверить. Это также известно как возможность тестирования или условия тестирования.
Зачем создавать тестовые сценарии?
Несколько тестовых случаев могут быть охвачены одним тестовым сценарием. Следовательно, связь между сценариями тестирования и контрольными случаями является однозначным. Но каждый сценарий должен быть учтен тестером при его создании. Тестеры создают его для тестирования приложения с точки зрения конечного пользователя. Тестировщики стремятся от всех разработчиков, заинтересованных сторон и клиентов подготовить их, которые являются критическими.
Причина их создания заключается в следующем:
- Полное и правильное покрытие тестов обеспечивается созданием совершенных тестовых сценариев.
- Их создание становится критически важным для изучения сквозных функций программы.
- Наиболее важные и критические сквозные транзакции или использование приложений в реальном времени могут быть точно определены при правильной их помощи.
- Они могут использоваться в качестве инструмента для быстрого определения рабочей силы по тестированию, которая также помогает клиентам или организациям эффективно и результативно создавать предложения и организацию рабочей силы по тестированию.
- Для обеспечения тщательного и правильного тестирования приложений его утверждение проводится на различных уровнях, включая клиентов, бизнес-аналитиков, разработчиков и т. Д.
Точно так же могут быть определенные обстоятельства, при которых его следует избегать.
- Его нельзя создавать в проектах, следующих за гибкими методологиями, такими как Scrum и т. Д.
- Когда тестируемые приложения нестабильны или слишком сложны, или когда проект находится в критическом состоянии, его создания можно избежать.
- Его можно избежать для регрессионного тестирования или для новой ошибки, потому что в проектах технического обслуживания их тяжелая документация может произойти заранее в предыдущих циклах тестирования.
Как тестовые сценарии могут быть написаны?
Следующие шаги могут быть выполнены тестером для создания тестовых сценариев:
- Шаг 1: Документ о требованиях, таких как Спецификация бизнес-требований (BRS), Спецификация функциональных требований (FRS) и Спецификация системных требований (SRS) приложения, подлежащего тестированию, следует внимательно и тщательно прочитать. Руководства, книги, варианты использования и т. Д. Тестируемого приложения могут быть отнесены к тому же.
- Шаг 2: Все возможные цели и действия пользователя должны быть правильно определены для каждого требования. Все технические характеристики каждого требования также должны быть определены.
- Шаг 3: Все возможные причины взлома системы и оценки пользователя должны выполняться с точки зрения хакера. Оценка пользователя может быть выполнена путем нахождения всех возможностей пользовательского управления приложениями.
- Шаг 4: Полный список всех возможных тестовых случаев для проверки всех функциональных возможностей приложения должен быть составлен после полного прочтения документа с требованиями и завершения анализа.
- Шаг 5: После привлечения всех из них для проверки соответствия требования и его сценария тестирования должна быть создана матрица отслеживания.
- Шаг 6: Все созданные тестовые сценарии проверяются и оцениваются супервизором. Это также дополнительно проверяется всеми заинтересованными сторонами.
В соответствии с процедурой проекта каждый сценарий тестирования должен соответствовать как минимум одной пользовательской истории или требованию. Обязательно проверять каждый тестовый сценарий на соответствие его требованию отдельно, перед несколькими требованиями в одном тестовом сценарии. Сложные тестовые сценарии с несколькими требованиями можно избежать для простоты. Цена прямо пропорциональна их количеству. Поэтому желательно всегда запускать только выбранные и требуемые в соответствии с приоритетом клиента.
Примеры
Ниже приведены несколько примеров сценария тестирования.
Тестовый сценарий для интернет-магазина приложений Buykart
Сценарии тестирования, которые можно принять во внимание при проверке приложения для онлайн-покупок Buykart, следующие:
Тестовый сценарий 1: проверка работоспособности входа
Тестовые случаи, которые можно рассмотреть для создания:
- Поведение приложения при вводе действительного идентификатора входа и действительного пароля можно проверить.
- Поведение приложения при вводе действительного логина и неверного пароля может быть проверено.
- Поведение приложения при вводе неверного логина и действительного пароля можно проверить.
- Поведение приложения при вводе неверного логина и неверного пароля можно проверить.
- Поведение приложения при входе путем ввода идентификатора входа без пароля можно проверить.
- Поведение приложения при входе путем ввода пароля без идентификатора входа можно проверить.
- Поведение приложения при входе в систему без ввода логина и пароля можно проверить.
- Поведение приложения при выборе забытого пароля.
Тестовый сценарий 2. Проверка функциональности поиска
Тестовые случаи, которые можно рассмотреть для создания:
- Поведение приложения при поиске действующего товара.
- Поведение приложения при поиске недействительного продукта.
Тестовый сценарий 3: проверка деталей продукта
Тестовые случаи, которые можно рассмотреть для создания:
- Поведение приложения при выборе продукта.
- Поведение приложения продукта в списке пожеланий.
- Поведение приложения при добавлении товара в корзину.
- Поведение приложения при выборе опции «Купить сейчас».
- Поведение приложения при вводе неверного адреса.
- Поведение приложения при вводе действительного адреса.
- Поведение приложения при проверке нескольких вариантов оплаты.
Тестовый сценарий 4: проверка функциональности платежа
Тестовые случаи, которые можно рассмотреть для создания:
- Поведение приложения при выборе каждого варианта оплаты.
- Поведение приложения, когда выбран правильный способ оплаты.
- Поведение приложения при выборе неверного варианта оплаты.
- Поведение приложения при успешной оплате.
- Поведение приложения при отклонении платежа.
Тестовый сценарий 5: проверка функциональности деталей заказа
Тестовые случаи, которые можно рассмотреть для создания:
- Поведение приложения при выборе каждого заказа.
- Поведение приложения при выборе опции «Возврат товара».
- Поведение приложения при выборе опции отслеживания товара.
- Поведение приложения при выборе опции «Обзор продукта».
Вывод
Он служит надлежащим руководством для тестировщиков и помогает им сделать тестирование более эффективным и действенным. Это помогает уменьшить сложность тестирования и избыточность. Каждый тестовый пример написан подробно для лучшего понимания. Это очень экономит время для тестеров.
Рекомендуемые статьи
Это было руководство к тому, что такое тестовый сценарий. Здесь мы обсудим, как создавать тестовые сценарии на разных примерах. Вы также можете взглянуть на следующие статьи, чтобы узнать больше -
- Стресс нестабильности работы
- Мотивированный и посвященный
- Что такое Agile Testing?
- Как написать контрольный пример?