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. Автоматизация (beta)

Подкожный тест (Subcutaneous test)

PreviousПараллельное тестирование (Parallel testing)NextРазница между coupling и cohesion

Last updated 3 years ago

Was this helpful?

Впервые упоминание встречается в 2010 году у Jimmy Bougard в : ”В то время как модульный тест фокусируется на мелкомасштабном дизайне, подкожный тест не касается дизайна, а вместо этого проверяет основные входы и выходы системы в целом”, затем в докладе Matt Davies and Rob Moore - “”, а позже и в презентации Daniel Lafeir and Michael Lawrie. Термин «подкожный» означает автоматизированный тест непосредственно под слоем пользовательского интерфейса. В приложении MVC это будут тесты для всего, что находится непосредственно под контроллером. Для веб-службы все, что находится ниже ендпоинта (endpoint).

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

  • UI-тесты медленные. От этого никуда не деться. Их можно запускать параллельно, допиливать напильником и делать чуть-чуть быстрее, но они останутся медленными;

  • UI-тесты нестабильные. Отчасти потому, что они медленные. А еще потому, что Web-браузер и интерфейс пользователя не были созданы для того, чтобы ими управлял компьютер (в настоящее время данный тренд меняется, но не факт, что это хорошо);

  • UI-тесты - это наиболее сложные тесты в написании и поддержке. Они просто тестируют слишком много. (Это усиливается тем фактом, что, зачастую, люди берут «ручные» тест-кейсы и начинают их автоматизировать как есть, без учета разницы в ручном и автоматическом тестировании);

  • Нам говорят, что, якобы, UI-тесты эмулируют реального пользователя. Это не так. Пользователь не будет искать элемент на странице по ID или XPath локатору. Пользователь не заполняет форму со скоростью света, и не «упадет» если какой-то элемент страницы не будет доступен в какую-то конкретную миллисекунду. И даже теперь, когда браузеры разрабатываются с учетом того, что браузером можно программно управлять - это всего-лишь эмуляция, даже если очень хорошая;

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

Таким образом определение можно сформулировать так: “Если модульный тест тестирует наименьший тестируемый компонент кода приложения, то подкожный тест представляет собой единый рабочий процесс (workflow), который можно идентифицировать и протестировать в коде приложения. Подкожное тестирование рассматривает рабочий процесс как тестируемую единицу”.

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

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

Поскольку подкожные тесты ориентированы на поведение высокого уровня (high-level behavior), а не на дизайн, они идеально подходят для стратегий тестирования на основе сценариев (scenario-based testing strategies), таких как BDD или паттерн .

К сожалению, наряду со всеми плюсами subcutaneous подхода мы можем получить и снижение покрытия (coverage), в частности glue code ( - программный код, который служит исключительно для «склеивания» разных частей кода, и при этом не реализует сам по себе никакую иную прикладную функцию). Насколько важна\существенна потеря покрытия в данном случае? Зависит от ситуации. Мы потеряли немного glue code, который может быть (а может и не быть) важным (рекомендую в качестве упражнения определить, какой код потерялся). Оправдывает ли данная потеря покрытия введения тяжеловесного тестирования на уровне UI? Это тоже зависит от ситуации. Мы можем, например:

  • Добавить один UI-тест для проверки glue code, или

  • Если мы не ожидаем частых изменений glue code - оставить его без автотестов, или

  • Если у нас есть какой-то объем «ручного» тестирования - есть отличный шанс, что проблемы с glue code будут замечены тестировщиком, или

  • Придумать что-то еще (тот же канареечный релиз, Canary deployment)

Один из способов избежать потери покрытия - “”

Источники:

+ +

блоге
Microtesting - How We Set Fire To The Testing Pyramid While Ensuring Confidence
в своем сообщении о подкожном тестировании
Testcase Class per Fixture
Связующий код
Feature Tests Model
Introduction To Subcutaneous Testing
Пишем автотесты эффективно - Subcutaneous tests
англ. версия
видеоверсия
Subcutaneous Testing in ASP.NET Core