Пошаговое руководство по приоритизации тестовых случаев в сквозном тестировании
programming web-development testing e2e

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

23 марта 2023 г.

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

Рентабельность инвестиций

Рентабельность инвестиций (ROI) — это показатель, используемый для сравнения стоимости различных инвестиций. Обычно это определяется как:

Image description

В случае E2E мы можем понимать части уравнения следующим образом:

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

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

  • те, которые проще всего протестировать и которые
  • наиболее важные функции.

Низко висящие плоды

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

Дымовые тесты

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

Даже такой простой тест может принести вам немало пользы:

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

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

Бонус: скриншот приложения

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

Важные рабочие процессы

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

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

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

Счастливый путь

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

Важные пограничные случаи

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

Повторно появляющиеся ошибки

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

Я пытался следовать политике охвата всех регрессий из рабочей среды с помощью E2E, и мои выводы таковы

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

Сезонные особенности

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

Соблюдайте баланс

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

Хотите узнать больше?

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

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

:::

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE