Тестирование мобильных приложений *

Привет, Хабр! Так уж сложилось, что игровые процессы занимают важную роль во многих жизненных процессах: как эволюционных, так и более приземлённых, повседневных. Игровые условности способствуют как обучению различным навыкам, так и расслаблению мозга и смене типа активности, что положительно сказывается на трудоспособности. Но сегодня речь пойдёт не о всяких сложных штуках типа геймификации процесса разработки или разработке обучающих игровых приложений, а о более простом и понятном деле: заработке на разработке игр.

Сегодня у многих IT-компаний есть собственные bounty-программы (или программы по поиску уязвимостей). Badoo — в их числе.

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

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

Мы хотим усилить интерес к ней, в том числе со стороны иностранных исследователей. Поэтому мы, во-первых, открыли страничку с нашей программой на крупнейшем портале исследователей hackerone.com, а во-вторых — увеличили суммы вознаграждений за найденные уязвимости! Теперь сумма вознаграждения, в зависимости от категории, начинается от £100 и может достигать £1000, сумма супер-премии составляет £2000 (а это более 200 000 рублей по текущему курсу!) и даже больше, если обнаруженная уязвимость представляет реальную угрозу для наших пользователей.

Android OS, если сравнить её с Windows, Linux или OSX, система молодая. Однако, ей пользуются более миллиарда человек. Как именно они работают с Android? Как сделать систему быстрее и удобнее? Новизна платформы не позволяет дать чётких ответов на эти вопросы. Более того, сценарии взаимодействия пользователей с Android-устройствами и приложениями постоянно меняются, нередко – довольно сильно и неожиданно.

Для исследования особенностей взаимодействия пользователей с различными программными и аппаратными комплексами создают особые тесты, так называемые варианты или сценарии использования систем (use cases). Их ещё называют «рабочими нагрузками» (workloads). Всё это – модели реально существующих сценариев работы, настоящими приложениями они не являются. В применении к Android, подобные тесты можно использовать для измерения и улучшения производительности.

Я собираюсь рассказать об одной из тем, касающихся Apache Cordova, которая практически не освещена в рунете — как тестировать свой плагин для Apache Cordova.

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

В первой части статьи мы разработали приложение для работы с github, состоящее из двух экранов, разделенное по слоям с применением паттерна MVP. Мы использовали RxJava для упрощения взаимодействия с сервером и две модели данных для разных слоев. Во второй части мы внедрим Dagger 2, напишем unit тесты, посмотрим на MockWebServer, JaCoCo и Robolectric.

Сегодня закончим цикл статей про IT конференции. Посмотрим на события за Сентябрь-Декабрь 2016 + на все присланные вами дополнения.

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

Большинство IT-компаний не делают версии своих продуктов под Windows Phone, потому что доля мобильной операционной системы от Microsoft меньше, чем у iOS и Android. Тем не менее, это третья крупнейшая мобильная операционная система на рынке, и в Badoo Windows Phone приложение уже давно существует.

Изначально оно было написано аутсорсным разработчиком на Silverlight и долгое время не обновлялось, и несколько лет у продукта не было выделенного отдела. В 2014 году в компанию пришел разработчик Windows Phone и стал поддерживать это приложение, а я стал получать на тестирование некоторые его задачи.

Через пару месяцев было решено написать полностью новое приложение, забросив почти все старые наработки во многом потому, что код был далек от идеала, а на его поддержку тратилось очень много времени. Первым новым приложением для Windows Phone стал экспериментальный проект Badoo — Hot or Not. По концепции он очень похож на Badoo, но в нем гораздо меньше функционала и он несколько отличается. Всего за 3 месяца мы вдвоем сделали приложение Hot or Not с нуля в одной ветке Git-репозитория, которую в итоге замержили в Master. А приложение TeamCity было настроено так, что каждый коммит разработчика собирался как отдельное приложение, что позволяло мне, как тестировщику, видеть историю изменений клиента.

Ян Другаль уже 2 года создает инструменты разработки в Unity. За последнее время его команда значительно выросла, а вместе с этим и наборы тестов, количество неустойчивых, медленных тестов и невоспроизводимых ошибок. Мы публикуем перевод статьи о том, как Ян и его команда решают эти проблемы.

В данной статье я рассмотрю несколько инструментов для A/B-тестирования мобильных приложений с примерами и дам их краткую характеристику. Для успешного проведения тестирования также необходим сервис аналитики, в котором можно сравнивать результаты. Независимые сервисы аналитики мы сегодня рассматривать не будем, но затронем те возможности, которые есть внутри инструментов, о которых пойдет речь.

В этой статье мы поговорим о проектировании архитектуры и создании мобильного приложения на основе паттерна MVP с использованием RxJava и Retrofit. Тема получилась довольно большой, поэтому подаваться будет отдельными порциями: в первой мы проектируем и создаем приложение, во второй занимаемся DI с помощью Dagger 2 и пишем тесты unit тесты, в третьей дописываем интеграционные и функциональные тесты, а также размышляем о TDD в реалиях Android разработки.

Предисловие

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

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

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

P.S.: И последнее — данный текст бы никогда не сформировался, если бы не полезные лекции Алексея Баранцева и Натальи Руколь, а также пропасть информации, написанная добрыми людьми за последние годы по данной теме.

Вот теперь всё, вы предупреждены — можно начинать рассказ.

В 2013 году рынок мобильной разработки для бизнеса оценивался в 245 миллионов долларов. В 2016 году наш рынок должен был составить $1 млрд, но, скорее всего, будет чуть ниже из-за ситуации с экономикой и из-за санкций. По некоторым оценкам, это примерно половина от общего рынка мобильной разработки.

Люди привыкают работать с планшетов и телефонов, привыкают иметь доступ к корпоративным сервисам в кафе, в самолёте, в машине — а работодатели хотят, чтобы сотрудники были на связи и за пределами офиса. Отсюда и такой рост направления.

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

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

Сейчас в каталогах приложений Apple App Store и Google Play в совокупности размещено около 3 миллионов мобильных программ. Количество приложений стабильно растет, чего нельзя сказать о качестве подавляющего количества уже размещенных программ. Одна из причин такой ситуации — разработчики недостаточно хорошо тестируют приложения, во многом это происходит из-за отсутствия должного опыта.

Профессиональный тестировщик, конечно же, смог бы помочь довести мобильное приложение практически до идеального состояния. Но у большинства разработчиков обычно нет средств на оплату услуг такого профессионала. А пользователи не хотят мириться с плохим качеством. И если пользователь обнаруживает серьезную проблему (чрезмерное потребление энергии, краш приложения, зависание телефона), то 44% пользователей, по статистике, сразу удаляют приложение, не разбираясь с проблемой. 96% таких пользователей пишут плохой отзыв о программе. На самом деле, причин, по которым приложение удаляется, довольно много, мы уже писали об этом в своем блоге. Сейчас давайте поговорим о том, что можно предпринять, чтобы приложение работало, как нужно, радуя пользователя стабильностью, а разработчика — доходом от рекламы.

Я помню то замечательное время, когда сборка релизной версии мобильного приложения сводилась к тому, что нужно было выставить debug = false и запустить экспорт apk-файла. Проходит 2 минуты, пока пыхтит IDE, и все готово. Все усилия сосредотачивались на необходимости указать данные сертификата подписи. Это было совсем недавно. Cейчас процесс сборки того самого приложения разросся настолько, что, если мне, вдруг, потребуется выполнить все операции самостоятельно, и даже если я все вспомню и проделаю безошибочно (во что я не верю), то это займет не час, который сегодня кажется непозволительно долгим, а, скорее всего, сутки, после чего терапевт обязан будет прописать мне больничный по усталости недели на две.

Итак, процесс сборки мобильного приложения. Попробую рассказать, из чего он у нас состоит — не потому, что в последнее время стало модным катать посты о CI той или иной мобильной команды (с покером, русалками и прочими обязательными атрибутами), а потому, что это отличный опыт, который я получил, работая над Почтой Mail.Ru для Android, и потому, что этой возможности, вероятнее всего, не было бы, работай я в другой команде, над другим проектом или в другой компании.

Не так давно мне довелось выступать на конференции FFConf с докладом «Вам следует использовать <впишите нужную библиотеку/фреймворк>, это самое лучшее!». И основные мысли я решил изложить в публикации, в надежде, что это спровоцирует в профессиональной среде более широкую дискуссию о «стоимости» современных фреймворков на мобильных устройствах.

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



и слайды презентации: speakerdeck.com/paullewis/framework-here-its-the-bestestest.

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

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

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

… Или, другими словами, как посчитать время на тестирование так, чтобы все поверили? Ведь на самом деле у нас обычно — две цели. Первая — посчитать время так, чтобы не ошибиться и правильно распределить ресурсы — скорее всего, поначалу сделать это хорошо все равно не получится. Вторая цель более реальна: посчитать время на тестирование так, чтобы доказать кому-то, что вам нужны еще люди в команде, объяснить, почему вы не успеваете и т. д. Как ни странно, после того, как раз 50 сделаете второе, то и первое будет получаться!

Давайте теперь посмотрим, как считать время на тестирование, на конкретных примерах.

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

Мой коллега skyline-gleb недавно писал на Хабре, как мы разработали свой selenium-like инструмент автоматизации функционального тестирования desktop-приложений под Windows. Параллельно мы разрабатывали аналогичный инструмент, только под мобильные платформы от Microsoft.

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

Это вольный перевод статьи mcgivery.com/unit-testing-ionic-app на тему тестирования мобильных приложений Ionic используя karma test runner и Jasmine test framework.

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