Статья публикуется от имени Батеевой Екатерины, Neifmetus
Мир не стоит на месте: еще десять лет назад пользователи выходили в интернет с помощью компьютера, а сегодня по статистике большая часть посещений приходится на мобильную версию сайта или мобильные приложения. Поэтому требования к стабильности и удобству использования этих приложений становятся выше.
В нашем банке мы тоже наблюдаем эту тенденцию: мобильное приложение по сравнению с интернет-банком используют на порядок больше пользователей. Поэтому остро встал вопрос автоматизации тестирования мобильного приложения. Несмотря на повсеместное использование мобильных приложений, средства для их автоматизированного тестирования далеко не идеальны. Кроме того, мы предъявляем к ним высокие требования. Например, самый популярный фреймворк Appium — open-source решение, поддерживающее платформы Android и iOS, — нам не подошел. Наши разработчики использовали много модных библиотек, и взаимодествовать с приложением иногда приходилось на более низком уровне. UI Automator и UI Automation оказались более сложными в развертывании, каждое приложение использовало свой язык для написания тестов, из-за чего возникали проблемы при перераспределении между платформами в команде автотестирования.
На старте процесса по автоматизации в нашей команде было два человека на два проекта и по 100 тест-сценариев на каждую платформу и довольно сжатые сроки. Мы искали решение, на разворачивание и доработку которого у нас бы ушло минимум времени. И еще мы надеялись, что решение быстро освоят новые сотрудники.
Наше внимание привлекло малоизвестное решение от компании «Experitest» — SeeTest Automation. Это кросс-платорменное решение для тестирования. Система интегрируется с WebDriver (Selenium), HP UFT/QTP, JUnit, Microsoft Visual Studio и другими. SeeTest Automation поддерживает мобильные платформы iOS, Android и Windows, причем как для смартфонов, так и для планшетов.
Для подключения устройств используется простой и понятный интерфейс.
В интерфейсе есть список добавленных устройств. Для каждого устройства отображается его статус (online/offline), имя и версия операционной системы. Приложения для тестирования устанавливаются через этот интерфейс, и для каждого устройства можно увидеть установленные тестовые приложения и их версию.
У подключенных телефонов можно открыть экран и увидеть все происходящее на девайсе. В режиме разработчика девайс реагирует на управление мышью и клавиатурой. Отображение экрана обновляется автоматически в режиме реального времени. Также на экране девайса доступен инспектор (Object Spy), в котором можно посмотреть дерево элементов.
Здесь можно увидеть как базовые, так и добавленные атрибуты документов. Например, для элементов, которые сложно или невозможно идентифицировать по таким параметрам, как text, label или id, мы просим разработчиков задавать дополнительные тэги с уникальным значением.
Инспектор позволяет сгенерировать уникальный xpath элемента как с использованием текста элемента, так и игнорируя текст. Сгенерированный xpath в 95% случаев получается стабильным. Также Object Spy предоставляет возможность ввести свой xpath и отображает найденные элементы.
Еще одна полезная функция у инспектора, позволяющая вызвать public методы объекта, — RunNativeAPICall. С ее помощью можно создавать и запускать скрипты на базе public-методов Native API класса этого элемента.
Как и многие другие средства, SeeTest позволяет тестировать мобильные приложения в режиме «Record and Replay». Я не сторонник этого подхода для автотестов: простота написания таких тестов иллюзорна. К счастью, у SeeTest есть и альтернативный вариант — использование библиотеки для взаимодействия с девайсами. Поддерживаются языки Java, Python, Perl, Ruby. Но, если пользователь слаб в разработке и затрудняется писать тесты, в SeeTest есть генерация кода под поддерживаемые языки и такие тестовые фреймворки, как TestNG или JUnit. Мы выбрали язык Java, развернули SeeTest, подключили девайсы и начали автоматизировать наш мобильный банк.
Процесс написания тестов оказался довольно простым и похожим на автоматизированное тестирование web’a. В качестве runner’а для тестов мы выбрали TestNG.
Каждый тест создается по следующей схеме:
В результате прогона формируется отчет, в котором сгруппированы все запущенные тесты. Страница Summary Report содержит статистику по запускам, название, длительность и результат каждого теста, и, если тест упал, то время падения и описание ошибки. В каждый тест можно перейти и посмотреть детальную информацию. По умолчанию все логи внутри одного теста падают подряд одним списком. Но, если тест хоть немного больше обычной авторизации на форме, объект Client имеет функционал для объединения тестов на группы. Группам можно дать внятное описание, их можно раскрывать и сворачивать, что позволяет легче работать с длинными отчетами.
Подключение большого количества устройств ограничено. Для разработки тестов необходимы лицензии разработчика на машину или на каждого конкретного пользователя. Для запуска тестов необходимы агенты (Executor Add-on). Агент не привязан строго к устройству, скорее thread для запуска тестов. Если необходимо задействовать больше пары-тройки устройств, Experitest предлагает использовать их device farm или развернуть локально SeeTestCloud. Cloud позволяет очень удобно мониторить и оперировать подключенными устройствами. Они отображаются в интерфейсе SeeTestAutomation: можно отслеживать какие подключены, какие заняты, доступны в данный момент, можно добавлять и удалять новые устройства. Для устройств, подключенных к Cloud, также можно в online-режиме наблюдать происходящие на телефоне действия.
Распараллеливание тестов реализовано, но сопряжено с некоторыми трудностями. Поскольку при запуске теста создается подключение к девайсу, объект Client имеет доступ к определенному устройству. Executor Add-on позволяет запускать на разных девайсах различные тесты одновременно, но для выполнения одного теста на разных устройствах необходимо провести распараллеливание самостоятельно.
Поддержка выгодно отличает платные решения. В SeeTest поддержка — весомый аргумент в пользу выбора именно этого инструмента для тестирования. При любых проблемах с настройкой, развертыванием, обновлением системы можно позвонить в call-центр, и специалисты все разъяснят и покажут. Если при тестировании был выявлен баг фреймворка, уведомите о нем разработчиков, и они создадут задачу на его исправление, сообщив о приблизительных сроках решения задачи.
Когда наша команда искала средство для автоматизации, признаюсь, SeeTest несколько пугал тем, что про него довольно мало известно, и в России он мало распространен. Но, начав использовать его, мы обнаружили, что это хорошее коробочное решение с гибкой конфигурацией под «свои» нужды и большим функционалом. SeeTest позволяет проводить и стандартные, и довольно экзотические манипуляции. Хотя мы все равно продолжаем исследовать open-source решения, пока они не полностью удовлетворяют нашим требованиям.
Мир не стоит на месте: еще десять лет назад пользователи выходили в интернет с помощью компьютера, а сегодня по статистике большая часть посещений приходится на мобильную версию сайта или мобильные приложения. Поэтому требования к стабильности и удобству использования этих приложений становятся выше.
В нашем банке мы тоже наблюдаем эту тенденцию: мобильное приложение по сравнению с интернет-банком используют на порядок больше пользователей. Поэтому остро встал вопрос автоматизации тестирования мобильного приложения. Несмотря на повсеместное использование мобильных приложений, средства для их автоматизированного тестирования далеко не идеальны. Кроме того, мы предъявляем к ним высокие требования. Например, самый популярный фреймворк Appium — open-source решение, поддерживающее платформы Android и iOS, — нам не подошел. Наши разработчики использовали много модных библиотек, и взаимодествовать с приложением иногда приходилось на более низком уровне. UI Automator и UI Automation оказались более сложными в развертывании, каждое приложение использовало свой язык для написания тестов, из-за чего возникали проблемы при перераспределении между платформами в команде автотестирования.
На старте процесса по автоматизации в нашей команде было два человека на два проекта и по 100 тест-сценариев на каждую платформу и довольно сжатые сроки. Мы искали решение, на разворачивание и доработку которого у нас бы ушло минимум времени. И еще мы надеялись, что решение быстро освоят новые сотрудники.
Что же выбрали мы?
Наше внимание привлекло малоизвестное решение от компании «Experitest» — SeeTest Automation. Это кросс-платорменное решение для тестирования. Система интегрируется с WebDriver (Selenium), HP UFT/QTP, JUnit, Microsoft Visual Studio и другими. SeeTest Automation поддерживает мобильные платформы iOS, Android и Windows, причем как для смартфонов, так и для планшетов.
Для подключения устройств используется простой и понятный интерфейс.
В интерфейсе есть список добавленных устройств. Для каждого устройства отображается его статус (online/offline), имя и версия операционной системы. Приложения для тестирования устанавливаются через этот интерфейс, и для каждого устройства можно увидеть установленные тестовые приложения и их версию.
У подключенных телефонов можно открыть экран и увидеть все происходящее на девайсе. В режиме разработчика девайс реагирует на управление мышью и клавиатурой. Отображение экрана обновляется автоматически в режиме реального времени. Также на экране девайса доступен инспектор (Object Spy), в котором можно посмотреть дерево элементов.
Здесь можно увидеть как базовые, так и добавленные атрибуты документов. Например, для элементов, которые сложно или невозможно идентифицировать по таким параметрам, как text, label или id, мы просим разработчиков задавать дополнительные тэги с уникальным значением.
Инспектор позволяет сгенерировать уникальный xpath элемента как с использованием текста элемента, так и игнорируя текст. Сгенерированный xpath в 95% случаев получается стабильным. Также Object Spy предоставляет возможность ввести свой xpath и отображает найденные элементы.
Еще одна полезная функция у инспектора, позволяющая вызвать public методы объекта, — RunNativeAPICall. С ее помощью можно создавать и запускать скрипты на базе public-методов Native API класса этого элемента.
Как и многие другие средства, SeeTest позволяет тестировать мобильные приложения в режиме «Record and Replay». Я не сторонник этого подхода для автотестов: простота написания таких тестов иллюзорна. К счастью, у SeeTest есть и альтернативный вариант — использование библиотеки для взаимодействия с девайсами. Поддерживаются языки Java, Python, Perl, Ruby. Но, если пользователь слаб в разработке и затрудняется писать тесты, в SeeTest есть генерация кода под поддерживаемые языки и такие тестовые фреймворки, как TestNG или JUnit. Мы выбрали язык Java, развернули SeeTest, подключили девайсы и начали автоматизировать наш мобильный банк.
Процесс написания тестов оказался довольно простым и похожим на автоматизированное тестирование web’a. В качестве runner’а для тестов мы выбрали TestNG.
От теории к практике
Каждый тест создается по следующей схеме:
- создаем объект Client, которому прописываем данные для подключения к девайсу. Этот объект будет своеобразной вариацией selenium-driver;
- на девайсе запускаем тестовое приложение;
- манипулируем приложением с помощью методов объекта client. Client позволяет кликать по элементам, вводить текст, считывать текст объектов. Он также умеет делать такие привычные для мобильных устройств действия, как swipe, long tap и другие. В последних версиях SeeTestAutomation появилась полезная функция synchronize, позволяющая дождаться полной загрузки экрана, не прибегая к нестабильным custom-решениям;
- на девайсе запускаем тестовое приложение;
- все вызовы методов объекта client логируем, каждый метод делает скриншот экрана, благодаря чему понятно, с каким элементом производилась манипуляция;
- если необходимо, добавляем вывод дополнительной информации. Например, можно вывести тестовые данные или сделать дополнительный скрин;
В результате прогона формируется отчет, в котором сгруппированы все запущенные тесты. Страница Summary Report содержит статистику по запускам, название, длительность и результат каждого теста, и, если тест упал, то время падения и описание ошибки. В каждый тест можно перейти и посмотреть детальную информацию. По умолчанию все логи внутри одного теста падают подряд одним списком. Но, если тест хоть немного больше обычной авторизации на форме, объект Client имеет функционал для объединения тестов на группы. Группам можно дать внятное описание, их можно раскрывать и сворачивать, что позволяет легче работать с длинными отчетами.
Лицензирование и масштабируемость
Подключение большого количества устройств ограничено. Для разработки тестов необходимы лицензии разработчика на машину или на каждого конкретного пользователя. Для запуска тестов необходимы агенты (Executor Add-on). Агент не привязан строго к устройству, скорее thread для запуска тестов. Если необходимо задействовать больше пары-тройки устройств, Experitest предлагает использовать их device farm или развернуть локально SeeTestCloud. Cloud позволяет очень удобно мониторить и оперировать подключенными устройствами. Они отображаются в интерфейсе SeeTestAutomation: можно отслеживать какие подключены, какие заняты, доступны в данный момент, можно добавлять и удалять новые устройства. Для устройств, подключенных к Cloud, также можно в online-режиме наблюдать происходящие на телефоне действия.
Распараллеливание тестов реализовано, но сопряжено с некоторыми трудностями. Поскольку при запуске теста создается подключение к девайсу, объект Client имеет доступ к определенному устройству. Executor Add-on позволяет запускать на разных девайсах различные тесты одновременно, но для выполнения одного теста на разных устройствах необходимо провести распараллеливание самостоятельно.
Поддержка
Поддержка выгодно отличает платные решения. В SeeTest поддержка — весомый аргумент в пользу выбора именно этого инструмента для тестирования. При любых проблемах с настройкой, развертыванием, обновлением системы можно позвонить в call-центр, и специалисты все разъяснят и покажут. Если при тестировании был выявлен баг фреймворка, уведомите о нем разработчиков, и они создадут задачу на его исправление, сообщив о приблизительных сроках решения задачи.
Заключение
Когда наша команда искала средство для автоматизации, признаюсь, SeeTest несколько пугал тем, что про него довольно мало известно, и в России он мало распространен. Но, начав использовать его, мы обнаружили, что это хорошее коробочное решение с гибкой конфигурацией под «свои» нужды и большим функционалом. SeeTest позволяет проводить и стандартные, и довольно экзотические манипуляции. Хотя мы все равно продолжаем исследовать open-source решения, пока они не полностью удовлетворяют нашим требованиям.
Поделиться с друзьями
Комментарии (9)
Artem_zin
24.03.2017 15:08Почему тесты занимают такое упоротое (2-4 минуты per test) количество времени на этом скриншоте?
Гоняете ли вы их на CI как часть проверок для каждого пулреквеста и с каким серверным окружением они у вас работают? (я подозреваю, что бекенд вы не мокаете)
Например, самый популярный фреймворк Appium — open-source решение, поддерживающее платформы Android и iOS, — нам не подошел. Наши разработчики использовали много модных библиотек, и взаимодествовать с приложением иногда приходилось на более низком уровне. UI Automator и UI Automation оказались более сложными в развертывании, каждое приложение использовало свой язык для написания тестов, из-за чего возникали проблемы при перераспределении между платформами в команде автотестирования.
И все таки непонятно, почему вам не подошел Appium? Он так же позволяет писать тесты на одном языке программирования для разных платформ и вот это всё, разве что нельзя вызывать нативный код, но это обходится, да и вообще странно брать тул для по сути black-box тестирования и вызывать руками код приложений :) Я не люблю Appium если что, просто интересно.
Спасибо за статью!
Neifmetus
24.03.2017 16:111) Каждый тест на скрине это целый тестовый сценарий, в него входит авторизация, оплата, создание шаблона, редактирование, поэтому и 2 минуты (ну и время теста может увеличиваться, когда мы ждем каких-либо экранов и нотификаций)
2) Вот именно вызов нативного кода — очень важно. По-другому в наших приложениях мы не можем получить баланс, суммы оплаты, а без этого тестировать банковское ПО невозможно
3) Запускаем тесты через Jenkins каждую ночью на выделенной машине на реальных девайсах, поскольку взаимодействие идет со всеми тестовыми системами, а по ночам они наиболее стабильны. Так же есть наборы smoke тестов, которые запускаются во время регресса после каждой новой сборки
asocial
24.03.2017 15:35А как обстоят дела с переходом IOS на XCUITest и, соответственно, с изменением всех локаторов у элементов с UITable, например, на XCUIElementTable? У вас же все xpath станут непригодными. Тот же Appium умеет подстраиваться под это автоматически, достаточно указать automationName = XCUITest, чем ответит SeeTest Automation?:)
Neifmetus
24.03.2017 16:14У SeeTest нет способа перейти на XCUITest. Зато SeeTest позволяет тестировать iPhone без компьютера с Mac OS. А что вам дал этот переход?
asocial
24.03.2017 16:48Xpath у вас генерится на основе UIAutomation, он заменен на xcuitest в xcode 8+, значит ли это, что ваши тесты не работают на ios10 (ведь сборку для ios10 поддерживает только xcode 8)?
Зато SeeTest позволяет тестировать iPhone без компьютера с Mac OS.
Вам же все равно нужна макось, чтобы собрать свое приложение перед тестированием:)
tinkoff_qa
24.03.2017 17:04Приложение собирают разработчики и выкладывают билд в hockeyApp. Experitest предоставляет файл Experitest.framework, который разработчики встраивали в приложение и для поддержки iOS10 мы этот фреймворк обновляли
Lexx918
27.03.2017 12:56Я не сторонник этого подхода для автотестов: простота написания таких тестов иллюзорна.
Но всё равно выбрали такое решение? Неужели профит на столько высокий? Во что выливаются изменения экранов и дерева элементов на них? А изменение flow различных процессов в приложении? Чем не устроил какой-нибудь WDA от Facebook'а в купе с кастомными PageObject'ами?
tundrawolf_kiba
Мы вот год его использовали, и нам не очень понравилось. Постоянно проблемы с xpath были, тех.поддержка их подтверждала, через 2-3 месяца фиксилось, но появлялись новый проблемы. С SQLite — приложение вообще падало. В итоге — отказались.