зачем нужна настройка do not keep activities
Системный подход к тестированию Android-приложений, или О чем молчали разработчики
У каждого тестировщика рано или поздно наступает неловкий момент. Обнаружился вредный баг и его необходимо локализовать. По закону подлости баг воспроизводится нестабильно, при непонятных шагах и только на некоторых устройствах. Есть логи, но они не информативны. Разработчик занимается новой функциональностью, он не может отвлечься от текущих задач, пока не будут найдены четкие шаги воспроизведения. Менеджер ждет исправления (надо быстрее, заказчик переживает).
Как внести ясность в такой ситуации? Некуда деваться, пора разбираться, что же там происходит «под капотом» приложения.
Конечно, можно перечитать всю доступную документацию для разработчиков, но вряд ли это время заложено в сроки проекта. Есть путь проще и продуктивнее: узнать у разработчика, что представляет из себя та функциональность, в которой возникает баг.
Понимая, из каких компонентов состоит приложение, вы сможете:
Предлагаю разобрать некоторые компоненты Андроид-системы и со стороны тестирования рассмотреть кейсы, которые надо проверять для них.
Давайте сразу оговорим, что определения в статье давались тестировщиком. Они не претендуют на истину в последней инстанции и могут содержать неточности. Комментарии и аргументированные замечания приветствуются.
В Андроиде все основано на работе процессов. Операционная система может завершить процесс, если он завис или появился новый с более высоким приоритетом. Когда пользователь видит результаты деятельности процесса, система воспринимает этот процесс как самый приоритетный. И при необходимости она будет закрывать его в последнюю очередь.
В процессах выполняется работа компонентов. Давайте начнем разбираться с таких компонентов, как активити и фрагменты, и рассмотрим кейсы, когда система может прекратить их работу.
Активити и фрагменты (activities and fragments)
С точки зрения тестировщика, активити можно воспринимать как экран, на котором отображаются элементы. Приложение состоит, как минимум, из одной активити. По сути, активити — это контейнер для UI-компонентов.
Если активити – это контейнер, то фрагменты – это UI-компоненты активити. Фрагмент тоже, в свою очередь, является контейнером для UI-компонентов.
Есть классная аналогия с браузером (спасибо разработчикам!) для более наглядного представления о том, как между собой связаны активити и фрагменты. Представим, что у нас открыто несколько окон одного браузера. Это несколько активити внутри одного приложения.
Внутри окна может быть открыто несколько вкладок. Это фрагменты внутри активити.
Фрагменты работают чуть быстрее, чем активити. Но на современных устройствах разница практически неощутима. В зависимости от того, каким образом решается задача, разработчик может написать приложение только на активити или на активити с использованием фрагментов.
Операционная система при управлении жизненным циклом приложения работает именно с активити приложения. Поэтому пока нас больше всего интересует жизненный цикл активити.
Пользователи запускают большое количество приложений, а значит, создается много процессов с активити. Каждый запущенный процесс съедает оперативную память устройства, и ее становится все меньше. Но Андроид тщательно следит за процессами и в случае нехватки ресурсов для выполнения более приоритетной работы закрывает те, которые менее приоритетны.
Давайте разберемся, в какой момент приложение «уязвимо» к таким решениям системы и как это может повлиять на его работоспособность.
Жизненный цикл активити
Для тех, кто не знал или знал, но забыл.
Жизненный цикл активити представлен следующими состояниями:
Теперь приведу примеры. Они покрывают основные кейсы, с которыми мы чаще всего сталкиваемся при тестировании.
Первый запуск приложения
При первом запуске приложения создается и загружается главная активити в приложении.
При переходе в состояние «Resumed» активити доступна для взаимодействия с пользователем. Все замечательно, проблем нет.
Переход с первого экрана на второй
Шаг 1: При переходе с первого экрана на второй активити первого экрана сначала встает на паузу. В этот момент могут выполняться такие действия, как сохранение введенных данных и остановка ресурсоемких операций (например, проигрывание анимаций). Это происходит довольно быстро и неощутимо для пользователя.
Шаг 2, 3, 4: Запускается активити второго экрана.
Шаг 5: Останавливается активити первого экрана. Также в случае, если Андроид в этот момент пытается освободить память, активити первого экрана дополнительно может перейти в состояние «Destroyed» (то есть уничтожиться).
Чтобы лучше понять, что из себя представляет состояние «Paused» давайте представим такую ситуацию: экран, поверх которого появился алерт. Мы не можем с ним взаимодействовать, но в то же время мы его видим.
Возврат со второго экрана на первый
При возврате со второго экрана на первый происходит почти то же самое, только первая активити не создается заново. Она подгружается из памяти (если, конечно, не была уничтожена системой). Вторая активити уничтожается после того, как была остановлена, так как она убирается из стека переходов.
Сворачивание и выход из приложения
При сворачивании приложения (например, по кнопке Home) активити останавливается.
Важно, чтобы при разворачивании приложения активити корректно восстановилась и данные сохранились.
На всех экранах стараемся проверять сворачивание-разворачивание приложения. Этот кейс особенно актуален на формах ввода. Согласитесь, будет обидно, если текст письма, который вы так старательно набирали, сотрется при банальном сворачивании приложения. Или форма, состоящая из множества полей, снова станет пустой.
При выходе из приложения (по аппаратной кнопке назад) помимо шага 1 и шага 2, выполняется шаг 3. Активити уничтожается и при следующем запуске приложения создается заново.
Поворот экрана
Один из значимых случаев, который плодит баги — это поворот экрана. Оказывается, при повороте экрана активити проходит полный жизненный цикл. А именно уничтожается и снова создается. И так при каждом повороте. Поэтому, опять же, проверяем поворот на каждом экране.
Поддержка горизонтальной ориентации экрана, с одной стороны, позволяет проверить корректность работы всех этапов активити, с другой стороны, значительно увеличивает количество тест-кейсов.
Многооконный режим
Начиная с Андроида 7 (с Андроида 6 как экспериментальная фича) стал доступен многооконный режим. Пользователи получили возможность видеть сразу несколько приложений на экране одновременно. При этом только то приложение, с которым пользователь сейчас взаимодействует, находится в состоянии «Resumed». Остальные устанавливаются в состояние «Paused».
Don’t keep activities (Не сохранять действия)
Надо ли проверять полный жизненный цикл активити, если приложение не поддерживает поворот экрана? Конечно, надо.
Если оперативная память давно не чистилась, ее не очень много, и в параллели с вашим приложением было запущено какое-нибудь ресурсоемкое приложение (например, PokemonGo), то шанс, что Андроид решит «прибить» процесс с вашей активити при переключении на другое приложение, возрастает.
Как проверить корректность работы приложения вручную, если оно не поддерживает поворот экрана? Довольно просто: установить галку «don’t keep activities» в настройках разработчика и перезапустить приложение.
В этом случае эмулируется ситуация, когда памяти не хватает и Андроид уничтожает все активити, с которыми пользователь сейчас не взаимодействует, оставляя только ту, что сейчас активна.
Это не значит, что галка должна всегда быть включенной при тестировании, но периодически смотреть приложение с опцией «don’t keep activities» полезно, чтобы пользователи со слабыми устройствами не сильно страдали и не ругали нас.
Broadcast receiver (широковещательный приемник)
Для обработки внешних событий используется компонент Broadcast receiver. Приложение может подписываться на события системы и других приложений. Андроид доставляет событие приложению-подписчику, даже если оно не запущено, и таким образом, может «мотивировать» его запуск.
При тестировании нам важно понимать, какие ожидаются события и как они обрабатываются.
Например, в коде заранее было прописано, что приложение ждет сообщение от конкретного номера и имеет доступ к смс. Когда пользователю придет секретный код, то Broadcast receiver получит уведомление и в поле подтверждения операции будет введен смс-код.
Сервисы (Services)
Еще одна очень важная вещь в Андроиде — это сервисы. Они нужны для выполнения фоновых задач. При этом приложение не обязательно должно быть открыто пользователем в этот момент.
У сервисов есть несколько режимов работы. Пользователь может видеть, что сервис запущен, а может и совершенно не замечать его.
Если вы услышали волшебное слово «сервис» от разработчика, не поленитесь, выясните, какую логику работы заложили в него:
Тут основной совет при проектировании тестовых сценариев — это обдумать пользовательские кейсы, когда работа сервиса может прерваться или начать конфликтовать с работой другого сервиса. Самые коварные ситуации: когда работа сервиса начинается, а пользователь этого не ждал. В этом случае полезно выяснить, что может спровоцировать запуск сервиса.
Самые простые и безобидные — это сервисы без дополнительных параметров. При ручном тестировании мы чаще всего не замечаем их работу. Например, если нужно отправить данные в систему аналитики, то для этой задачи нередко используют именно такие сервисы.
Еще один тип сервисов это sticky-сервисы. Если работа такого сервиса внезапно завершится, то спустя какое-то время sticky-сервис «возродится». Примечательно, что с каждым разом период до «возрождения» увеличивается, чтобы он меньше мешал работе системы. В некоторых приложениях примером sticky-сервиса может быть скачивание файлов на устройство. Возможно, вы замечали, если в «шторке» сбросить закачку, то спустя какое-то время она может восстановиться и продолжить скачивать файлы.
Самые важные сервисы — те, работу которых пользователь «ощущает» на себе и она для него важна. Они называются foreground-сервисы, и у них обязательно есть нотификация в «шторке», которую пользователь не может закрыть. Система их будет уничтожать в последнюю очередь, так как приоритет у таких сервисов самый высокий.
Например, музыкальный плеер. Если свернуть приложение и даже закрыть его, то плеер продолжает играть, пока пользователь не поставит его на паузу или не закроет. Или пока другое приложение или система не приостановит его работу. В частности, для музыкального плеера вариантов может быть много: входящий звонок, другое музыкальное приложение, звуковая нотификация.
Раз речь зашла о музыкальных плеерах, то стоит отметить такое понятие, как аудиофокус.
Аудиофокус
Представим, что при запуске нескольких аудиоплееров, они все будут играть одновременно. Вряд ли это кому-то понравится. Тут на помощь приходит аудиофокус, который запрашивается приложением у системы. В случае обычного запроса аудиофокуса система как бы оповещает все запущенные приложения: «Сейчас другое приложение будет говорить, помолчите, пожалуйста». Забавно, но это происходит именно в формате просьбы.
Если ваше приложение не очень вежливое, то оно спокойно может проигнорировать запрос. Наша задача – проверять эти ситуации.
Компромиссный режим запроса аудиофокуса называется «временным перехватом аудиофокуса». Это значит, что вашему приложению вернется аудиофокус, когда прервавшее его подаст системе сигнал, что аудиофокус освобожден.
Еще один вид запроса аудиофокуса — это «duck». Он просит остальные приложения не молчать, а уменьшить громкость наполовину пока воспроизводится звук запросившего фокус приложения. Например, такой запрос используется при проигрывании звука нотификации о новом сообщении в мессенджере.
Тестирование аудиофокуса очень важно, т.к. здесь все завязано на совести разработчиков и система не принимает особого участия в разрешении конфликтов. Ну а если баг все-таки вылезет к пользователям, то не сомневайтесь, они быстро вам об этом сообщат.
На этом, пожалуй, пока можно закончить. Конечно, есть еще много деталей и нет необходимости учитывать абсолютно все при тестировании. По моему опыту, тестировщику необходимо понимать из чего состоит приложение и как оно работает. Это дает возможность анализировать непростые баги, которые возникают на пересечении бизнес-логики приложения и особенностей работы операционной системы. Особенно если дело касается Андроида.
Мобильные приложения и их тестировщики: all you need to know
Привет тебе, хабр! Меня зовут Максим и я работаю в отделе QA компании Trinity Digital. В сфере обеспечения качества я уже более двух лет, люблю мобильные приложения, их сложность и динамичность. В этой статье я попытался сделать относительно небольшой список инструментов, источников информации и скилов, которые тестировщик мобильных приложений всегда должен иметь при себе в нашем 2к17 году.
Если разбить статью на части, то она будет выглядеть так:
В этой статье я не буду рассказывать что такое iOS и Android, но нельзя не сказать, какую важную роль играют мобильные платформы в нашей жизни. Если обратиться к статистике по продажам PC и смартфонов, то мы можем увидеть, что с каждым годом количество мобилок растет, а вот PC все меньше пользуется спросом. Однако не стоит разводить полемику о смерти какой-либо из платформ. Как отлично было сказано в статье Пола Адамса — каждому бизнесу стоит найти свой идеальный баланс между мобильным и стационарным типом работы с информацией. А пока менеджеры убежали решать вопросы бизнеса, я продолжу.
//Параграф для менеджеров закончился
Источники информации для тестирования
В каком-то смысле тестировщик должен быть маленьким специалистом в каждой отдельной области, наподобие перочинного ножа. Чтобы всегда быть в курсе событий, нужно заручиться определенными источниками информации.
Инструменты для упрощения жизни тестировщика
Жизнь тестировщика разнообразна и многогранна. Для того, чтобы не утонуть в потоках информации и быть максимально эффективным, существует множество техник и инструментов.
Hint’ы
В любом виде тестирования есть исторически сложившиеся bottle neck’и зная которые можно за максимальное короткое время находить большую часть ошибок. Также тут я попытался описать некоторые рабочие моменты, которые упростят поиск ошибок.
Доставка и анализ приложений
Доставка приложений на тестовые девайсы является очень важной частью тестирования, ведь вы не сможете проверить последний актуальный билд, пока он не попадет к вам в руки. Именно для решения этой проблемы на помощь приходят различные сервисы. Ниже я поделюсь теми, которые мы успели не только попробовать в деле, но и найти идеальное место в процессе разработки для каждого из них.
Куда расти дальше
Все мы начинаем с мануального тестирования, но редко кто остается в той же должности на протяжении долгих лет. Так куда же двигаться тестировщику, когда все инструменты из списка уже изучены и хочется чего-то нового? По сути, каждый тестировщик в итоге движется по одному из следующих путей — разработка, автотесты, управленец, DevOps. Какой бы из путей не был бы вам по душе, их все объединяют некоторые качества, которые должны присутствовать в каждом уважающем себя профессионале.
Заключение
Как я говорил в самом начале статьи — я попытался сделать маленький список всего самого необходимого для начинающего мобильного тестировщика. Теперь окидывая статью своим пристальным взглядом, я понимаю, что вся статья отлично отображает само тестирование как феномен. Сначала может показаться, что оно крошечное, но с каждым новым шагом обрастает новыми деталями.
В качестве финального слова хочу пожелать вам побольше девайсов на ферму, поменьше финальных правок и максимум удовольствия от процесса.
The title is pretty self-explanatory. I understand what this developer option does.
What I don’t understand are the following points:
I am eager to know the reasons behind this option.
3 Answers 3
I believe it’s a feature used for debugging purpose.
Don’t keep activities under the Developer Options menu. When this option is enabled, the Android OS will destroy an activity as soon as it is stopped. It is intended to help developers debug their apps. For example, it can simulate the case that Android will kill an activity in the background due to memory pressure. In normal use, it is not recommended to turn this option on because this may lead to unexpected issues on the apps, such as freezes, force closes and reboots.
It sounds like it basically helps testing deterministically how your app behaves when the OS shuts it down due to any reason (out of memory and so on).
So, this replied to point 1. Point 2 is: Yes, I guess 🙂
EDIT: further references
The «don’t keep activities» developer option simply changes the framework’s behavior so it will always destroy your activity when it goes into the background or backstack. This allows you to test how your activity responds to what is normally a rare occurrence.
A link cited in another answer says:
In normal use, it is not recommended to turn this option on because this may lead to unexpected issues on the apps, such as freezes, force closes and reboots.
This is incorrect. If your activities are written properly, the only effect of having «don’t keep activities» turned on should be (possibly) slightly higher battery and CPU usage from constantly saving and restoring persistent state. Any apps that exhibit «unexpected issues» or force closes when this option is on are broken and need to be fixed. As a developer, I habitually leave «don’t keep activities» turned on all the time. I’ve seen a lot of buggy apps, even some of Google’s own. But it’s never caused a reboot, and I don’t think there’s any way it could.
What is «Don’t Keep Activities» in Android Developer Options
You might have heard lot about Android’s hidden and secret settings. I am talking about developer options. As name itself speak, these settings are intended for development use only. People who make Android apps can use these options to test their app performance and for debugging process.
They allow you to see CPU usage, screen touches, pointer location, screen updates, layout bounds and other useful information. They also allow to slow down and speed up the animation scales manually. For example, you can increase or decrease the screen transition time.
One of the most popular and talked feature of developer options is «Don’t keep activities». Some people have misunderstanding about this feature. So I am here to explain you everything about it. But before that, you should know about how to enable these developer options settings in your Android phone.
How to enable developer options
First of all, go to «Settings» and click «About phone». Here you’ll find «Build number» option. Now click it more than 7 times as fast as you can. After too many clicks, it will display a dialog box showing a message as «You are now a developer!».
Finally go back to the settings window and you will find new «Developer options» there.
Note: After enabling developer options, you can not hide them again. The only way is to reset your phone settings. However, you can turn off this feature any time. To do this, go to «Settings > Developer options» and switch off the button at the top-right corner of the screen. Make sure that it’s turned off when not in use.
What does «Don’t keep activities» feature actually do?
We all know that Android phones also have RAM memory which is used by system and other third-party apps to save their temporary files (such as images, text or thumbnails). Each app needs its own space to work.
As soon as the operation is completed, app will automatically leave the RAM space and delete all its cached data. While on the other hand, there are some applications which work in background even when you’re not using them.
Tell me how it was possible to get WhatsApp and Facebook push notifications when your phone is locked. It’s all because of apps running in background. In the same way, there are hundreds of other activities working every time in your Android phone.
Drawbacks of using this feature
This is all what you need to know about «Don’t keep activities» feature in your Android developer options. If you’ve any doubts, share them in below comment box. What do you think about this feature? Where do you think this can be helpful?
Тренды в тестировании в 2020
Автор статьи: Дмитрий Шадрин
Вступление
Хочется поделиться моим топом инструментов для тестирования, которые еженедельно помогают мне в эффективной работе и улучшении своих показателей.
Я занимаюсь тестированием на аутсорсе и приходится работать с различными видами продуктов: мобильные приложения и игры, web, серьезные криптовалютные проекты для Desktop и т.д. В этой статье я хотел бы подобрать наиболее удобные и значимые инструменты, которые помогают мне оптимизировать свою работу при тестировании мобильных приложений.
Мобильные приложения
Самое главное, на что необходимо сделать упор в тестировании мобильного приложения — это функциональное тестирование. Когда вы определились для кого сделан ваш продукт, кто конечный потребитель, то только тогда вы сможете составить грамотные end-to-end тесты для своего приложения.
Начинаем тестирование мы всегда с соответствия требованиям и дизайну приложения. Хороший QA должен знать требования к тестируемому продукту, а отличный — дружить с дизайном. И это значит не просто уметь заглянуть в Figma, Invision или Zeplin, но и понимать как устроен UI/UX его приложения.
Для более точного закрепления всех перемещений пользователя по экранам приложения обычно составляется майндкарта (mindmap). Из наиболее удобных для меня могу выделить xMind, Mindomo и MindMeister.
С появлением и актуализацией майндкарты становится легче тестировать приложения, а что особенно удобно — актуализировать и пополнять тестовую документацию (чек-лист, например).
Хороший чек-лист опирается на требования к проекту, документацию к фичам и задачи, поставленные перед командой в текущей реализации. Майнд-карта же позволяет не забыть и учесть все нюансы, тем самым делая отличную почву для end-to-end тестирования. Сервис, который поможет вам как найти готовые чек-листы, так и актуализировать свой: https://checkvist.com/checklists/476089
Снифферы Charles или Fiddler, как самые популярные до сих пор инструменты для анализа сетевого трафика. Они позволяют проверить кейсы на обрыв сети и слабый интернет, посмотреть на исходящие запросы и полученные ответы. Так же позволяют имитировать некоторые ситуации, которые сложно воспроизвести на реальных кейсах.
Данные из снифферов пригодятся при дальнейшем тестировании API. Но для работы с API советую использовать специализированные инструменты: Swagger UI, Postman. Оба инструмента решают две задачи: документирование запросов и их интерактивную проверку.
Стоит задуматься и об автоматизации процесса тестирования. Одним из самых распространенных решений для автоматизации UI тестирования мобильных приложений является Appium. Сравнительно легкий порог вхождения и обилие документации, а также огромная база QA специалистов, которые всегда помогут ответить на возникающие вопросы.
Appium — это бесплатный кроссплатформенный инструмент с открытым исходным кодом, который помогает автоматизировать приложения как для Android, так и для iOS. Является одним из самых широко используемых инструментов для создания автоматических тестов для смартфонов и планшетов.
Несомненными преимуществами Appium является простота в использовании, а также поддержка многих языков программирования: Java, Ruby, Python, C#, PHP.
Прежде чем начинать работать с Appium, необходимо настроить окружение из следующих компонентов:
В процессе автоматизации тестирования рано или поздно встает вопрос: тестирования на реальных устройствах или использовать эмуляторы. Как показывает практика и безжалостная статистика, эмуляторы — не панацея. Очень часты ситуации, когда на эмуляторах все отрабатывает идеально и все тесты пройдены. Но на реальном устройстве работа приложения блокируется системой безопасности, работой другого приложения или кастомной прошивкой (привет Android!).
Моя рекомендация — комбинировать и использовать фермы устройств. Такие сервисы как BrowserStack, AWS Device Farm, Xamarin Test Cloud. Вы подключаетесь к реальным устройствам, можете интегрировать в эти сервисы свои автотесты и смотреть на получаемые результаты. Но всегда стоит иметь в парке девайсов целевые устройства, а так же устройства из верхней и нижней планки (минимально допустимые и флагманские).
Неплохая альтернатива Appium — codecept.io
Если вам предпочтителен JS в качестве языка для разработки автотестов — warmly welcome to CodeceptJS. Подробнейшая документация, тесты не занимают много экранного места (вы поймете о чем я) и активная поддержка всех современных операционных мобильных систем заставят задуматься в пользу этого инструмента.
После того как ваш проект оброс значительным количество автотестов было бы неплохо автоматизировать их запуск при каждой сборке нового билда. Кастомизировать и настроить это вам помогут современные системы CI\CD. Лично я предпочитаю Jenkins или Teamcity, но здесь уж дело вкуса.
Еще одним инструментом, позволяющим сократить и оптимизировать регрессионное тестирование является матрица зависимостей (она же матрица трассировки). Если коротко — это таблица, в которой проставляются зависимости элементов системы друг от друга. Для составления такой матрицы требуется разбираться в коде приложения, а также очень поможет проконсультироваться с архитектором проекта. Но в итоге такой инструмент позволит существенно (на моей памяти — до 40%) сократить время регрессионного тестирования. Более подробно о матрице можно прочитать здесь.
Hint’ы
Вот мой набор полезных хинтов для того, позволяющих найти максимальное количество ошибок, учитывая специфику мобильных приложений.