Тестовый сценарий образец

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И так далее…

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

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

Источник

Тестовые сценарии (Test case), тестовые варианты. Оформление результатов тестирования.

ТЕРМИНОЛОГИЯ И ОБЩИЕ СВЕДЕНИЯ

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

Во главе всего лежит термин «тест». Официальное определение звучит так.

Тест — набор из одного или нескольких тест-кейсов.

Поскольку среди всех прочих терминов этот легче и быстрее всего произносить, в зависимости от контекста под ним могут понимать и отдельный пункт чек-листа, и отдельный шаг в тест-кейсе, и сам тест-кейс, и набор тест-кейсов и… продолжать можно долго. Главное здесь одно: если вы слышите или видите слово «тест», воспринимайте его в контексте.

Теперь рассмотрим самый главный для нас термин — «тест-кейс».

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

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

Мы ещё вернёмся к этой мысли, но уже сейчас критически важно понять и запомнить: если у тест-кейса не указаны входные данные, условия выполнения и ожидаемые результаты, и/или не ясна цель тест-кейса — это плохой тест-кейс (иногда он не имеет смысла, иногда его и
вовсе невозможно выполнить).

Иногда термин «test case» на русский язык переводят как «тестовый случай». Это вполне адекватный перевод, но из-за того, что «тест-кейс» короче произносить, наибольшее распространение получил именно этот вариант.

Высокоуровневый тест-кейс — тест-кейс без конкретных входных дан-
ных и ожидаемых результатов.

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

Низкоуровневый тест-кейс — тест-кейс с конкретными входными дан-
ными и ожидаемыми результатами.

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

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

Спецификация теста — документ, состоящий из спецификации тест-дизайна, спецификации тест-кейса и/или спецификации тест-процедуры.

Тест-сценарий — документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»).

ЦЕЛЬ НАПИСАНИЯ ТЕСТ-КЕЙСОВ

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

Наличие же тест-кейсов позволяет:

  • Структурировать и систематизировать подход к тестированию (без чего крупный проект почти гарантированно обречён на провал).
  • Вычислять метрики тестового покрытия (test coverage 296 metrics) и принимать меры по его увеличению (тест-кейсы здесь являются главным источником информации, без которого существование подобных метрик теряет смысл).
  • Отслеживать соответствие текущей ситуации плану (сколько примерно понадобится тест-кейсов, сколько уже есть, сколько выполнено из запланированного на данном этапе количества и т.д.).
  • Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками (тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем это отражено в требованиях).
  • Хранить информацию для длительного использования и обмена опытом между сотрудниками и командами (или как минимум — не пытаться удержать в голове сотни страниц текста).
  • Проводить регрессионное тестирование и повторное тестирование (которые без тест-кейсов было бы вообще невозможно выполнить).
  • Повышать качество требований (мы это уже рассматривали: написание чек-листов и тест-кейсов — хорошая техника тестирования требований).
  • Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту.

ЖИЗНЕННЫЙ ЦИКЛ ТЕСТ-КЕЙСА

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

  • Создан — типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания.
  • Запланирован — в этом состоянии тест-кейс находится, когда он
    или явно включён в план ближайшей итерации тестирования, или как минимум готов для выполнения.
  • Не выполнен — в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.
  • Выполняется — если тест-кейс требует длительного времени на выполнение, он может быть переведён в это состояние для подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний — «провален», «пройден успешно» или «заблокирован».
  • Пропущен — бывают ситуации, когда выполнение тест-кейса отменяется по соображениям нехватки времени или изменения логики тестирования.
  • Провален — данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одному шагу тест-кейса не совпадает с фактическим результатом. Если в процессе выполнения тест-кейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидаемыми результатами, тест-кейс считается пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся отчёт о дефекте).
  • Пройден успешно — данное состояние означает, что в процессе выполнения тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и фактических результатов его шагов.
  • Заблокирован — данное состояние означает, что по какой-то причине выполнение тест-кейса невозможно (как правило, такой причиной является наличие дефекта, не позволяющего реализовать некий пользовательский сценарий).
  • Закрыт — очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В данное состояние в некоторых системах управления тест-кейс переводят, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия с ним завершены.
  • Требует доработки — как видно из схемы, в это состояние (и из него) тест-кейс может быть преведён в любой момент времени, если в нём будет обнаружена ошибка, если изменятся требования, по которым он был написан, или наступит иная ситуация, не позволяющая считать тест-кейс пригодным для выполнения и перевода в иные состояния.

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

Атрибуты (поля) тест-кейса.

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

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

Общий вид всей структуры тест-кейса представлен ниже:

Теперь рассмотрим каждый атрибут подробно.

Идентификатор представляет собой уникальное значение, позволяющее однозначно отличить один тест-кейс от другого и используемое во всевозможных ссылках. В общем случае идентификатор тест-кейса может представлять собой просто уникальный номер, но (если
позволяет инструментальное средство управления тест-кейсами) может быть и куда сложнее: включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить цель тест-кейса и часть приложения (или требований), к которой он относится (например:
UR216_S12_DB_Neg).

Приоритет показывает важность тест-кейса. Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но чаще всего лежит в диапазоне от трёх до пяти.

Приоритет тест-кейса может коррелировать с:

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

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

Связанное с тест-кейсом требование показывает то основное требование, проверке выполнения которого посвящён тест-кейс (основное — потому, что один тест-кейс может затрагивать несколько требований). Наличие этого поля улучшает такое свойство тест-кейса,
как прослеживаемость.

Частые вопросы, связанные с заполнением этого поля, таковы:

  • Можно ли его оставить пустым? Да. Тест-кейс вполне мог разрабатываться вне прямой привязки к требованиям, и (пока?) значение этого поля определить сложно. Хоть такой вариант и не считается хорошим, он достаточно распространён.
  • Можно ли в этом поле указывать несколько требований? Да, но чаще всего стараются выбрать одно самое главное или «более высокоуровневое» (например, вместо того, чтобы перечислять R56.1, R56.2, R56.3 и т.д., можно просто написать R56). Чаще всего в инструментах управления тестами это поле представляет собой выпадающий список, где можно выбрать только одно значение, и этот вопрос становится неактуальным. К тому же многие тест-кейсы всё же направлены на проверку строго одного требования, и для них этот вопрос также неактуален.

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

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

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

  • Механизм запуска:

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

  • Механизм взаимодействия с файловой системой:

    • механизм обхода дерева SOURCE_DIR;
    • механизм обработки ошибочных ситуаций.

  • Механизм преобразования файлов:

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

  • Механизм ведения журнала:

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

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

  • Стартер:
    • анализатор параметров;
    • сборщик приложения;
    • обработчик ошибок.
  • Сканер:
    • обходчик;
    • обработчик ошибок.
  • Преобразователь:
    • детектор;
    • конвертер;
    • обработчик ошибок.
  • Регистратор:
    • дисковый регистратор;
    • консольный регистратор;
    • обработчик ошибок.

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

Внимание! Частая ошибка! Модуль и подмодуль приложения — это НЕ действия, это именно структурные части, «куски» приложения. В заблуждение вас могут ввести такие названия, как, например, «печать, настройка принтера» (но здесь имеются в виду именно части приложения, отвечающие за печать и за настройку принтера (и названы
они отглагольными существительными), а не процесс печати или настройки принтера).

Сравните (на примере человека): «дыхательная система, лёгкие» — это модуль и подмодуль, а «дыхание», «сопение», «чихание» — нет; «голова, мозг» — это модуль и подмодуль, а «кивание», «думание» — нет.

Наличие полей «Модуль» и «Подмодуль» улучшает такое свойство тест-кейса, как прослеживаемость.

Заглавие тест-кейса призвано упростить и ускорить понимание основной идеи (цели) тест-кейса без обращения к его остальным атрибутам. Именно это поле является наиболее информативным при просмотре списка тест-кейсов.

Сравните.

Плохо Хорошо
Тест 1 Запуск, одна копия, верные параметры
Тест 2 Запуск одной копии с неверными путями
Тест 78 (улучшенный) Запуск, много копий, без конфликтов
Остановка Остановка по Ctrl+C
Закрытие Остановка закрытием консоли

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

  • Информативность.
  • Хотя бы относительная уникальность (чтобы не путать разные тест-кейсы).

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

И ещё одна небольшая мысль, которая может помочь лучше формулировать заглавия. В дословном переводе с английского «test case» обозначает «тестовый случай (ситуация)». Так вот, заглавие как раз и описывает этот случай (ситуацию), т.е. что происходит в тест-кейсе, какую
ситуацию он проверяет.

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

  • Состояние базы данных.
  • Состояние файловой системы и её объектов.
  • Состояние серверов и сетевой инфраструктуры.

То, что описывается в этом поле, готовится БЕЗ использования тестируемого приложения, и таким образом, если здесь возникают проблемы, нельзя писать отчёт о дефекте в приложении.
Эта мысль очень и очень важна, потому поясним её простым жизненным примером. Представьте, что вы дегустируете конфеты. В поле «исходные данные» можно прописать «купить конфеты таких-то сортов в таком-то количестве». Если таких конфет нет в продаже, если закрыт магазин,
если не хватило денег и т. д. — всё это НЕ проблемы вкуса конфет, и нельзя писать отчёт о дефекте конфет вида «конфеты невкусные потому, что закрыт магазин».

Некоторые авторы не следуют этой логике и допускают в приготовлениях работу с тестируемым приложением. И здесь нет «правильного варианта» — просто в одной традиции решено одним образом, в другой — другим. Во многом это — ещё и терминологическая проблема: «preparation», «initial data» и «setup» вполне логично выполнять без участия тестируемого приложения, в то время как «precondition» по смыслу ближе к описанию состояния тестируемого приложения. В реальной рабочей обстановке вам достаточно будет прочитать несколько тест-кейсов, уже созданных вашими коллегами,
чтобы понять, какой точки зрения на данный вопрос они придерживаются.

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

  • начинайте с понятного и очевидного места, не пишите лишних начальных шагов (запуск приложения, очевидные операции с интерфейсом и т. п.);
  • даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность в будущем случайно «приклеить» описание этого шага к новому тексту);
  • если вы пишете на русском языке, используйте безличную форму (например, «открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»), в английском языке не надо использовать частицу «to» (т.е. «запустить приложение» будет «start application», не «to start application»);
  • соотносите степень детализации шагов и их параметров с целью тест-кейса, его сложностью, уровнем и т. д. — в зависимости от этих и многих других факторов степень детализации может варьироваться от общих идей до предельно чётко прописанных значений и указаний;
  • ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста (например, «повторить шаги 3–5 со значением…»);
  • пишите шаги последовательно, без условных конструкций вида «если… то…».

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

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

По написанию ожидаемых результатов можно порекомендовать следующее:

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

Внимание! Частая ошибка! В ожидаемых результатах ВСЕГДА описывается КОРРЕКТНАЯ работа приложения. Нет и не может быть ожидаемого результата в виде «приложение вызывает ошибку в операционной системе и аварийно завершается с потерей всех пользовательских данных».

При этом корректная работа приложения вполне может предполагать отображение сообщений о неверных действиях пользователя или неких критических ситуациях. Так, сообщение «Невозможно сохранить файл по указанному пути: на целевом носителе недостаточно свободного места» — это не ошибка приложения, это его совершенно нормальная и правильная работа. Ошибкой приложения (в этой же ситуации) было бы
отсутствие такого сообщения, и/или повреждение, или потеря записываемых данных.

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

Свойства качественных тест-кейсов

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

Правильный технический язык, точность и единообразие формулировок. Это свойство в равной мере относится и к требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой до-
кументации. Основные идеи уже были описаны (см. главу «Атрибуты (поля) тест-кейсов»), а из самого общего и важного напомним и добавим:

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

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

Рассмотрим поля «шаги» и «ожидаемые результаты» двух тест-кейсов (подумайте, какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему):

Тест-кейс 1:

Шаги Ожидаемые результаты
Конвертация из всех поддерживаемых кодировок
Приготовления:
— Создать папки C:/A, C:/B, C:/C, C:/D.
— Разместить в папке C:/D файлы 1.html, 2.txt, 3.md из прилагаемого архива.
1. Запустить приложение, выполнив команду php converter.php c:/a c:/b c:/c/converter.log.
2. Скопировать файлы 1.html, 2.txt, 3.md из папки C:/D в папку C:/A.
3. Остановить приложение нажатием Crtl+C.		 1. Отображается консольный журнал приложения с сообщением «текущее_время started, source dir c:/a, destination dir c:/b, log file c:/c/converter.log», в папке C:/C появляется файл converter.log, в котором появляется запись «текущее_время started, source dir c:/a, destination dir c:/b, log file c:/c/converter.log».
2. Файлы 1.html, 2.txt, 3.md появляются в папке C:/A, затем пропадают оттуда и появляются в папке C:/B. В консольном журнале и файле C:/C/converter.log появляются сообщения (записи) «текущее_время processing 1.html (KOI8-R)», «текущее_время processing 2.txt (CP-1251)», «текущее_время processing 3.md (CP-866)».
3. В файле C:/C/converter.log появляется запись «текущее_время closed». Приложение завершает работу.

Тест-кейс 2:

Шаги Ожидаемые результаты
Конвертация из всех поддерживаемых кодировок
1. Выполнить конвертацию трёх файлов до пустимого размера в трёх разных кодировках всех трёх допустимых форматов.		 1. Файлы перемещаются в папку-приёмник, кодировка всех файлов меняется на UTF-8.

Если вернуться к вопросу «какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему», то ответ таков: оба тест-кейса плохие потому, что первый является слишком специфичным, а второй — слишком общим. Можно сказать, что здесь до абсурда доведены идеи низкоуровневых и высокоуровневых тест-кейсов.

Почему плоха излишняя специфичность (тест-кейс 1):

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

Почему плоха излишняя общность (тест-кейс 2):

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

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

Вот пример такого срединного подхода:

Тест-кейс 3:

Шаги Ожидаемые результаты
Конвертация из всех поддерживаемых кодировок
Приготовления:
— Создать в корне любого диска четыре отдельные папки для входных файлов, выходных файлов, файла журнала и временного хранения тестовых файлов.
— Распаковать содержимое прилагаемого архива в папку для временного хранения тестовых файлов.
1. Запустить приложение, указав в параметрах соответствующие пути из приготовления к тесту (имя файла журнала — произвольное).
2. Скопировать файлы из папки для временного хранения в папку для входных файлов.
3. Остановить приложение.		 1. Приложение запускается и выводит сообщение о своём запуске в консоль и файл журнала.
2. Файлы из папки для входных файлов перемещаются в папку для выходных файлов, в консоли и файле журнала отображаются сообщения о конвертации каждого из файлов с указанием его исходной кодировки.
3. Приложение выводит сообщение о завершении работы в файл журнала и завершает работу.

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

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

Баланс между простотой и сложностью. Здесь не существует академических определений, но принято считать, что простой тест-кейс оперирует одним объектом (или в нём явно виден
главный объект), а также содержит небольшое количество тривиальных действий; сложный тест-кейс оперирует несколькими равноправными объектами и содержит много нетривиальных
действий.

Преимущества простых тест-кейсов:

  • их можно быстро прочесть, легко понять и выполнить;
  • они понятны начинающим тестировщикам и новым людям на проекте;
  • они делают наличие ошибки очевидным (как правило, в них предполагается выполнение повседневных тривиальных действий, проблемы с которыми видны невооружённым взглядом и не вызывают дискуссий);
  • они упрощают начальную диагностику ошибки, т.к. сужают круг поиска.

Преимущества сложных тест-кейсов:

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

Рассмотрим примеры.

Шаблон тестового сценария по стандартам WorldSkills (демо-экзамен) с комментариями

Для выполнения процедуры тестирования удаления товаров Вам нужно описать пять сценариев.

Удаление может быть выполнимо, а может быть отклонено согласно требованиям предметной области.

Необходимо, чтобы варианты тестирования демонстрировали различные исходы работы алгоритма. Для описания тестовых сценариев в ресурсах предоставлен шаблон testing-template.docx (есть в этом репозитории в каталоге docs).

Расшифровка тестовых информационных полей:

Поле Описание
Название проекта Название тестируемого проекта
Рабочая версия Версия проекта/программного обеспечения (первый тест считается 1.0).
Имя тестирующего Имя того, кто проводил тесты
Дата(ы) теста Дата(ы) проведения тестов – это один или несколько дней. Если тесты проводились в более протяженный период времени, нужно отметить отдельную дату для каждого теста.
Тестовый пример # Уникальный ID для каждого тестового примера. Следуйте некоторым конвенциям, чтобы указать типы тестов. Например,‘TC_UI_1′ означает‘user interface test case #1′ ( ТС_ПИ_1: тестовый случай пользовательского интерфейса#1)
Приоритет тестирования (Низкий/Средний/Высокий) Насколько важен каждый тест. Приоритет тестирования для бизнес-правил и функциональных тестовых случаев может быть средним или высоким, в то время как незначительные случаи пользовательского интерфейса могут иметь низкий приоритет.
Заголовок/название теста Название тестового случая. Например, Подтвердите страницу авторизации с действительным именем пользователя и паролем.
Краткое изложение теста Описание того, что должен достичь тест.
Этапы теста Перечислите все этапы теста подробно. Запишите этапы теста в том порядке, в котором они должны быть реализованы. Предоставьте как можно больше подробностей и разъяснений. Пронумерованный список – хорошая идея.
Тестовые данные Перечислите/опишите все тестовые данные, используемые для данного тестового случая. Так, фактические используемые входные данные можно отслеживать по результатам тестирования. Например, Имя пользователя и пароль для подтверждения входа.
Ожидаемый результат Каким должен быть вывод системы после выполнения теста? Подробно опишите ожидаемый результат, включая все сообщения/ошибки, которые должны отображаться на экране.
Фактический результат Каким должен быть фактический результат после выполнения теста? Опишите любое релевантное поведение системы после выполнения теста.
Предварительное условие Любые предварительные условия, которые должны быть выполнены до выполнения теста. Перечислите все предварительные условия для выполнения этого тестового случая.
Постусловие Каким должно быть состояние системы после выполнения теста?
Статус (Зачет/Незачет) Если фактический результат не соответствует ожидаемому результату, отметьте тест как неудачный. В ином случае обновление пройдено.
Примечания/комментарии Используйте эту область для любых дополнительных заметок/комментариев/вопросов. Эта область предназначена для поддержки вышеуказанных полей (например, если есть некоторые особые условия, которые не могут быть описаны в любом из вышеуказанных полей, или если есть вопросы, связанные с ожидаемыми или фактическими результатами).

Аннотация теста

    Мои комментарии
Название проекта DoeduSam
Рабочая версия 1.0 Эту версию не плохо бы вписать в свойства проекта
Имя тестирующего DEMO_xx
Дата(ы) теста 21.12.2020 текущая

Тестовый пример #1:

    Мои комментарии
Тестовый пример # TC_DP_1 расшифровывается: TestCase_DeleteProduct_x
Приоритет тестирования средний бизнес-правило
Заголовок/название теста Удаление товара без продаж и дополнительных товаров
Краткое изложение теста Товар должен без ошибок удалиться из таблицы товаров
Этапы теста 1. Очистить таблицы продаж, дополнительных товаров, дополнительных картинок и товаров. 2. Добавить тестовый товар в таблицу Products
3. Вызвать метод удаления товара
4. Проверить наличие удаленной записи в таблице
Тестовые данные Название: Моторное масло Motor Oil KE900-90042-R
Изображение: Товары автосервиса8FE07916.jpg
Производитель: Nissan
Активен: да
Цена: 2060		 Тут нужно вставить содержимое любой записи из products_a_import
Ожидаемый результат Запись должна быть удалена из таблицы без ошибок и исключений
Фактический результат Запись удалена
Статус зачет
Предварительное условие В базу должны быть загружен тестовый продукт
Постусловие Таблица товаров должна быть пустой
Примечания/комментарии Т.к. мы добавили только товар без продаж и дополнительных товаров, то ошибок в принципе быть не может ни по вине кода ни по ограничениям базы

Что еще можно проверить

  • №2 — удаление товара с дополнительными товарами. Если ограничения настроены правильно (каскадное удаление), то тоже долно удаляться нормально.

  • №3 — удаление товара с дополнительными картинками. Аналогично №2.

  • №4 — удаление товара с продажами. Вариант без предварительной проверки — база должна вернуть ошибку, приложение это исключение должно перехватить и выдать сообщение, что удалять нельзя.

  • №5 — удаление товара с продажами. Вариант с предварительной проверкой — в коде нужно проверить есть ли у товара продажи и при наличии продаж вывести сообщение, что удалять товар нельзя.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

Примеры

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

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

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

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

Тестовые случаи, которые можно рассмотреть для создания:

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

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

Тестовые случаи, которые можно рассмотреть для создания:

  • Поведение приложения при поиске действующего товара.
  • Поведение приложения при поиске недействительного продукта.

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

Тестовые случаи, которые можно рассмотреть для создания:

  • Поведение приложения при выборе продукта.
  • Поведение приложения продукта в списке пожеланий.
  • Поведение приложения при добавлении товара в корзину.
  • Поведение приложения при выборе опции «Купить сейчас».
  • Поведение приложения при вводе неверного адреса.
  • Поведение приложения при вводе действительного адреса.
  • Поведение приложения при проверке нескольких вариантов оплаты.

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

Тестовые случаи, которые можно рассмотреть для создания:

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

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

Тестовые случаи, которые можно рассмотреть для создания:

  • Поведение приложения при выборе каждого заказа.
  • Поведение приложения при выборе опции «Возврат товара».
  • Поведение приложения при выборе опции отслеживания товара.
  • Поведение приложения при выборе опции «Обзор продукта».

Вывод

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

Рекомендуемые статьи

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

  1. Стресс нестабильности работы
  2. Мотивированный и посвященный
  3. Что такое Agile Testing?
  4. Как написать контрольный пример?
Источник

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

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

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

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

Варианты:

1.  Оплата мобильного телефона через платежный терминал

  1. Снятие наличных денег в банкомате

3.  Проезд в автобусе с кондуктором

4.  Использование будильника мобильного телефона

5.  Ксерокопирование

6.  Проход в метро (по смарт-карте и/или с жетоном)

7.  Закрывание двери ключом

8.  Поездка в лифте

9.  Звонок в службу поддержки Интернет-провайдера/мобильного оператора

Содержание отчета:

1.  Титульный лист с названием курса, номером и темой лабораторной работы, вариантом,
номером группы и Ф.И.О. авторов.

2.  Цель и задание, соответствующие полученному варианту.

3.  Результаты работы:

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

4.  Выводы: достигли ли цели работы, что сделали, чему научились и т.д.

Примерные вопросы
для подготовки защите:

1.  См. лабораторную работу №1

2.  Что такое тестовый сценарий? Каково его назначение? Из чего он состоит?

3. 
Что такое план тестирования? Каково его назначение? Из чего он состоит?

4.  Что такое шаг тестового сценария? Какого назначение каждого из его
полей?

5.  Напишите отчет о тестировании по вашему тестовому сценарию.

6.  …

Пример:

Название

IS-Login-1

Дата создания

01.09.2008

Автор

Ivan Ivanov

Дата последнего
изменения

15.09.2008

Описание

Проверка
функционирования подсистемы «Вход в IS» некой информационной системы на
соответствие требованиям при вводе корректных и некорректных значений имени
пользователя и пароля.

Шаг №

Описание

Тестовые данные

Ожидаемый
результат

1

Введите имя
пользователя. Нажмите кнопку «Войти»

Имя пользователя = Test

Основное окно
программы не откроется. Должно быть выведено сообщение «Введите пароль».

2

Введите пароль.
Нажмите кнопку «Войти»

Пароль = Test

Основное окно
программы не откроется. Должно быть выведено сообщение «Введите имя
пользователя».

3

Введите имя
пользователя и пароль. Нажмите кнопку «Войти»

Имя пользователя = Test  Пароль = XXX

Основное окно программы
не откроется. Должно быть выведено сообщение «Имя пользователя  и/или пароль
неверные. Пожалуйста, введите правильные данные».

4

Введите имя
пользователя и пароль. Нажмите кнопку «Войти»

Имя пользователя = XXX

Пароль = Test

Основное окно
программы не откроется. Должно быть выведено сообщение «Имя пользователя 
и/или пароль неверные. Пожалуйста, введите правильные данные».

5

Введите имя
пользователя и пароль. Нажмите кнопку «Войти»

Имя пользователя = XXX

Пароль = XXX

Основное окно
программы не откроется. Должно быть выведено сообщение «Имя пользователя
и/или пароль неверные. Пожалуйста, введите правильные данные».

6

Введите имя
пользователя и пароль. Нажмите кнопку «Войти»

Имя пользователя =
» «

Пароль = »
«

Основное окно
программы не откроется. Должно быть выведено сообщение «Имя пользователя
и/или пароль неверные. Пожалуйста, введите правильные данные».

7

Введите имя
пользователя и пароль. Нажмите кнопку «Войти»

Имя пользователя = Test  Пароль = Test

Должно открыться
основное окно приложения.

8

Введите имя
пользователя и пароль. Нажмите кнопку «Войти»

USER = ADMIN

Пароль = ADMIN

Должно открыться
окно приложения с административными настройками.
Источник

Отчет - отчет - отчет

Контрольные примеры

Что такое тестовый пример?

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

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

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

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

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

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

Запись тестовых примеров

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

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

Проектирование тестовых примеров

Формат для теста входа в систему содержит следующий формат:

  1. Идентификатор теста
  2. Часть тестового сценария.
  3. Тестовые шаги должны быть выполнены.
  4. Тестовые данные.
  5. Ожидаемые результаты.
  6. Актуальные результаты.
  7. Результат теста (успешный или нет).

При подготовке тестового примера нам нужна следующая информация:

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

Лучшие практики для хороших тестовых случаев

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

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

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

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

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

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

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

4. Не оставляйте доставленное приложение

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

5. Обеспечить покрытие 100%

Убедитесь, что вы создали тестовые случаи, которые проверяют все перечисленные требования к программному обеспечению. Кроме того, используйте ЖЕСТОКИЙ матрица, чтобы гарантировать, что никакие функции / условия не будут непроверены.

6. Контрольные примеры должны быть идентифицируемыми

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

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

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

8. Обзор коллегиального обзора

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

Группа LinkedIn

Обсудить с нами LinkedIn.

резюме

Примеры тестов, примеры и рекомендации

статья

Примеры тестов, примеры и рекомендации

Описание

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

Автор

Имя издателя

ITpedia

Издательство Логотип

ITpedia

Источник

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

Для начинающих поясним, что такое тест-кейс озвучив определение из глоссария терминов ISTQB: 

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

Определение тест-кейса языком обывателя: 

Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат. 

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

Обязательные атрибуты для заполнения 

  • Номер тест-кейса — уникальный идентификатор тест-кейса (такие системы как TestRail, TestLink и подобные автоматически присваивают тест-кейсам уникальные номера). Если у вас тысячи тест-кейсов, то при общении с коллегами, вам будет удобнее сообщить номер тест-кейса ссылаясь на него, а не пытаться словами рассказать, где и как найти определённый тест-кейс. 
  • Заголовок — краткое, понятное и ёмкое описание сути проверки. 
  • Предусловия — описание действий, которые необходимо предварительно выполнить или учесть, и которые не имеют прямого отношения к проверке. 
  • Шаги проверки — описание последовательности действий, которые необходимо выполнить для проверки. 
  • Ожидаемый результат — проверка, которая устанавливает, что мы ожидаем получить, после выполнения определённых действий в соответствующем шаге. 

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

Правила написания тест-кейсов 

  1. Заголовок:
    • должен быть чётким, кратким, понятным и однозначно характеризующим суть тест-кейса;
    • не может содержать выполняемые шаги и ожидаемый результат.
  2. Предусловие:
    • может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса; 
    • может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…); 
    • не может содержать ссылки на тестируемый ресурс, если у информационной системы более одной среды (прод, тест, препрод…), данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии; 
    • не может содержать данные для авторизации, данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии; 
    • не может содержать выполняемые шаги и ожидаемый результат, если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем «открыта главная страница сайта»; 
    • не может содержать ожидаемый результат. 
  3. Шаги проверки: 
    • должны быть чёткими, понятными и последовательными; 
    • следует избегать излишней детализации шагов. Правильно: «ввести в поле число 12».
      Неправильно: «нажать на клавиатуре на цифру ‘1’, следующим шагом нажать на клавиатуре на цифру ‘2’»; 
    • должны использоваться безличные глаголы.
      Правильно: нажать, ввести, перейти.
      Неправильно: нажмите, введите, идите; 
    • не должно быть комментариев и пояснений, если есть необходимость привести мини-инструкцию, то оформляем инструкции в базе-знаний и в предусловии ссылаемся на неё; 
    • не должно быть жёстко прописанных статических данных (логины, пароли, имена файлов) и примеров, для исключения эффекта пестицида. 
  4. Ожидаемый результат: 
    • должен быть у каждого шага проверки; 
    • должно быть кратко и понятно описано состояние системы или объекта, наступающее после выполнения соответствующего шага; 
    • не должно быть избыточного описания. 
  5. Общие требования к тест-кейсам: 
    • язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц; 
    • тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще); 
    • тест-кейсы группируются в функциональные блоки по их назначению; 
    • в тест-кейсах проверяющих работу функционала скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсах при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы проверяющие отображение страниц и форм. 

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

Примеры 

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

Тест-кейс №1. Корректный

Номер 1 
Заголовок  Отправка сообщения через форму обратной связи на странице “Контакты” 
Предусловие  Открыта главная страница сайта victorz.ru. Есть доступ к почте администратора сайта victorz.ru 
   
Шаг  Ожидаемый результат 
В верхнем меню сайта нажать на ссылку “Контакты”  Открылась страница “Контакты” 
Ввести значение в поле “Ваше имя” состоящее из латинских букв, кириллицы  В поле “Ваше имя” отображается введённое имя 
Ввести корректный email в поле “Ваш e-mail”  В поле “Ваш e-mail” отображается введённый email 
Ввести в поле “Тема” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел  В поле “Тема” отображается введённый текст 
Ввести в поле “Сообщение” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел  В поле “Сообщение” отображается введённый текст 
Ввести в поле капчи требуемое капчей значение  В поле капчи отображается введённое значение 
Нажать под заполняемой формой на кнопку “Отправить”  Под кнопкой «Отправить» появился текст “Спасибо. Ваше сообщение было отправлено.”
Все заполненные поля очищены.
Проверить почту администратора сайта  На почту пришло сообщение, отправленное с сайта через форму обратной связи и содержащее в теле сообщения данные введённые на шагах 1-5. 

Тест-кейс №2. Некорректный 

В данном тест-кейсе постарался в каждой строке писать неправильно, чтобы было наглядно. И в скобках добавлял наводящие пояснения. 

Номер  1 
Заголовок  Отправить сообщение через форму обратной связи (Указываем, что проверяем или что делаем?) 
Предусловие  Перейти на главную страницу сайта victorz.ru (Это не предусловие, а описание шага) 
   
Шаг  Ожидаемый результат 
Нажать на ссылку “Контакты” (Где она находится?)  Открылась страница (Какая?) 
Ввести имя в поле “Ваше имя” (Какие символы вводить?)  (Ничего не указано в ожидаемом результате, что должно произойти?) 
Ввести email в поле “Ваш e-mail” (корректный или некорректный?)  В поле отображается email (Какой? Введённый? В каком поле отображается?) 
Ввести в поле значение, состоящее из латинских букв, кириллицы, спецсимволов и чисел (В какое поле?)  В поле “Тема” отображается текст (Какой?) 
Ввести в поле “Сообщение” текст (Какие символы вводить?)  Видим в поле “Сообщение” введённый текст (Видим или отображается?) 
Вводим в поле капчи требуемое капчей значение (Помните только безличные глаголы — Ввести).  В поле капчи будет введённое значение (Что будет делать? Танцевать?) 
Нажать под заполняемой формой на кнопку (На какую?)  Появился текст “Спасибо. Ваше сообщение было отправлено.” (Где появится?) 
(Последний шаг не заполнен, а это неправильно, так как мы не проверим действительно ли работает отправка писем через форму обратной связи)   

Во второй части видео (с 8-й минуты) разбираю на примерах создание тест-кейсов:

Главное в нашем деле практика. Практикуйтесь в написании тест-кейсов. 

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

Источник

Тема сценарного тестирования уже давно раскрыта, а осознание необходимости использования TDD и BDD в той или иной мере есть почти в каждой компании. Исключением не стала и наша небольшая группа разработчиков на 1С. Однако, от момента понимания необходимости, до реального использования технологии, проходит время, и на этом пути неокрепшие умы как, например, автор этой статьи, начинают задумываться об эффективности всей этой затеи. Если вам интересно как группка смышленых ребят внедрила в своей работе что-то похожее на сценарное тестирование – добро пожаловать.

Предыстория

На рынке существуют очень мощные и развитые средства тестирования пользовательского интерфейса. Есть специальные языки описания сценариев, масса документации и методологий. Другими словами, «Есть проблема? Есть решение!».

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

Итак, дано: территориально распределенная группа разработчиков на 1С до 10 человек, в среднем, до 5 активных проектов, в основном разработка кастомных решений без использования типовых продуктов 1С.

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

После исследования ряда инструментальных систем западных вендоров, а также, сценарного тестирования от 1С версии 3.0, и xUnitFor1C, складывалось впечатление, что мы пока ментально не доросли до внедрения этих технологий. Время шло, а мы всё никак не можем дорасти. При этом, нутро всё требовало и требовало хоть какого-то решения.

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

  • Решение должно быть облачным
  • База тестов для всех разработок должна быть единой
  • Должен быть контроль доступа к приложениям (у каждого программиста свой пул разработок)
  • Разработка тестов и их выполнение должно быть в одной IDE
  • Сценарии должны программироваться, а не записываться действиями пользователя
  • Желательно, чтобы язык программирования тестов был похож на язык 1С
  • Запуск тестов должен производиться по одной кнопке, без предварительных манипуляций, компиляций, сборок, выгрузок, загрузок и прочего
  • В процессе написания теста должна быть возможность анализа структуры окон и реквизитов тестируемого приложения в терминах модели управляемого интерфейса 1С, и это должно быть в той программе, где разрабатывается и сам тест. Должна быть возможность получения свойств полей тестируемого приложения, при проходе по дереву контролов в базе тестирования — тестируемое приложение должно отзываться и показывать где этот контрол.
  • Для тестирования бизнес-логики не должна использоваться эталонная база
  • Для отработки теста, не должна быть заготовленная специально база, все тесты должны уметь работать и создавать всё что нужно сами

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

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

Как это выглядит

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

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

Когда пишутся тесты

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

Пример теста

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

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

image

image

Сверху – разрабатываемое приложение, снизу – тестер, в режиме работы тонкого клиента, база тестов в облаке. Код, который вы видите, написан на языке 1С. Код сценария взаимодействует с запущенным клиентским приложением через обертки методов тестируемого приложения 1С, например, вот как выглядит метод Choose (…);

image

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

Перейду к более интересным сценариям.

Взаимосвязь тестов

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

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

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

Вот пример как тест создания Assembling готовится к поступлению:

image

(цены, сумы и кол-ва задаются в виде строк, чтобы избежать проблем ложного срабатывания проверки теста в случае его запуска в другой локали, где разделитель триад и дробной части, например, могут отличаться)

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

image

image

Тестирование бизнес логики

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

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

Вот пример отчета по движениям документа в тестируемом приложении:

image

Вот как эти движения будет проверять тестер:

image

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

Типовые проверки

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

Контроль ошибок

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

image

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

Вот пример реализации такой проверки в одном из тестов:

image

image

Анализ дерева элементов

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

image

Заключение

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

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

И конечно, многое еще не реализовано:

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

Тестер открытый и бесплатный, запускать желательно начиная 8.3.8, но и на 8.3.7 тоже работать будет, если включить режим совместимости. Внутри есть небольшая справка (подкачивается из инета), обёртки методов есть и на русском языке, dt-шник можно скачать отсюда. Там есть пару примеров для бухгалтерии корп 3.0.

Удачных вам тестов друзья и спасибо за внимание!

Источник

Smartsheet Contributor

Kate Eby

January 25, 2019

In this article, you’ll find the most useful free, downloadable test case templates in Microsoft Excel and PDF formats. Learn how to use these templates to review and verify certain features and functions of an application, software, a trial, or a test and update those features and functions based on test results.

Test Case Planning and Execution Template

Test Casde Planning and Execution Template

Download Test Case Planning and Execution Template

Excel | Word | PDF | Smartsheet

With this complete test case planning and execution template, you can map out test plans for individual components of a project or trial, seamlessly execute tests, and analyze the data that comes from a test. You can also track tests by test ID and name, identify each step of a test, add priority levels and notes, and compare actual versus expected results. This complete testing template is compatible for all tests, from clinical trials to software updates.

Test Case Point Estimate Template

Test Case point Estimate Template

Download Test Case Point Estimate Template

Excel | Smartsheet

Assess the approach needed to test software, determine testing checkpoints and preconditions, and analyze all test results with this comprehensive test case point estimate template. Use this template to rate priorities and complexities based on a high-to-low measure, allocate testing time for each specific step, and determine the amount of work associated with each test.

Manual Testing Test Case Template

Manual Testing Test Case Template

Download Manual Testing Test Case Template

Excel | Word | PDF

With this manual testing test case template, you can record testing steps and data, analyze expected results versus actual results, and determine whether or not you can consider a test to be a success. With space to record each individual step of the testing process, the test ID and name, and additional notes to consider during analysis, this template allows you to run through every possible result in a trial and determine if it passed or failed inspection.

Automation Testing Test Case Template

Automation Testing Test Case Template

Download Automation Testing Test Case Template

Excel | PDF

Use this automation testing test case template to review the success or failure of an automated software, application, or feature. Document the test name and ID, the test duration, each separate step and component, and any notes about the test, including the parts of the test that are automated. Simply download and fill out this form to fit the needs of whatever automated application you are testing.

User Acceptance Testing Test Case Template

User Acceptance Testing Test Case Template

Download User Acceptance Testing Test Case Template

Excel | PDF

With this user acceptance testing (UAT) test case template, test newly designed software to ensure that it matches the designated specifications and meets all user-provided requirements. Track individual applications, the steps to execute them, and both the expected and actual results with this comprehensive testing template.

SQL Server Integration Services Testing Test Case Template

SQL Server Integration Services Testing Test Case Template

Download SQL Server Integration Services Testing Test Case Template

Excel | PDF

Manage, test, and track all SQL server integration services with this detailed test case template. You can use this SQL test case template to ensure that all programming and data management systems are working correctly and test any updates or quick fixes.

What Is a Test Case Document?

A test case document is a set of steps that a team can execute to test certain scenarios based on the needs of the function, from clinical trials to software updates and even project management changes. Each test case includes a set of preconditions as well as test data, expected results, actual results, and post-conditions that help determine the success or failure of a test.

All steps of a test case are meant to check the functionality and applicability of each test, based on the preconditions and expected results. A test case is considered the smallest unit of a testing plan and contributes to the overall test script or user story.

To begin a test case, one must first describe the actions and parameters they mean to achieve, verify, or challenge regarding any expected behavior of a test. There are sets of conditions and variables that the tester uses to determine the quality and success of a system, trial, feature, or software, and the end results can confirm these facts.

What Is the Purpose of a Test Case?

A test case can help you easily identify any problems, unplanned issues, or missed details in a project, update, or trial. Additionally, test cases provide the following benefits for the individuals or teams who carry them out:

  • Minimize ad-hoc testing
  • Make manual test case management easier and more streamlined
  • Save valuable time when testing and analyzing results
  • Enable testers to develop individual test cases for specific scenarios
  • Verify the success of updates or changes
  • Make it easier to share results with stakeholders and gain buy-in from all involved parties
  • Lessen the effort and error rate involved in testing
  • Define and flesh out all positive and negative test results or behavior
  • Divide tests into positive and negative segments
  • Eliminate the number of bugs or errors in an end product
  • Communicate all specific conditions from the start in order to eliminate confusion
  • Keep management updated on the quality status of a test
  • Help testers generate detailed summaries and reports on test status, defects, bugs, etc.
  • Track productivity and trace all problems back to the source
  • Help testers write and report on more comprehensive test case results

What Are the Components of a Test Case?

A test case is comprised of many different components: It assesses what is being tested, the expected results of a test, and the process involved in testing each specified element of a case.

In general, test cases should include the following:

  • Test Process: This includes the test review and approval, the test execution plan, the test report process, use cases (if applicable), and performance risks.
  • Positive and Negative Tests: Positive tests should help check whether the functionality is performing correctly, while negative tests should check every reverse situation where an error or issue could occur.
  • Test Case ID: This helps you correctly and uniformly document each test case and its corresponding results; it also helps you avoid retesting the same things.
  • Test Scenario: This includes all the information about a test in the form of specific, detailed objectives that will help a tester perform a test accurately. It will not, however, include specific steps or sequences.
  • Test Steps: The steps should tell a tester, in detail, exactly what they should do during each step, including specific objectives.
  • Test Data: This section includes all the information and data that a test collects throughout the duration of the process.
  • Expected Results: This includes any detailed and precise information or data that a tester should expect to see and gather from a test.
  • Actual Results: This includes all positive and negative results that you receive from a test and that help you confirm or reject the expected results and detect any issues or bugs.
  • Confirmation: This is the part of the process during which testers discuss and review whether or not a test was a success or a failure, based on the results.

What Is the Difference between a Test Case and a Test Scenario?

Although they may seem quite similar, test cases and test scenarios are two very different aspects involved in testing the functionality of a new software, update, or process. Test cases are specific conditions under which a new functionality is tested, whereas a test scenario is the overall end-to-end functionality of an application when it is working correctly.

Test cases are usually lower-level actions that can be created or derived from test scenarios. They give information about preconditions, what is being tested, how the test will be carried out, and the expected results.

Test cases require detailed documentation in order to assess how a test is proceeding, and a test case verifies the output of a function.

On the other hand, test scenarios are made up of test procedures, which encompass many test cases. Test scenarios are generally considered to be higher level and include groups of test cases, depending on the following factors: the functionality being tested, the type of test being performed, and the duration of the test.

Overall, test scenarios help reduce the complexity and confusion involved in creating a new product or updating a new function.

Tips to Write, Implement, and Track Test Cases

In order to gain the most from the tests you are running, you must create comprehensive, detailed, and test-specific test cases that describe exactly what is being tested, why it is being tested, and what the expected results should be.

To run the most effective test cases and gain powerful, actionable insights, follow these simple tips:

  • Make the test steps as clear as possible, avoiding vague objectives and directions.
  • Ensure that the test has no more than 15 steps to avoid confusion. If there are more than 15 steps, break the test into separate tests.
  • In the test directions, include any additional documents or references that might be relevant to the test itself.
  • Include a detailed description of the requirement being tested, and explain in detail how the test should be carried out for each requirement.
  • Provide details on all the expected results, so the tester can compare the actual results against them. Of course, this step is unnecessary if the expected results are obvious.
  • Use active case language when writing the steps, and make sure they are as simple and clear as possible.
  • Avoid repeating any of the same steps, as this could add confusion to an already complicated process.
  • Include the test name and ID in the testing instructions.
  • Keep the end user in mind as you develop the test and its variables.
  • Reread and peer review the test case instructions before finalizing them.
  • Remember that the test case should be repeatable, traceable, and accurate.

Test Case Use Cases

You can leverage test cases for a variety of purposes: to gain insight into how processes are performing; to determine how software updates are being used; and to figure out how business trials or tests are progressing.

Some of the most common use cases for test cases include the following:

  • Confirming login functionality on a username and password combination
  • Checking to see how the login function reacts to a valid or invalid username or password
  • Seeing what happens when someone inputs an empty response for either the username or password component

Numerous companies, such as HP Quality Center and Jira, use test cases to track and update their processes.

Improve Your Test Cases with Free Test Case Templates in Smartsheet

Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change. 

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. 

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.

Источник

Понравилась статья? Поделить с друзьями:
  • Тесо праздник ведьм билеты событий
  • Тестовые сценарии тестовые варианты оформление результатов тестирования лекции
  • Тесо праздник ведьм 2021
  • Тестовые сценарии калькулятора
  • Тесо праздник ведьм 2020