Создание сценария тестирования

Что такое тестовый сценарий?

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

Что такое тестирование сценария?

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

Давайте изучим это с помощью видео ниже —

Зачем создавать тестовые сценарии?

Тестовые сценарии создаются по следующим причинам:

Создание тестовых сценариев обеспечивает полное покрытие тестами
Сценарии тестирования могут быть одобрены различными заинтересованными сторонами, такими как бизнес-аналитик, разработчики, клиенты, для обеспечения тщательного тестирования тестируемого приложения. Это гарантирует, что программное обеспечение работает для наиболее распространенных случаев использования.
Они служат быстрым инструментом для определения трудозатрат на тестирование и, соответственно, создают предложение для клиента или организуют рабочую силу.
Они помогают определить наиболее важные сквозные транзакции или реальное использование программных приложений.
Для изучения сквозного функционирования программы, тестовый сценарий имеет решающее значение.

Когда не создать тестовый сценарий?

Тестовые сценарии не могут быть созданы, когда

Тестируемое приложение является сложным, нестабильным, и в проекте есть время.
Проекты, которые следуют Agile методологии, такие как Scrum, Kanban, могут не создавать тестовые сценарии.
Сценарий тестирования не может быть создан для исправления новой ошибки или регрессионного тестирования . В таких случаях сценарии тестирования должны быть уже задокументированы в предыдущих циклах тестирования. Это особенно верно для проектов технического обслуживания.

Как написать тестовые сценарии

Как тестер, вы можете выполнить следующие пять шагов для создания тестовых сценариев:

Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию.
Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера.
Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения.
Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования.
Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте.

Советы по созданию тестовых сценариев

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

Пример 1. Сценарий тестирования для приложения электронной коммерции

Для приложения электронной коммерции несколько тестовых сценариев

Тестовый сценарий 1: проверка функциональности входа

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

Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
Проверить Забыли пароль работает как положено
Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
Проверять поведение системы, когда установлен флажок «Держать меня в подписи»

Как видно, тестовые случаи являются более конкретными.

Тестовый сценарий 2. Проверка функциональности поиска

Тестовый сценарий 3: проверьте страницу описания продукта

Сценарий тестирования 4: Проверьте функциональность платежей

Тестовый сценарий 5: проверка истории заказов

Помимо этих 5 сценариев, здесь приведен список всех других сценариев.

Проверьте поведение домашней страницы для постоянных клиентов
Проверьте категорию / страницы продукта
Проверьте службу поддержки / контактные страницы
Проверьте страницы ежедневных предложений

Пример 2: Тестовые сценарии для банковского сайта

Тестовый сценарий 1 : Проверьте функциональность входа и аутентификации

Тестовый сценарий 2 : Проверить перевод денег можно

Тестовый сценарий 3. Проверьте выписку со счета.

Тестовый сценарий 4 : Проверка фиксированного депозита / периодического депозита может быть создана

И так далее…

Шаблон сценария тестирования

Скачать шаблон тестового сценария Excel (.xlsx)

Источник

Важность тестирования программ
Автоматизация тестирования в 1С
Использование конфигурации «1С:Сценарное тестирование» для автоматизации процессов тестирования
- Основные принципы работы решения
- Способы написания сценариев тестирования: «накликивание», предопределенные шаги или универсальные макрошаги?
  - Первый способ — использование автоматической записи сценариев по журналу действий пользователя
  - Второй способ — использование предопределенных шагов
  - Третий способ — использование универсальных макрошагов
Организация тестирования 1С:Общепит
- Документирование — реестр и описание созданных сценариев тестирования
- Написание сценария тестирования с использованием универсальных макрошагов
- Загрузка, хранение и пакетный запуск сценариев тестирования
- Полезные доработки для более быстрого и безошибочного использования универсальных макрошагов
  - Гид по форме
  - Замена синонимов в сценарии тестирования
Полномасштабное автоматическое тестирование — This Is the Way

Важность тестирования программ

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

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

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

И главный вопрос, который возникает в данной ситуации: “Как?” Как ускорить процесс тестирования без ущерба качеству? Как не попасть в ловушку человеческого фактора и банально не забыть протестировать смежные блоки?

Одним из вариантов решения данной проблемы является автоматизация процессов тестирования.

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

Речь пойдет о трех видах тестирования: формальное, функциональное и регрессионное. И они будут рассмотрены со стороны процесса тестирования: ручного и автоматического.

Формальное тестирование — тестирование объектов конфигурации на наличие или отсутствие необходимого функционала и его работоспособности. Данный вид тестирования помогает выявить критические ошибки «падения», неверную логику работы объекта. По сути формальное тестирование отвечает за возможность объекта работать.

Функциональное тестирование — тестирование бизнес-логики работы объекта. Данный вид тестирования помогает выявить ошибки логики работы математических алгоритмов, ошибки записей по регистрам. По сути функциональное тестирование отвечает за правильность получаемых результатов в процессе работы объекта.

Регрессионное тестирование — собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода (Википедия).

Автоматизация тестирования в 1С

Рассматривая данные виды тестирования с точки зрения ручного и автоматизированного процесса тестирования необходимо учитывать стадию разработки тестируемого объекта или блока. Либо это новый разрабатываемый объект или блок, на который ещё не написан автоматизированный тест, либо стабильный протестированный объект или блок, у которого уже есть автоматизированный тест и в который вносятся доработки.

Если объект или блок новый и находится на стадии разработки, то сперва его стоит протестировать формально и функционально вручную. Это необходимо, чтобы понять, какие требования предъявлены объекту или блоку, как правильно он должен работать и, главное, чтобы подготовить план его тестирования. Как говорится, «пощупать на практике».

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

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

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

Регрессионное автоматизированное тестирование уменьшает время процесса тестирования, снижает нагрузку на тестировщика, освобождает его время для других задач, избавляет от человеческого фактора и проверяет смежные объекты или блоки, на которые могли повлиять внесенные изменения в проверяемом объекте или блоке.

Теперь давайте поговорим про инструменты автоматизации процессов тестирования. Для тестирования программных продуктов в среде «1С» можно выделить два инструмента:

1С:Сценарное тестирование, ред. 3.0 — конфигурация от фирмы «1С».
Vanessa ADD (Automation Driven Development) — open-source проект, являющийся результатом объединения фреймворков xUnitFor1C (дымовое и юнит-тестирование) и Vanessa-Behavior (сценарное тестирование и BDD). Может применяться в связке с 1С:СППР.

В рамках данной статьи будет рассмотрен вариант работы с решением «1С:Сценарное тестирование» по нескольким причинам:

Решение разрабатывается и находится на постоянной поддержке со стороны фирмы «1С».
Включает в себя обширный функционал для организации автоматического тестирования.

Использование конфигурации «1С:Сценарное тестирование» для автоматизации процессов тестирования

Основные принципы работы решения

Конфигурация устанавливается обычным способом для всех решений фирмы «1С»: установка шаблонов и развертывание информационной базы из них. Далее в конфигурации необходимо завести пользователей и произвести первоначальные настройки. Целью данной статьи не является полное описание настроек конфигурации для дальнейшей работы, потому не будем останавливаться на данном моменте. Узнать более подробно об первоначальной настройке конфигурации можно в документации на ИТС (https://its.1c.ru/db/kip#content:66:hdoc) и в обучающих видео (https://www.youtube.com/channel/UCbdRui0PGMp9lqhvnVJcRzA) от разработчиков данной конфигурации.

Итак, где же можно создавать сценарии тестирования

Непосредственно в конфигурации «1С:Сценарное тестирование» средствами встроенной обработки для написания сценариев тестирования, либо в любой другой информационной базе используя внешнюю обработку.

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

Менеджер тестирования — клиентское приложение, запущенное с параметром /TESTMANAGER. По сути это информационная база, на которой запускается обработка для написания и редактирования сценариев тестирования, т. е. является исполнителем сценария для проверяемого, клиентского приложения.

Клиент тестирования — клиентское приложение, запущенное с параметром /TESTCLIENT. По сути это информационная база, где исполняется сценарий тестирования.

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

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

В конфигурации «1С:Сценарное тестирование» создание сценариев тестирования происходит непосредственно из справочника Тесты, на закладке Сценарии. По кнопке Создать вызывается обработка для написания сценариев тестирования.

В случае использования внешней обработки, ее сначала необходимо сохранить из конфигурации «1С:Сценарное тестирование». Сделать это можно из подсистемы Администрирование, выбрав в группе Сервис команду Сохранить обработку в файл.

Сохраняется два вида обработок: «старая» с именем STest_<номер_версии_СцТ>.epf и интерактивная iSTest_<номер_версии_СцТ>.epf с префиксом «i» в начале имени файла.

Целью статьи не является сравнение функциональных возможностей двух обработок, но стоит отметить два существенных отличия. В «старой» обработке присутствует больше предопределенных шагов, в том числе, и групповой шаг проверки бизнес-логики. Интегрированная обработка является как внешней, так и встроенной, т. е. при написании сценариев тестирования непосредственно в конфигурации «1С:Сценарное тестирование» будет запускаться именно она.

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

Чем удобнее пользоваться: встроенной или внешней обработкой? Это зависит от поставленных целей. Если, например, необходимо продемонстрировать работу сценария тестирования или проверить работоспособность конфигурации на рабочем месте, где нет доступа к базе «1С:Сценарное тестирование», то удобнее пользоваться внешней обработкой и файлами сценариев. При редактировании сценария тестирования во внешней обработке его легко можно загрузить и обновить в конфигурации «1С:Сценарное тестирование».

При написании сценариев непосредственно в базе «1С:Сценарное тестирование» они сразу создаются и хранятся в ней.

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

Загрузка сценариев тестирования в конфигурацию «1С:Сценарное тестирование» необходимо для их хранения, компоновки в пакеты и запуска данных пакетов по регламенту.

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

Способы написания сценариев тестирования: «накликивание», предопределенные шаги или универсальные макрошаги?

Для ответа на вопрос: «Как писать сценарии тестирования?», необходимо предварительно разобраться с понятиями: сценарий тестирования, шаг сценария и типов шагов.

Сценарий тестирования — иерархический набор интерактивных и вспомогательных шагов, имитирующих работу пользователя для проверки правильности работы конфигурации.

Шаг сценария — действие или набор действий, выполняемых пользователем при проверке правильности работы конфигурации (например, нажатие кнопок командного интерфейса; открытие, закрытие форм объектов; заполнение полей формы (полей в шапке формы, в табличных частях) и т. д.). Шаги могут быть одиночными (выполнять какое-то одно конкретное действие), групповыми (объединенные в группу по природе действий или смыслу) и макрошагами.

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

Отдельно стоит выделить групповой шаг проверки бизнес-логики, который позволяет проверять как правильность заполнения объекта, так и его записи по регистрам.

Бизнес-логика — групповой шаг, предназначенный для хранения правил поиска объектов и записей информационной базы для дальнейшего полного или частичного сравнения объекта или записи информационной базы с эталонным значением, либо воспроизведения объекта или записи в информационной базе из эталонного значения.

Теперь, когда понятно, что сценарий тестирования состоит из шагов разного типа, перейдем к теме написания сценариев тестирования и рассмотрим подходы к созданию сценариев тестирования.

Выделим три способа написания сценариев. Два способа предлагается самой обработкой для написания сценариев, а третий способ — авторская разработка:

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

И рассмотрим данные способы с позиции двух, на наш взгляд, основных критериев:

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

Первый способ — использование автоматической записи сценариев по журналу действий пользователя

Автоматическая запись сценариев по журналу действий пользователя или «накликивание» достаточно простой и понятный способ работы со сценариями тестирования. Суть данного способа заключается в последовательном выполнении нескольких действий:

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

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

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

Главным достоинством данного способа является именно скорость и простота создания сценариев тестирования: пользователь просто записывает выполнение своих действий на клиенте тестирования, а обработка преобразовывает их в шаги сценария тестирования.

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

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

Второй способ — использование предопределенных шагов

Другой способ создания сценариев тестирование — использование предопределенных шагов, предлагаемых в обработке написания сценариев тестирования.

Необходимые шаги добавляются в сценарий тестирования вручную.

Как уже было сказано, количество шагов в «старой» и интерактивной обработках отличается, но в основных шагах они схожи. Ниже рассмотрены типы шагов «старой» обработки.

Обработка предоставляет возможность работы со следующими типами шагов:

интерактивные шаги для работы с формой;
интерактивные шаги для работы с таблицей;
интерактивные шаги для работы с табличным документом;
общие шаги проверки бизнес-логики;
общие интерактивные шаги;
общие шаги.

Каждый шаг имеет собственную форму настройки, а ее внешний вид зависит от типа настраиваемого шага.

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

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

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

Третий способ — использование универсальных макрошагов

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

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

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

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

На данный момент нами создано шесть универсальных макрошагов, которые позволяют покрывать требуемую нам для тестирования функциональность:

Переход в подсистемы и открытие формы списка объектов.
Изменение реквизитов на формах объектов.
Поиск в динамическом списке.
Закрытие всех или конкретного активного окна формы.
Нажатие любой кнопки на форме, в том числе декораций и гиперссылок командного интерфейса.
Сравнение табличных документов.

Какие плюсы универсальных макрошагов можно отметить?

Скорость заполнения одного макрошага
Макрошаги составлены таким образом, чтобы была возможность выполнять однотипные действия в пределах одной итерации. К примеру, заполнение элементов на форме происходит циклически и не требует постоянного добавления одного и того же шага на каждый элемент. Это сокращает время на поиск формы, поиск самого элемента и т. д.
Логика заполнения параметров универсальных макрошагов
Параметры структурированы логической цепочкой, которая позволяет быстро выстраивать алгоритм необходимых действий.
Меньше лишних действий
Макрошаги дают защиту «от дурака», когда пользователю нужно оперировать только элементами и необходимыми для его заполнения значениями, не задумываясь как именно макрошаг будет его выбирать и подставлять.
Количество универсальных макрошагов
Их всего шесть, в них тяжело запутаться.
Компактность сценариев тестирования
Один универсальный макрошаг может покрыть проверкой форму одного объекта, так как в значениях параметров возможно сразу указать несколько элементов формы.
Дополнительные возможности
Во-первых, это гид по форме, который позволяет видеть структуру проверяемой формы, копировать из него необходимое имя элемента или по двойному клику на элементе автоматически создавать требуемый универсальный макрошаг с предзаполненными параметрами и значениями в них.
Во-вторых, это возможность автоматической замены синонимов объектов во всех параметрах макрошагов сценария тестирования (см. Полезные доработки).

Данные плюсы, при минимальной практике, позволяют довольно быстро создавать и редактировать сценарии тестирования.

Организация тестирования 1С:Общепит

Организации тестирования типового отраслевого решения состоит из трех этапов:

Документирование, то есть создание описания плана тестирования и ведение реестра созданных сценариев тестирования.
Написание и отладка сценариев тестирования в обработке.
Создание пакетов тестирования и запуск их вручную или по расписанию.

Пройдемся подробнее по каждому из этапов.

Документирование — реестр и описание созданных сценариев тестирования

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

Реестр сценариев — список наименований сценариев тестирования, сгруппированный по определенному принципу, с возможностью отслеживать статусы написания/изменения и глубины раскрытия конкретного сценария тестирования.

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

Из реестра возможно перейти к описательной составляющей каждого указанного сценария, то есть к его плану тестирования, который состоит из трех обязательных пунктов:

предусловие,
сценарий тестирования,
результат.

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

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

Написание сценария тестирования с использованием универсальных макрошагов

Наши сценарии тестирования обязательно включают в себя два важных блока:

Ряд последовательных шагов, которые приводят к открытию или созданию объекта.
Групповой шаг проверки бизнес-логики, который является следствием и венцом правильности проверки объекта.

Для написания сценариев тестирования нами используется «старая» обработка.

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

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

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

Здесь следует отметить, что запуск менеджера тестирования и тестируемого клиента происходит под толстым клиентом. Такой режим работы необходим для универсальных макрошагов, использующих методы и объекты, доступные только на толстом клиенте. Так для проверки правильности создания печатных форм используется объект СравнениеФайлов, доступный только на толстом клиенте.

После установки соединения приступаем к написанию сценария тестирования.

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

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

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

И текста процедуры исполняемого на стороне менеджера тестирования.

Код

При нажатии на кнопку «Добавить параметры из макрошага» происходит заполнение предопределенными в макрошаге параметрами. При необходимости нужно заполнить значения параметров. На примере с рисунка ниже четыре базовых параметра, которые определяют порядок работы данного универсального макрошага.

КоличествоДобавляемыхСтрок — количество добавляемых строк в табличную часть объекта. Относится к элементу управления табличные части. Заполняется, если необходимо работать с табличной частью объекта.
Области — области объекта, в которых расположены элементы управления по названию из конфигуратора. Областью являются Шапка объекта, Вкладки. Есть возможность указать несколько областей через точку с запятой. Если область не указывается, то она игнорируется.
ПроверятьОткрытиеСервисныхОкон — для закрытия типовых сервисных окон, принимает значение Да или Нет. В значении Нет проверка на открытие сервисных окон не происходит. В значении Да закрывает служебные сервисные сообщения нажатием на кнопку ДА в окне сообщения.
СпискиДляПоиска — имя списка в конфигураторе, который будет использоваться при работе шага. Данный параметр актуален, если одна и та же форма подбора имеет несколько списков для поиска и необходимо точно знать в каком списке необходимо осуществлять поиск.

После добавления основных параметров производим заполнение значений параметров используя Гид по форме (см. Полезные доработки). Каждому исполняемому параметру, в зависимости от его типа, проставляется соответствующий префикс, что существенно облегчает поиск необходимого элемента на форме клиентского приложения.

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

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

Дальнейшее заполнение сценария универсальными макрошагами происходит в аналогичном ключе.

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

Добавление бизнес-логики происходит посредством создания группы, где можно выбрать отдельный объект для работы с ним.

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

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

На картинке видно, что фиксируется дата создания документа. В случае, если мы попробуем запустить этот тест завтра, то сформированный документ просто не будет найден. Решить данную проблему помогает привязка к уникальным идентификаторам у объекта. Как пример, можно осуществлять поиск по номеру документа в упорядоченном по убыванию списке. Либо же привязаться к уникальному комментарию в объекте.

В нашем случае запрос упрощается на порядок, осуществляя поиск последнего сформированного документа. Далее становясь на группу бизнес-логики по кнопке Добавить увидим, что появился набор дополнительных шагов.

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

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

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

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

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

Данный универсальный макрошаг может выполняться в двух режимах:

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

Для более наглядного примера логирование в примере выше отключено. Это значит, что в случае наличия различий в печатных формах будет выведено соответствующее окно сравнения двух табличных документов.

Загрузка, хранение и пакетный запуск сценариев тестирования

Сценарии тестирования пишутся нами во внешней обработке и сохраняются в файлы формата xml или zip. Для дальнейшего использования их необходимо загрузить в базу «1С:Сценарное тестирование».

Для чего это надо?

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

Во-вторых, для того, чтобы хранить все сценарии тестирования в едином месте. Гораздо проще следить за актуальностью сценариев тестирования, когда они хранятся в базе «1С:Сценарное тестирование». А также делать бэкап базы, а не отдельных файлов сценариев тестирования.

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

Загрузка сценариев тестирования происходит непосредственно в справочнике Тесты на закладке Сценарии по кнопке Создать из файла.

Здесь стоит отметить, что при использовании универсальных макрошагов они загружаются в базу «1С:Сценарное тестирование» один раз с любым из загруженных сценарием тестирования и в дальнейшем только заменяются на актуальные, если в их коде произошли изменения. Т.е. на все наши проекты мы используем только шесть наших универсальных макрошагов.

После того, как сценарии тестирования загружены в конфигурацию «1С:Сценарное тестирование» можно создавать пакеты. Для этого переходим в справочник Пакетное выполнение и создаем пакет по кнопке Создать.

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

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

В своих пакетах мы используем следующие шаги:

Группа подключения к базе, развернутой на сервере «1С» — в ней указывается расположение и параметры подключения к заранее вручную развернутой серверной базе.
Загрузка в нее эталонной ИБ — загрузка файла dt, расположенного по указанному пути. Эталонная база — это база, в которой уже предопределены необходимые настройки и есть минимальные данные для отработки сценариев тестирования.
Обновление ИБ файлом cf — обновление эталонной базы заранее сохраненным файлом cf с актуальными изменениями конфигурации.
Запуск тестируемого приложения — запуск эталонной базы с параметром клиента тестирования.
Выполнение интерактивных шагов сценариев тестирования — перечень интерактивных сценариев для выполнения.
Закрытие тестируемого приложения — закрытие эталонной базы.

Пакет можно запускать двумя способами:

Вручную по кнопке Выполнить. При этом протокол выполнения данного пакета можно посмотреть на одноименной вкладке Протоколы выполнения.
Автоматически по расписанию. При этом происходит автоматическая рассылка протокола выполнения для всех указанных пользователей.

Для того, чтобы пакет запустить по расписанию, мы используем планировщик заданий Windows и командную строку для запуска.

Командную строку можно взять из самого пакета по кнопке Еще, команда Получить командную строку для запуска.

Настройка планировщика заданий Windows подразумевает указание расписания и два действия, расположенных в определенной последовательности для правильной логики работы:

Запуск bat-файла для создания актуального cf, который далее будет загружаться шагом пакета Обновление ИБ файлом cf.
Запуск пакета.

Bat-файл состоит из команд для выгрузки актуального cf из информационной базы, подключенной к хранилищу:

Стоит отметить, что эталонная база и база, из которой выгружается cf — это разные базы. Мы намеренно не делаем подключение эталонной базы к хранилищу, чтобы была возможность вернуться к первоначальному состоянию эталонной базы. У нас эталонная база — это всегда актуальный вышедший релиз.

При запуске пакета возможна рассылка оповещений о результатах тестирования. Мы сделали рассылку через отдельный электронный почтовый ящик. Настройку его можно осуществить в подсистеме Администрирование, Органайзер, Учетные записи электронной почты.

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

Письмо на электронную почту получателя приходит с данными о пакете, который выполнялся: есть ли в нем ошибки и количество выполненных шагов в пакете. А также сам протокол, прикрепленный в виде внешнего файла в формате html.

В наименовании пакета стоит указывать наименование решения, чтобы по заголовку письма было понятно к какому проекту относится протокол выполнения.

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

Полезные доработки для более быстрого и безошибочного использования универсальных макрошагов

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

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

Здесь мы хотели бы поделиться своим опытом доработок, упрощающих тестировщику работу в написании сценариев тестирования.

Гид по форме

Первой доработкой стала функциональность, позволяющая динамически отрисовывать дерево элементов активной тестируемой формы в отдельном окне на стороне менеджера тестирования. Она получила название Гид по форме. Первоначальная идея была заимствована с open-source проекта Vanessa ADD, который там называется Исследователь формы.

При более подробном изучении, оказалось, что и в интерактивной обработке для написания сценариев конфигурации «1С:Сценарное тестирование» тоже присутствует Исследователь.

Основной задачей работы Гида по форме является упрощение поиска имен элементов формы для заполнения в значениях параметров универсальных макрошагов. Поскольку универсальные макрошаги по умолчанию могу работать как с наименованиями объектов, так и с их конфигурационными именами, было принято решения отрисовывать пары Синоним-Имя для существующих элементов формы.

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

Однако это не всегда действенно, когда речь заходит о большом количестве элементов на одной форме.

Было принято решение сделать двустороннее позиционирование. При нажатии на любую из строк дерева на стороне «Гида по форме» происходит позиционирование на элементе формы на стороне клиента тестирования. И наоборот, при нажатии на элемент формы на стороне клиента тестирования происходит позиционирование на строке дерева «Гида по форме» с его синонимом и именем.

Специфика некоторых универсальных макрошагов подразумевает иерархический поиск необходимого элемента формы среди множества группировок. Необходимо сначала указывать область поиска (группу), после чего сам элемент. Иногда бывает сложно визуально в форме Гида определить к какой табличной части или группировке принадлежит тот или иной реквизит.

Данная проблема была решена посредством введения дух вещей:

Динамической подсветкой родителя элемента.
Добавлением поля реквизита Комментарий, в котором выводится имя выделенного реквизита с префиксом, помогающим идентифицировать тип элемента формы (таблица, группа, поле ввода или кнопка).

И последняя доработка, которая была на данный момент произведена — возможность автоматического создания универсального макрошага по двойному клику на любом из элементов «Гида по форме». Тип универсального макрошага будет зависеть от того, какой тип у элемента. Необходим универсальный макрошаг, который работает с табличной частью объекта — нажимаем на элемент табличной части. Необходимо работать с кнопкой — нажимаем на имя кнопки.

На текущий момент Гид по форме продолжает развиваться и дорабатываться, с каждым разом все больше упрощая тестировщикам процесс создания автотестов.

Замена синонимов в сценарии тестирования

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

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

Обусловлено это тем, что некоторые элементы формы выстраивают свои наименования/имена динамически, в момент работы «1С:Предприятия» или же напрямую зависят от имени/синонима другого объекта конфигурации.

Так мы столкнулись с проблемой кнопок введения на основании. Наименование кнопки введения на основании здесь напрямую зависит от синонима того объекта, который мы хотим сформировать.

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

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

Решение проблемы оказалось достаточно тривиальным. За основу автозамены старого синонима в сценариях на новый был выбран подход мэппинг, позволяющий в отдельном файле хранить связку ИмяОбъекта — СинонимСтарый — СинонимНовый.

Мапирование (англ. data mapping, иногда маппинг, маппирование, мэппинг) — определение соответствия данных между потенциально различными семантиками одного объекта или разных объектов.(Википедия)

Решение задачи разделили на три этапа:

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

Рассмотрим более подробно каждый из этапов:

На основную форму обработки были добавлены и вынесены два новых реквизита:

Кнопка Синонимы метаданных, открывающая форму отбора метаданных.
Реквизит Синонимы, куда подтягивается соответствующий файл, с которым нам предстоит работать.

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

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

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

В случае ответа Да происходит ровно тоже самое за исключением того, что ранее установленные связи СтарыйСиноним‑НовыйСиноним исчезают, оставляя актуальным только последний существующий синоним.

Полномасштабное автоматическое тестирование — This Is the Way

С уверенностью можно утверждать, что на сегодняшний день отраслевые решения на платформе «1С:Предприятие» перешли в фазу, когда для качественного тестирования нужно полномасштабно проходить по всему решению при подготовке каждого релиза продукта.

Разумеется, сделать это вручную силами одного, двух и даже трех тестировщиков возможным не представляется из-за широты отраслевого функционала, серьезной ролевой развязки, большого количество настроек и функциональных опций. Единственным выходом из ситуации является организация профессионального автоматического тестирования всех видов, рассмотренных в статье.

Конечно можно еще предложить и вовсе не тестировать или тестировать частично, но это забег в пропасть. Мы выбираем путь профессионалов.

Если вам интересна разработка на платформе «1С:Предприятие», вы можете почитать другие статьи от экспертов «1С-Рарус»:

Jenkins в разработке конфигураций «1С»
Производительность нового RLS в 1С БСП 3. Переходить или нет?
Оптимизация перезапуска рабочих процессов на платформе «1С» 8.3.15 и выше

И подписывайтесь на рассылку с новостями компании «1С-Рарус». Рассылка выходит один раз в 2 недели и содержит список актуальных мероприятий, которые мы проводим, и свежих публикаций на сайте.

Авторы статьи

Осипов Александр

Черанев Андрей

Источник

Санкт-Петербургский
Государственный Университет Информационных
Технологий, Механики и Оптики

Кафедра Информационных
Технологий и Программирования

Лабораторная
работа №2.
Вар 1.

Тема:
Создание тестового сценария (test
case).

Выполнили студенты:

Шевченко Алексей

Тихонов Дмитрий

Группа: 5511

Преподаватель:

Санкт-Петербург

2008 год

Цель:
Научиться создавать простейшие тестовые
сценарии (test case).

Задание:
Написать тестовый сценарий из не
менее 10 шагов, Оплата мобильного телефона
через платежный терминал. Сценарий
должен включать в себя не только основной
вариант использования функционала, но
и ошибочный (например: ввод пустого/неверного
пароля в примере). Обратите внимание,
что все предварительные действия,
необходимые для прохождения шага, должны
быть явно описаны. Например, нельзя
требовать от тестировщика банкомата
ввести ПИН код до того как он вставил
карту.

Название	Оплата телефона
Дата создания	20.10.2008
Автор	Алексей Шевченко
Дата последнего изменения	25.10.2008
Описание	Проверка функционирования терминала оплаты мобильного телефона и его антивандальной устойчивости.

Шаг №	Описание	Тестовые данные	Ожидаемый результат
1	Введите номер телефона, на экранной клавиатуре	1234567	В окне появиться номер 1234567 Кнопка Ок подсветиться.
2	Нажмите кнопку Ок		Появится окно с номером телефона в углу, пустым счетчиком купюр, и надписью Жду денег, 100, 500, 1000р, неактивная кнопка оплатить и кнопка изменить номер
3	Сунем рваную десяти рублевую бумажку, в щель приема денег	10 рублей	На экране ничего не происходит, автомат «выплевывает» бумажку обратно
4	Сунем 100 рублей	100 рублей	Купюра исчезла, в окне счетчика появилась цифра 100 кнопка оплатить стала активной
5	Сунем еще 100 рублей	100 рублей	Купюра исчезла, в окне счетчика появилась цифра 200
6	Нажмем на кнопку изменить номер		Появляется меню для выбора номера телефона, экранная клавиатура
7	Введем номер 7654321, так же как в пункте один	7654321	Появилось Появится окно с номером телефона в углу, в окне счетчика написано 200 и надписью Жду денег, 100, 500, 1000р, активная кнопка оплатить и кнопка изменить номер
8	Нажимаем кнопку оплатить		Появляется надпись 200р успешно зачислено на счет, и чек.
9	Повторяем шаги 1.2. Сунем 1000 рублей	1000 рублей	Купюра исчезла, в окне счетчика появилась цифра 1000
10	Вспоминаем, что уже оплатили телефон		Пытаемся вернуть деньги
11	Нажимаем на кнопку помощь		На экране появляется инструкция по использованию автомата, Пункт 1 КАК Вернуть Деньги Засунутые в Автомат
12	Нажимаем на 1 пункт меню пальцем		На экране появляется надпись крупными красными буквами, гласящая о том, что автомат деньги не возвращает.
13	Злимся. Пинаем автомат ногой и разбиваем экран		Автомат вырубается, получаем удар током, попадаем в руки прапорщика из местного отдела ППС

4. Система прошла тестирование успешно,
за исключением антивандальной защиты
(необходимо сделать корпус прочнее). Мы
освоили написание тестовых сценариев,
а

Соседние файлы в папке все лабы итип

#
#
#
#
#
09.05.201437.89 Кб745511-5-s14&s17.xls

Источник

Введение в тестовый сценарий

Тестовый сценарий — это комбинация двух слов, то есть теста и сценария. Тест представляет собой акт проверки или подтверждения, а сценарий представляет собой путешествие пользователя. Любая тестируемая функциональность называется сценарием тестирования. Сценарий тестирования может быть описан как проверка или подтверждение правильности поездки пользователя. Он будет в форме документов, содержащих все тестовые примеры, подробно написанные для проверки сквозной функциональности приложений. Это одна из высокоуровневых категорий требований, которые можно проверить. Это также известно как возможность тестирования или условия тестирования.

Зачем создавать тестовые сценарии?

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

Причина их создания заключается в следующем:

Полное и правильное покрытие тестов обеспечивается созданием совершенных тестовых сценариев.
Их создание становится критически важным для изучения сквозных функций программы.
Наиболее важные и критические сквозные транзакции или использование приложений в реальном времени могут быть точно определены при правильной их помощи.
Они могут использоваться в качестве инструмента для быстрого определения рабочей силы по тестированию, которая также помогает клиентам или организациям эффективно и результативно создавать предложения и организацию рабочей силы по тестированию.
Для обеспечения тщательного и правильного тестирования приложений его утверждение проводится на различных уровнях, включая клиентов, бизнес-аналитиков, разработчиков и т. Д.

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

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

Как тестовые сценарии могут быть написаны?

Следующие шаги могут быть выполнены тестером для создания тестовых сценариев:

Шаг 1: Документ о требованиях, таких как Спецификация бизнес-требований (BRS), Спецификация функциональных требований (FRS) и Спецификация системных требований (SRS) приложения, подлежащего тестированию, следует внимательно и тщательно прочитать. Руководства, книги, варианты использования и т. Д. Тестируемого приложения могут быть отнесены к тому же.
Шаг 2: Все возможные цели и действия пользователя должны быть правильно определены для каждого требования. Все технические характеристики каждого требования также должны быть определены.
Шаг 3: Все возможные причины взлома системы и оценки пользователя должны выполняться с точки зрения хакера. Оценка пользователя может быть выполнена путем нахождения всех возможностей пользовательского управления приложениями.
Шаг 4: Полный список всех возможных тестовых случаев для проверки всех функциональных возможностей приложения должен быть составлен после полного прочтения документа с требованиями и завершения анализа.
Шаг 5: После привлечения всех из них для проверки соответствия требования и его сценария тестирования должна быть создана матрица отслеживания.
Шаг 6: Все созданные тестовые сценарии проверяются и оцениваются супервизором. Это также дополнительно проверяется всеми заинтересованными сторонами.

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

Примеры

Ниже приведены несколько примеров сценария тестирования.

Тестовый сценарий для интернет-магазина приложений Buykart

Сценарии тестирования, которые можно принять во внимание при проверке приложения для онлайн-покупок Buykart, следующие:

Тестовый сценарий 1: проверка работоспособности входа