Тестовые сценарии тестовые варианты оформление результатов тестирования лекции

Тестовые сценарии (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». Приложение завершает работу.

Шаги	Ожидаемые результаты
Конвертация из всех поддерживаемых кодировок Приготовления: — Создать папки 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. Приложение выводит сообщение о завершении работы в файл журнала и завершает работу.

Шаги

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

Конвертация из всех поддерживаемых кодировок
Приготовления:
— Создать в корне любого диска четыре отдельные папки для входных файлов, выходных файлов, файла журнала и временного хранения тестовых файлов.
— Распаковать содержимое прилагаемого архива в папку для временного хранения тестовых файлов.
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 — удаление товара с продажами. Вариант с предварительной проверкой — в коде нужно проверить есть ли у товара продажи и при наличии продаж вывести сообщение, что удалять товар нельзя.

Источник

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

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

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

Тестовый
отчет (или тест) содержит информацию о следующем:

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

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

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

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

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

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

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

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

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

Тестовые сценарии могут быть созданы при редактировании тест-планов
(тестовых документов), либо существовать независимо от них.

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

Трассировка
на требования

Трассировка тестовой документации на требования используется для
следующих задач:

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

Тестируемое приложение является сложным, нестабильным, и в проекте есть время.
Проекты, которые следуют 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

Описание слайда:

Тестовые сценарии и тестовые наборы
Выполнил: Вдовин А.В. ИСП-О-18

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

Описание слайда:

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

Слайд 3

Описание слайда:

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

Слайд 4

Описание слайда:

Добавление тестов в тестовый набор в существующем сценарии

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

Слайд 5

Описание слайда:

Добавление тестов в существующий сценарий

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

Слайд 6

Описание слайда:

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

Слайд 7

Описание слайда:

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

Слайд 8

Описание слайда:

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

Слайд 9

Описание слайда:

Перед получением результата программа проходит несколько уровней:
· Тестирование компонентов — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто тестирование компонентов осуществляется разработчиками программного обеспечения.
· Интеграционное тестирование — тестируются интерфейсы между компонентами, подсистемами или системами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.
· Системное тестирование — тестируется интегрированная система на её соответствие требованиям.
· Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком.
· Бета-тестирование — в некоторых случаях выполняется распространение предварительной версии (в случае проприетарного программного обеспечения иногда с ограничениями по функциональности или времени работы) для некоторой большей группы лиц с тем, чтобы убедиться, что продукт содержит достаточно мало ошибок.

Слайд 10

Описание слайда:

Сценарии функционального тестирования:
Протестируйте валидацию всех обязательных полей
Убедитесь, что знак звездочки отображается у всех обязательных полей
Убедитесь, что система не отображает окно ошибки при незаполненных необязательных полях.
Убедитесь, что високосные коды корректно валидируются и не вызывают ошибок в расчетах.
Протестируйте числовые поля: они не должны принимать буквы, в этом случае должно отображаться соответствующее сообщение об ошибке.
Протестируйте отрицательные значения в числовых полях, если они разрешены.
Протестируйте, что деление на ноль верно обсчитывается.
Протестируйте максимальную длину каждого поля, чтобы убедиться, что данные не обрезаются.
Протестируйте функциональность доступных кнопок.
Протестируйте условия использования и часто задаваемые вопросы: они должны быть внятными и доступными пользователю.
Протестируйте, что при отказе функциональности пользователь перенаправляется на специальную страницу ошибки.
Протестируйте, что все загруженные документы правильно открываются.
Протестируйте, что пользователь может скачать загруженные файлы.
Протестируйте почтовую функциональность системы.
Протестируйте, что Java Script верно работает в разных браузерах (IE, Firefox, Chrome, Safari, Opera).

Источник

1. Основы разработки тестовых сценариев

2. Составляющие теста

Цель теста
Метод тестирования
Окружение, данные, подготовка системы
Сценарий: Шаги, оформленные таблицей или
списком
Действия
Ожидаемые результаты
Опциональная дополнительная информация:
Снимки экрана
Логи
Файлы, сгенерированные в процессе теста

3. Требования к хорошему тестовому сценарию

Существует
обоснованная вероятность выявления тестом
дефекта.

Определены
входные данные.

Определен
ожидаемый результат, считаемый «хорошим».
Воспроизводимость.

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

4. Основные ошибки при составлении тестовых сценариев

Слишком
длинный сценарий.

Неполное,
неправильное или непоследовательное описание
условий тестирования или подготовки тестового окружения.
Пропущенные
«очевидные» шаги.
Использование
устаревшей информации о тестируемой
системе.
Неочевидно,
кто должен выполнить действие: пользователь
или система.
Неясно,
что является успешным результатом.
Отсутствие
очистки системы.

5. Основные ошибки при составлении тестовых сценариев

Слишком
длинный сценарий.

Отсутствие
очистки системы.

6. Методы выбора входных значений

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

7. Метод перебора

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

Попарный перебор. Перебираем комбинации
пары 2х входных параметров. Работаем в
предположении, что параметры попарно
зависимы. На практике находит ~80%
функциональных дефектов низкого уровня.

8. Случайные входные данные

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

Часто используется в нагрузочном тестировании.

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

Пример: программа подсчета числа вхождений символа
в строку

9. Предугадывание ошибки

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

10. Графы причина-следствие

Выделяем
причины и следствия в спецификациях.

Строим
граф, связывающий причины и следствия.

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

Превращаем
каждый столбец в тестовый сценарий.
Преимущества и недостатки:

◦ Комбинаторный взрыв числа вариантов.

◦ Позволяет систематизировать процесс построения сценариев.
◦ Используются эвристики для уменьшения числа комбинаций

11. Пример графа

12. Классы эквивалентности

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

13. Классы эквивалентности — примеры

Классы эквивалентности примеры
Программа классификации треугольников.
Классы эквивалентности по корректным
входным данным:
Равнобедренные треугольники.
Равносторонние треугольники.
Прямоугольные треугольники.
Просто треугольники.
Классы эквивалентности по
некорректным входным данным:
Отрезки не образуют треугольник.
Числа больше sizeof(int).
Строка, содержащая буквы.

14. Классы эквивалентности — Примеры

Программа, говорящая дату
следующего дня.

Классы эквивалентности по
корректным входным данным:
◦
◦
◦
◦
День от 1 до 27;
Последний день месяца;
Последний день года;
28 февраля високосного года.
Классы эквивалентности по
некорректным входным данным:

◦ Месяц > 12;
◦ День > 31;
◦ Неверная строка.

15. Поиск классов эквивалентности

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

16. Граничное тестирование

17. Граничное тестирование — применение

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

При покупке более 100 единиц товара дается
скидка 5%.
Нужно проверить:
100
99
101

18. Оракулы

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

19. Оракулы. Примеры-1

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

20. Оракулы. Примеры-2

21. Оракулы. Примеры-3

22. Оракулы. Примеры-4

23. Оракулы. Примеры-5

24. Оракулы. Примеры-6

25. Оракулы. Примеры-7

Источник

Цель
работы: описать набор тестовых сценариев
для верификации ПО. Оптимизировать
тестовый набор. Научиться составлять
спецификацию для разработки тестов.

Отчет
по лабораторной работе: набор тестовых
сценариев, спецификация для тест дизайна.

Теоретическая часть Функциональное тестирование или Functional Testing

Функциональное тестированиерассматривает заранее указанное
поведение и основывается на анализе
спецификаций функциональности компонента
или системы в целом.

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

Тестирование функциональности может
проводиться в двух аспектах:

требования
бизнес-процессы

Тестирование в перспективе «требования»
использует спецификацию функциональных
требований к системе как основу для
дизайна тестовых случаев (Test Cases). В этом
случае необходимо сделать список того,
что будет тестироваться, а что нет,
приоритезировать требования на основе
рисков (если это не сделано в документе
с требованиями), а на основе этого
приоритезировать тестовые сценарии
(test cases). Это позволит сфокусироваться
и не упустить при тестировании наиболее
важный функционал.

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

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

имитирует фактическое использование
системы;

Недостатки функционального тестирования:

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

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

Тестовый случай (Test Case)

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

Под тест кейсом понимается
структура вида:

Action
> Expected Result
> Test Result

Пример:

Action

Expected
Result

Test
Result

(passed/failed/blocked)

Open
page «login»

Passed

Виды Тестовых Случаев

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

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

Структура Тестовых Случаев (Test Case Structure)

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

Каждый тест кейс должен
иметь 3 части:

PreConditions	Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description	Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions	Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)

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

Пример
тест кейса:

do
A1, verify B1

do
A2, verify B2

do
A3, verify B3

В приведенном примере
конечная проверка — В3. Это значит, что
именно она является ключевой. Значит,
A1 и А2 — это действия приводящие систему
в тестопригодное состояние. А В1 и В2 —
условия того, что система находится в
состоянии пригодном для тестирования.
Таким образом имеем:

Action	Expected Result	Test Result (passed/failed/blocked)
PreConditions
do A1	verify B1
do A2	verify B2
Test Case Description
do A3	verify B3
PostConditions

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

Теперь ответим на вопрос:
«Почему данное разбиение удобно
использовать?»

Ответ: конечная проверка
одна, т.е. в случае если тест провален
(test failed)
будет сразу ясно из-за чего. Т.к. если
провальными окажутся проверки В1 и/или
В2, то тест кейс будет заблокирован (test
blocked), из-за того, что
функцию не возможно привести в
тестопригодное состояние (состояние
пригодное для проведения тестирования),
но это не значит, что тестируемая функция
не работает.

Action	Expected Result	Test Result (passed/failed/blocked)
PreConditions
do A1	verify B1	passed
do A2	verify B2	failed
Test Case Description:
do A3	verify B3	blocked
PostConditions

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

Источник

Any capability that may be tested is defined as a TEST SCENARIO. It’s also known as Test Possibility or Test Condition. As a tester, you should put yourself in the shoes of the end user and determine the Application Under Test’s real-world scenarios and use cases.

In liner statements, a test scenario is a complete list containing test cases that cover end-to-end functionality of a software program. A scenario is defined as a liner statement. The test scenario is a classification of testable requirements at a high level. These criteria are categorized according to a module’s functionality and derived from use cases.

Because there are so many test cases in the scenario, there is a thorough testing process. The tester must evaluate the test cases for each scenario before completing the test scenario. Testers must put themselves in the shoes of the user in the test scenario because they are testing the software application from the user’s perspective. The most important aspect of the process is scenario preparation, which necessitates seeking advice or assistance from customers, stakeholders, or developers.

Important − Because the text scenario process does not include navigation steps or input, the test execution process cannot be done.

These are high-level documents that describe all of the conceivable permutations or various ways or combinations of utilizing the application, with the primary goal of understanding the application’s general flow.

Method of Writing Test Scenario

To build Test Scenarios as a tester, follow these steps —

Examine the software’s requirement documents, such as SRS (System Requirement Specification), the BRS (Business Requirement Specification), and FRS (Functional Requirement Specification). You could also consult the application’s use cases, books, manuals, and other resources.
For each requirement, determine all technical aspects and objectives.
Find every feasible way for the user to interact with the software.
Determine all possible scenarios in which the system could be exploited, as well as users who could be hackers.
Make a list of various test cases to check each function of the software after reading the requirement document and completing the scheduled analysis.
Create a traceability matrix after you’ve identified all of the possible test scenarios to see if each requirement has a matching test scenario or not.
All possibilities are reviewed by the project supervisor. They are then evaluated by the project’s other stakeholders.

When writing test cases, we had to observe a few rules —

Always keep a list of the most frequently utilized features and modules.
We usually begin the scenarios by selecting modules one by one, in order to maintain a good sequence and avoid missing any module levels.
Scenarios are usually defined at the module level.
Delete scenario should always be the final resort; else, we will waste a lot of time re-creating data.
It should be written in plain English.
Every scenario should be written in a single or two-line format, try not to write in paragraphs.
Do’s and checks should be included in every scenario.

Reason for creating Test Scenario

One test scenario can cover several test cases. As a result, Test Scenarios and Test Cases have a one-to-many relationship. However, the tester must consider each scenario when developing it. It was created by testers to test the application from the perspective of an end-user. Testers look for crucial information from all developers, stakeholders, and customers.

The following are the reasons for their creation −

The design of excellent Test Scenarios ensures complete and proper Test Coverage.
It is necessary to create them in order to investigate a program’s end-to-end functionality.
They can be used to determine the most significant and critical end-to-end transactions or real-time application usage.
They can be used as a tool for quickly determining testing workforce, which can then be utilized to assist clients or organizations with proposal creation and testing workforce organization efficiently and effectively.
Approval of applications is done at multiple levels, including customers, business analysts, developers, and so on, to ensure thorough and proper testing.

When Test Scenario should not be created

There are some conditions in which its production should be prevented —

It is unlikely to be developed in projects that use Agile Methodologies like Scrum.
It may be avoided when the applications to be tested are unstable or excessively complicated, or when the project is in a critical-time state.
Its creation may be prevented for regression testing or a new defect because substantial documentation of them would happen in previous test cycles in maintenance projects.

Features of Test Scenario

The test scenario is a one-liner that directs testers through the testing process.
The product’s complexity and repetition are reduced by using a test scenario.
A test scenario is when you talk and think about tests in great detail yet write them down in liner statements.
It’s a series of procedures threaded together.
When the tester does not have enough time to write test cases and the team agrees on a comprehensive liner scenario, the test scenario becomes more significant.
The test scenario is a useful activity for saving time.
It is simple to maintain because adding and modifying test scenarios is simple and self-contained.

Test Scenario Examples

We’re using the Gmail application to create test cases for the most often used modules, such as Login, Compose, and inbox

Test Scenarios for the Login module

Check that the home page is displayed after entering the correct login information (username and password).
Check for the home page after entering the invalid Username and password.
Check for an error message if you leave the username and password fields blank.
Enter a valid Login, click Cancel, and look for the fields to be reset.
Check that the account has been blocked by entering invalid Login more than three times.
Check sure the Username is displayed on the home screen after entering a valid Login.

Test Scenario for compose module

Checks if all users have access to the To, Cc, and Bcc email addresses.
Check that the entire user has access to the To, Cc, and Bcc fields.
Prepare a message, send it, and wait for a confirmation message.
Compose an email, send it, and check the sender’s sent item as well as the inbox.
Create a message, send it, and check for invalid and legitimate email addresses (valid format) in the sender’s inbox
Check for conformation messages and check-in draft messages after composing main and then discarding it.
After you’ve finished writing your email, save it as a draft and look for the confirmation message.
Compose an email, shut it, and check for confirmation before saving it as a draft.

On the Inbox module, Test scenario.

Check that all received mail is shown and highlighted in the inbox by clicking on it.
Check that the sender email id for the most recent received email has been accurately displayed.
Select the email, reply, and forward it; check the sender’s sent item and the receiver’s inbox.
Examine any attached attachments to the email to see if they have been downloaded or not.
Before downloading, be sure the attachment has been properly inspected for malware.
Select the email, reply, and forward it, then save it as a draft. Check the Draft section for the confirmation message and checks.
Check that all of the emails that have been marked as read have not been highlighted.
Verify that all Cc recipients are visible to all users.
Checks that all Bcc email recipients are hidden from the users.
Select the message, delete it, and then check the Trash folder.

Источник

Important − Because the text scenario process does not include navigation steps or input, the test execution process cannot be done.

Method of Writing Test Scenario

To build Test Scenarios as a tester, follow these steps —

Examine the software’s requirement documents, such as SRS (System Requirement Specification), the BRS (Business Requirement Specification), and FRS (Functional Requirement Specification). You could also consult the application’s use cases, books, manuals, and other resources.
For each requirement, determine all technical aspects and objectives.
Find every feasible way for the user to interact with the software.
Determine all possible scenarios in which the system could be exploited, as well as users who could be hackers.
Make a list of various test cases to check each function of the software after reading the requirement document and completing the scheduled analysis.
Create a traceability matrix after you’ve identified all of the possible test scenarios to see if each requirement has a matching test scenario or not.
All possibilities are reviewed by the project supervisor. They are then evaluated by the project’s other stakeholders.

When writing test cases, we had to observe a few rules —

Always keep a list of the most frequently utilized features and modules.
We usually begin the scenarios by selecting modules one by one, in order to maintain a good sequence and avoid missing any module levels.
Scenarios are usually defined at the module level.
Delete scenario should always be the final resort; else, we will waste a lot of time re-creating data.
It should be written in plain English.
Every scenario should be written in a single or two-line format, try not to write in paragraphs.
Do’s and checks should be included in every scenario.

Reason for creating Test Scenario

The following are the reasons for their creation −

The design of excellent Test Scenarios ensures complete and proper Test Coverage.
It is necessary to create them in order to investigate a program’s end-to-end functionality.
They can be used to determine the most significant and critical end-to-end transactions or real-time application usage.
They can be used as a tool for quickly determining testing workforce, which can then be utilized to assist clients or organizations with proposal creation and testing workforce organization efficiently and effectively.
Approval of applications is done at multiple levels, including customers, business analysts, developers, and so on, to ensure thorough and proper testing.

When Test Scenario should not be created

There are some conditions in which its production should be prevented —

It is unlikely to be developed in projects that use Agile Methodologies like Scrum.
It may be avoided when the applications to be tested are unstable or excessively complicated, or when the project is in a critical-time state.
Its creation may be prevented for regression testing or a new defect because substantial documentation of them would happen in previous test cycles in maintenance projects.

Features of Test Scenario

The test scenario is a one-liner that directs testers through the testing process.
The product’s complexity and repetition are reduced by using a test scenario.
A test scenario is when you talk and think about tests in great detail yet write them down in liner statements.
It’s a series of procedures threaded together.
When the tester does not have enough time to write test cases and the team agrees on a comprehensive liner scenario, the test scenario becomes more significant.
The test scenario is a useful activity for saving time.
It is simple to maintain because adding and modifying test scenarios is simple and self-contained.

Test Scenario Examples

We’re using the Gmail application to create test cases for the most often used modules, such as Login, Compose, and inbox

Test Scenarios for the Login module

Check that the home page is displayed after entering the correct login information (username and password).
Check for the home page after entering the invalid Username and password.
Check for an error message if you leave the username and password fields blank.
Enter a valid Login, click Cancel, and look for the fields to be reset.
Check that the account has been blocked by entering invalid Login more than three times.
Check sure the Username is displayed on the home screen after entering a valid Login.

Test Scenario for compose module

Checks if all users have access to the To, Cc, and Bcc email addresses.
Check that the entire user has access to the To, Cc, and Bcc fields.
Prepare a message, send it, and wait for a confirmation message.
Compose an email, send it, and check the sender’s sent item as well as the inbox.
Create a message, send it, and check for invalid and legitimate email addresses (valid format) in the sender’s inbox
Check for conformation messages and check-in draft messages after composing main and then discarding it.
After you’ve finished writing your email, save it as a draft and look for the confirmation message.
Compose an email, shut it, and check for confirmation before saving it as a draft.

On the Inbox module, Test scenario.

Check that all received mail is shown and highlighted in the inbox by clicking on it.
Check that the sender email id for the most recent received email has been accurately displayed.
Select the email, reply, and forward it; check the sender’s sent item and the receiver’s inbox.
Examine any attached attachments to the email to see if they have been downloaded or not.
Before downloading, be sure the attachment has been properly inspected for malware.
Select the email, reply, and forward it, then save it as a draft. Check the Draft section for the confirmation message and checks.
Check that all of the emails that have been marked as read have not been highlighted.
Verify that all Cc recipients are visible to all users.
Checks that all Bcc email recipients are hidden from the users.
Select the message, delete it, and then check the Trash folder.

Источник