Пирамида Автоматизации Тестирования Хабр
Автоматические регрессионные тесты — основа стратегии автоматизации тестирования. Ниже представлена пирамида автоматизации Майка Кона, которая иллюстрирует эффективный подход к автоматизации тестирования. Автоматизированное тестирование предполагает использование специального программного обеспечения (помимо тестируемого) для контроля выполнения тестов и сравнения ожидаемого результата работы программы с фактическим. Пирамида автоматизированного тестирования предлагает больше фокусироваться на модульных и интеграционных тестах, потому что они дешевле и быстрее в написании и выполнении, но дают хороший охват функциональности. Системные тесты должны быть относительно небольшими, чтобы ускорить их выполнение и уменьшить время ожидания результатов. Такие тесты проверяют доступность веб-сервисов, к которым обращается приложение.
API-тесты и/или сервис-тесты могут запускаться на компьютере разработчика или быть частью сборки, но если они начинают занимать длительное время, лучше запускать их в среде непрерывной интеграции. Для сервис-тестов можно использовать такие инструменты, как SoapUI. Чаще всего это происходит, когда над проектом работают несколько разных команд, возможно, изолированных друг от друга, и они добавляют тесты на разные уровни пирамиды. Например, разработчики пишут модульные и интеграционные тесты независимо от QA-инженеров, которые пишут сквозные тесты.
Автоматизация тестирования позволяет улучшить качество и скорость тестирования, а также сократить затраты на тестирование. Когда тестирование выполняется вручную, это может быть очень трудоемким процессом. Например, если тестирование включает множество шагов, которые необходимо повторить несколько раз, это может занять много времени и сил. Кроме того, при ручном тестировании возникает риск ошибок, так как человек может пропустить какую-то деталь или не заметить ошибку.
Вндрение Пирамиды Тестирования #
Облако в верхней части пирамиды включает в себя действия, ориентированные на человека, такие как исследовательское тестирование и другие задачи, которые не могут быть автоматизированы. В целом, пирамида тестирования может служить полезным фреймворком для организации регрессионного тестирования, а регрессионное тестирование, в свою очередь, является ключевым элементом для поддержания качества кода на всех этапах жизненного цикла разработки. Внедрение пирамиды тестирования в процесс разработки программного обеспечения — это сложная задача, требующая планирования, координации и постоянного мониторинга.
Большая часть моего рабочего времени уходит на вещи вроде добавления тестов для поддержки новой функции приложения или перепроверки отчёта о непростом баге. Мы понимаем, что нам нужны тесты на всех уровнях, но при этом должны иметь больше тестов на более низких уровнях, поскольку они позволяют быстро и эффективно диагностировать проблемы. Пирамида тестов — это абстракция, которая отражает группировку тестов программного обеспечения по разным уровням детализации.
На канале “БАГаж тестировщика” вышел новый практический выпуск о тестировании требований и макетов. Можно рассмотреть ещё пограничные варианты, когда вообще ничего нет или есть только ручное тестирование, но не будем вдаваться в крайности. Все эти вопросы раскроет автор в своем докладе, на примере одной из своих моделей «Пирамида степени автоматизации действий». Оба вида тестирования имеют как преимущества, так и недостатки.
Тесты Безопасности (security Tests)
Итак, у нас есть UI тесты короткие и быстрые, а есть долгие и упорные (назовем их end-2-end сценарии). Первые обычно не проверяют какую-то серьезную бизнес логику, только точечно небольшие визуальные фишки на странице, вторые же наоборот, проверяют бизнес логику через UI, имитируя действия пользователя. В связи с этим, по уровню их применения короткие можно отнести к модульным UI тестам, а длинные – к супер интеграционным тестам, применяемым в основном при приемочном тестировании. Я предлагаю другой подход к автоматизированному тестированию – Колесо автоматизации. Размер сектора колеса не означает число тестов, которые должны быть автоматизированы.
На этом примере я перечислю ключевые моменты, которые необходимо учитывать, чтобы получить максимальный эффект от проведения автоматизированных тестов. Чтобы исполнить этот тест-кейс, мы должны запустить браузер, ввести имя пользователя и пароль, нажать на кнопку «Вход»… и, в конце концов, сравнить фактический и ожидаемый результаты. Теперь представьте себе, что некая программа делает те же самые действия за вас.
Допустим, проверить вычисление процентов с отрицательной суммы наверняка возможно на “среднем уровне” или даже на уровне юнит-тестов, так зачем делать это на уровне пользовательского интерфейса? Автоматизировать тесты на более низком уровне эффективнее, это позволяет раньше обнаруживать дефекты, экономит время и деньги. Ключом к успеху в автоматизации является вовлечение всей команды в разработку стратегии удовлетворения различных потребностей в автоматизации и ее реализации.
Это самый нижний уровень, на котором тестируются отдельные функции, методы или блоки кода. Модульные тесты должны быть быстрыми и надежными, и должны проверять отдельные аспекты функциональности приложения. Визуальные тесты проверяют отображение элементов интерфейса на экране. Они схожи с UI-тестами, но фокусируются на проверке внешнего вида интерфейса, а не на функциональности. Примерами таких проверок могут быть проверка правильности отображения изображения кнопки или проверка отображения логотипа продукта на экране.
Пирамида тестирования являет собой наиболее популярный и востребованный шаблон по созданию стратегии тестирования в сфере QA услуг, которую многие веб-сообщества используют при планировании будущей методики автоматизированного тестирования. Трудности, с которыми мы сталкиваемся при компонентном тестировании, и наши подходы к избавлению от недетерминированности — темы для отдельной статьи. Скажу лишь, что мы придерживаемся политики нулевой терпимости к недетерминированности в компонентных тестах (а для приложения Bumble на iOS у нас их около 300). Опять же изучать архитектуру проекта, то, как он развёртывается. И начинать с простых тестовых сценариев, возможно даже с тех, которые будут в начале тестировать только бекэнд, постепенно переходя к UI.
Напомню, что ручное тестирование строится на методах тестирования. Сюда относятся и техники тест-дизайна, и техники, основанные на опыте. Просто еще раз хочу обратить внимание, что тестирование — это заранее продуманная деятельность по сравнению фактического результата с ожидаемым, а не просто поиск ошибок «методом тыка». Но почему же автоматизированное тестирование до сих пор не вытеснило ручное? Таким образом мы получим сравнительно небольшое количество UI тестов, написанных и поддерживаемых тестировщиками, что даст им возможность больше времени уделять именно тестированию, а не кодированию тестов. Автотесты производительности проверяют, что ответ на запрос приходит в рамках соответствующего периода времени.
Интеграционный Уровень
Чудесная картинка, которую каждый находит, когда начинает изучение автоматизации тестирования или пытается начать строить процесс автоматизированного тестирования в компании. Я тоже когда-то видел эту картинку и восхищался ей, насколько она понятна и проста и даёт понимание того, как всё должно выглядеть. Но она хороша ровно до тех пор, пока начинающий тестировщик не сталкивается с суровыми буднями и ожиданиями руководства, которые эту пирамиду видели. Например, если граничные значения были проверены на уровне юнит-тестов, не стоит повторять их на уровне GUI – таким образом мы вряд ли получим новую информацию. Предложенная Майком Коном (Mike Cohn) пирамида автоматизации может помочь командам найти лучший из возможных подходов к автоматизации тестирования. В то время как unit-тесты основаны на тестировании функций внутри класса, интеграционные тесты формируют следующую ступень, направленную на тестирование классов, образующих компонент, входящий в состав нового функционала.
Подавляющее большинство из них выполняется на симуляторах параллельно (насколько это возможно) и относительно быстро. Последние измерения показывают, что в среднем выполнение сквозного теста на симуляторе iOS занимает от 30 до 90 секунд (включая настройку и удаление). Следовательно, выполнение полного набора тестов займёт 20—30 минут. Кроме того, мы делаем тестовые запуски и на реальных iOS-устройствах. Это другое подмножество тестов, которые нельзя перенести в симулятор, потому что им, например, нужна физическая камера или какие-то разрешения. Такие прогоны занимают около 12 минут при средней продолжительности теста в две минуты.
Приемку проводит либо внутреннее тестирование (необязательно тестировщики) или внешнее тестирование (сам заказчик и необязательно тестировщик).
Обратите внимание, что, к счастью, мы не запускаем все эти конфигурации для каждого изменения в приложении. Мы внедрили специальную логику, которая выбирает для изменённых модулей и функций только подходящие тесты. Однако если мы спустимся по пирамиде вниз, от сквозных к более низкоуровневым тестам, то скорость и частота запусков вырастут, а объём ручного контроля уменьшится. Что касается длительности выполнения, то, забегая вперёд, скажу, что в разных конфигурациях запуск сценария компонентного тестирования занимает в среднем 12—15 секунд. Автоматические тесты на уровне UI медленны, уязвимы к любым изменениям, их трудно поддерживать.
Как правило, любая функциональность системы, которая может быть протестирована с помощью Unit, компонентного или сервисного теста, должна быть проверена с использованием упомянутого типа теста. Тесты же пользовательского интерфейса должны быть сосредоточены исключительно на выявлении ошибок во взаимодействии пользователя с графическим интерфейсом. Введение в проект автоматизации тестирования позволяет существенным образом упростить процесс проверки программного обеспечения, экономя финансовые средства клиента, а также дает возможность выпускать веб-продукт в производство как можно скорее. Поскольку автоматизация тестов через пользовательский интерфейс, как правило, занимает больше времени, возникает соблазн передать это отдельной команде по автоматизации или заставить тестировщиков взять на себя полную ответственность за это.
- Визуальные тесты проверяют отображение элементов интерфейса на экране.
- Предложенная Майком Коном (Mike Cohn) пирамида автоматизации может помочь командам найти лучший из возможных подходов к автоматизации тестирования.
- Эта методология тестирования позволяет также убедиться в том, что в процессе тестирования ПО не были пропущены существенные ошибки и недочеты.
- Подобная метрика являет собой актуальное соотношение числа багов, найденных после релиза, к числу ошибок, которые были обнаружены во время непосредственной процедуры тестирования.
- Этот пакет тестов не предназначен для проверки всех возможностей приложения, поскольку их работа уже проверена функциональными регрессионными пакетами.
Мартин Фаулер считает, что главные причины этого – недостаток изолированности, асинхронное поведение, удалённые сервисы, утечки ресурсов. На проекте есть в большом объеме автоматизация ui тестов box ручное тестирование и какой-то объём модульных тестов. Про интеграцию и системные тесты там слышали, но не видели, автоматизация может быть и есть, но только UI.
Кроме того, некоторые виды тестирования, например, исследовательское тестирование, могут быть выполнены только вручную. Это программы, которые помогают проводить стрессовое и нагрузочное тестирование. Этот тип тестирования помогает автоматизировать часто повторяющиеся, но необходимые для максимизации тестового покрытия, задачи. Итоговая цель любой автоматизированной проверки – создание корпоративной культуры тестирования разными отделами и командами, которые в той или иной степени вовлечены в процесс создания ПО.
Такие тесты запускаются только после того, как unit-тестирование было успешно завершено. Функциональный пакет регрессионных тестов нужен для более детальной проверки работы приложения, чем это позволяют «дымовые» тесты. «Дымовой» пакет регрессионных тестов нужен для проверки того, что приложение загружается и запускается. В него также входят несколько ключевых сценариев, позволяющих убедиться, что приложение ещё работает.
В центральной части данной пирамиды находятся наборы из приемочных и интеграционных тестов графического интерфейса, которые являются наиболее малозначимой группой проверок при автоматизации. Конечно же, внедрение подобной формы тестирования – процесс непростой, требующий максимальной концентрации и использования наиболее подходящих https://deveducation.com/ и эффективных инструментов, с помощью которых можно измерить величину производительности и качество веб-продукта. Компонентными называют приёмочные тесты, которые проверяют пользовательский опыт посредством взаимодействия с графическим интерфейсом. Они зависят от возможностей UI-тестирования фреймворка Apple XCTest.
