Appium — это инструмент с открытым исходным кодом для автоматизации, способный взаимодействовать с тестовым скриптом, сервером Appium и эмулятором или реальным устройством, на котором выполняется скрипт.
Этот хорошо зарекомендовавший себя фреймворк очень популярен для тестирования мобильных, веб- и гибридных приложений. Appium является кроссплатформенным, то есть пользователи могут использовать один и тот же API и писать тестовые скрипты, которые можно запускать на Android, iOS и Windows. Кроме того, этот фреймворк автоматизации поддерживает несколько языков программирования, таких как Python, Ruby, C#, PHP, JavaScript и Java. Appium был разработан как аналог Selenium для тестирования мобильных приложений, который является самым популярным фреймворком для автоматизации тестирования веб-приложений.
Чтобы использовать весь потенциал Appium, важно знать об основных «подводных камнях», с которыми придется столкнуться в начале работы с фреймворком, а также внутренние возможности Appium. В данном руководстве мы рассмотрим несколько лучших практик, которые помогут QA-специалистам оптимизировать тесты в Appium.
Лучшие практики: тестирование с помощью Appium
1. Распараллеливание
Цель автоматизации тестирования — сделать тесты более быстрыми, менее подверженными ошибкам и менее трудоемкими. Поэтому запуск тестовых скриптов на одном устройстве за раз кажется необоснованным, так как это отнимает больше времени и ресурсов. При автоматизации тестирования всегда следует по возможности запускать тестовый скрипт на максимальном количестве устройств, поскольку это позволяет выявить проблемы совместимости, мгновенно получить результаты и быстро решить все найденные проблемы.
Многопоточность — это принципиальная концепция, без которой невозможно написать эффективные программы с быстрым временем выполнения. Точнее говоря, многопоточность позволяет программисту делегировать задачи множеству различных потоков, выполняя их параллельно и тем самым значительно сокращая время выполнения программы. Хорошей иллюстрацией к этому может служить ситуация постройки дома одним человеком: он должен сначала срубить деревья, потом подготовить бревна, затем выровнять площадку, на которой дом будет строиться, и так далее. Однако теперь представим, что этот же дом строят 20 человек, каждый из которых может взять на себя одну задачу — совместная работа позволит им завершить строительство гораздо быстрее.
Одним из наиболее эффективных методов ускорения процесса автоматизации тестирования является параллельное тестирование. Метод распараллеливания часто используется в автоматизированном тестировании и по своей концепции схож с многопоточностью. Под распараллеливанием понимается одновременное выполнение множества автоматизированных тестовых скриптов для различных конфигураций окружения и устройств как локально, так и в рамках CI/CD-пайплайна разработчика.
Понятно, почему распараллеливание является популярным подходом при автоматизации тестирования. Благодаря нему тестирование и разработка становятся более гибкими, что позволяет создать более надежные и качественные тестовые скрипты. Кроме того, отказ от последовательного выполнения тестов позволяет сэкономить значительное количество времени без какого-либо ущерба для качества тестов.
2. Использование правильных локаторов
Чтобы успешно протестировать все компоненты приложения, QA-инженеры должны знать различные стратегии использования локаторов. Ведь если скрипты не смогут обнаружить нужные элементы, то весь процесс автоматизации окажется бесполезным.
Читайте по теме: Краткая шпаргалка по локаторам XPath
Одной из часто встречающихся грубых ошибок, допускаемых при написании тестовых скриптов, является чрезмерное использование локаторов XPath. XPath можно использовать двумя способами:
Абсолютный XPath: Это абсолютный путь к элементу и очень специфичен для него. Он задает путь от корня к элементу. Звучит неплохо, однако недостатком использования этой стратегии локализации является то, что любое изменение в приложении может привести к изменению абсолютного XPath элемента, а значит, тестовый скрипт необходимо будет обновлять каждый раз, когда происходят какие-либо изменения. Это очень утомительно и непрактично.
Относительный XPath: Этот путь начинается не с корневого, а с нужного элемента; таким образом, если в приложение будут внесены какие-либо изменения, элемент все равно можно будет найти.
Таким образом, из двух вариантов лучше использовать относительный. Однако XPath не рекомендуется использовать в тестовых скриптах из-за того, что он очень медленно находит нужный элемент при выполнении. Кроме того, в разных браузерах этот показатель различается, причем выполнение тестового скрипта, как правило, медленнее всего происходит в Internet Explorer. Причина этого заключается в том, что браузеры используют различные механизмы и правила рендеринга, что приводит к различиям во времени выполнения тестовых скриптов с локаторами XPath.
Более эффективной альтернативой селекторам XPath являются идентификаторы доступности. Эти локаторы широко используются в тестовых скриптах для приложений Android и iOS, и они более простые и быстрые в использовании по сравнению с XPath.
3. Использование POM (Page Object Model)
Со временем в любое приложение обычно вносятся значительные изменения. С развитием приложения локаторы, соответствующие определенным элементам, также обновляются и, соответственно, становятся неактуальными в ранее написанных тестовых скриптах. Это может быть очень утомительно и потребовать от тестировщиков больших затрат времени.
Эту проблему можно легко решить, используя для создания тестовых скриптов паттерн проектирования Page Object Model. В данном случае тесты взаимодействуют с пользовательским интерфейсом страницы с помощью методов класса page object. Благодаря использованию паттернов проектирования POM при изменении пользовательского интерфейса страницы необходимо изменять только код, входящий в состав объекта page, а сами тесты не нуждаются в модификации. В результате локаторы, используемые в тестовом скрипте, и сам тестовый скрипт оказываются разделены. Это гарантирует, что изменения в локаторах не приведут к масштабному переписыванию всех тестовых скриптов.
Преимуществом является то, что при изменении пользовательского интерфейса страницы нужно обновлять только код, входящий в объект page. Таким образом, все модификации для поддержки нового пользовательского интерфейса можно найти в одном месте.
4. Выполнение тестов на реальных устройствах
Количество выпускаемых устройств с каждым годом существенно растет. Эта проблема, называемая фрагментацией устройств, является одной из основных задач каждой QA-команды. Чтобы не упустить ни одного потенциального клиента, необходимо обеспечить работоспособность и надежность приложения на нескольких различных комбинациях устройств/ОС/браузеров.
Есть два варианта проведения тестирования на различных устройствах:
Использование эмуляторов и симуляторов: Хотя эмуляторы/симуляторы обычно проще в настройке и считаются более экономичными, они не являются лучшим выбором для подтверждения функциональности приложения. Дело в том, что эмуляторы не всегда работают и ведут себя так, как могло бы работать реальное устройство, поэтому выполнение тестовых скриптов на них не гарантирует работоспособности на реальном устройстве.
Использование реальных устройств или облака реальных устройств: Основным недостатком при проведении тестов на реальных устройствах является то, что настройка устройства и установка нескольких программ может занять много времени. К счастью, есть и другой вариант: использовать облачную платформу.
Тесты Appium рекомендуется проводить в облаке реальных устройств. Имея 3000+ реальных комбинаций устройств и браузеров, QA-инженер может всесторонне протестировать мобильное приложение с помощью BrowserStack App Automate и быть уверенным в его функциональности на тысячах реальных устройств.
5. Использование ожиданий
Функциональность любого тестового скрипта полностью зависит от того, сможет ли он точно определить элементы приложения и автоматизировать различные тест-кейсы в соответствии со спецификациями, предоставленными командой разработчиков ПО. Если правильные элементы не могут быть найдены, то тест будет давать ложноотрицательный результат.
Очень распространенной причиной неточного определения местоположения элемента в тесте, помимо использования неправильных локаторов, является неиспользование команд ожидания. Если приложение загрузилось не полностью или по какой-то причине происходит задержка между страницами, скрипт не сможет использовать локатор для поиска элемента. Для таких сценариев важно реализовать команды ожидания.
Есть два основных типа ожидания:
Явное ожидание (explicit): явная команда ожидания указывает драйверу Appium на необходимость подождать, пока элемент не будет найден, прежде чем переходить к следующей строке кода.
Неявное ожидание (implicit): команда неявного ожидания указывает драйверу Appium на необходимость ожидания в течение определенного времени при многократном поиске заданного элемента до тех пор, пока он не будет найден или пока не истечет время. Если команде задан список из нескольких элементов, то она будет искать их на странице до тех пор, пока не будет найден хотя бы один элемент или не истечет заданное время.
6. Использование логов Appium
Серверный продукт «Сервер Appium Server» является сервером, который имеет возможность построения системы с подробным логированием и отчетами. Многие считают логи Appium несколько устрашающими: при запуске тестового скрипта появляется запутанный поток логов, содержащих информацию о выполняемом тестовом скрипте, но детали зачастую непонятны и загадочны.
В связи с этим логи в Appium полезно научиться читать и использовать. Логи очень информативны и раскрывают такие детали:
В логах часто содержится стек-трейс, связанный с ошибками, произошедшими во время выполнения теста. Это может стать хорошей отправной точкой при отладке и выявлении ошибок, которые необходимо исправить в приложении или тестовом скрипте.
Также в логах видны желаемые и заданные по умолчанию настройки, указанные в тесте. Эти настройки можно использовать для понимания и модификации поведения сервера Appium.
Чтобы сохранить краткость строк логов, в логах по умолчанию не указываются временные метки. Однако если запустить сервер Appium с параметром -log-timestamp, то в начало каждой строки будет добавлена временная метка. При попытке выявить причины медленной работы или потенциальные ошибки это очень полезно, поскольку строки с большим временем выполнения можно легко идентифицировать.
Заключение
Appium — это фреймворк для автоматизации, который помогает тестировщикам выявлять ошибки на ранних этапах разработки и снижает трудозатраты на ручное тестирование. Перечисленные в статье практики помогут получить максимальную отдачу от этого фреймворка и сделать тестирование мобильных устройств более эффективным и надежным.
Материал подготовлен в преддверии старта онлайн-курса "Java QA Engineer. Professional". Также в рамках курса 3 августа пройдет бесплатный открытый урок «REST Assured & JSON Schema Validator», на котором своим опытом поделится Сергей Мирошин, Senior QA Automation Engineer.
На этом занятии рассмотрим, как можно автоматизировать API. Поговорим об инструменте REST Assured, который позволит нам автоматизировать тестирование API. А также познакомимся с JSON Schema Validator для валидации ответа сервера. Присоединяйтесь!