Skip to content

Latest commit

 

History

History
440 lines (323 loc) · 78.8 KB

vidy-i-instrumenty-avtomatizacii.md

File metadata and controls

440 lines (323 loc) · 78.8 KB
Raw

Виды и инструменты автоматизации

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

При всем многообразии того, что можно считать автоматизацией, можно попытаться выделить категории:

  • Функциональное или нефункциональное тестирование;
  • Уровни: unit, integration, UI/E2E;
  • Метод: white box, black box;
  • Уровень в сетевой модели: frontend, backend, database;
  • Платформы: desktop, mobile, web, cross platform;
  • ОС: windows, macos, linux, cross platform;
  • Масштабируемость: однопоточные, многопоточные;
  • Программа, скрипт, фреймворк или библиотека;
  • Работа непосредственно с тестами, как вспомогательное средство (генераторы данных), инфраструктура (CI/CD, раннеры, отчетность);
  • Если это создание тестов, то каким образом: нативный язык программирования, универсальный ЯП, тестовая модель и ключевые слова, рекордеры (Capture & Playback);
  • и т.д. и т.п. до бесконечности.

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

Технологии автоматизации тестирования

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

Подход Суть Преимущества Недостатки
1 Частные решения

Для решения каждой

отдельной задачи

пишется отдельная

программа

 Быстро, просто

Нет системности,

много времени уходит на поддержку.

Почти невозможно

повторное использование
2

Тестирование под

управлением данными (DDT)

Из тест-кейса вовне

выносятся входные

данные и ожидаемые результаты.

Один и тот же тест кейс можно повторять многократно с

разными данными

Логика тест-кейса по прежнему строго

определяется

внутри, а потому для

ее изменения тест кейс надо переписывать
3

Тестирование под

управлением ключевыми словами (KDT)

Из тест-кейса вовне

выносится описание

его поведения

Концентрация на высокоуровневых действиях. Данные и

особенности поведения хранятся вовне и

могут быть изменены

без изменения кода

тест-кейса

Сложность выполнения низкоуровневых

операций
4

Использование

фреймворков

 Конструктор, позволяющий использовать остальные подходы Мощность и гибкость

Относительная

сложность (особенно

- в создании

фреймворка)
5 Запись и воспроизведение (Record & Playback)

Средство автоматизации записывает

действия тестировщика и может воспроизвести их,

управляя тестируемым приложением

Простота, высокая

скорость создания

тест-кейсов.

Крайне низкое качество, линейность, неподдерживаемость

тест-кейсов. Требуется серьёзная доработка полученного

кода
6

Тестирование под

управлением поведением (BDT)

Развитие идей тестирования под управлением данными и

ключевыми словами.

Отличие - в концентрации на бизнес сценариях без выполнения мелких

проверок

Высокое удобство

проверки высокоуровневых пользовательских сценариев

Такие тест-кейсы

пропускают большое

количество функциональных и нефункциональных дефектов,

а потому должны

быть дополнены

классическими более низкоуровневыми тест-кейсами

На текущем этапе развития тестирования представленные в таблице технологии иерархически можно изобразить следующей схемой:

Технологии: Частные решения

Иногда перед тестировщиком возникает уникальная (в том плане, что такой больше не будет) задача, для решения которой нет необходимости использовать мощные инструментальные средства, а достаточно написать небольшую программу на любом из высокоуровневых языков программирования (Java, C#, PHP и т.д.) или даже воспользоваться возможностями командных файлов операционной системы или подобными тривиальными решениями. Также сюда можно отнести задачи вида:

  • Подготовить базу данных, наполнив её тестовыми данными (например, добавить в систему миллион пользователей со случайными именами).
  • Подготовить файловую систему (например, создать структуру каталогов и набор файлов для выполнения тест-кейсов).
  • Перезапустить набор серверов и/или привести их в требуемое состояние.

Удобство частных решений состоит в том, что их можно реализовать быстро, просто, «вот прямо сейчас». Но у них есть и огромный недостаток - это «кустарные решения», которыми может воспользоваться всего пара человек. И при появлении новой задачи, даже очень похожей на ранее решенную, скорее всего, придётся всё автоматизировать заново.

Преимущества:

  • Быстрота и простота реализации;
  • Возможность использования любых доступных инструментов, которыми тестировщик умеет пользоваться;
  • Эффект от использования наступает незамедлительно;
  • Возможность нахождения очень эффективных решений в случае, когда основные инструменты, используемые на проекте для автоматизации тестирования, оказываются малопригодными для выполнения данной отдельной задачи;
  • Возможность быстрого создания и оценки прототипов перед применением более тяжеловесных решений

Недостатки:

  • Отсутствие универсальности и, как следствие, невозможность или крайняя сложность повторного использования (адаптации для решения других задач).
  • Разрозненность и несогласованность решений между собой (разные подходы, технологии, инструменты, принципы решения).
  • Крайне высокая сложность развития, поддержки и сопровождения таких решений (чаще всего, кроме самого автора никто вообще не понимает, что и зачем было сделано, и как оно работает).
  • Является признаком «кустарного производства», не приветствуется в промышленной разработке программ.

Технологии:Тестирование под управлением данными (DDT)

Обратите внимание, как много раз в командных файлах повторяются строки, выполняющие одно и то же действие над набором файлов (и нам ещё повезло, что файлов немного). Ведь куда логичнее было бы каким-то образом подготовить список файлов и просто передать его на обработку. Это и будет тестированием под управлением данными. Теперь нам достаточно подготовить CSV-файл с любым количеством имён сравниваемых файлов, а код тест-кейса не увеличится.

К другим типичным примерам использования тестирования под управлением данными относится:

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

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

Преимущества:

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

Недостатки:

  • При изменении логики поведения тест-кейса его код всё равно придётся переписывать;
  • При неудачно выбранном формате представления данных резко снижается их понятность для неподготовленного специалиста;
  • Необходимость использования технологий генерации данных;
  • Высокая сложность кода тест-кейса в случае сложных неоднородных данных;
  • Риск неверной работы тест-кейсов в случае, когда несколько тест-кейсов работают с одним и тем же набором данных, и он был изменён таким образом, на который не были рассчитаны некоторые тест-кейсы;
  • Слабые возможности по сбору данных в случае обнаружения дефектов;
  • Качество тест-кейса зависит от профессионализма сотрудника, реализующего код тест кейса.

Технологии: Тестирование под управлением ключевыми словами

Логическим развитием идеи о вынесении вовне тест-кейса данных является вынесение вовне тест-кейса команд (описания действий). Идею можно развить, добавив в CSV-файл ключевые слова, являющиеся описанием выполняемой проверки. Ярчайшим примером инструментального средства автоматизации тестирования, идеально следующего идеологии тестирования под управлением ключевыми словами, является Selenium IDE, в котором каждая операция тест-кейса описывается в виде: Действие (ключевое слово) - Необязательный параметр 1 - Необязательный параметр 2.

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

Вторым естественным преимуществом тестирования под управлением ключевыми словами (хотя она вполне характерна и для тестирования под управлением данными) стала возможность использования различных инструментов одними и теми же наборами команд и данных. Так, например, ничто не мешает нам взять показанные CSV-файлы и написать новую логику их обработки не на PHP, а на C#, Java, Python или даже с использованием специализированных средств автоматизации тестирования.

Преимущества:

  • Максимальное устранение избыточности кода тест-кейсов;
  • Возможность построения мини-фреймворков, решающих широкий спектр задач;
  • Повышение уровня абстракции тест-кейсов и возможность их адаптации для работы с разными техническими решениями;
  • Удобное хранение и понятный человеку формат данных и команд тест-кейса;
  • Возможность поручения описания логики тест-кейса сотруднику, не имеющему навыков программирования;
  • Возможность повторного использования для решения новых задач;
  • Расширяемость (возможность добавления нового поведения тест-кейса на основе уже реализованного поведения)

Недостатки:

  • Высокая сложность (и, возможно, длительность) разработки;
  • Высокая вероятность наличия ошибок в коде тест-кейса;
  • Высокая сложность (или невозможность) выполнения низкоуровневых операций, если фреймворк не поддерживает соответствующие команды;
  • Эффект от использования данного подхода наступает далеко не сразу (сначала идет длительный период разработки и отладки самих тест-кейсов и вспомогательной функциональности);
  • Для реализации данного подхода требуется наличие высококвалифицированного персонала;
  • Необходимо обучить персонал языку ключевых слов, используемых в тест-кейсах

Технологии: Фреймворки

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

Фреймворки автоматизации тестирования представляют собой не что иное, как успешно развившиеся и ставшие популярными решения, объединяющие в себе лучшие стороны тестирования под управлением данными, ключевыми словами и возможности реализации частных решений на высоком уровне абстракции.

Фреймворков автоматизации тестирования очень много, они очень разные, но их объединяет несколько общих черт:

  • высокая абстракция кода (нет необходимости описывать каждое элементарное действие) с сохранением возможности выполнения низкоуровневых действий;
  • универсальность и переносимость используемых подходов;
  • достаточно высокое качество реализации (для популярных фреймворков).

Как правило, каждый фреймворк специализируется на своём виде тестирования, уровне тестирования, наборе технологий. Существуют фреймворки для модульного тестирования (например, семейство xUnit), тестирования веб-приложений (например, семейство Selenium), тестирования мобильных приложений, тестирования производительности и т.д.

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

Преимущества:

  • Широкое распространение;
  • Универсальность в рамках своего набора технологий;
  • Хорошая документация и большое сообщество специалистов, с которыми можно проконсультироваться;
  • Высокий уровень абстракции;
  • Наличие большого набора готовых решений и описаний соответствующих лучших практик применения того или иного фреймворка для решения тех или иных задач.

Недостатки:

  • Требуется время на изучение фреймворка;
  • В случае написания собственного фреймворка де-факто получается новый проект по разработке ПО;
  • Высокая сложность перехода на другой фреймворк;
  • В случае прекращения поддержки фреймворка тест-кейсы рано или поздно придётся переписывать с использованием нового фреймворка;
  • Высокий риск выбора неподходящего фреймворка.

Технологии: Запись и воспроизведение (Record & Playback)

Технология записи и воспроизведения (Record & Playback) стала актуальной с появлением достаточно сложных средств автоматизации, обеспечивающих глубокое взаимодействие с тестируемым приложением и операционной системой. Использование этой технологии, как правило, сводится к следующим основным шагам:

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

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

Преимущества:

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

Недостатки:

  • Линейность тест-кейсов: в записи не будет циклов, условий, вызовов функций и прочих характерных для программирования и автоматизации явлений;
  • Запись лишних действий (как просто ошибочных случайных действий тестировщика с тестируемым приложением, так и (во многих случаях) переключений на другие приложения и работы с ними);
  • Так называемый «хардкодинг», т.е. запись внутрь кода тест-кейса конкретных значений, что потребует ручной доработки для перевода тест-кейса на технологию тестирования под управлением данными;
  • Неудобные имена переменных, неудобное оформление кода тест-кейса, отсутствие комментариев и прочие недостатки, усложняющие поддержку и сопровождение тест кейса в будущем;
  • Низкая надёжность самих тест-кейсов в силу отсутствия обработки исключений, проверки условий и т.д

Технологии: Тестирование под управлением поведением

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

Такой подход не только упрощает выполнение целого класса проверок, но и облегчает взаимодействие между разработчиками, тестировщиками, бизнес-аналитиками и заказчиком, т.к. в основе подхода лежит очень простая формула «given-when-then»:

  • Given («имея, предполагая, при условии») описывает начальную ситуацию, в которой находится пользователь в контексте работы с приложением;
  • When («когда») описывает набор действий пользователя в данной ситуации;
  • Then («тогда») описывает ожидаемое поведение приложения.

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

Преимущества:

  • Фокусировка на потребностях конечных пользователей;
  • Упрощение сотрудничества между различными специалистами;
  • Простота и скорость создания и анализа тест-кейсов (что, в свою очередь, повышает полезный эффект автоматизации и снижает накладные расходы).

Недостатки:

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

К классическим технологиям автоматизации тестирования также можно отнести разработку под управлением тестированием (Test-driven Development, TDD) с её принципом «красный, зелёный, улучшенный» (Red-Green-Refactor), разработку под управлением поведением (Behavior-driven Development), модульное тестирование (Unit Testing) и т.д. Но эти технологии уже находятся на границе тестирования и разработки приложений, потому выходят за рамки данной темы.

Автоматизация вне прямых задач тестирования

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

  • Использование командных файлов для выполнения последовательностей операций - от копирования нескольких файлов из разных каталогов до развертывания тестового окружения. Даже в рамках многократно рассмотренных примеров по тестированию «Конвертера файлов» запуск приложения через командный файл, в котором указаны все необходимые параметры, избавляет от необходимости вводить их каждый раз вручную;
  • Генерация и оформление данных с использованием возможностей офисных приложений, баз данных, небольших программ на высокоуровневых языках программирования. Нет картины печальнее, чем тестировщик, руками нумерующий три сотни строк в таблице;
  • Подготовка и оформление технических разделов для отчётов. Можно тратить часы на скрупулезное вычитывание журналов работы некоего средства автоматизации, а можно один раз написать скрипт, который будет за мгновение готовить документ с аккуратными таблицами и графиками, и останется только запускать этот скрипт и прикреплять результаты его работы к отчёту;
  • Управление своим рабочим местом: создание и проверка резервных копий, установка обновлений, очистка дисков от устаревших данных и т.д. и т.п. Компьютер всё это может (и должен!) делать сам, без участия человека;
  • Сортировка и обработка почты. Даже раскладывание входящей корреспонденции по подпапкам гарантированно занимает у вас несколько минут в день. Если предположить, что настройка специальных правил в вашем почтовом клиенте сэкономит вам полчаса в неделю, за год экономия составит примерно сутки;
  • Виртуализация как способ избавления от необходимости каждый раз устанавливать и настраивать необходимый набор программ. Если у вас есть несколько заранее подготовленных виртуальных машин, их запуск займёт секунды. А в случае необходимости устранения сбоев разворачивание виртуальной машины из резервной копии заменяет весь процесс установки и настройки с нуля операционной системы и всего необходимого программного обеспечения

Классификация инструментов автотестирования мобильных приложений

Драйвер. Утилиты автотестирования, как и другие программы, могут взаимодействовать с приложением только через программный интерфейс - по-другому они не умеют. Для работы через другие интерфейсы существуют специальные программы - драйверы. Драйвер - программа, которая предоставляет API для одного из интерфейсов приложения. Для каждого интерфейса, кроме, собственно, API, необходим свой драйвер. Например, когда вы даёте драйверу для GUI команду “Нажать на кнопку Menu”, он воспринимает её через API и отсылает в тестируемое приложение, где эта команда превращается в клик по графической кнопке Menu. Для взаимодействия с API приложения драйверы не нужны или почти не нужны - взаимодействие программное. А вот при работе с остальными интерфейсами без них не обойтись. Наиболее сложными обычно являются драйверы для GUI, так как этот интерфейс сильно отличается от обычного для программы общения кодом. При этом в автоматизированном тестировании мобильных приложений GUI наиболее актуален, так как в интеграционном тестировании использовать чаще всего приходится именно его. Наиболее популярные драйвера для GUI в мобильном тестировании - UIAutomator и Espresso для Android, XCUITest - для iOS.

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

У надстройки могут быть следующие функции:

  • Модификация поведения (без изменения API). Например:
    • дополнительное протоколирование,
    • валидация данных,
    • ожидание выполнения действия в течение определенного времени.
  • Повышение удобства и/ или уровня абстракции API через:
    • использование синтаксического сахара - удобных названий функций, более коротких обращений к ним, унифицированного стиля написания тестов;
    • неявное управление драйвером, когда, например, он инициализируется автоматически, без необходимости прописывать каждое такое действие вручную;
    • упрощение сложных команд вроде выбора события из календаря или работы с прокручивающимися списками;
    • реализацию альтернативных стилей программирования, таких как процедурный стиль или fluent.
  • Унификация API драйверов. Здесь надстройка предоставляет единый интерфейс для работы сразу с несколькими драйверами. Это позволяет, например, использовать один и тот же код для тестов на iOS и Android, как в популярной надстройке Appium.

Фреймворк. С другой стороны тестов находится фреймворк запуска. В рамках данной статьи я буду коротко называть его “фреймворк”. Фреймворк - это программа для формирования, запуска и сбора результатов запуска набора тестов.

В задачи фреймворка входят:

  • формирование, группировка и упорядочение набора тестов,
  • распараллеливание набора (опционально),
  • создание фикстур,
  • запуск тестов,
  • сбор результатов их выполнения,
  • формирование отчётов о выполнении (опционально).

Можно заметить, что эти функции не связаны с тестированием только мобильных приложений - их можно успешно применять и в тестировании десктоп- и веб-приложений. Дело в том, что фреймворк не должен обеспечивать взаимодействие тестов и приложения - он работает только с тестами, и тип приложения не имеет значения. Если драйверы и надстройки находятся между тестами и приложением, то фреймворк находится над тестами, организуя их запуск. Поэтому важно не путать понятия “драйвер” и “фреймворк”. Конечно, в некоторых фреймворках есть собственные драйверы для работы с приложениями, но это вовсе не обязательное условие. Самые заметные фреймворки в мобильном тестировании - xUnit и Cucumber.

Комбайны. Наконец, еще одна группа утилит, использующихся для автоматизации тестирования мобильных приложений, - это комбайны, объединяющие в себе и фреймворки, и драйверы (причём не только мобильные), и даже возможности разработки. Xamarin.UITest, Squish, Ranorex - все они поддерживают автоматизацию тестирования iOS-, Android-, веб-приложений, а два последних - ещё и десктоп-приложений.

Android: Инструменты для автоматизации тестирования

Тесты под андроид бывают локальные и инструментальные:

  • Instrumented tests выполняются на устройстве Android, физическом или эмулированном. Тест собирается в APK и устанавливается вместе с тестовым приложением. Instrumented tests обычно представляют собой тесты пользовательского интерфейса, запуск приложения и последующее взаимодействие с ним;
  • Local tests выполняются на вашей машине разработки или сервере, поэтому их также называют тестами на стороне хоста (host-side tests). Для запуска тестов используется виртуальная машина Java (JVM). Обычно они маленькие и быстрые, изолируя тестируемый объект от остальной части приложения.

Не все модульные тесты являются локальными, и не все Е2Е тесты выполняются на устройстве. Например:

  • Большой локальный тест: вы можете использовать симулятор Android, который работает локально, например Robolectric;
  • Небольшой инструментальный тест: вы можете убедиться, что ваш код хорошо работает с функцией платформы, такой как база данных SQLite. Вы можете запустить этот тест на нескольких устройствах, чтобы проверить интеграцию с несколькими версиями SQLite.

UI тесты обращаются к GUI-драйверам. GUI-драйверы являются наиболее сложным компонентом всего стека тестирования. Они решают базовые, низкоуровневые задачи. Когда вы даете GUI-драйверу (Espresso, UiAutomator, Robotium, Selendroid) команду «кликнуть на кнопку», он обрабатывает ее, взаимодействует с приложением, и эта команда превращается в клик по элементу.

Все драйверы работают на Android Instrumentation Framework - базовом API Android для взаимодействия с системой. Самые популярные - Espresso и UiAutomator. Они оба разрабатываются и поддерживаются компанией Google. Их без труда можно использовать одновременно в пределах одного теста.

UiAutomator поставляется вместе с Android SDK начиная с 16 версии API. Как GUI-драйвер он служит для поиска элементов интерфейса на экране девайса и эмуляции различных действий: кликов, тачей, свайпов, ввода текста, проверок на видимость. Рекордер для записи тестов он не предоставляет, зато предоставляет утилиту для просмотра древовидной структуры экрана - Ui Automator Viewer.

UiAutomator позволяет писать тесты по модели черного ящика (black-box). Он живет в собственном процессе и работает без доступа к исходному коду приложения. Значит, тест с его использованием может взаимодействовать практически с любыми приложениями, в том числе системными. Это открывает доступ к множеству функций, например, становятся возможны:

  • набор номера и совершение звонка;
  • отправка и чтение смс;
  • взаимодействие с нотификациями;
  • управление настройками сети, геолокации;
  • снятие скриншотов.

Наиболее подходящим сценарием для использования UiAutomator является не работа с тестируемым продуктовым приложением, а взаимодействие со сторонними или системными приложениями. Более подходящим инструментом для работы с продуктовым приложением является Espresso.

Это также официальный фреймворк для UI-тестирования от Google, но тесты с его использованием работают уже по модели белого ящика (white-box). Espresso поддерживает Android API с 10 версии, хотя появился значительно позже. Предоставляет рекордер для записи тестов. Фактически Espresso является лидером и даже стандартом в индустрии. Такой успех может быть связан с тем, что он обеспечивает повышенную скорость и стабильность тестов в сравнении с конкурентами. Espresso решает низкоуровневую задачу - найти необходимый элемент на экране по заданным параметрам (ViewMatcher), произвести с ним действия (ViewAction) или выполнить проверки (ViewAssertion). Синтаксис Espresso реализован на основе фреймворка Hamcrest. Он построен на использовании иерархий вложенных матчеров - сущностей, описывающих требования к объекту, в случае Espresso - к элементам интерфейса. Они используются при задании параметров поиска элемента на экране, а также в проверках как описание свойств, которыми элемент должен обладать. Вложенность матчеров часто приводит к тому, что код тестов становится трудно читать и поддерживать. Стабильность и скорость тестов на Espresso обусловлены его внутренним устройством - все команды Espresso выполняются в том же процессе, в котором работает само тестируемое приложение. Действия и проверки преобразовываются и кладутся в очередь сообщений главного потока приложения. Выполняются они только когда приложение готово к этому, то есть его главный поток находится в состоянии ожидания пользовательского ввода (idle).

Итак, с драйверами и устройством наиболее популярных из них мы разобрались. Мы поняли, что все они решают низкоуровневые задачи: поиск элемента на экране и выполнение с ним какого-либо действия. Из-за этого они предоставляют невыразительный API, которым неудобно пользоваться для решения более высокоуровневых проблем. Например, ни один из них не предоставляет собственный механизм для реализации повторов неудачных действий или логирования. Более того, часто существует необходимость работать в тестах сразу с несколькими драйверами, например, с Espresso и UiAutomator.

На помощь приходят обертки (надстройки). Именно к API оберток мы будем обращаться в наших тестах, и именно обертки предоставляют конечный арсенал приемов для наших тестов.

  • Kakao - простой и удобный Kotlin DSL для Espresso. Он позволяет упростить код тестов на Espresso и повысить его читаемость;
  • Barista - это объемная библиотека, содержащая большое количество полезных решений и приемов при работе с Espresso;
  • Kaspresso - это фреймворк-обертка для UI-тестирования, который претендует на то, чтобы избавить мир от зла и стать практически единственной зависимостью в вашем проекте для работы с тестами. Kaspresso расширяет лаконичный Kakao DSL - он предоставляет собственный Kotlin DSL для описания тестовых секций и шагов, внутри которых продолжает жить Kakao.

Подробнее в источнике по первой ссылке далее.

iOS: Инструменты для автоматизации тестирования

Под iOS существуют следующие инструменты:

  • TestProject - фреймворк для iOS тестирования на базе Appium и Selenium. Подходит для тестирования веба, Android-приложений и API. При этом не обязательно использовать XCode;
  • EarlGrey - open-source инструмент, разработанный компанией Google для тестирования своих собственных iOS-приложений, таких как YouTube, Google Calendar и т.д.;
  • XCTest - инструмент, созданный Apple для iOS тестирования. Он полностью совместим с XCode. XCTest универсален - c помощью него можно проводить как unit-тесты, так и тестировать производительность и пользовательский интерфейс;
  • Detox - это инструмент end-to-end тестирования, который используется для тестирования методом серого ящика;
  • OCMock - проект с открытым исходным кодом, который упрощает iOS-тестирование с помощью mock-объектов. OCMock расшифровывается как Objective-C Mock. С его помощью тестировщик может создавать mock-объекты, используя язык Objective-C;
  • KIF - это фреймворк для интеграционного тестирования iOS-приложений. KIF расшифровывается как “keep it functional” и используется для тестирования пользовательского интерфейса, как и XCTest.

Подробнее в источнике по первой ссылке далее.

Кроссплатформенные обертки

  • Appium - это довольно популярный кросс-платформенный open source инструмент для автоматизации тестирования десктоп и мобильных приложений под Android и iOS. Архитектура Appium схожа с Selenium WebDriver, широко распространенным и ставшим стандартом в web-тестировании. Кроссплатформенность достигается за счет использования разных драйверов для разных платформ. Именно драйверы транслируют клиентский Appium-код в команды, непосредственно исполняемые на устройствах. Для написания тестов Appium предоставляет клиентские библиотеки с фиксированным API;
  • Calabash пользуется большой популярностью среди разработчиков благодаря стабильности и подходу к построению тестов. Calabash использует Cucumber, благодаря чему его могут использовать даже люди, незнакомые с программированием. Поддерживает много языков программирования, может работать как с iOS, так и с Android приложениями.

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

WEB: Инструменты для автоматизации тестирования

  • Selenium: Старейший фреймворк, все еще самый популярный. Поддерживает Java, Python, C#, Ruby, JavaScript. Эмулирует почти все возможные действия пользователя;
  • Cucumber: Фреймворк ориентирован на behavior-driven development (BDD) - “разработка через поведение”; удобный как для разработчиков, так и QA. Главное преимущество: простота;
  • Cypress: И наконец Cypress, делающий жизнь тестировщиков проще. В нем нет некоторых проблем, существующих в Selenium, потому что он имеет другую архитектуру - построен на основе JS-фреймворка Mocha. Преимущества: простота и удобство асинхронных тестов. Применяется BDD/TDD-библиотека (TDD = test-driven development);
  • Playwright enables reliable end-to-end testing for modern web apps;
  • Puppeteer is a Node library which provides a high-level API to control Chrome or Chromium over the DevTools Protocol

Подробнее в источнике по первой ссылке далее.

API: Инструменты для автоматизации тестирования

По постману и соап есть множество ссылок в инструментах для мануальщика.

Unit

Инструменты по performance/security и всему не вошедшему смотри в разделе полезных ссылок по мануальному тестированию.

Инструменты, касающиеся инфраструктуры CI/CD вынесены в следующую тему.

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

По инструментам: