Home

Автор: Арсений Батыров

Готовясь к первому запуску курса “Автоматизированное тестирование Android-приложений”, я задался вопросом: какие инструменты функционального автотестирования для мобильных приложений сейчас наиболее популярны, что стоит выбрать для знакомства новичков с этой темой?

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

Поэтому я разместил простой опрос из трёх пунктов на нескольких крупных сообществах QA в FB, Telegram и Skype. За несколько дней я получил ответы от 36 человек, что уже подходит под критерии большой статистической выборки. Конечно, этот опрос не претендует на звание серьёзного исследования рынка, но помогает понять основные тренды.

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

Супер быстрая автоматизация тестирования на iOS, Виктор Короневич, Badoo, London

Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения- SQA Days-22, Санкт-Петербург, ноябрь.

Автор: Эран Кинсбрунер (Eran Kinsbruner)

Оригинал статьи: https://mobiletestingblog.com/2017/08/25/optimizing-mobile-test-automation-across-the-pipeline/

Перевод: Ольга Алифанова

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

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

Множество "хозяев" у одной и той же проблемы

Так как мы живем в мире Agile/DevQAOps, разработка кода автотестов – проблема не только QA, но и всех вообще. Тесты выполняются в процессе разработки, начиная от разработки как таковой и заканчивая интеграцией и пред/пострелизным тестированием.

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

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

Автор: Франсуа Ле Нотр (Francois Le Notre)

Оригинал статьи: https://www.lyontesting.fr/en/testing-mobile-website-without-any-mobile-device-at-what-cost

Перевод: Ольга Алифанова

Эта статья – продолжение статьи Стефана про разнообразие методик для тестирования мобильных приложений в условиях нехватки физических устройств: ‘Как тестировать на мобильных телефонах, не имея телефонов?’

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

Автор: Владимир Иванов

Оригинальная публикация: http://www.performance-lab.ru/blog/load-testing/mobile-app-load-testing_traffic-recording

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

Введение

Мобильный рынок — один из самых быстрорастущих во всем направлениям: от рекламы до использования в бизнес-сфере.

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

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

Оригинальная публикация: https://habrahabr.ru/company/mobileup/blog/327416/

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

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

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

Видео выступления на конференции DUMP-2017 автора и тренера курса "Тестирование мобильных приложений", Арсения Батырова.

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

Для ускорения этого процесса уже достаточно давно используется debug-консоль, которая позволяет быстро сформировать нужное состояние приложения и заниматься тестированием сразу. В своём докладе я расскажу об опыте использования таких панелей на популярных ОС: Android, iOS и Windows Phone, а также на паре непопулярных. Мы рассмотрим варианты решений для клиента и сервера, как защитить этот режим от попадания в руки пользователя и как убедить разработчиков в его необходимости. Ну, и пара фейлов, конечно же, куда без них.

Автор: Никита Анисимов

Оригинальная публикация: https://habrahabr.ru/company/mailru/blog/325552/

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

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

Нажмите на картинку, чтобы увеличить изображение

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

Широко известно, что iOS - достаточно закрытая система. Apple четко следует своему курсу на высокое качество приложений и ограничивает установку приложений из сторонних источников. И хотя для пользователей это может быть благом, в тестировании такая закрытость может очень сильно усложнять рабочий процесс. Ведь для того, чтобы установить приложение из среды разработки на реальное устройство, нужно обладать платным аккаунтом разработчика Apple.

По крайней мере, так было до недавнего времени. С выходом Xcode 8 Apple сняла это ограничение, и теперь можно подписывать приложения, даже не участвуя в этой программе. Однако этот факт до сих пор малоизвестен, к тому же нужно очень чётко следовать правилам, чтобы у вас получилось подписать приложение. В этом видео, которое является частью курса “Тестирование мобильных приложений”, рассматривается схема подписывания и установки приложения на iOS-устройство:

Автор: Екатерина Батеева, Отдел автоматизированного тестирования, Тинькофф Банк

Оригинальная публикация: https://habrahabr.ru/company/tinkoff/blog/324766/

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

В нашем банке мы тоже наблюдаем эту тенденцию: мобильное приложение по сравнению с интернет-банком используют на порядок больше пользователей. Поэтому остро встал вопрос автоматизации тестирования мобильного приложения. Несмотря на повсеместное использование мобильных приложений, средства для их автоматизированного тестирования далеко не идеальны. Кроме того, мы предъявляем к ним высокие требования. Например, самый популярный фреймворк Appium — open-source решение, поддерживающее платформы Android и iOS, — нам не подошел. Наши разработчики использовали много модных библиотек, и взаимодествовать с приложением иногда приходилось на более низком уровне. UI Automator и UI Automation оказались более сложными в развертывании, каждое приложение использовало свой язык для написания тестов, из-за чего возникали проблемы при перераспределении между платформами в команде автотестирования.

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