Системы управления тестированием (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-практик, позволяет минимизировать риски и обеспечить стабильную работу приложения в реальных условиях эксплуатации.
