velizaryan Dec 13 2024 at 21:52

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

Easy

8 min

1.1K

Opinion

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

Все знают, как писать тест-кейсы (конкретный тест-кейс). В интернете достаточно статей на эту тему. Но вот как составлять карту тест-кейсов, особенно, в условиях микросервисной архитектуры? Какую стратегию для этого выбрать? Я до сих пор не встречала хорошей статьи на эту тему. Поэтому, вот вам одна из них 😊)

Предпосылки

У меня сейчас несколько доменов:

Определения личности пользователя.
Санкции.
Микрофронтенд.
Апп приложение- “маркет”.

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

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

С чего начать?

Не будем изобретать велосипед и применим C4-модель (Context, Container, Component, Code) к нашему репозиторию. Эта модель позволяет структурировать сложные системы от контекста до отдельных компонентов.

Первый уровень: Контекст (Context)

“Контекст (Context): показывает систему в окружении пользователей и взаимодействующих с ней внешних систем.”

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

Бэкенд
Веб
Мобаил
Интеграции

- Integration cases
  - ...
- Back end cases
  - ...
- Front end (Web) cases
  - ...
- Front end (Mobile) cases
  - ...

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

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

Второй уровень: Контейнеры (Containers) - Integration

Контейнеры (Containers): детализирует основные исполняемые элементы системы и их взаимодействие.

- Integration cases
  - User portal
  - Shops
  ...

В разрезе папки интеграционных тестов контейнерами мы считаем интеграции со сторонними сервисами (например, "Shops", "User portal").

Это дает следующие плюсы:

Логическая изоляция и распределение ответственности: каждое направление (например, Shops, User portal) представляет отдельную область ответственности сторонней системы.
Явное разделение видов интеграции: деление по видам интеграции позволяет четко выделить границы каждого контейнера.

Пример из проекта Микрофронт.

Shops интеграция: она проверяет точку входа в Microfront KYC flow. Эти тест-кейсы проверяют 1) что для нового пользователя в сервисе Shops есть вход в KYC flow 2) что для старого пользователя входа в KYC flow нет (он прошел ее в прошлом).

Второй уровень: Контейнеры (Containers) - Backend

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

Это подход позволяет держать фокус тестирования на одном объекте и не пытаться в одном ТК проверить все.

Пример:

В тестах на order происходит создание session и отправка events, но проверка session или event не является частью этих ТКs. Фокус проверки в этих ТКс лежит на order сущности.
Аналогично, основная проверка events осуществляется в разделе тестов, посвященных events. Когда проверяется event на создание (это может быть создание order или другой обект), то фокус в этих тестах идет на проверке event логики.

Второй уровень: Контейнеры (Containers) - Frontend and Mobile

Переходим к самому интересному разделу — Frontend.

Пример №1: Микрофронтенд.

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

Здесь можно выделить три подхода для определения следующего уровня вложенности:

Бизнес сущность провайдер: разделить тест-кейсы по провайдерам, а дальше ввести деления на функциональные и UI сценарии. Здесь упор делается на уникальность провайдеров во flow.
Тип тестов: разделить тест-кейсы на функциональные и UI, а уже внутри делать деление по провайдерам. Здесь упор делается на уникальность провайдера во flow.
Возможно, что-то ещё?

На данный момент у меня нет единого подхода.

1. Разделение тест-кейсов по провайдерам → функциональные и UI сценарии

Плюсы:

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

2. Разделение тест-кейсов на функциональные и UI → провайдеры

Плюсы:

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

Минусы:

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

Как выбрать оптимальный вариант?

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

Первый уровень деление на функциональные и UI-тесты.
Внутри них создается вложенность по провайдерам.

- Functional Tests
  - [Provider_1]
      - Test case 1
      - Test case 2
  - [Provider:2]
      - Test case 1
      - Test case 2
- UI Tests
  - [Provider_1]
      - Test case 1
      - Test case 2

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

Пример №2: Пользовательские проверки

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

Для этого проекта мы выбрали другое деление:

- Front end (Web)
	- Проверка 1
	  - Functional cases
      - UI check cases
	- Проверка 2
	  - Functional cases
      - UI check cases
- Front end (Mobile)
	- Проверка 1
	  - Functional cases
      - UI check cases

Почему так?

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

По сути, каждая проверка- это отдельный контейнер внутри микросервиса. Каждая проверка — это самостоятельная область ответственности. И выбранная структура чётко это отображает.

Итог:

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

Третий уровень: Component (Front/Mobile)

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

Для создания и организации тестов внутри контейнера мы придерживаемся принципа разделения ответственности и группировки по компонентам. Обычно этот слой мы применяем только для Front/Mobile тестов. В других папках такая вложенность избыточна.

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

Дополнительно мы выделяем проверки модульного функционала в отдельные тест-кейсы. К примеру:

Проверка поиска,
Проверка восстановления пароля,
Проверка навигации,
Проверка валидации данных.

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

Правила которые помогают проверить тест-кейсы на правильную группировку

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

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

Полезные советы

Полезный совет №1:

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

Полезный совет №2:

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

Задачу в системе трекинга задач (Jira например).
Notion - Документацию фичи (если она есть).
Miro – ссылка на схему или процесс, разработанный для фичи.

Полезный совет №3:

Разделяйте тест-кейсы по репозиториям. Если вы тестируете большой домен, состоящий из 10 микросервисов, оптимальным решением будет разделить общий репозиторий с тест-кейсами этого домена на подрепозитории. Это позволяет не размазывать фокус тестирования.

Hubs:

IT systems testing