QA_Bible
  • Введение
  • FAQ для новичков
    • Ответы на самые популярные вопросы новичков в чатах
    • Качества и навыки, которыми нужно обладать тестировщику?
    • Что должен знать и уметь Junior? Что спросят на собеседовании?
    • С чего начать обучение и куда развиваться?
    • Как составить резюме?
    • Где искать работу?
    • Как происходит процесс найма?
    • Как проходить собеседование?
    • Начало работы Junior-тестировщика
    • Ошибки в работе у начинающих тестировщиков
    • Как взаимодействовать с коллегами?
    • Перспективы профессии
  • Полезные ссылки
    • Список полезных ресурсов на разных платформах
    • Список ресурсов по инструментам тестировщика
  • Общее
    • QA/QC/Testing
    • Почему требуется тестирование ПО?
    • Качество ПО (Software Quality)
    • Принципы тестирования
    • Верификация и валидация (Verification and Validation)
    • Дефекты и ошибки
    • Серьезность и приоритет Дефекта (Severity & Priority)
    • Альфа- и бета- тестирование (Alpha Testing and Beta Testing)
    • Процесс тестирования (test process) (draft)
    • Техники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)
    • Экономика тестирования/стоимость качества (Cost of quality)
    • Подход к тестированию (Test Approach)
    • Импакт анализ (анализ влияния, Impact Analysis)
    • Анализ первопричин (RCA - Root Cause Analysis)
    • Тестирование со сдвигом влево (Shift left testing)
    • Модель зрелости возможностей (CMM - Capability Maturity Model)
    • Тестовая среда и тестовый стенд (Test Environment/Test Bed)
    • Бизнес-логика (Business logic)
    • Политика отсутствия багов (ZBP - Zero Bug Policy)
    • Независимое тестирование (Independent testing)
    • Роли/должности в команде
    • Эвристики и мнемоники
  • Виды-методы-уровни тестирования
    • Методы тестирования (White/Black/Grey Box)
    • Тестирование методом черного ящика (Black Box Testing)
    • Тестирование методом белого ящика (White Box Testing)
    • Тестирование методом серого ящика (Grey Box Testing)
    • Статическое и динамическое тестирование (Static Testing, Dynamic Testing)
    • Пирамида / уровни тестирования (Test Pyramid / Testing Levels)
    • Модульное/юнит/компонентное тестирование (Module/Unit/Component testing)
    • Интеграционное тестирование (Integration testing)
    • Системное тестирование (System Testing)
    • Приемочное тестирование (AT - Acceptance testing)
    • Основные виды тестирования ПО
    • Функциональное тестирование (Functional/Behavioral testing)
    • Нефункциональное тестирование (Non-Functional testing)
    • Тестирование производительности (Performance testing)
    • Тестирование емкости (Capacity testing)
    • Нагрузочное тестирование (Load testing)
    • Стрессовое тестирование (Stress testing)
    • Тестирование масштабируемости (Scalability testing)
    • Объемное тестирование (Volume testing)
    • Тестирование выносливости/стабильности (Endurance/Soak/Stability testing)
    • Тестирование устойчивости (Resilience testing)
    • Тестирование надежности (Reliability Testing)
    • Тестирование на отказ и восстановление (Failover and Recovery testing)
    • Эталонное и базовое тестирование (Benchmark and Baseline Testing)
    • Тестирование хранилища (Storage testing)
    • Одновременное / многопользовательское тестирование (Concurrency/Multi-user testing)
    • Тестирование сервиса (Service Testing)
    • Тестирование безопасности (Security and Access Control testing)
    • Оценка уязвимости/защищенности (Vulnerability Assessment)
    • Фаззинг-тестирование (Fuzz testing)
    • Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тести
    • Тестирование совместимости/взаимодействия (Compatibility/Interoperability testing)
    • Конфигурационное тестирование (Configuration testing)
    • Инсталляционное тестирование (Installation Testing)
    • Тестирование на соответствие (Conformance/Compliance testing)
    • Тестирование удобства пользования (Usability testing)
    • Тестирование доступности (Accessibility testing)
    • Тестирование локализации, глобализации и интернационализации (Localization/ globalization/internatio
    • Исследовательское тестирование (Exploratory testing)
    • Свободное / Интуитивное тестирование (Adhoc, Ad-hoc Testing)
    • Тестирование поддержки (Maintenance testing)
    • Регрессионные виды тестирования (Regression testing)
    • Тестирование клиентской части и серверной (Frontend testing Vs. Backend testing)
    • Тестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testing
    • Тестирование API (API - Application Programming Interface)
    • A/B тестирование (A/B Testing)
    • Деструктивное и недеструктивное тестирование (DT - Destructive testing and NDT - Non Destructive tes
    • Выборочное/хаотическое тестирование (Random/monkey testing)
    • Тестирование рабочего процесса/воркфлоу (Workflow testing)
    • Тестирование документации (Documentation testing)
    • Как протестировать продукт без требований?
    • Кроссбраузерное тестирование (Cross-browser testing)
    • Тестирование, основанное на рисках (Risk-Based Testing)
    • Разница тестирования ПО и железа (Software Vs. Hardware testing)
    • Тестирование качества данных (Data Quality Testing)
  • Тест дизайн
    • Тест-дизайн и техники тест-дизайна (Test Design and Software Testing Techniques)
    • Static - Reviews
    • Static - Static Analysis
    • Dynamic - White box
    • Dynamic - Black box
    • Dynamic - Experience based
  • Тестовая документация и артефакты (Test Deliverables/test artifacts)
    • Виды тестовой документации
    • Политика качества и политика тестирования (Quality policy and Test policy)
    • Стратегия тестирования (Test strategy)
    • План тестирования (Test plan)
    • Тестовый сценарий (Test scenario)
    • Тест-кейс (Test case)
    • Чек-лист (Check List)
    • Баг-репорт (Defect/bug report)
    • Требования (Requirements)
    • Пользовательские истории (User stories)
    • Критерии приемки (Acceptance Criteria)
    • Виды отчетов (Reports)
    • Базис тестирования (Test basis)
    • Матрица трассируемости (RTM - Requirement Traceability Matrix)
    • Метрики тестирования (Software Test Metrics)
    • Тестовый оракул (Test oracle)
  • Мобильное тестирование
    • Android
      • Архитектура Android OS
      • Архитектура Android Application
      • Тестирование покупок в Android-приложениях
      • Android Developer Settings
      • Android Debug Bridge (ADB)
      • Android Studio для QA
    • iOS
      • Архитектура iOS
      • Архитектура iOS Application
      • Тестирование покупок в iOS-приложениях
      • iOS Developer Settings
    • Особенности в тестировании мобильных приложений
    • Покрытие девайсов
    • Типы мобильных приложений
    • Симуляторы и эмуляторы
    • Основные различия Android/iOS
    • Последнее обновление Android/iOS, что нового?
    • Основные проверки при тестировании мобильного приложения
    • Каким образом тестировщик получает приложение на тест?
    • Как успешно зарелизить продукт в App Store и Google Play
    • Тестирование требований к мобильным приложениям
    • Тестирование push-уведомлений
    • Тестирование дип линков (mobile deep links)
    • Тестирование сохраненных поисков
    • Тестирование рекламы
    • Тестирование просмотренных товаров
    • Middleware
    • Как проверить использование ресурсов на Android
    • Как протестировать приложение для другой страны?
  • Тестирование в разных сферах-областях (testing different domains)
    • Тестирование веб-сайта или веб-приложения (Web application)
    • Тестирование интернет-магазина (eCommerce)
    • Тестирование платежного шлюза (Payment Gateway)
    • Тестирование игр (Game testing)
    • Тестирование VR программного обеспечения
    • Тестирование мессенджера (Messenger)
    • Тестирование чат-бота (Chatbot)
    • Тестирование электронных писем (E-mail)
    • Тестирование интернета вещей (IoT - Internet of Things)
    • Тестирование облачных решений (Cloud testing)
    • Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture)
    • Тестирование микросервисной архитектуры (MSA/Microservices)
    • Тестирование платформы электронного обучения (E-learning platform)
    • Тестирование систем розничной торговли (POS - Point Of Sale)
    • Тестирование банковского ПО (Banking domain applications/BFSI)
    • Тестирование страхового ПО (Insurance)
    • Тестирование в сфере телекоммуникаций (Telecom)
    • Тестирование планирования ресурсов предприятия (ERP - Enterprise Resource Planning)
    • Тестирование миграции данных (ETL)
    • Тестирование баз данных (Database)
    • Другое
  • SDLC и STLC
    • Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle)
    • Жизненный цикл тестирования ПО (STLC - Software Testing Lifecycle)
    • Модели разработки ПО
    • Agile
    • Scrum
    • Подходы к разработке/тестированию (... - driven development/testing)
  • Сети и около них
    • База по сетям
    • Клиент - серверная архитектура (Client-Server Architecture)
    • Микросервисная архитектура (Microservice Architecture)
    • Эталонные модели OSI и TCP/IP
    • HTTP
    • Идентификация ресурсов в сети (Identifying resources on the Web)
    • Веб-сервис (WS - Web service)
    • REST/SOAP/gRPC
    • Socket / WebSocket
      • Сокет/веб-сокет (socket/websocket)
      • Тестирование WebSocket на клиентах
    • Хранилище на стороне клиента (Client-side storage)
    • Кэш (Cache)
    • Аутентификация и авторизация (Authentication and authorization)
    • Рендеринг в интернете (Rendering on the Web)
  • Практическая часть
    • Логические задачи
    • Тестирование полей и форм
    • Примеры задач на собеседованиях и тестовых заданий
    • Платформы для тренировок и квизы
  • Автоматизация (beta)
    • Общее
    • Полезные ссылки
    • Как стать автоматизатором и вопросы с собеседований
    • Что нужно автоматизировать?
    • Виды и инструменты автоматизации
    • Инфраструктура и пайплайн (CI/CD)
    • Процессы и автоматизация проекта с нуля
    • Лучшие практики автоматизации
    • Что такое flaky tests?
    • Мутационное тестирование (Mutation testing)
    • Параллельное тестирование (Parallel testing)
    • Подкожный тест (Subcutaneous test)
    • Разница между coupling и cohesion
    • Другое (ссылки)
  • Контакты
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
  1. Тестирование в разных сферах-областях (testing different domains)

Тестирование микросервисной архитектуры (MSA/Microservices)

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

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

Само тестирование можно разделить на следующие виды:

  • unit тестирование;

  • контрактное тестирование;

  • интеграционное тестирование;

  • end-to-end тестирование;

  • нагрузочное тестирование;

  • UI или функциональное тестирование.

Unit тестирование

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

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

Unit тестами у нас покрыто 70% функционала, и так как мы применяем CI/CD, пока они не пройдены, приложение не задеплоится.

Контрактное тестирование

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

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

Например, бэкэнд-разработчик написал код, проставил аннотации и сделал swagger-документацию. Но если swagger не провалидируется фронтендом, а QA его уже протестируют ­- мы просто зря потратим время. Поэтому и создается контракт: например, у сервиса 8 эндпоинтов, и мы знаем, в каком формате он отдаёт и принимает данные.

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

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

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

Интеграционное тестирование

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

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

Что касается сборщика, то все тоже максимально просто: наша текущая архитектура изначально использует Gradle.

Если рассмотреть нашу инфраструктуру автоматизации, то это по большей части кастомный проект, в основе которого Java и Gradle, плюс куча библиотек, таких как Junit5, Feign, Rest Assured и т.д.

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

Для развертывания окружения в docker-контейнерах локально или на CI-сервере используется Java-библиотека TestContainers, которая позволяет оркестрировать docker-контейнерами непосредственно из кода тестов (testcontainers.org). При развертывании окружения поднимаются сам тестируемый сервис, а также используемые сервисом базы данных, брокер сообщений и эмулятор, который и мокает все внешние сервисы.

Так как все контейнеры мы поднимаем локально и на ранних этапах разработки, то потребовалось очень много времени на то, чтобы настроить перманентное окружение. Например, у нас есть сервис Settings, которому для работы нужны Сервисы 1 и 2, и какие-то данные с Kafka и MINO. Все это берется из переменных окружения, и за счет огромного количества зависимостей тяжело контролировать процесс поднятия одного сервиса.

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

End-to-end тестирование

По сути своей E2E тестирует бизнес-логику, так же, как и в интеграционном, но уже не изолированно, а в масштабе всей системы.

В end-to-end тестировании мы проверяем взаимодействие всех сервисов c платформой:

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

Нагрузочное тестирование

Процесс нагрузочного тестирования будем формально разделять на 4 небольших этапа:

  • тестирование производительности (Performance Testing) - исследование времени отклика ПО при выполнении операций на разных нагрузках, в том числе на стрессовых нагрузках;

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

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

  • объемное тестирование (Volume Testing) - исследование производительности ПО для прогнозирования долгосрочного использования системы при увеличении объемов данных, то есть анализ готовности системы к долгосрочному использованию.

Для тестов мы используем JMeter, а сами нагрузочные скрипты написаны на Groovy.

Мы используем около пяти виртуальных машин, развернутых на AWS и у нас есть 7 физических машин. Последние используем, если нужно создать большую нагрузку - 15,000 RPS и больше. Виртуальные машины, так как они, по сути, являются «откусанными» частями одной большой машины, таких цифр показать не могут - каждый реквест нужно отправлять с подписью шифрования, и это сильно нагружает процессор. Так что VM используем для фоновой или статической нагрузки в районе 2000 RPS.

Статистику собираем в Grafana - анализируем все показатели, нагрузку на CPU, GPU, сеть, диски и т.д.

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

UI или функциональное тестирование

Это завершающий этап тестирования. Если в предыдущих тестах фигурировал только API, теперь тестируется и фронт. Проводим как мануальное тестирование, так и автотесты.

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

Мы используем Java, Cucumber и самописную библиотеку для описания логики сценариев (раньше использовали Akitа сценарии, но поддержка библиотеки закончилась на Java 8, нам пришлось написать свою библиотеку для работы с UI-тестами, но в основе лежат методы именно оттуда). Cucumber используем для удобства написания самих тестов.

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

В Jenkins создается pipeline, в котором прописываем, сколько контейнеров необходимо поднять для запуска теста.

Например, нужно протестировать email-шаблоны, которых у нас 100-200. В один поток это займет 15-20 минут. Поэтому создаем pipeline в Jenkins, который этот скрипт разбивает на много маленьких контейнеров, которые поднимаются в Selenide.

Можно сказать, что Selenide - это виртуальный браузер, а Selenium - виртуальный пользователь. Одновременно поднимаются 10 контейнеров, и все тесты проходят за пару минут. Все пайплайны тоже написаны на Groovy.

После этого собираем это все в отчеты в зависимости от проекта: UI в Cucumber reports, а API-тесты - в Azure.

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

Источники:

Доп. материал:

PreviousТестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture)NextТестирование платформы электронного обучения (E-learning platform)

Last updated 3 years ago

Was this helpful?

Testing Microservices: an Overview of 12 Useful Techniques - ,

Тестируем микросервисную архитектуру
Тестирование микросервисов: разумный подход
How to test microservices?
Testing Strategies in a Microservice Architecture
Лучшие практики тестирования микросервисов
Микросервисы (Microservices)
How to Test Microservices
Microservices Testing Strategies, Types & Tools: A Complete Guide
Part 1
Part 2
Best testing strategies in a Microservice architecture