Gui — Автоматическое тестирование Android app (интерфейс, камера)


Содержание

Automated GUI testing: пошаговая инструкция

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

Тестирование — это неотъемлемая часть разработки ПО, цель которой — своевременное представление информации о качестве продукта группе заинтересованных лиц. Автоматизация тестирования — часть процесса тестирования с использованием программных средств для выполнения тестов и проверки результатов.

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

Преимущества автоматизации тестирования

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

Уровни тестирования

Существует несколько уровней тестирования:

  • Unit tests;
  • Integration tests;
  • GUI tests;
  • Manual tests.

Unit и Integration tests оставим разработчикам, с Manual тестами все понятно. Давайте остановимся более подробно на GUI-автоматизации, набирающей популярность огромными темпами.

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

Место автоматизации GUI в процессе разработки

Для успешного тестирования с применением автоматизации необходимо определиться с местом автотестов в процессе разработки. Поскольку при помощи автоматизации GUI покрываются в основном регрессионные сценарии, то есть смысл запускать тесты для каждой новой сборки. Для этого мы используем Jenkins. После каждого успешного билда автоматически стартует сборка проекта с тестами. Также есть возможность ручного запуска или по расписанию, для запуска тестов ночью — в момент минимальной нагрузки на тестовые стенды.

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

Путем проб и ошибок мы в Ukad пришли к следующему инструментарию для GUI автоматизации:

  • Java — как язык для написания тест-скриптов.
  • Maven — для сборки проекта.
  • Selenide — как фреймворк для написания GUI тестов.
  • TestNG — как фреймворк для управления запуском тестов.
  • Selenoid — для непосредственного управления сессиями браузера.
  • Allure — для создания и эффектной презентации отчета.
  • Jenkins — для непрерывной интеграции тестов в процесс разработки.

Более подробно об инструментах и причинах, почему мы выбрали именно этот набор:

  • Java. Мы используем Java, так как это путь наименьшего сопротивления ведь сообщество просто огромно, что дает доступ к большому количеству готовых решений для тестирования и не только. Это в свою очередь позволяет не тратить много времени на исследование и решение часто возникающих проблем, так как очень велика вероятность того, что решение уже найдено.
  • Maven. Можно использовать любой другой сборщик. Для автотестов это не принципиально, но лично мне Maven ближе.
  • Selenide позволяет не изобретать свой велосипед для решения стандартных проблем Selenium (таких как ожидания и поиск элементов на странице, добавление «мягких» проверок и т. д.) и значительно повысить скорость разработки и стабильность тестов.
  • TestNG. Мы перешли с Junit на TestNG для использования наборов на основе .xml файлов, а также возможности объединения тестов в группы.
  • Selenoid. Мы используем Selenoid вместо Selenium Hub, так как он более стабилен и позволяет запускать сессии браузеров в Docker контейнерах, плюс добавляет такие приятные бонусы, как просмотр выполнения конкретного теста и запись видео его прохождения.
  • Allure. Позволяет значительно расширить возможности стандартного TestNG отчета, эффектно и удобно презентовать всю информацию о пройденных сценариях. В репорте каждый член команды сможет найти для себя полезную информацию. Начиная от времени и количества пройденных сценариев с результатами прохождения, до прикрепленного видео прохождения и скриншотами для упавших тестов.
  • Jenkins. Мы используем Jenkins для сборки некоторых своих проектов, поэтому мы решили использовать его же для сборки тестов. Также с Jenkins удобно интегрировать Allure репорты при помощи дополнительного плагина.

Пример использования GUI автоматизации

Создаем проект с тестами

Рассмотрим, как используется GUI автоматизация на примере простого теста. Для этого создадим Maven-проект и подключим необходимые зависимости для Selenide, TestNG и Allure. Добавим простой тест, который будет открывать главную страницу сайта и проверять, что футер отображается. Для написания теста используется PageObject паттерн. Для управлением драйверами браузера используется WebDriverManager.

Актуальный pom.xml и исходный код проекта доступен по ссылке.

Проект может быть запущен командой «mvn test» (Maven должен быть установлен и добавлен к системным переменным). Все работает, но тест будет запущен в локальном браузере, а нам необходимо запускать на тестовом стенде. Самые популярные варианты удаленного запуска тестов — Selenium hub и Selenoid. Остановимся подробнее на Selenoid.

Selenoid

Selenoid — это имплементация Selenium hub кода, использующая Docker-контейнеры для запуска браузера, что позволяет нам не задумываться об управлении браузерами и сессиями. Для каждого теста будет запущен свой Docker-контейнер, который будет остановлен после окончания теста. После установки Selenoid (по ссылке доступна подробная инструкция по установке) нам только остается подправить код создания драйвера на код предложенный Selenoid.

Снова запустим наш проект командой “mvn test” .

Тест работает. Но что если мы хотим видеть выполнение теста? Для этого достаточно добавить дополнительный параметр в создание браузера и использовать Selenoid контейнеры с поддержкой VNC, например “selenoid/vnc:chrome_66.0” для 66 версии Chrome. Также нужно добавить дополнительную Capability к созданию браузера “browser.setCapability(«enableVNC», true);” .

Вот так выглядит browser.json после обновления. Для простоты я оставил только Chrome 66 версии.

Также добавим дополнительную Capability к созданию драйвера “browser.setCapability(«enableVNC», true);” .

Запустим наш тест еще раз и перейдем на вкладку «Session». Теперь мы можем следить за выполнением теста.

Но для эффективного использования автотестов необходима непрерывная интеграция с процессом разработки. Для этого мы используем Jenkins.

Jenkins CI

Jenkins — проект для непрерывной интеграции с открытым исходным кодом, написанный на Java. Используется для сборки и поставки программного обеспечения. У нас есть возможность использовать Jenkins для запуска тестов для каждой новой сборки тестируемого продукта. Для создания тестовой сборки нам необходимо установить дополнительные плагины:

  • Maven Integration — для более удобной интеграции с Maven.
  • Allure Jenkins Plugin — для генерации и отображения отчета.

Создадим новую Jenkins job с типом «Maven project».

Добавим наш репозиторий с тестами в секцию «Source Code Management».

Для генерации Allure отчета добавим «Post-build Actions» -> «Allure report».

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

А вот и Allure отчет.

Финальная стадия интеграции — связываем нашу тестовую сборку со сборкой нашего тестируемого приложения путем добавления в «Build Triggers» — > «Project to watch».

Таким образом после каждой успешной сборки тестируемого проекта мы автоматически запускаем сборку тестов. Остается только оповестить о результатах теста заинтересованную группу людей путем отправки Email или Slack-уведомлений.

Полезные ссылки

  • официальная документация Selenide;
  • официальная документация TestNG;
  • официальная страница Maven;
  • официальная документация Selenoid;
  • официальная документация Allure;
  • официальная документация Jenkins;
  • Иван Крутов «Selenoid: запускаем Selenium тесты в Docker контейнерах» — обзорный доклад о Selenoid от одного из разработчиков;
  • Allure 2: new gen test report tool — обзорный доклад по Allure 2 от разработчика.

Вывод

По мере усложнения кода, добавления нового функционала и исправления багов, процесс тестирования будет занимать все больше времени. Команда мануального тестирования физически не сможет успевать за ритмом команды разработчиков. Ведь проверка нового функционала — это не только функциональные тесты, но и ресурсоемкие регрессионные прогоны. Внедрение автоматизированного тестирования позволяет снять с команды мануального тестирования достаточно объемную часть регрессионных прогонов. Но следует помнить, что ни полная автоматизация, ни стопроцентное ручное тестирование не дадут гарантии идеального результата. Оптимальным подходом в данном случае является разумный баланс.

Задача автоматизации — не только в создании автоматизированных сценариев, но также в непосредственной интеграции в процесс разработки ПО.

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

Тестирование Android приложений

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

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


  • размером и разрешением экрана;
  • версией Android;
  • форм-фактор устройства;
  • системы команд процессора;
  • фронтальная камеры, NFC, внешняя клавиатура и т.д.

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

Автоматическое тестирование приложений для Android

Рассмотрим несколько средств для автоматического тестирования функциональности, которые входят в состав Android SDK или распространяются с открытым исходным кодом.

Принцип автоматического тестирования приложений

Наша задача — с наибольшей точностью автоматизировать действия, выполняемые вручную. Рассмотрим эти действия. Будем использовать несколько приложений и несколько устройств с Android. Для каждого приложения и каждого устройства нужно выполнить следующие действия:

  • Установить приложение на устройство
  • Запустить приложение
  • Протестировать приложение, используя выбранный метод
  • Удалить приложение
  • Сбросить устройство в исходное состояние
  • На каждом этапе нужно собирать и анализировать данные (журналы и снимки экрана). Ниже описываются средства для автоматизации этих действий.
  • Управление устройствами Android

Прежде всего необходимо выбрать компьютер, который будет использоваться для запуска автоматических тестов, и установить на нем Android SDK. В данном примере мы используем настольный компьютер с операционной системой Linux*. На каждом устройстве необходимо отключить экран блокировки и увеличить «время перед переходом в спящий режим» до максимального значения. Для некоторых методик тестирования также нужно отключить изменение ориентации экрана. В составе Android SDK предусмотрено две программы для управления устройствами с Android: ADB и monkeyrunner* ADB (Android Debug Bridge) — это программа командной строки для управления устройствами с Android.

Методы автоматического тестирования Android

Тестирование с помощью Monkey*

Предположим, что тестируемое устройство попало в лапы крайне любопытной и деятельной обезьяны: программа Monkey имитирует именно такую ситуацию. Программа Monkey, входящая в состав Android SDK, отправляет поток случайных действий пользователя. В командной строке можно указать количество действий пользователя, долю действий каждого типа и имя пакета (чтобы программа Monkey не вышла за пределы тестируемого приложения и не начала, к примеру, рассылать SMS-сообщения всем контактам из адресной книги).

Основное преимущество Monkey в отсутствии затрат на обслуживание. К тому же нагрузочное тестирование может выявлять сложные и малозаметные ошибки.

Недостатки тестирования с помощью Monkey:

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

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

Тестирование с помощью MonkeyRunner

MonkeyRunner позволяет не только создавать сценарии для управления устройствами с Android, но и создавать сценарии для тестирования приложения на определенном устройстве. Основное преимущество – гибкость, а недостаток в сложности написания скриптов, даже в простых случаях. Создание скриптов monkeyrunner занимает немало времени, поэтому обычно этот метод использовать нецелесообразно. Но в некоторых случаях его применение может оказаться весьма полезным.

Тестирование с помощью getevent и sendevent

Программы getevent и sendevent позволяют пользователю записывать последовательность действий и затем воспроизводить ее. Для запуска этих программ не требуются права доступа root.

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

Тестирование с помощью Robotium

Robotium не входит в состав Android SDK, эта программа распространяется с открытым исходным кодом. Сценарии Robotium определяют действия на уровне пользовательского интерфейса приложений, а не на уровне устройства ввода. Например, в сценарии требуется коснуться кнопки «ОК». В этом случае скрипт monkeyrunner будет построен следующим образом: «имитировать касание экрана в точке с координатами (x0, y0)». Скрипт Robotium будет построен иначе: «нажать кнопку с текстом «ОК».

Описание действий на уровне интерфейса позволяет сделать тестовый скрипт независимым от расположения и размеров элементов интерфейса, разрешения и ориентации экрана. Кроме того, в Robotium можно проверять реакцию приложения на действия. Например, предположим, что после нажатия кнопки «ОК» должен появиться список с элементом «Элемент 1». В Robotium можно проверять имена элементов списков. Проверка состояния приложения после каждого шага позволяет с легкостью находить шаг, на котором произошла ошибка.

  • Для каждого приложения требуется разрабатывать тестовый сценарий на языке Java*. Для этого требуется время и навыки программирования;
  • При смене интерфейса приложения потребуется переделать последовательность событий;
  • Создавать сценарии Robotium сложнее, чем записывать события с помощью getevent / sendevent;

В целом, Robotium позволяет создавать тестовые сценарии высшего качества с разумными затратами.

Сравнение методов тестирования мобильных приложений

Метод тестирования Преимущества Недостатки
Monkey — поток случайных действий пользователей Затраты на обслуживание отсутствуют.

Независимость от устройства.

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

Сложно воспроизводить последовательность действий, вызвавших ошибку, в отчетах об ошибках.

Monkey не проверяет состояние приложения во время тестирования. MonkeyRunner — скрипт для управления устройством Гибкость Сложность написания сценариев, даже для простых приложений. Getevent/sendevent — запись и воспроизведение действий пользователя Для записи последовательности событий не требуются навыки программирования. Записанная последовательность действий подойдет только для одного устройства при фиксированной ориентации экрана.

При смене интерфейса приложения необходимо переделывать последовательность событий.

Этот метод не проверяет состояние приложения во время тестирования. Robotium — API тестовых скриптов для проверки состояния Действия описываются на уровне пользовательского интерфейса приложения.

Скрипт может не зависеть от разрешения и ориентации экрана.

Скрипт может проверять состояние приложения после действий. Сложность написания сценариев на языке Java.

При изменении интерфейса приложения необходимо переделывать скрипт.

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

Ручное тестирование Android приложений

Рассмотрим ручное функциональное тестирование. Тестировщик устанавливает на устройство приложение, вдумчиво проверяет всю функциональность, затем возвращает устройство в первоначальное состояние. И так для каждого приложения и каждого устройства. Очевидный недостаток такого способа – большие затраты времени для регулярного тестирования.

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

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

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

Особенности альфа/бета тестирования в консоли разработчика Google Play

В консоли разработчика Google Play можно выбирать группы пользователей для альфа- и бета-тестирования различных версий приложения, после чего поэтапно внедрять обновления.

Что нужно знать перед началом тестирования

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

  • Присоединиться к группе тестировщиков может только пользователь с аккаунтом Google (@gmail.com) или Google Apps;
  • При тестировании опубликованного ранее приложения обновление его альфа- и бета-версии получат только тестировщики. И только они смогут найти и скачать приложение, которое вы публикуете и проверяете впервые;
  • Если вы впервые публикуете файл APK альфа- или бета-версии, ссылка станет доступна пользователям в течение нескольких часов. Примерно такое же время требуется, чтобы тестировщики смогли увидеть изменения, внесенные вами в уже опубликованную версию;
  • Любые изменения на странице Цены и распространение (в том числе значения платное или бесплатное) применяются ко всем версиям приложения, включая тестовые, рабочие и будущие.

Мы рекомендуем начать с маленькой группы альфа-тестировщиков, а затем перейти к бета-тестированию с участием большего количества пользователей. Файлы дополнений можно тестировать с помощью альфа-канала распространения в консоли разработчика. Для тестирования нельзя использовать черновики, то есть файл APK должен быть опубликован как альфа-, бета- или рабочая версия. Файлы дополнений нельзя добавлять для первого загруженного файла APK нового приложения.

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

GUI Тестирование Android App

November 2020

511 раз

я занимаюсь разработкой Andriod приложения. О развитии GUI, я выдавать, как проверить, если GUI работает на разных телефонах Android (я имею в виду с различным размером экрана, плотность и т.д.). Как я могу проверить, все ли правильно?

4 ответы


You are asking for the hardest thing to do in Android development :)

  1. Read Supporting Multiple Screens.
  2. If you are targeting motorola devices, here are a bunch of SDK addons for the emulator.
  3. If you need to test a specific device, you can try using perfectomobile.

Can’t you test that with the emulator?

You’ll have to create multiple AVDs («Android Virtual Devices») with the settings you want for Resolution, Density and so on.

You can test your android app. without using any mobile phone.. Just go through the link(if your app is using flash) here..

I usually use two steps:

  1. Create a few emulators with different screen-sizes and versions of Android.
  2. After succesfully testing step 1 I hand out my app to some friends with different Android phones and let them test my app.

TDD и Android

Содержание статьи

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

В отладке программного обеспечения действует так называемый принцип Парето — в данном случае он может быть сформулирован как
«На отладку 20%-ного кода уходит 80% общего времени отладки». Попробуем разобраться, почему так происходит. Предположим, существует программа, выполняющая некоторые расчеты. Также предположим, что в изначальной версии программы третий метод не был реализован (и, соответственно, не был учтен при проектировании архитектуры ПО).

Однако в следующей версии программы понадобилось его добавить.

Как видно из блок-схемы, третий метод очень трудно отлаживается, и в случае, если программист допустит ошибку, найти ее при отладке будет очень сложно, так как из-за условного оператора этот метод будет вызываться крайне редко. Одним из выходов может быть написание небольшой отдельной программы для тестирования этого метода. Однако он не профессионален и зачастую слишком сложен — к примеру, если этот метод зависит от других классов. Для того чтобы избежать таких проблем, следует использовать модульное тестирование.

Модульное тестирование (англ. unit testing) — один из методов тестирования программного обеспечения, при котором пишется отдельный набор тестов для каждого класса, состоящий из тестов для каждого метода, объявленного в тестируемом классе. Подобная техника заменяет большую часть отладки и значительно упрощает разработку приложения как на конечных, так и на начальных стадиях, потому что позволяет проверить все случаи поведения каждого метода тестируемого класса, что зачастую не представляется возможным при
«ручной» отладке.

К примеру, если требуется перебрать все значения у аргумента функции типа int32, — у модульного теста это займет несколько минут, а тестировщик вряд ли вообще сможет справиться с этим заданием. Для еще большего упрощения и ускорения разработки рекомендуется использовать методологию разработки, называемую
«Разработка через тестирование». Разработка через тестирование, или TDD (англ. Test Driven Development), — один из видов экстремального программирования. Если в классических методах разработки сначала пишется программный код, а потом (при условии использования модульных тестов) — тесты, то в TDD сначала пишутся модульные тесты, и только потом тестируемые классы и методы реализуются в программном коде. Несмотря на то, что этот метод относится к экстремальному программированию, и, на первый взгляд, кажется абсурдным, он все чаще используется при разработке крупных программных продуктов.

Требования, предъявляемые к программному коду при разработке через тестирование

  • Код должен быть разделен на как можно более мелкие части
  • Должен выполняться принцип «один тест — одно действие», то есть один test case не должен проверять правильность выполнения более чем одного действия. Инициализация объектов должна производиться вне тестов.
  • Желательно выполнение принципа «один тест — один метод», то есть test case должен содержать 1-2 строки кода.
  • Должны быть соблюдены уровни абстракции классов программы, то есть логика программы не должна быть привязана к интерфейсу программы.

Преимущества разработки через тестирование

  • Отделение логики программного продукта от интерфейса пользователя
  • Как следствие из предыдущего пункта — упрощение процедуры повторного использования кода в других программных продуктах
  • Упрощение отладки, поддержки и доработки программного кода за счет разделения его на небольшие части
  • Меньшая вероятность неожиданного поведения программы

Роберт Мартин, известный специалист в области экстремального программирования, предлагает использовать следующий алгоритм TDD:
«Сначала нужно добиться, чтобы код хоть как-то работал, и только потом улучшать его». На практике эта рекомендация выглядит следующим образом:

  1. Написать модульный тест для какого-либо метода (на данный момент еще не реализованного). Вследствие того, что метод еще не реализован, тестовый проект даже не скомпилируется.
  2. Написать «заглушку» для этого метода. К примеру, если метод должен возвращать переменную типа boolean,
    то он должен содержать только строку вида «return false» (в случае, если при правильном выполнении метода должен быть возвращен true), то есть заглушка должна возвращать такое значение, чтобы тест
    «не проходил». Теперь тестовый проект компилируется, но тест по понятной причине не выполняется.
  3. Реализовать метод алгоритмически правильно, но не пытаться улучшить его — требуется просто сделать
    «чтобы работал». Убедиться, что все тесты проходят.
  4. Усовершенствовать код — привести к наиболее удобочитаемому виду, разбить метод на более мелкие части. Убедиться, что все тесты проходят.
  5. Перейти к реализации следующего метода.

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

В задачах, выполняющихся слишком долго. К примеру, метод, выполняющий запрос к БД, лучше исключить из списка тестируемых, потому что все тесты должны выполняться каждый раз при запуске тестирования, и если тест выполняется долго — программист будет стремиться отключить его. Если нужно протестировать метод, разбирающий ответ от БД, то лучше отделить этот метод непосредственно от запроса, и передавать ему заранее подготовленные
«фальшивые» данные.

Как это выглядит на практике?

В качестве примера мы напишем приложение (и модульные тесты к нему) для ОС Android. Этот пример частично актуален не только для Android, но и для любой платформы, поддерживающей Java. Тестовое приложение будет принимать от пользователя массив точек и принимать решение, расставлены ли они в правильном порядке, возвращая true или false. Логика расстановки проясняется, если представить, что на первой точке написано, к примеру,
«1», на второй — «2», на третьей — «3» и т.д.

Точки могут располагаться в ряд, в столбик или в смешанном порядке.

Для начала нужно создать проект для Android (подразумевается, что у тебя уже установлена среда разработки, к примеру, Eclipse, а также плагин ADT и Android SDK)
и тестовый проект. Для того чтобы создать тестовый проект, нужно в диалоге
создания проекта нажать кнопку «Next» и отметить чекбокс «Create a test project».

Теперь можно приступить к написанию модульного теста. В тестировании Java-приложений стандартом де-факто считается JUnit. JUnit также включен в Android SDK, соответственно, тестирование приложений на Android производится именно при помощи этой библиотеки.

Тестирование логики

Сначала создается TestSuite для проекта (его код модифицировать не нужно), а потом — TestCase для каждого класса. В нашем случае класс всего один, и в нем содержится всего один открытый метод (статический). Напишем два теста — первый будет передавать заведомо верный список точек, второй — заведомо неверный.

public void testValidOrder()
<

points = new ArrayList

points.add(new Point(0, 0));

points.add(new Point(1, 0));

points.add(new Point(2, 0));

points.add(new Point(3, 0));

boolean result = Matrix.orderIsRight(points);

assertTrue(result);
>
public void testInvalidOrder()
<

points = new ArrayList

points.add(new Point(0, 0));

points.add(new Point(3, 0));

points.add(new Point(1, 0));

points.add(new Point(2, 0));

boolean result = Matrix.orderIsRight(points);

Прошу обратить внимание, что каждый тест должен начинаться со слова test, иначе он не будет распознан JUnit как… ну, в общем, как тест :). Чтобы запустить выполнение тестов, нужно нажать + .

Однако тесты даже не запустятся, потому что класс Matrix не содержит метода orderIsRight().
Теперь следует написать заглушку для этого метода, состоящую из одной строчки: «return false». Тесты запустятся, но их поведение будет немного странным: первый тест не будет пройден, а второй — будет. Сначала нужно добиться прохождения первого теста, и только потом браться (если, конечно, потребуется) за второй.

Реализуем метод orderIsRight() следующим образом:

public static boolean orderIsRight(
final List

pPoints)
<
Point firstPoint = pPoints.get(0);
for (int i = 1; i

Метод pointsAreInWrongOrder() — закрытый статический, состоящий из одной строки:

return (pFirstPoint.x >= pSecondPoint.x);

Нетрудно догадаться, что он возвращает true, если первая точка находится правее, чем вторая (либо перекрывает ее). Запускаем тесты — они проходят. Отлично, на этом тестирование логики приложения можно считать законченным. Теперь можно приступить к тестированию графического интерфейса.

Тестирование GUI

Графический интерфейс — крайне важная часть любого ПО. Если пользователю не понравится GUI — он, скорее всего, не будет использовать программу, какая бы мощная
«начинка» не содержалась внутри. Тестирование GUI должно быть не менее тщательным, чем тестирование логики программы, причем тестирование желательно максимально автоматизировать — только так можно покрыть наибольшее количество возможных вариантов действий пользователя. Конечно же, программист может протестировать интерфейс вручную, но здесь есть один нюанс. Дело в том, что программист тестирует приложение с точки зрения программиста, а не пользователя, и ему, в отличие от пользователя, может просто не прийти в голову, что можно ввести символьную строку в поле для ввода чисел.

В Android SDK есть инструментарий для тестирования графического интерфейса, в который включен класс ActivityInstrumentationTestCa se2. Его следует наследовать при написании модульных тестов для GUI. Стоит обратить внимание на то, что ActivityInstrumentationTest Case2 — это шаблонный класс, т.е. использовать его следует в виде class MainActivityTest extends ActivityInstrumentationTestCase2 .


Наше приложение содержит одну Activity (MainActivity), ее мы и будем тестировать. Как она выглядит, можно увидеть на рисунке на предыдущей странице.

Я использую отладку на устройстве с Android 2.3.4 через Wi-Fi. Кстати говоря, отладка по Wi-Fi очень удобна по сравнению с отладкой по кабелю и, тем более, в эмуляторе. Для того чтобы отлаживать приложения подобным образом, нужно установить виджет Adb over Wi-Fi из Android Market (подходит только для телефонов с правами root). После запуска нужно подключиться к устройству. Например, следующим образом:

adb connect 192.168.1.5:31337

Тестирование GUI выглядит приблизительно так же, как и тестирование логики приложения. Создается класс, в нем создается метод setUp(), в котором инициализируются объекты. Объекты, представляющие Activity, поля для ввода текста и кнопку следует сделать закрытыми полями:

private Activity mActivity;
private EditText mEditText1;
private EditText mEditText2;
private EditText mEditText3;

Инициализируются они следующим образом:

protected void setUp() throws Exception
<
super.setUp();
mActivity = getActivity();
mEditText1 = (EditText)mActivity.findViewById
(com.example.matrix.R.id.editTextLine1);

mTextView = (Button)mActivity.findViewById(com.example.matrix.R.id.textView);
>

В первую очередь нужно проверить, создались ли элементы интерфейса:

public void testControlsCreated()
<
assertNotNull(mActivity);
assertNotNull(mEditText1);

assertNotNull(mTextView);
>

Этот тест проходит без ошибок, но лучше перестраховаться и выполнять его всегда — он может не проходить, если, к примеру, у какого-либо элемента неправильно задано какое-то свойство. В полях для ввода указываются координаты точки через пробел, а в textView появляется результат (OK или NOT OK).

Напишем модульный тест для просчета:

public void testValidData()
<
TouchUtils.tapView(this, mEditText1);
sendKeys(KeyEvent.KEYCODE_0, KeyEvent.KEYCODE_SPACE,
KeyEvent.KEYCODE_0);
TouchUtils.tapView(this, mEditText2);
sendKeys(KeyEvent.KEYCODE_1, KeyEvent.KEYCODE_SPACE,
KeyEvent.KEYCODE_0);
TouchUtils.tapView(this, mEditText3);
sendKeys(KeyEvent.KEYCODE_2, KeyEvent.KEYCODE_SPACE,
KeyEvent.KEYCODE_0);
TouchUtils.tapView(this, mEditText1);
assertEquals(«OK», mTextView.getText());
>

Он не проходит, потому что редактирование не обрабатывается. Напишем обработчик для события смены фокуса на EditText’ах — и тест будет пройден. Код обработчика приводиться не будет из-за ограниченности объема статьи, к тому же, он абсолютно тривиален. Также необходимо проверить, правильно ли обрабатываются неверные данные — это задание останется на твоей совести, тем более, что оно практически аналогично предыдущему тесту :).

При запуске тестов можно наблюдать, как сами нажимаются элементы интерфейса, переключаются Activity (для каждого теста Activity запускается заново) — забавное зрелище :).

Мораль сей басни такова

В данной статье были рассмотрены как теоретическая, так и практическая части разработки через тестирование. В качестве примера приведен код приложения на Java под ОС Android с использованием инструментария JUnit, однако принципы тестирования приблизительно одинаковы на любой ОС.

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

Тестирование графического интерфейса (GUI testing)

Дата публикации: 14.07.2020

Статья просмотрена: 5898 раз

Библиографическое описание:

Абраров Р. Д., Пак В. О. Тестирование графического интерфейса (GUI testing) // Техника. Технологии. Инженерия. — 2020. — №3.1. — С. 3-4. — URL https://moluch.ru/th/8/archive/62/2630/ (дата обращения: 14.11.2020).

Что такое GUI?

Есть два типа интерфейсов для компьютерных приложений.

Интерфейс командной строки, где вы набираете текст и компьютер ответчик к этой команде.

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

Ниже приведены GUI элементы, которые могут быть использованы для взаимодействия между пользователем и приложением:

GUI тестирование, является проверкой указанных элементов[1].

Что такое GUI тестирование?

Тестирование GUI является процесс тестирования графического пользовательского интерфейса системы из тестируемого приложения. Тестирование GUI участвует проверку экранов с элементами управления, такими как кнопки меню, иконка и все виды баров – панели инструментов, панели меню, диалоговым окном и т.д.

GUI это то, что видит пользователь. Пользователь не видит исходный код. Интерфейс виден пользователю. Особенно акцент делается на дизайн структуры, образы, которые они работают должным образом или нет.

В приведенном выше примере, если мы должны сделать тестирование GUI, сначала убедитесь, что изображения должны быть полностью видны в разных браузерах.

Кроме того, ссылки доступны, и кнопка должна работать при нажатии.

Кроме того, если пользователь изменил размер экрана, ни изображения, ни содержание должно сокращаться или кадрирования или перекрытия.

Необходимость тестирования графического интерфейса пользователя

Теперь, основная концепция тестирования GUI ясно. Несколько вопросов:

 Почему тестирование GUI?

 Действительно ли это необходимо?

 Достаточно ли тестирование функциональности и логики приложения?

Чтобы получить ответ, думайте как пользователь, а не в качестве тестера. Это пользовательский интерфейс приложения, который решил, что пользователь будет использовать приложение дальше или нет.

Обычный пользователь сначала наблюдает за дизайном и внешностью приложения / программного обеспечения и насколько легко понять его интерфейс. Если пользователь не чувствует себя комфортно с интерфейсом приложений или найти сложно понять, что он никогда не будет использовать это приложение еще раз. Вот почему, графический интерфейс является предметом для беспокойства, и надлежащее тестирование должно проводиться для того, чтобы убедиться, что GUI свободен от ошибок.

Что вы проверяете в GUI тестирования?

Следующий перечень обеспечит детальное тестирование GUI.

 Проверьте все элементы GUI для размера, положения, ширины, длины и акцепта символов или цифр. Например, вы должны быть в состоянии внести свой вклад в соответствующие поля ввода.

 Убедитесь, что вы можете выполнить намеченную функциональность приложения с помощью графического интерфейса

 Проверить Сообщения об ошибках отображаются правильно

 Проверьте, четкое разграничение различных участков на экране

 Проверьте шрифт, используемый в приложении для чтения

 Проверьте выравнивание текста собственно

 Проверьте цвет шрифта и предупреждающие сообщения эстетично

 Убедитесь, что изображения имеют хорошую прозрачность

 Убедитесь, что изображения правильно выровнены

 Проверьте расположение элементов графического интерфейса для различного разрешения экрана.

Подход тестирования графического интерфейса пользователя

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

Ручное тестирование

При таком подходе графические экраны проверяются вручную тестерами в соответствии с требованиями, указанными в документе бизнес-требований.

Запись и воспроизведение

Тестирование GUI можно выполнить с помощью инструментов автоматизации. Это делается в 2 частях. Во время записи шаги теста записываются инструментом автоматизации. Во время воспроизведения записанные этапы тестирования выполняются в тестовом приложении.

Модель на основе тестирования

Модель представляет собой графическое описание поведения системы. Это поможет нам понять и предсказать поведение системы. Модели помогают в поколении эффективных тестов с использованием требований к системе. Эти потребности должны быть рассмотрены для этого тестирования на основе модели:

 Определить исходные данные для модели

 Рассчитать ожидаемый выход для модели

 Сравните фактический выход с ожидаемым выходом

 Решение о дальнейших действиях по модели

Тестирование графического интерфейса пользователя в основном связано с

  1. Тестирование размер, положение, ширину и высоту элементов.
  2. Тестирование получения сообщения об ошибках, которые выводятся на экран.
  3. Тестирование различных секций экрана.
  4. Тестирование шрифта, является ли он для чтения или нет.
  5. Тестирование экрана в различных разрешениях с помощью увеличения и уменьшения масштаба, как 640 х 480, 600×800 и т.д.
  6. Проверка выравнивания текста и другие элементы, такие как иконки, кнопки и т.д. находятся в нужном месте или нет.
  7. Тестирование цвета шрифтов.
  8. Тестирование цвета сообщений об ошибках и предупреждениях.
  9. Тестирование имеет ли изображение хорошую прозрачность или нет.
  10. Проверка выравнивания изображений.
  11. Тестирование орфографии.
  12. Тестирование интерфейс является привлекательным или нет.
  13. Тестирование размера изображений.
  14. Тестирование заголовков, правильно ли она выровнена или нет.
  15. Тестирование цвета гиперссылки.

Проблемы в тестировании GUI


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

Вывод:

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

    GUI Testing: Complete Gu >Основные термины(генерируются автоматически): GUI, графический интерфейс пользователя, тестирование, графический интерфейс, нет, пользователь, ручное тестирование, ожидаемый выход, изображение, хорошая прозрачность.

Похожие статьи

Игровой интерфейс и управление игрой | Статья в журнале.

Тестирование графического интерфейса (GUI testing). Тестирование GUI участвует проверку экранов с элементами управления, такими как кнопки меню, иконка и все виды баров – панели инструментов, панели меню, диалоговым окном и т.д.

Пользовательский интерфейс | Статья в журнале.

Тестирование графического интерфейса (GUI testing). GUI означает графический интерфейс пользователя, где вы взаимодействуете с компьютером, используя изображения, а не текст. Ниже приведены GUI элементы.

Графический интерфейс пользователя — это обширная тема.

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

Анализ и сравнение методов контроля при проведении.

Тестирование графического интерфейса (GUI testing). Тестирование GUI является процесс тестирования графического пользовательского интерфейса системы из тестируемого приложения.

Разработка модуля формирования документов студенческой.

Тестирование графического интерфейса (GUI testing). Тестирование GUI является процесс тестирования графического пользовательского интерфейса системы из тестируемого приложения.

INTERFACE — использование интерфейсов; — IMPLEMENTS.

Тестирование графического интерфейса (GUI testing). Есть два типа интерфейсов для компьютерных приложений. Интерфейс командной строки, где вы набираете текст и компьютер ответчик к этой команде.

Работа с элементами GUI на примере приложения.

Тестирование графического интерфейса (GUI testing). Тестирование GUI участвует проверку экранов с элементами управления, такими как кнопки меню, иконка и все виды баров – панели инструментов, панели меню, диалоговым окном и т.д.

Разработка программного приложения визуализации упражнений.

Тестирование графического интерфейса (GUI testing).

Кроме того, если пользователь изменил размер экрана, ни изображения, ни содержание должно сокращаться или кадрирования или перекрытия.

Применение возможностей Python для автоматизации.

Тестирование графического интерфейса (GUI testing).

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

Автоматизация тестирования пользовательского интерфейса на Android

Russian (Pусский) translation by Ilya Nikov (you can also view the original English article)

Введение

Библиотека поддержки тестирования Android включает в себя фреймворк UIAutomator, который может использоваться для автоматического тестирования черного ящика в приложениях для Android. Внедренный в API-уровне 18, фреймворк позволяет разработчикам моделировать действия пользователей над виджетами, составляющими пользовательский интерфейс приложения.

В этом уроке я расскажу вам, как использовать фреймворк для создания и запуска теста базового пользовательского интерфейса для приложения калькулятора.

Предпосылки

Чтобы следовать уроку, вам нужно:

  • последняя версия Android Studio
  • устройство или эмулятор, работающий под управлением Android 4.3 или выше
  • базовое понимание JUnit

1. Установка зависимостей

Чтобы использовать фреймворк UI Automator в вашем проекте, отредактируйте файл build.gradle в каталоге app вашего проекта, добавив следующие зависимости:

Теперь кнопка Sync Now должна появиться на экране. Когда вы нажмете на нее, вы должны увидеть следующую ошибку:

Нажмите ссылку Установить репозиторий и синхронизировать проект, чтобы установить Android Support Repository.

Если вы используете библиотеку appcompat-v7 версии 22.1.1, вам нужно добавить следующую зависимость, чтобы убедиться, что приложение и его тесты используют одну и ту же версию com.android.support:support-annotations :

Далее, из-за ошибки в Andro >packagesOptions . Если вы не сделаете этого, это приведет к следующей ошибке при попытке запустить тест:

Добавьте следующий фрагмент внизу файла build.gradle:

2. Создайте тестовый класс

Создайте новый тестовый класс CalculatorTester , создав файл с именем CalculatorTester.java внутри каталога andro >InstrumentationTestCase .

Нажмите Alt + Insert, а затем нажмите SetUp Method, чтобы переопределить метод setUp .

Нажмите Alt + Insert еще раз и нажмите Test Method, чтобы создать новый тестовый метод. Назовите этот метод testAdd . Класс CalculatorTester теперь должен выглядеть следующим образом:

3. Расмотрим пользовательский интерфейс Launcher

Подключите Android-устройство к компьютеру и нажмите кнопку «домой» на вашем устройстве, чтобы перейти на главный экран.

Вернитесь на свой компьютер и используйте свой проводник или терминал для поиска в каталоге, где установлен Android SDK. Затем перейдите в каталог tools внутри него и запустите uiautomatorviewer. Это запустит UI Automater Viewer. Вам должен быть представлен экран, который выглядит следующим образом:

Нажмите кнопку, похожую на телефон, чтобы сделать снимок экрана вашего устройства Android. Обратите внимание, что снятый снимок экрана является интерактивным. Нажмите значок «Приложения» внизу. В разделе Детали узла справа вы можете увидеть различные детали вашего выбора, как показано ниже.

Чтобы взаимодействовать с элементами на экране, фреймворк тестирования UI Automator должен иметь возможность однозначно идентифицировать их. В этом учебнике вы будете использовать либо text , и content-desc , либо class элемента, чтобы однозначно идентифицировать его.

Как вы можете видеть, значок Приложения не имеет text , но у него есть content-desc . Запишите его значение, потому что вы будете использовать его на следующем шаге.

Выберите Android-устройство и нажмите значок «Приложения», чтобы перейти к экрану, на котором отображаются приложения, установленные на устройстве. Вернитесь в UI Automator Viewer и сделайте еще один снимок экрана. Поскольку вы будете писать тест для приложения Calculator, щелкните его значок, чтобы просмотреть его детали.

На этот раз content-desc пустой, но text содержит значение Calculator. Запомните это.

Если на вашем Android-устройстве запущен другой ланчер или другая версия Android, экраны и детали узла будут разными. Это также означает, что вам придется внести некоторые изменения в свой код в соответствии с операционной системой.

4. Подготовка тестовой среды

Вернитесь в Andro >setUp . Как следует из его названия, метод setUp должен использоваться для подготовки тестовой среды. Другими словами, здесь вы указываете, что нужно сделать, прежде чем запускать фактический тест.

Теперь вы будете писать код, чтобы имитировать то, что вы сделали на своем устройстве Android на предыдущем шаге:

  1. Нажмите кнопку home, чтобы перейти на главный экран.
  2. Нажмите значок «Приложения», чтобы просмотреть все приложения.
  3. Запустите приложение «Калькулятор», нажав на его значок.

В своем классе объявите поле типа UiDevice и назовите его device . Это поле представляет собой Android-устройство, и вы будете использовать его для имитации взаимодействия с пользователем.

В методе setUp инициализируйте device , вызвав метод UiDevice.getInstance , передав экземпляр Instrumentation , как показано ниже.

Чтобы имитировать нажатие кнопки home на устройстве, вызовите метод pressHome .

Затем вам нужно смоделировать событие click на значке Apps. Вы не можете сделать это немедленно, потому что Android-устройству потребуется время, чтобы перейти на главный экран. Попытка щелкнуть значок «Приложения» до того, как он будет виден на экране, вызовет исключение во время выполнения.

Чтобы подождать, чтобы что-то произошло, вам нужно вызвать метод wait у экземпляра UiDevice . Чтобы дождаться появления значка Apps на экране, используйте метод Until.hasObject .

Чтобы определить значок приложения, используйте метод By.desc и передайте ему значение Apps. Вам также необходимо указать максимальную продолжительность ожидания в миллисекундах. Установите его на 3000. Это приводит к следующему коду:

Чтобы получить ссылку на значок «Приложения», используйте метод findObject . После того, как у вас есть ссылка на значок Приложения, вызовите метод click для имитации щелчка.

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

Используйте методы findObject и click , чтобы получить ссылку на значок калькулятора и эмулировать клик.

5. Инспектируем пользовательский интерфейс калькулятора


Запустите приложение «Калькулятор» на своем устройстве Android и используйте UI Automater Viewer, чтобы инспектировать его. После захвата снимка экрана щелкните кнопки, чтобы увидеть, как вы можете однозначно идентифицировать их.

Для этого тестового примера вы заставим калькулятор вычислить значение 9 + 9 = и проверим, показывает ли он 18 в качестве результата. Это означает, что вам нужно знать, как идентифицировать кнопки с метками 9, + и =.

На моем устройстве я собрал следующее из инспекции:

  • Кнопки, содержащие цифры, имеют соответствующие значения text .
  • Кнопки, содержащие символы + и =, имеют значения content-desc , установленные как plus и equals соответственно.
  • Результат показан в виджетах EditText .

Обратите внимание, что эти значения могут отличаться на вашем устройстве, если вы используете другую версию приложения Calculator.

6. Создаем тест

На предыдущих шагах вы уже узнали, что вы можете использовать метод findObject вместе с By.text или By.desc , чтобы получить ссылку на любой объект на экране. Вы также знаете, что вам нужно использовать метод click для имитации клика на объекте. Следующий код использует эти методы для выполнения вычисления 9 + 9 =. Добавьте его в метод testAdd класса CalculatorTester .

На этом этапе вам нужно подождать результата. Однако вы не можете здесь использовать Until.hasObject , потому что EditText , содержащий результат, уже находится на экране. Вместо этого вы должны использовать метод waitForIdle , чтобы дождаться завершения вычисления. Опять же, максимальная продолжительность ожидания может составлять 3000 мс.

Получите ссылку на объект EditText с помощью методов findObject и By.clazz . Когда у вас есть ссылка, вызовите метод getText , чтобы определить результат вычисления.

Наконец, используйте assertTrue , чтобы проверить, что результат равен 18.

Теперь ваш тест завершен.

6. Запуск теста

Чтобы запустить тест, на панели инструментов Andro >CalculatorTester из раскрывающегося списка и нажмите кнопку play справа.

После завершения сборки тест должен быть выполнено и успешно завершен. Во время теста вы сможете увидеть автоматизацию пользовательского интерфейса на вашем устройстве Android.

Заключение

В этом уроке вы узнали, как использовать фреймворк тестирования Automator UI и UI Automater Viewer для создания тестов пользовательского интерфейса. Вы также видели, как легко запускать тесты с помощью Android Studio. Несмотря на то, что мы протестировали довольно простое приложение, вы можете применить концепции, которые вы здесь изучили, для тестирования практически любого приложения для Android.

Вы можете узнать больше об библиотеке поддержки тестирования на веб-сайте разработчиков Android.

Понимание и освоение тестирования Andro >

Представляем вашему вниманию статью Аритры Роя, инженера-проектировщика и Full-stack разработчика.

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

Основная мотивация написания этой серии статей — дать вам четкое представление о всем разнообразии тестирования на Android и сделать его простым и понятным. Даже если раньше у вас не было опыта тестирования, эта серия станет отличным началом в вашем путешествии.

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

Зачем беспокоиться о тестировании?

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

В течение долгого времени мне было непонятно, почему я должен тратить время на автоматические тесты вместо того, чтобы делать это вручную обычным способом. Я знал так называемые «теоретические» причины, но не были ясны фактические последствия написания и не написания тестов.

Уверенность в вашем коде

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

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

Избавление от ошибок регрессии

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

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

Написание минималистичного кода

После того, как вы начнете писать тесты для своего кода, вы, в конечном итоге, будете писать намного меньше продашн кода, чем бы писали без тестов.

Предположим, что вы следуете Test-Driven Development (TDD), и написали тест. Теперь вашей основной целью будет написание только нужного кода, чтобы пройти этот конкретный тест. Вы не будете писать лишний или ложный код, который вы написали бы в противном случае.

В конечном итоге вы будете экономить время и быстрее выпускать безупречные и надежные функции.

Пирамида тестирования

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

Юнит-тестирование

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

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

Единственным недостатком этих тестов является то, что они не работают на реальном устройстве, и их точность меньше по сравнению с другими типами тестов. Вы будете использовать различные методы, чтобы эмулировать разные состояния и поведение, и не всегда будете уверены, действительно ли они будут работать на реальном устройстве.

Интеграционные тесты

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

Эти тесты обычно проверяют, работают ли два разных модуля или компонента вместе так, как должны. Это сильно отличается от тестирования бизнес-логики, о котором мы говорили ранее. Как правило, эти тесты являются средними по размеру (больше, чем юнит-тесты, но короче, чем end-to-end тесты) и должны составлять около 20% от общего количества тестов, написанных для вашего приложения.

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

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

End-to-end тестирование

Предположительно, вы будете использовать лишь несколько таких тестов. В идеале вы должны постараться сделать так, чтобы около 10% ваших тестов были end-to-end вариантами. Как следует из названия, вы будете использовать эти тесты для полного тестирования потока – с начала и до конца.

Предположим, ваше приложение имеет регистрацию, состоящую из нескольких шагов, и вы хотите протестировать весь поток – тогда вам помогут именно end-to-end тесты. Они также будут выполняться на реальном устройстве или эмуляторе, как и тесты интеграции, и, следовательно, будут довольно медленными в исполнении.

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

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

Типы тестирования на Android

Теперь, когда у вас есть четкое представление о различных типах тестов, которые вы можете написать, давайте попробуем разобраться в типах тестов, доступных на платформе Android.

Не волнуйтесь, они не очень отличаются от того, что мы обсуждали ранее, но в Android мы склонны классифицировать тесты на основе того, работают ли они на локальном компьютере или на реальном устройстве/эмуляторе.

Локальные unit-тесты

Это те тесты, которые могут выполняться локально на вашей девелоперской машине. Эти тесты находятся в module/src/test/java и не имеют никакого доступа к любым API-интерфейсам Android.

Предположим, что у вас есть метод с именем validateEmailAddress(String), и вы хотите проверить его работоспособность. Вы могли бы написать очень маленькие и целенаправленные тесты для каждого сценария этой функции, например, когда электронное письмо является нулевым, пустым или недействительным.

Для модульного тестирования мы используем JUnit, который является очень популярным фреймворком юнит-тестирования, помогая нам писать четкие и понятные тесты. Мы также можем использовать Robolectric, который является еще одной популярной платформой тестирования, позволяющей нам также тестировать зависимости Android.

Инструментальные тесты

Это те тесты, которые относятся к категории тестов «Integration» и «End-to-End». Все эти тесты находятся в module /src/androidTest/java.

Обратите внимание на добавление префикса «android» перед «тестом», означающим, что эти тесты должны запускаться на устройстве Android или эмуляторе и иметь доступ к зависимостям Android. Они в основном известны как «source sets», если вам интересно.

Эти тесты довольно медленны в исполнении, так как каждый раз тест создает новый APK и запускает его вместе с тестируемым исходным приложением. Оба этих приложения работают в одном процессе, что позволяет тестовому приложению получать доступ к методам и полям в реальном приложении и автоматизировать взаимодействие с пользователем.
Вы можете использовать эти типы тестов для автоматизации нажатия на любую кнопку, ввода текста, просмотра некоторых Views, прокрутки списков и выполнения различных действий в приложении, которые только пользователь может выполнить вручную.

Теперь у вас может возникнуть вопрос, почему эти тесты называются «инструментальными»? Это связано с тем, что они используют Android Instrumentation API через InstrumentationRegistry для управления компонентами Android и их жизненными циклами вручную, вместо того, чтобы позволять системе их контролировать.

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

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

Выводы

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


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

Автоматическое тестирование приложений для Andro >

Представлено: Roman Khatko, опубликовано: 4 февраля 2013 г.

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

  • Размер и разрешение экрана
  • Версия Android
  • Типоразмер устройства
  • Набор инструкций процессора
  • Наличие передней камеры, поддержка NFC, внешняя клавиатура и пр.

Приложения для Android следует тестировать на множестве устройств.

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

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

В этой статье рассматривается несколько средств для автоматического тестирования функциональности. При этом речь идет только о средствах, входящих в состав Android SDK или распространяющихся с открытым исходным кодом.

Принцип автоматического тестирования

Наша задача — с наибольшей точностью автоматизировать действия, выполняемые вручную. Рассмотрим эти действия. Будем использовать несколько приложений и несколько устройств с Android.

Для каждого приложения и каждого устройства нужно выполнить следующие действия:

  1. Установить приложение на устройство
  2. Запустить приложение
  3. Протестировать приложение, используя выбранный метод
  4. Удалить приложение
  5. Сбросить устройство в исходное состояние

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

Управление устройствами Android

Прежде всего необходимо выбрать компьютер, который будет использоваться для запуска автоматических тестов, и установить на нем Android SDK. В данном примере я использую настольный компьютер с операционной системой Linux*. На каждом устройстве необходимо отключить экран блокировки и увеличить «время перед переходом в спящий режим» до максимального значения. Для некоторых методик тестирования также нужно отключить изменение ориентации экрана.

В составе Android SDK предусмотрено две программы для управления устройствами с Android: ADB и monkeyrunner*. Сейчас мы подробно рассмотрим автоматизацию действий, применяемых при тестировании вручную .

Управление устройствами Android с помощью ADB

ADB (Android Debug Bridge) — это программа командной строки для управления устройствами с Android. Домашняя страница ADB: http://developer.android.com/tools/help/adb.html

Проверка установки ADB

Установите и настройте Android SDK, затем подключите к компьютеру устройства с Android и выполните команду:

По этой команде будет показан список всех подключенных устройств с Android. Если список устройств не пуст, то ADB исправно работает .

Работа с несколькими устройствами

Чтобы выбрать устройство, с которым должна работать программа ADB, используйте параметр «-s».

adb -s [серийный_номер] [команда]

adb -s [серийный_номер] logcat

Серийный номер устройства можно получить в выходных данных команды «adb devices». Параметр -s позволяет работать одновременно с несколькими подключенными устройствами .

Основные команды ADB

Открыть консоль на устройстве:

Выполнить команду на устройстве:

adb shell [команда]

В состав Android входит множество стандартных команд Linux: ls, cat, dmesg, .

Установить приложение из APK-файла:

adb install example.apk

adb uninstall [пакет]

Получить имя пакета из APK-файла:

aapt dump badging example.apk | grep «пакет»

Загрузить файл с устройства на компьютер:

adb pull [путь на устройстве] [файл]

Отправить файл с компьютера на устройство:

adb push [файл] [путь на устройстве]

К большинству папок на устройстве с Android возможен доступ только для чтения. Доступ на запись доступен только к папкам /sdcard (но из этой папки невозможно запускать программы) и /data/local/tmp.

adb shell am start -n [пакет]/[действие]

Запустить определенное действие.

Имя действия можно извлечь из APK-файла:

aapt dump badging example.apk | grep «запускаемое_действие»

Logcat — это средство командной строки для чтения журналов с устройств Android.

Домашняя страница Logcat: http://developer.android.com/tools/help/logcat.html

Читать журналы с устройства (блокировка до нажатия клавиш Ctrl-C):

Очистить буфер журнала на устройстве:

Записать буфер журнала на устройстве (отображение текущего содержимого буфера, без блокировки):

Получение снимков экрана с помощью screencap

Программа screencap сохраняет снимок текущего экрана в графический файл:

Программа screencap доступна на смартфонах с Android 4.x и более поздними версиями. На более ранних версиях Android можно получать снимки экрана с помощью monkeyrunner.

Скрипт BASH для тестирования приложения с помощью ADB

Управление устройствами Android с помощью MonkeyRunner

Программа monkeyrunner предоставляет интерфейсы API для скриптов, управляющих устройствами Android. Можно написать скрипт Python*, устанавливающий приложение Android, запускающий его, получающий снимки экрана и сохраняющий их на компьютере. Для запуска скриптов Monkeyrunner использует Jython*.

Чтение журналов с помощью monkeyrunner

Сценарий будет записывать данные журнала в файл example.log в текущей папке.

Получение снимков экрана с помощью MonkeyRunner

Сценарий делает снимок экрана и сохраняет его в файл screenshot.png в текущей папке.

Пример управления устройством с помощью monkeyrunner

Методы автоматического тестирования

Тестирование с помощью Monkey*

Предположим, что тестируемое устройство попало в лапы крайне любопытной и деятельной обезьяны: программа Monkey имитирует именно такую ситуацию. Программа Monkey, входящая в состав Android SDK, отправляет поток случайных действий пользователя. В командной строке можно указать количество действий пользователя, долю действий каждого типа и имя пакета (чтобы программа Monkey не вышла за пределы тестируемого приложения и не начала, к примеру, рассылать SMS-сообщения всем контактам из адресной книги).

Примеры и список параметров приведены на домашней странице Monkey : http://developer.android.com/tools/help/monkey.html

Основным преимуществом программы Monkey является отсутствие каких бы то ни было затрат на обслуживание. Кроме того, нагрузочное тестирование может выявлять сложные и малозаметные ошибки.


Недостатки тестирования с помощью Monkey :

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

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

Тестирование с помощью MonkeyRunner

MonkeyRunner позволяет не только создавать сценарии для управления устройствами с Android, но и создавать сценарии для тестирования приложения на определенном устройстве.

  • Сложность написания скриптов, даже в простых случаях.

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

Тестирование с помощью getevent и sendevent

Программы getevent и sendevent позволяют пользователю записывать последовательность действий и затем воспроизводить ее. Для запуска этих программ не требуются права доступа root.

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

Запись последовательности событий:

Тестирование с помощью Robotium*

Robotium не входит в состав Android SDK, эта программа распространяется с открытым исходным кодом. Домашняя страница Robotium: http://code.google.com/p/robotium/.

Сценарии Robotium определяют действия на уровне пользовательского интерфейса приложений, а не на уровне устройства ввода.

Например, в сценарии требуется коснуться кнопки «ОК». В этом случае скрипт monkeyrunner будет построен следующим образом: «имитировать касание экрана в точке с координатами (x0, y0)». Скрипт Robotium будет построен иначе: «нажать кнопку с текстом «ОК».

Описание действий на уровне интерфейса позволяет сделать тестовый скрипт независимым от расположения и размеров элементов интерфейса, разрешения и ориентации экрана.

Кроме того, в Robotium можно проверять реакцию приложения на действия. Например, предположим, что после нажатия кнопки «ОК» должен появиться список с элементом «Элемент 1». В Robotium можно проверять имена элементов списков. Проверка состояния приложения после каждого шага позволяет с легкостью находить шаг, на котором произошла ошибка .

  • Для каждого приложения требуется разрабатывать тестовый сценарий на языке Java*. Для этого требуется время и навыки программирования.
  • При смене интерфейса приложения потребуется переделать последовательность событий.
  • Созавать сценарии Robotium сложнее, чем записывать события с помощью getevent / sendevent.

В целом, Robotium позволяет создавать тестовые сценарии высшего качества с разумными затратами.

Сравнение методов тестирования

Monkey — поток случайных действий пользователей

Затраты на обслуживание отсутствуют.

Независимость от устройства.

Нагрузочное тестирование может выявлять сложные и малозаметные ошибки .

Качество тестирования может различаться для разных приложений.

Сложно воспроизводить последовательность действий, вызвавших ошибку, в отчетах об ошибках.

Monkey не проверяет состояние приложения во время тестирования .

MonkeyRunner — скрипт для управления устройством

Сложность написания сценариев, даже для простых приложений.

Getevent/sendevent — запись и воспроизведение действий пользователя

Для записи последовательности событий не требуются навыки программирования.

Записанная последовательность действий подойдет только для одного устройства при фиксированной ориентации экрана.

При смене интерфейса приложения необходимо переделывать последовательность событий.

Этот метод не проверяет состояние приложения во время тестирования.

Robotium — API тестовых скриптов для проверки состояния

Действия описываются на уровне пользовательского интерфейса приложения.

Скрипт может не зависеть от разрешения и ориентации экрана.

Скрипт может проверять состояние приложения после действий .

Сложность написания сценариев на языке Java.

При изменении интерфейса приложения необходимо переделывать скрипт .

Анализ результатов

Теперь нужно провести анализ журналов и снимков экрана, полученных при автоматическом тестировании, чтобы обнаружить ошибки.

Анализ журнала

Можно выполнить поиск строк:

TВ этот список можно добавить сообщения об ошибках, обнаруженные при тестировании вручную.

Анализ снимков экрана

Можно подготовить набор снимков экрана в основные моменты тестирования и сравнивать их с содержимым экрана при автоматическом тестировании. Это позволит определить, правильно ли проходит автоматическое тестирование.

Полезно сравнить начальный снимок экрана со снимком, полученным после запуска приложения. Это поможет определить случаи отказа приложения без вывода сообщений об ошибках.

Monkeyrunner позволяет сравнивать два снимка экрана с определенным допустимым расхождением (в процентах) :

К сожалению, не существует API MonkeyImage для загрузки изображения из файла. Можно самостоятельно написать функцию для сравнения изображений с помощью, например, Python* Imaging Library.

Сброс устройства в исходное состояние

После тестирования необходимо сбросить устройства в исходное состояние. Это можно сделать несколькими способами:

  • Нажать кнопку «Назад» несколько раз.
  • Перезагрузить устройство.
  • Перезапустить процесс-оболочку.

Первый вариант обычно является наиболее целесообразным.

Многократное нажатие кнопки «Назад»

Нажатие кнопки «Назад» с помощью monkeyrunner:

Такой подход является рекомендуемым, поскольку он имитирует действия настоящих пользователей.

Заключение

В этой статье мы обсудили некоторые методы автоматического тестирования приложений Android. Мы рассмотрели преимущества и недостатки методов автоматического тестирования.

Также рассказано о средствах Monkey и monkeyrunner, входящих в состав Android SDK, и о программе Robotium.

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

Как выполнить автоматическое тестирование с приложениями GUI?

Просто новичок в тестировании программного обеспечения .

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

Есть ли решение для тестирования таких приложений с меньшим трудозатратом? Спасибо, что поделились своим опытом.

Да, приложения с графическим интерфейсом действительно сложно автоматизировать. Независимо от технологии приложения (Swing, Web, WPF, iOS), в первую очередь вы должны сосредоточиться на автоматизации дорогостоящих тестов. Более того, автоматизация тестирования должна быть не только на уровне графического интерфейса пользователя, она также должна сочетать в себе модульные, интеграционные и функциональные (GUI) тесты.

Вы работаете над веб-приложением? Если это так, взгляните на отличные инструменты с открытым исходным кодом, такие как Watir или WebDriver. (Я также передам вам тестовую студию Telerik ; однако для полного раскрытия я являюсь их евангелистом в этом инструменте.)

Настольные (или мобильные) приложения доставляют много проблем автоматизации, и это полностью зависит от того, с какой платформой вы работаете. Test Studio поддерживает WPF, но вы также можете посмотреть другие коммерческие и несколько бесплатных инструментов. Я не знаю каких-либо инструментов для приложений Swing, но этот недостаток знаний связан с тем, что я находился вне этой области в течение многих лет. (И, возможно, я настолько не в себе, что Swing — даже не обычный инструментарий Java GUI . )

Для iOS и Android сложно найти надежные инструменты автоматизации. Я знаю, что фреймворк / API Фрэнка будет работать на iOS (у Test Studio есть бесплатный рекордер в App Store), но я не знаю других инструментов, которые бы надежно поддерживали экстраординарную матрицу версий оборудования и ОС Droid.

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

Это долгий путь, но если вы будете работать осторожно, это того стоит.

Java. Тестирование GUI?

Здравствуйте, товарищи Хабралюди!

У меня назрела очередня проблема — возникла необходимость автоматизированно тестировать интерфейсы.

Есть ряд ограничивающих нюансов:

1) Тестируем под линуксом.

2) Тестируем RCP (Rich Client Platform) и SWT приложения.

Соответственно, желательно, чтобы тестировалка встраивалась в эклипс (не обязательно).

Желательно, чтобы тест был написан на джаве, так же как и программа.

Не так важно, платная или бесплатная будет программа — главное чтобы работала хорошо.

С радостью почитаю про опыт использования разных средств.

Спасибо за внимание!

  • Вопрос задан более трёх лет назад
  • 4367 просмотров

Платность — не проблема.
Главное — работа. У них пробный период есть? Чтоб посмотреть, что там да как?

Из-за специфики продукта у нас используется собственная автоматическая система сборки и тестирования, написанная на Java. В частности QFTest просто запускается системой в batch-режиме (задается опцией QFTest’a) через обычный аналог exec() (считай через консоль) каждую ночь, и утром уже имеются очень удобные отчеты с результатами. Главное, чтобы заранее был готов уже работающий и отлаженный файл тестового сценария.

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

Цукерберг рекомендует:  Стиль тетрадного листа
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих
Метод тестирования Преимущества Недостатки