<style>.lazy{display:none}</style>Cквозное тестирование

Cквозное тестирование

Сквозное тестирование (англ. End to End, E2E) предполагает проверку приложений от начала до конца. Его главная цель – имитация реального пользовательского сценария, проверка тестируемой системы, ее компонентов на интеграцию и целостность данных.

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

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

БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"

Содержание

Что собой представляет сквозное тестирование?

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

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

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

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

Почтовый конверт

Сквозная проверка учетной записи Gmail включает следующие шаги:

  • Запуск страницы входа в Gmail через URL-адрес.
  • Вход в учетную запись Gmail с использованием валидных учетных данных.
  • Доступ к папке “Входящие”. Открытие прочитанных и непрочитанных писем.
  • Создание нового письма, ответ или пересылка письма.
  • Открытие отправленных файлов и проверка писем.
  • Проверка писем в папке “Спам”.
  • Выход из приложения Gmail путем нажатия кнопки “Выход”.

Инструменты сквозного тестирования

1. Avo Assure

Assure-Logo

Avo Assure – это 100% верное решение для автоматизации тестирования без использования сценариев, которое помогает тестировать сквозные бизнес-процессы с помощью нескольких нажатий кнопок.

Будучи гетерогенным, оно позволяет тестировать с помощью одного решения приложения в Интернете, на Windows, на мобильных платформах (Android и IOS), программы без UI (веб-сервисы, пакетные задания), ERP, системы Mainframe и соответствующие эмуляторы.

С Avo Assure вы можете:

  • Обеспечить комплексную автоматизацию тестирования, поскольку решение не требует написания кода и позволяет проводить тестирование в различных приложениях.
  • Получить представление о всей иерархии тестирования с высоты птичьего полета, определить планы тестирования и разработать тестовые случаи с помощью функции Mindmaps.
  • Одним нажатием кнопки запустить тестирование доступности для ваших приложений. Он поддерживает стандарты WCAG, Section 508 и ARIA.
  • Использовать интеграцию с различными SDLC и инструментами непрерывной интеграции, такими как Jira, Sauce Labs, ALM, TFS, Jenkins, QTest и другими.
  • Запланировать выполнение тестов в нерабочее время.
  • Выполнять тестовые сценарии на одной виртуальной машине независимо или параллельно с помощью функции интеллектуального планирования и выполнения.
  • Оперативно анализировать отчеты, поскольку теперь они доступны в виде скриншотов и видеозаписи процесса выполнения.
  • Повторно использовать более 1500 предварительно созданных ключевых слов и более 100 ключевых слов, специфичных для SAP, чтобы ускорить дальнейшее тестирование.
  • Avo Assure сертифицирован для интеграции с SAP S4/HANA и SAP NetWeaver.

2. testRigor

testRigor-Logo

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

Ключевые особенности testRigor:

  • Для создания сложной автоматизации тестирования не нужно уметь программированить, разбираться в Xpath или селекторах CSS.
  • testRigor – единственная компания, которая решает проблему сопровождения тестов.
  • Ручной тестировщик получает возможность самостоятельно участвовать в процессе автоматизации тестирования.

С testRigor вы можете:

  • Создавать тест-кейсы в 15 раз быстрее, используя знания базового английского языка.
  • Сократить затраты на обслуживание тестирования на 99,5 %.
  • Тестировать приложение в разных браузерах и операционных системах в дополнение к тестированию устройств Android и iOS.
  • Планировать и выполнять тестирование одним нажатием кнопки.
  • Экономить время, выполняя наборы тестов за считанные минуты, а не за дни.

3. Virtuoso

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

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

Основные преимущества Virtuoso:

  • Любой браузер, любое устройство.
  • Комбинированное функциональное тестирование пользовательского интерфейса и API.
  • Визуальная регрессия.
  • Моментальное тестирование.
  • Тестирование доступности.
  • Тестирование локализации.
  • Комплексный инструмент для всех ваших потребностей в сквозном тестировании.

Как работает сквозное тестирование?

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

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

Методы сквозного тестирования

1. Горизонтальное тестирование

Этот метод используется очень часто. Он проводится горизонтально в контексте нескольких приложений. Такой метод можно легко реализовать в одном приложении ERP (Enterprise Resource Planning). Возьмем пример веб-приложения для онлайн-заказов. Весь процесс будет включать в себя информацию об учетной записи, состояние запасов продукции, а также детали доставки.

2. Вертикальное тестирование

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

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

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

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

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

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

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

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

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

С помощью сквозного тестирования этих рисков можно избежать. Поэтому:

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

Ниже перечислены мероприятия, которые входят в процесс сквозного тестирования:

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

Структура проектирования E2E-тестирования

Структура проектирования E2E-тестирования

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

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

2. Условия. Следующие действия должны выполняться как часть построения условий на основе пользовательских функций:

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

3. Тест-кейсы. При построении тест-кейсов необходимо учитывать следующие факторы:

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

Применяемые метрики

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

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

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

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

Системное тестирование включает в себя:

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

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

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

Заключение

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

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

Перевод статьи «What Is End to End Testing: E2E Testing Framework with Examples».

1 комментарий к “Cквозное тестирование”

  1. Пингбэк: Тест-кейс и тестовый сценарий

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *