Системы управления тестированием (TMS) позволяют тестировать микросервисы (изоляция, взаимодействие, стабильность); мобильные приложения (UI-тесты, совместимость, производительность); инфраструктуру (нагрузочное тестирование, устойчивость, виртуализация); безопасность (анализ уязвимостей, защита от атак); документацию и артефакты (трассировка тестов, хранение документации, формирование отчетов).
Хорошо, если управление тестами, анализ результатов, запуск автотестов на CI/CD, багрепорт организованы в едином конвейере, что позволит не только видеть полную картину качества продукта, но и управлять ей.
Интеграция с AI в TMS позволяет генерировать тесты на основе требований, сэкономить время, сформировать корнер-кейсы, сократить time-to-market.
Технологии TMS позволяют снижать риски, повышать качество, экономить ресурсы, сокращать время вывода продукта на рынок и увеличивать удовлетворенность клиентов. Подробности — далее в этой статье.
- Инфраструктурное тестирование и DevOps
- Как тестировать
- Что проверяется
- Типы тестов
- Разделение по слоям
- Возможные проблемы
- Тестирование микросервисов
- Проверка отдельных сервисов и их взаимодействий
- Работа с независимыми CI-пайплайнами
- Маппинг переменных окружения
- Маппинг тестов на конкретные микросервисы
- Изоляция результатов тестов
- Триггеры и запуск тестов в независимых сервисах
- Покрытия по каждому микросервису
- Тестирование API
- Резюме
- Тестирование мобильных приложений
- Сложности тестирования мобильных приложений
- Инструменты автоматизации тестирования
- Матрица окружений
- Кэш зависимостей
- Использование эмуляторов и облачных платформ (Device Farms)
- Резюме
- Тестирование производительности
- Инструменты для тестирования производительности
- Диаграммы флакеров (Flaker Diagrams)
- Динамика длительности тестов от раза к разу
- Резюме
- Тестирование безопасности
- Уникальность ниши ИБ
- Интеграция с корпоративными системами аутентификации
- Ссылки на CVE и статусы исправления
- Отслеживание и мониторинг уязвимостей
- Резюме
- Тестирование юзабилити (UI, удобство интерфейса)
- Как тестировать
- a11y (Accessibility)
- Принципы WCAG
- Автоматизация и управление параметрами запуска
- Заключение
Инфраструктурное тестирование и DevOps
Инфраструктурное тестирование — это проверка и верификация работоспособности и стабильности инфраструктуры, на которой размещено приложение. При этом применяются различные виды тестирования.
Цель — убедиться, что инфраструктура способна выдержать планируемую нагрузку, соответствует требованиям безопасности и доступна круглосуточно. В рамках DevOps (Development & Operations) тестируются как сами приложения, так и окружающая их инфраструктура.
Как тестировать
Весь код (Terraform, Ansible, CloudFormation и т.д.) должен храниться в системе контроля версий (например, Git).
На каждое изменение в коде (merge/pull request) должен автоматически запускаться пайплайн (в GitLab CI/CD, GitHub Actions, Jenkins и т.п.).
Федор Алексеев, владелец продукта Сфера.Функциональное тестирование:
Проверяйте инфраструктуру в «песочнице», максимально похожей на боевую/продуктивную среду, и устраивайте ей «стресс-тесты».
Современная инфраструктура управляется через код (Terraform, Ansible и т. п.). Хорошая практика — поднимать временную тестовую среду при каждом изменении и проверять:
- корректность настроек безопасности,
- возможность быстрого восстановления после сбоев,
- соответствие корпоративным правилам.
Дальше можно включить «хаос-тестирование» — искусственно выключать сервер или замедлять сеть и смотреть, как система реагирует. Цель — убедиться, что сервисы сами восстанавливаются или быстро переключаются на резерв.
Пример: если при падении одного дата-центра приложение продолжает работать из другого, значит инфраструктура настроена правильно.
Пайплайн должен дестроить и заново создавать тестовую среду. Это проверяет, что ваш код способен создать инфраструктуру с нуля, а не только дополнить существующую.
Каждая тестовая среда должна быть изолирована, чтобы не мешать другим разработчикам или процессам. Используйте уникальные идентификаторы (имена проектов, теги, неймспейсы).
Что проверяется
- Конфигурация серверов и сетей.
- Версии и совместимость используемых компонентов.
- Установка и обновление пакетов и зависимостей.
- Скриптинг и автоматизация деплоймента.
- Доступность и производительность систем.
- Работа системы при отключении ЦОД
Типы тестов
- Тестирование конфигурации: проверка правильности установленных параметров и настроек (например, портов, SSL/TLS сертификатов, DNS-записей).
- Нагрузочное тестирование: проверка инфраструктуры на предмет способности выдерживать запланированную нагрузку.
- Тестирование безопасности: проверка уязвимостей и соответствий требованиям безопасности (например, с использованием scanners).
- Integration Tests: проверка совместимости и интеграции между компонентами инфраструктуры (например, микросервисами).
- Тест на отказоустойчивость: проверка работы системы при отсутствии связи с одним из ЦОД.
- Хаос-тест: отключение и/или замедление серверов; отслеживание переключения на резерв.
Разделение по слоям
- Infrastructure layer: проверка физической инфраструктуры (серверы, сети, VPN).
- API layer: проверка API-ответов и взаимодействия между сервисами.
- UI layer: проверка пользовательского интерфейса и взаимодействия с ним.
Возможные проблемы
- Неинициализированная переменная среды: отсутствие переменной окружения, необходимой для работы приложения.
- Нестыковка микросервисов: несоответствие между версиями микросервисов, что приводит к конфликтам API.
- Несоответствие требованиям безопасности: нарушение политик безопасности и стандартов.
Инфраструктурное тестирование помогает обеспечить стабильную и безопасную работу инфраструктуры, поддерживающей приложение.
Тестирование микросервисов
Микросервисная архитектура усложняет процесс тестирования, так как приложение делится на множество маленьких независимых сервисов, работающих совместно. Главные особенности:
- Независимая природа сервисов: Каждый микросервис имеет собственную инфраструктуру, технологию и базу данных, что создает сложности при взаимодействии и совместном тестировании.
- Возрастающее количество зависимостей: Возникает необходимость проверки взаимодействия между сервисами, так как изменение одного может повлиять на работу других.
- Повышенный риск сбоев: Из-за большого количества связей между сервисами возрастает вероятность ошибок, вызванных несогласованными действиями или некорректными контрактами API.
Проверка отдельных сервисов и их взаимодействий
Один из способов тестирования микросервисов — раздельное тестирование каждого сервиса и проверка их взаимодействий:
- Тестирование отдельного сервиса: Тестируются индивидуальные сервисы в изоляции, что позволяет выявить проблемы внутри конкретного компонента.
- Интеграционное тестирование: Проверяется взаимодействие между несколькими микросервисами. Например, если один сервис отвечает за вычисления, а другой за сохранение данных, проверяется корректность их взаимодействия.
Федор Алексеев, владелец продукта Сфера.Функциональное тестирование:
Совет: проверяйте работу микросервисов через «контракты» между ними.
Микросервисы редко работают в одиночку — обычно они обмениваются данными с другими сервисами. Чтобы избежать сюрпризов, для каждого взаимодействия стоит описывать «контракт» — правила обмена данными (например, в формате OpenAPI). Далее тесты должны проверять: если один сервис меняется, не ломает ли он работу других. Это называется consumer-driven contract testing. Таким образом, вы ловите ошибки ещё на этапе сборки кода, а не после релиза.
Пример: сервис «Заказ» ждёт от сервиса «Оплата» определённый ответ. Если разработчик изменил формат ответа, тесты тут же покажут проблему, и релиз не попадёт в продакшн с багом.
Самая большая опасность в микросервисной архитектуре — не падение одного сервиса, а незаметный разрыв связей между ними. Изменение в одном сервисе может быть корректным само по себе, но «ломать» всех его потребителей.
Работа с независимыми CI-пайплайнами
Для тестирования микросервисов важно организовать независимые пайплайны CI/CD (continuous integration/continuous delivery), чтобы каждый сервис мог проходить тесты и разворачиваться отдельно от других. Это помогает избежать зависимостей и позволяет локализовать ошибки.
Методология Consumer-Driven Contract (CDC) Testing позволяет находить проблемы на самых ранних этапах — еще на этапе сборки кода, а не после развертывания в продакшен. Это радикально снижает стоимость исправления ошибок и ускоряет разработку.
CDC-тестирование — это не единичный тест, а непрерывный процесс:
-
Потребитель определяет и публикует контракт своих ожиданий.
-
Поставщик в своем CI-пайплайне постоянно проверяет, что его изменения не нарушают контракты всех его известных потребителей.
-
Если контракт нарушен, пайплайн поставщика немедленно падает, не давая выпустить ломающее изменение.
Маппинг переменных окружения
Каждая служба может требовать уникальной конфигурации и переменных окружения. Необходимо четко регулировать и настраивать переменные, чтобы тесты проходили одинаково и предсказуемо на любых окружениях (локальных, staging, production).
Маппинг тестов на конкретные микросервисы
Важна правильная привязка тестов к конкретным микросервисам. Это позволяет сократить время на диагностику ошибок и повышает прозрачность процесса тестирования. Определите, какие тесты касаются какого сервиса, чтобы минимизировать пересекающиеся и дублирующие тесты.
Изоляция результатов тестов
Каждое тестирование микросервиса должно проводиться изолированно, чтобы не допустить влияния одного сервиса на другой. Используйте mock-обработки или заглушки, чтобы смоделировать зависимые сервисы и изолировать их от тестов.
Триггеры и запуск тестов в независимых сервисах
Автономные триггеры тестов позволяют инициировать запуск тестов при изменениях в любом микросервисе. Независимо от размера системы, любое изменение должно незамедлительно запускать тестирование соответствующего сервиса.
Покрытия по каждому микросервису
Оценка покрытия тестов по каждому отдельному микросервису — необходимое условие для гарантирования качества. Желательно стремиться к достижению высокого уровня покрытия кода и функционала каждым сервисом индивидуально.
Тестирование API
Так как большинство взаимодействий между микросервисами осуществляются через API, особое внимание следует уделить тестированию API каждого сервиса. Проверяйте корректность ответов, время отклика, валидность данных и совместимость контрактов API.
Резюме
Микросервисы требуют особого подхода к тестированию из-за своей природы: каждый сервис автономен, но тесно связан с остальными. Тестирование микросервисов требует глубокого анализа зависимостей, точной настройки CI/CD-пайплайнов, изоляции тестов и качественного покрытия каждого компонента.
Тестирование мобильных приложений
Тестирование мобильных приложений отличается от тестирования обычных веб-приложений и настольных программ. Основные отличия заключаются в большем разнообразии аппаратных платформ, операционных систем, экранных разрешений и вариантов использования устройств. Кроме того, необходимо учитывать низкое качество мобильного интернета, разряд батареи, переключение между Wi-Fi и мобильной сетью, push-уведомления и многое другое.
Сложности тестирования мобильных приложений
- Огромное разнообразие устройств и платформ: Существует тысячи моделей смартфонов и планшетов с разными размерами экрана, плотностью пикселей, процессорами и памятью.
- Разница в версиях операционной системы: Одну и ту же версию Android или iOS могут воспринимать по-разному на разных устройствах.
- Внешние зависимости: Технологии Bluetooth, NFC, GPS, камера, микрофон и сенсорные экраны могут давать непредсказуемые результаты.
- Аппаратные ограничения: Разряд аккумулятора, нехватка оперативной памяти, перегрев устройства.
- Скорость и стабильность сети: Неустойчивое соединение, низкая скорость Интернета или отключение сигнала могут повлиять на поведение приложения.
Инструменты автоматизации тестирования
Существует множество инструментов для автоматизации тестирования мобильных приложений:
- Appium: Открытый фреймворк для автоматизации тестирования нативных, гибридных и веб-приложений на Android и iOS.
- Espresso: Официальный инструмент Google для тестирования Android-приложений.
- XCUITest: Инструмент Apple для автоматизации тестирования iOS-приложений.
- Calabash: Инструмент для автоматизации нативных и гибридных приложений на обеих платформах.
- Robot Framework Mobile Library: Библиотека для Python, позволяющая писать автотесты для мобильных приложений.
Матрица окружений
Матрица окружений — это таблица, которая показывает, на каких устройствах, версиях ОС и сетевых условиях нужно тестировать приложение. Ее составляют на основе наиболее распространенных устройств и наиболее популярных версий операционных систем. Например:
- Samsung Galaxy S20/S21/S22 (Android 10, 11, 12)
- iPhone 11 Pro Max/iPhone 12 Mini/iPhone 13 Pro (iOS 14, 15)
- Huawei Mate/Poco/Xiaomi Mi Notebook (Android 9, 10, 11)
Такая матрица позволяет эффективно распределить тестирование и убедиться, что приложение работает на большинстве устройств.
Кэш зависимостей
Особенностью мобильных приложений является сильное влияние кэша и локальных данных. Если приложение не очищает кэш или хранит неправильные данные, возможны странные ошибки и неправильное поведение. При проведении тестов важно учитывать очистку кэша, сброс данных, удаление cookies и локальных хранилищ.
Использование эмуляторов и облачных платформ (Device Farms)
- Эмуляторы: Бесплатные и бесплатные инструменты для эмуляции мобильных устройств на компьютере. Примеры: Android Emulator (для Android), Simulator (для iOS).
- Device Farms: Облачные платформы, предоставляющие удаленный доступ к физическим устройствам для тестирования. Примеры: AWS Device Farm, BrowserStack, Sauce Labs, Perfecto Mobile.
Эти инструменты позволяют тестировать приложения на сотнях реальных устройств без необходимости приобретать и поддерживать физическое оборудование.
Резюме
Тестирование мобильных приложений — непростая задача, требующая тщательного планирования, хороших инструментов и аккуратного подхода. Учитывая разнообразие устройств и операционных систем, сложности тестирования нельзя недооценивать. Однако с правильным выбором инструментов и методов можно существенно повысить качество мобильных приложений и удовлетворить потребности пользователей.
Тестирование производительности
Тестирование производительности — это процесс проверки поведения приложения или системы при увеличенных нагрузках, который позволяет оценить, насколько стабильно и быстро приложение справляется с нагрузкой, а также выявить узкие места и точки деградации производительности.
Инструменты для тестирования производительности
- Apache JMeter: Универсальный инструмент для нагрузочного тестирования web-приложений, REST/SOAP-сервисов, FTP и других протоколов.
- Gatling: High-performance, opensource toolkit for load testing written in Scala, поддерживающий запись и воспроизведение сценариев.
- Locust: Open-source framework для тестирования нагрузки, основанный на Python, позволяющий создавать многопоточные user-like нагрузки.
- BlazeMeter: Cloud-based service для нагрузочного тестирования, работающий поверх Apache JMeter и других инструментов.
- Neotys NeoLoad: Commercial solution для нагрузочного тестирования, предоставляющая богатый набор опций и аналитики.
Диаграммы флакеров (Flaker Diagrams)
Диаграммы флакеров — это особый вид графиков, отображающих разброс результатов тестов по времени. Эти диаграммы полезны для выявления нестабильных тестов, называемых flaky-тестами, которые время от времени дают разные результаты при одинаковых входных данных и условиях.
Графики показывают среднюю длительность выполнения тестов и размах вариаций. Это позволяет выявить нестабильно проходящие тесты и устранить их, чтобы улучшить надежность тестирования.
Динамика длительности тестов от раза к разу
Наблюдение динамики длительности тестов — это полезный подход для выявления проблем производительности и регрессий. Анализируя разницу во времени выполнения тестов, можно выявить узкие места, провалы в производительности и зависимости от окружения.
Для анализа используют:
- Среднее время выполнения: Средняя длительность теста за период времени.
- Медианное время выполнения: медиана всех замеров времени выполнения теста.
- Коэффициент вариации: мера относительной изменчивости, показывающая стабильность выполнения теста.
Эти данные позволяют определить:
- Какие тесты стали медленными и требуют оптимизации.
- Есть ли признаки деградации производительности.
- Являются ли тесты стабильными или подвержены колебаниям.
Резюме
Тестирование производительности, анализ диаграмм флакеров и мониторинг динамики длительности тестов — это важные мероприятия, направленные на повышение стабильности и производительности приложений. Использование специализированных инструментов и техник позволяет выявить и устранить узкие места, обеспечить хорошее пользовательское впечатление и повысить общую надежность продукта.
Тестирование безопасности
Тестирование безопасности — это процесс выявления уязвимостей и угроз в программном обеспечении и инфраструктуре. Цель тестирования — защитить продукт от атак злоумышленников и минимизировать последствия киберинцидентов.
Уникальность ниши ИБ
Информационная безопасность (ИБ) стала критическим фактором успеха для бизнеса. Компании осознают важность безопасного продукта и инфраструктуры, поскольку атаки хакеров становятся все более массированными и опасными. Решения в сфере ИБ пользуются огромным спросом, особенно в финансовой сфере, здравоохранении и государственном секторе.
Интеграция с корпоративными системами аутентификации
Интеграция с корпоративными системами аутентификации (LDAP, Active Directory, OAuth и др.) позволяет соблюдать политику безопасности компании и упрощает процесс идентификации пользователей. Это снижает риски, связанные с поддельными аккаунтами и злоупотреблением правами доступа.
LDAP (Lightweight Directory Access Protocol) — это стандартный протокол для доступа к каталогам пользователей и их атрибутов, применяемый для централизованной аутентификации и управления доступом. LDAP позволяет безопасно запрашивать и изменять записи о пользователях в каталоге, обеспечивая унификацию доступа к различным системам и приложениям.
Active Directory (AD) — это фирменная реализация Microsoft протокола LDAP, предназначенная для Windows Server. AD используется для управления пользователями, группами, компьютерами и политиками безопасности в домене Windows. Она предоставляет возможность централизованного управления доступом и безопасности в корпоративных сетях.
OAuth (Open Authorization) — это открытый стандарт для делегирования доступа к защищённым ресурсам. OAuth позволяет пользователям разрешать доступ к своим данным сторонним приложениям без необходимости делиться паролем. Наиболее распространённой реализацией является OAuth 2.0, который используется крупными сервисами (Google, Facebook, Twitter) для авторизации пользователей в сторонних приложениях.
Ссылки на CVE и статусы исправления
Common Vulnerabilities and Exposures (CVE) — это международная база данных известных уязвимостей, созданная MITRE Corporation. Включение ссылок на CVE в отчётах о тестировании безопасности позволяет квалифицировать и сравнивать уязвимости с международными стандартами. Важно отслеживать статусы исправления уязвимостей, чтобы оперативно закрывать обнаруженные дыры.
Отслеживание и мониторинг уязвимостей
Мониторинг уязвимостей включает постоянный анализ систем и приложений на предмет новых угроз. Существуют специализированные инструменты для сканирования уязвимостей (Nessus, Qualys, Acunetix), которые помогают своевременно выявлять и устранять проблемы.
Nessus — это мощный инструмент для сканирования уязвимостей в сетевом оборудовании, серверах и приложениях. Позволяет выявлять распространенные уязвимости, несоответствия политике безопасности и проблемы конфигурации. Имеет бесплатную версию с ограниченными функциями и коммерческую версию с расширенным функционалом.
Qualys — облачная платформа для сканирования уязвимостей и управления ими. Предназначена для комплексного анализа безопасности сетевых устройств, серверов, приложений и инфраструктуры. Позволяет проводить регулярные проверки и предоставлять подробные отчёты о статусе безопасности.
Acunetix — специализированный инструмент для тестирования веб-приложений на уязвимости. Автоматически находит и анализирует проблемы безопасности, такие как SQL-инъекции, XSS, CSRF и другие. Отличается удобным интерфейсом и поддержкой различных языков программирования и фреймворков.
Резюме
Тестирование безопасности — это неотъемлемая часть процесса разработки и эксплуатации программного обеспечения. Особую роль играет уникальная ниша ИБ, которая требует глубоких знаний и опыта в защите цифровых активов. Интеграция с корпоративными системами аутентификации, использование международных стандартов (CVE) и активное отслеживание уязвимостей помогают обеспечить надежную защиту продуктов и минимизировать риски для бизнеса.
Тестирование юзабилити (UI, удобство интерфейса)
Тестирование юзабилити направлено на оценку удобства и простоты использования интерфейса сайта или приложения. Основными задачами тестирования являются:
- Проверка логичности расположения элементов интерфейса.
- Оценка интуитивности навигации и доступности функционала.
- Исследование восприятия и поведения пользователей при взаимодействии с продуктом.
Существуют как количественные (опросы, аналитика), так и качественные (интервью, наблюдения) методы оценки юзабилити.
Как тестировать
Главный сдвиг парадигмы — отказ от тестов, «придуманных в вакууме». Вместо этого фокус смещается на реальное поведение реальных пользователей. Это гарантирует, что усилия по тестированию тратятся на то, что действительно критично для бизнеса и UX, а не на гипотетические или маловероятные сценарии.
Тестовые сценарии должны строиться на основе объективных данных:
-
Аналитика (Google Analytics, Яндекс.Метрика, Hotjar)
-
Записи сессий (session recordings)
-
Карты кликов (heatmaps)
Это превращает тестирование из субъективного искусства в Data-Driven процесс.
Федор Алексеев, владелец продукта Сфера.Функциональное тестирование:
Совет: тестируйте самые популярные сценарии глазами пользователя, а не только технически.
Вместо того чтобы вручную придумывать тесты, можно взять реальные данные о том, как пользователи чаще всего используют продукт: какие кнопки нажимают, какие страницы открывают. Из этих «путей» строится сценарий поведения. Автоматические тесты должны проверять именно эти сценарии на разных устройствах и скоростях интернета.
Дополнительно полезно проверять:
- доступность для людей с ограниченными возможностями (a11y),
- стабильность интерфейса (сравнение скриншотов),
- скорость отклика.
Пример: если большинство клиентов проходит путь «Каталог → Товар → Корзина → Оплата», то именно этот сценарий должен проверяться при каждом обновлении.
Цель автоматизации — не просто проверить, что кнопка нажимается, а обеспечить работоспособность сквозных сценариев, которые составляют основу пользовательского опыта.
Система должна работать не в идеальных лабораторных условиях, а в условиях, максильно приближенных к реальности. Это означает обязательное тестирование на:
-
Разных устройствах и браузерах (мобильные телефоны, планшеты, десктопы).
-
Разной скорости интернета (3G, 4G, медленный Wi-Fi), чтобы убедиться в отзывчивости и работоспособности в условиях слабого соединения.
Такой подход позволяет оптимизировать ресурсы на автоматизацию. В первую очередь автоматизируются не случайные тесты, а те самые «пути», которые проходят 80% пользователей. Это дает максимальную отдачу от инвестиций в автоматизацию.
a11y (Accessibility)
a11y — это сокращённое слово от «accessibility», означающее доступность цифрового контента людям с особыми потребностями. Например, если сайт не поддерживает скринридеры или отсутствует необходимая разметка HTML, люди с нарушениями зрения или моторики могут столкнуться с серьезными препятствиями при попытке получить доступ к контенту.
Принципы WCAG
WCAG (Web Content Accessibility Guidelines) сформулировали четыре основных принципа доступности:
- Perceivable (Восприятие): Контент должен быть представлен в формах, воспринимаемых всеми пользователями.
- Operable (Управляемость): Интерфейс и навигация должны быть удобны для всех пользователей.
- Understandable (Понимание): Содержимое и интерфейс должны быть просты и понятны для восприятия.
- Robust (Надёжность): Контент должен оставаться доступным на разных платформах и устройствах.
Автоматизация и управление параметрами запуска
Для повышения эффективности тестирования юзабилити и доступности применяется автоматизация рутинных задач через CI/CD (Continuous Integration/Continuous Deployment)-конвейеры. Например, с помощью инструментов автоматизации можно централизованно управлять параметрами запуска тестов, записывать результаты и отслеживать изменения в параметрах доступности (a11y) и удобства использования (юзабилити).
Таким образом, сочетание ручного тестирования и автоматизации позволяет создать полноценный процесс тестирования юзабилити и доступности, обеспечивая максимальную вовлеченность аудитории и комфортное использование продукта.
Заключение
Выбор подходящего набора тестов напрямую зависит от особенностей конкретного проекта, ожидаемой пользовательской нагрузки и инфраструктуры, на которой развернут продукт. Важно подбирать типы тестов (например, инфраструктурные, UI, API), исходя из потребностей бизнеса и технических ограничений.
Сочетание автоматизированных и ручных тестов, наряду с применением DevOps-практик, позволяет минимизировать риски и обеспечить стабильную работу приложения в реальных условиях эксплуатации.
