Happy path в тестировании что это

Счастливый путь (Happy path)

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

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

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

Фрагмент таблицы различных путей процессов:

Аналитика	Путь (слово процесса)	Кол-во экземпляров процессов
Аренда площадей	BKN	826
AKN	469
BEKN	420
Хранение для таможенного оформления	BGKPSTN	435
BGEGKPSTN	413
BGKN	390
BEGKPSTN	314
BKN	306
AGGKPSTZ	264
Ответственное хранение	BCKN	557
BCGKPSTN	323
ACKN	304
BCN	265
Транзитное хранение	BGKN	642
BKN	441
AGKN	397

В таблице выделены наиболее часто встречающиеся пути процесса в разрезе каждой аналитики: BKN, BGKPSTN, BCKN, BGKN — это счастливые (основные) пути. Они начинаются валидным (предусмотренным) событием «B» и завершаются валидным событием «N», то есть приводят процесс к ожидаемому полезному результату.

Другие пути, не являющиеся «Happy Path» являются альтернативными путями процесса. Среди альтернатив можно выделить антипод «Happy Path» — «unhappy path». Его переводят по-разному: «Несчастный путь», «Путь исключения», «Бракованный путь». «Unhappy path» позволяет выявлять брак в ходе осуществления процесса. Если счастливый путь один для каждой аналитики, то альтернативных путей может быть множество.

«Бракованный путь» не позволяет достигнуть требуемого результата — это главный критерий его определения. В примере выше бракованным является путь «AGGKPSTZ», так как начальное событие «А» и конечное событие «Z» не являются валидными начальными/конечными событиями.

Happy path в тестировании что это

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

Книги автора: Руководство по DevOps
Книги автора: Руководство по DevOps
Книги автора: Руководство по DevOps
Книги автора: Руководство по DevOps
Книги автора: Руководство по DevOps Как мы покупали русский интернет
Книги автора: Руководство по DevOps

Книга: Руководство по DevOps

Обеспечьте безопасность приложений

Скрыть рекламу в статье

Обеспечьте безопасность приложений

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

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

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

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

• Статический анализ: это тестирование не в среде исполнения: идеальная среда — конвейер развертывания. Обычно инструмент статического анализа проверяет код программы на все возможные способы выполнения кода и ищет недочеты, лазейки и потенциально вредоносный код (иногда этот процесс называют «тестированием изнутри наружу»). Примеры инструментов статического анализа — Brakeman, Code Climate и поиск запрещенных функций (как, например, «exec()»).

• Динамический анализ: в противоположность статическому тестированию динамический анализ состоит из тестов, проводимых во время работы программы. Динамические тесты проверяют системную память, поведение функций, время ответа и общую работоспособность системы. Этот метод (иногда называемый «тестированием снаружи внутрь») имеет много общего с тем, как злоумышленники взаимодействуют с приложением. Примерами инструментов могут быть Arachni и OWASP ZAP (Zed Attack Proxy)[162]. Некоторые типы тестирования на проникновение (pentesting) можно проводить автоматически, их можно включить в динамический анализ с помощью таких инструментов, как Nmap и Metasploit. В идеале автоматизированное динамическое тестирование должно проводиться во время фазы автоматического функционального тестирования в конвейере развертывания или даже уже во время эксплуатации сервиса. Чтобы проконтролировать соблюдение требований безопасности, можно настроить инструменты вроде OWASP ZAP, так чтобы они атаковали наши сервисы через прокси-сервер, а затем изучать сетевой трафик в специальной тестовой программе.

• Проверка зависимостей: еще один тип статического тестирования, проводимый во время сборки программы в конвейере развертывания, включает в себя проверку всех зависимостей продукта на наличие бинарных и исполняемых файлов, а также проверку того, что у всех этих зависимостей (а над ними у нас часто нет контроля) нет уязвимых мест или вредоносного кода. Примеры инструментов для таких тестов — Gemnasium и bundler audit для Ruby, Maven для Java, а также OWASP Dependency-Check.

• Целостность исходного кода и подпись программы: у всех разработчиков должен быть свой PGP-ключ, возможно, созданный и управляемый в такой системе, как keybase.io. Все подтверждения кода в системе контроля версий должны быть подписаны — это легко сделать с помощью таких инструментов свободного ПО, как gpg и git. Кроме того, все пакеты, созданные во время процесса непрерывной интеграции, должны быть подписаны, а их хэш должен быть записан в централизованный сервис логирования для облегчения аудита.

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

• как хранить пароли;

• как работать с забытыми паролями;

• как работать с входом в систему;

• как избежать уязвимых мест межсайтового скриптинга (XSS).

Тест критического пути

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

Тест критического пути

Может быть как позитивным, так и негативным:

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

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

Пример тестирования критического пути

1. Зайти на сайт KUKU.io
2. Ввести логин, пароль.
3. Нажать Войти
4. Выбрать аккаунты, в которые планируются публикации
5. Создать пост
6. Опубликовать пост
7. Просмотр Статуса поста
8. Выход из сервиса

Компонент	Подкомпонент	Проверка
Вход на сайт	Ввод логина	проверка правильности введенных значений
	Пароль
	Войти
Аккаунты	Перечень добавленных аккаунтов	выбор аккаунтов для публикации
Пост	Создать	ввод текста, превью, добавление картинок
	Редактировать	добавление/удаление материала для публикации
	Запланировать	выбор времени опубликования поста
	Опубликовать	публикация поста
Статус поста	Просмотр
	Удаление	удаление поста из таймлайна и из соц.сети (при соответствующих настройках)
Выход	выход из сервиса

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

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

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

Все о тестировании и качестве ПО

• Чек-лист локализации
• Тестирование по степени глубины
• Виды нагрузочного тестирования
• Расширенное тестирование
• Собеседование Junior QA

I believe in QA, все о тестировании

Октябрь 2023

Пн	Вт	Ср	Чт	Пт	Сб	Вс
1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Больше о тестировании и качестве ПО

• Исследовательское тестирование (Exploratory Testing)
• Тест-кейсы и все о них
• Виды нагрузочного тестирования
• Чек-лист локализации
• Туры в исследовательском тестировании
• Use-cases (юз-кейсы)

Что такое Happy Path тестирование?

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

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

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туторилов, задач по автоматизации и книг по QA.

Что такое Happy Path Testing?

Тестирование счастливого пути (Happy Path Testing) – это проверка приложения в нормальных условиях работы, когда все происходит так, как ожидается, и нет сбоев или ошибок. Этот тип тестирования обычно проводится первым.

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

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

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

Цель Happy Path тестирования заключается не в том, чтобы “сломать” функционал приложения или искать нестандартные ситуации, а в том, чтобы заставить приложение функционировать исправно.

Happy path тестирование проводится в реальных условиях использования приложения, чтобы убедиться, что оно работает в соответствии с требованиями пользователей. Happy Path тестирование является частью E2E тестирования (End-to-end testing – Сквозное тестирование) .

Сколько должно быть Happy Path тестов?

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

Пример Happy Path теста

Давайте рассмотрим пример Happy Path теста:

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

Когда следует проводить Happy Path Testing?

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

Каковы преимущества Happy Path тестирования?

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

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

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

Каковы недостатки Happy Path тестирования ?

Существует пять основных недостатков Happy Path тестирования, а именно:

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

Ограничения для Happy Path тестирования

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

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

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

Результат 1: Не будет выдано никаких сообщений об ошибке, и выполнение процесса будет успешно завершено без прерываний или ошибок.

Сценарий 2: Введите валидное имя пользователя, но неверные значения в поле пароля и нажмите на кнопку входа.

Результат 2: Будет выдана ошибка неверного входа в систему, которая уведомит пользователя о вводе некорректных символов в поле для пароля.

Сценарий 1 является единственным положительным тест-кейсом для страницы входа в систему из всех возможных сценариев. Ввод недействительных учетных данных в сценарии 2 будет примером Sad Path Testing.

Happy Path тестирование в Unit-тестах

Один из лучших способов повысить качество продукта – это проведение модульного тестирования. Существует множество преимуществ, помогающих разработчикам проводить Happy Path тестирование в Unit-тестах . Среди них следующие:

• Доработка API перед написанием кода (при использовании TDD).
• Появляется уверенность в том, что ранее реализованный код по-прежнему функционирует в соответствии с ожидаемым результатом.

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

Happy Path Testing в автоматизированном тестировании

Существуют две основные проблемы при написании UI-тестов с Happy Path сценариями:

1. Автоматизированные тесты обычно охватывают лишь небольшую часть happy path сценариев. Это означает, что множество других возможных случаев остаются непроверенными.
2. Команда автоматизации при создании GUI-тестов ориентируется на базовые и ожидаемые действия пользователя, уделяя меньше внимания более сложным случаям.

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

Чем отличается Happy Path тестирование от Sad Path тестирования?

Happy Path Testing – это тип тестирования программного обеспечения, при котором используются валидные входные данные с целью достичь желаемых результатов. Этот метод помогает тестировщикам быстрее выявлять потенциальные проблемы в приложении.

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

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

Заключение

Все типы тестирования имеют одну общую цель: создать приложение без дефектов и ошибок. Используя правильные входные данные, Happy Path Testing проводится для подтверждения того, что приложение работает согласно требованиям пользователей. Далее уже проводится Sad Path тестирование для обработки исключительных и более сложных случаев.

Похожие записи:

1. Полное руководство по тестированию масштабируемости
2. Полное руководство по ad-hoc тестированию
3. Когда следует начинать нагрузочное тестирование?
4. Как проводить backend тестирование