Приветствую!

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

Меня зовут Антон, я QA Mobile в компании MobileUp. В статье я разберу, что такое пермишены, для чего нужны, какие виды существуют, где их можно найти и как тестировать. Эту статью я пишу исключительно с точки зрения ручного тестирования, но в конце текста оставлю интересные ресурсы, которые могут пригодиться для QA Auto (но это не точно ?).

Что такое пермишены

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

Какие задачи решают permissions:

Защита конфиденциальности. Пермишены позволяют пользователю контролировать, какие данные и функции его устройства могут использовать установленные приложения. Например, приложение может запросить доступ к камере, контактам, геолокации и другим функциям.
Снижение рисков безопасности. Благодаря системе разрешений пользователь может предотвратить несанкционированный доступ приложений к чувствительной информации или функциям устройства. Это помогает защитить смартфон от злоумышленников.
Управление ресурсами. Пермишены помогают управлять системными ресурсами вроде батареи, памяти и процессора. Ограничив доступ к ресурсоемким функциям, система способствует более эффективной работе устройства.
Информированность пользователя. Система разрешений предоставляет пользователю информацию о том, какие функции устройства использует приложение. Это повышает прозрачность и позволяет делать осознанный выбор о том, стоит ли устанавливать приложение или предоставлять ему определенные разрешения.

В Android и iOS реализации системы пермишенов отличаются.
Android. Приложения запрашивают пермишены во время установки и в процессе использования. С появлением Android 6.0 (Marshmallow) Google внедрила модель «пермишенов на лету», позволяющую отправлять запросы в момент первого использования функции, а не в момент установки приложения.
iOS Apple всегда следовала модели запроса разрешений в момент первого использования. Приложения должны запрашивать разрешение на доступ к функциям или данным, когда они впервые нужны для работы. iOS также предлагает более детальные настройки конфиденциальности для управления доступом приложений к различным функциям.

Виды пермишенов

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

Пермишены, требующие разрешения

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

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

Рассмотрим наиболее распространенные разрешения для iOS и Android.

Android

Геолокация. Доступ к точному или приблизительному местоположению.
Камера. Доступ к камере для съёмки фото и видео.
Запись аудио: Доступ к микрофону для записи аудио.
Чтение и запись в хранилище. Доступ к файлам и медиа на устройстве.
Контакты. Доступ к контактам пользователя.
SMS. Доступ для чтения, отправки или получения SMS.
Телефон. Доступ к статусу телефона, включая чтение идентификатора телефона, текущего сетевого состояния, а также возможность совершения и управления звонками.
Интернет. Доступ к интернету и сетям.
Bluetooth. Доступ к Bluetooth для пары и взаимодействия с другими устройствами.
Уведомления. Показ уведомлений на устройстве пользователя.
Автозапуск при запуске системы. Разрешение приложению автоматически запускаться при загрузке устройства.

iOS

Данные геолокации. Запрос доступа к местоположению пользователя. Может использоваться, например, для отображения карт или предоставления локализованной информации.
Камера. Доступ к камере устройства для съёмки фотографий или видео.
Фотогалерея. Доступ к фотогалерее для чтения или сохранения изображений и видео.
Микрофон. Доступ к микрофону для записи аудио.
Контакты. Доступ к адресной книге устройства для чтения или изменения контактов.
Календарь. Доступ к календарю для чтения или изменения событий.
Напоминания. Доступ к напоминаниям для чтения или создания новых.
Здоровье и Фитнес. Доступ к данным о здоровье пользователя, собираемым устройствами и приложениями.
Bluetooth. Запрос доступа к Bluetooth для взаимодействия с другими устройствами.
Уведомления. Запрос разрешения на отправку уведомлений.
Фоновое обновление. Разрешение на выполнение задач в фоновом режиме.

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

Пермишены, не требующие разрешения

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

Android

В Android эти разрешения относятся к категории "Normal permissions". Вот некоторые из них:

ACCESS_NETWORK_STATE. Позволяет приложениям получать информацию о сетевом подключении, например, находится ли устройство в режиме роуминга или какая сеть используется.
ACCESS_WIFI_STATE. Разрешает приложениям доступ к информации о состоянии Wi-Fi.
BLUETOOTH. Позволяет приложениям подключаться к сконфигурированным устройствам Bluetooth.
INTERNET. Разрешает приложениям открывать сетевые сокеты.
RECEIVE_BOOT_COMPLETED. Позволяет приложению получать уведомление после завершения загрузки системы.
VIBRATE. Разрешает контроль вибромотора.

Подробнее о всех «нормальных» пермишенах можно узнать по ссылке на официальном сайте:
1) Для Kotlin
2) Для Java

iOS

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

Однако есть несколько примеров пермишенов, для которых можно обойтись без него:

Access to Basic Device Information. Позволяет получить информацию о модели устройства, операционной системе и версии.
Network Access and Information. Использование интернета через API и проверка состояния сети (Wi-Fi, сотовая сеть, наличие интернета).
Device Orientation and Motion. Определение изменений ориентации устройства (портретный или ландшафтный режим), а также доступ к акселерометру и гироскопу для функций, связанных с движением устройства.
Local Notifications. Создание и управление локальными уведомлениями без запроса разрешения на отправку уведомлений.
Multimedia Control. Управление воспроизведением мультимедиа, например, пауза и воспроизведение музыки.
Time and Date. Доступ к текущему времени и дате устройства для использования в приложении.
UI Customization. Настройка пользовательского интерфейса в пределах приложения, такие как темы, шрифты и цвета.
Sensor Data. Доступ к неличностным датчикам, таким как датчик света или датчик приближения.

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

Где хранится информация о имеющихся у приложения разрешениях в Android и iOS

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

Android

На платформе Android информация о разрешениях хранится в файле AndroidManifest.xml. Этот файл является обязательным компонентом любого Android-приложения и должен находиться в корневой директории проекта. В AndroidManifest.xml разработчики объявляют необходимые приложению разрешения, используя элемент <uses-permission>. Например, для запроса разрешения на доступ к камере в файле манифеста будет указана строка:

Пользовательская система Android затем использует эту информацию для предоставления соответствующих запросов на разрешение при попытке приложения использовать защищенные функции.

Информацию о необходимых разрешениях приложения можно найти в Android Studio в файле AndroidManifest.xml или же можно вывести этот файл в дебаг-панель непосредственно внутри мобильного приложения (если такая есть и при помощи коллег-разработчиков, например?).

iOS

В операционной системе iOS информация о разрешениях, которые приложение может запрсить у пользователя, хранится в файле Info.plist (список свойств). Этот файл содержит конфигурационные данные приложения и используется для хранения различной информации, включая тексты запросов на разрешения. Разработчики должны включить в Info.plist специальные ключи для разрешений, которые они хотят запрашивать, а также поясняющие сообщения, которые будут показаны пользователю в момент запроса. Например, для запроса доступа к камере необходимо добавить ключ NSCameraUsageDescription с описанием, почему приложению требуется доступ к камере.

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

В «чистом» виде файл Info.plist внутри вашего проекта можно найти в Xcode версии 12 или старее.

В Xcode версии 13 и новее эта информация хранится здесь — Project (нужно нажать на иконку проекта в левой панеле) > Targets > Info

Файл Info.plist можно вывести в панель как было до Xcode 13, если возникнет такая необходимость, шаги описаны в этой статье.

Как тестировать пермишены

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

Понимание требований и документации

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

Сценарии тестирования

Нужно разработать тестовые сценарии для проверки поведения приложения в различных условиях:

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

Здесь при проверках понадобится обращение к файлам конфигов пермишенов в AndroidManifest.xml и Info.plist для сравнения, что доступы действительно получены или отозваны.

Производительность и безопасность

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

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

Тестирование на разных устройствах и версиях ОС

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

Использование реальных сценариев

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

Проверка документации и UI/UX

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

Автоматизация тестирования

Этот пункт здесь потому, что пермишены это как раз-таки тот функционал, который хорошо можно автоматизировать. Для автоматизации тестирования для проверки разрешений подойдут следующие инструменты: Appium, Espresso для Android, XCTest для iOS. Это может включать автоматическое предоставление и отзыв разрешений для тестирования приложения в различных сценариях.

Пример применения подхода

Разберём применения подхода на примере конкретного приложения для записи и сохранения звуковых заметок (запись производится во внутреннюю песочницу приложения).
Приложение поддерживает Android 9.0 и выше и iOS 14 и выше.

Изучение документации и создание списка разрешений

Android

Проверяем AndroidManifest.xml для доступа к следующим разрешениям:

Запись аудио. android.permission.RECORD_AUDIO — это разрешение необходимо для доступа к микрофону устройства для записи аудио.

Сохранение файлов

Для версий Android до 10 (API level 29):

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

Для Android 10 (API level 29) и выше можно не использовать разрешения WRITE_EXTERNAL_STORAGE и READ_EXTERNAL_STORAGE благодаря концепции "scoped storage", которая ограничивает доступ к файлам во внешнем хранилище.

iOS

Проверяем Info.plist для NSMicrophoneUsageDescription.

Запись аудио. NSMicrophoneUsageDescription — в Info.plist должно быть указано описание, объясняющее, почему приложению требуется доступ к микрофону. Это описание покажется пользователю при запросе разрешения на использование микрофона.

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

Сценарии тестирования разрешений

Android

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

Без разрешения. При отклонении разрешения на микрофон, приложение предлагает только просмотр и воспроизведение сохраненных заметок.

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

Повторные запросы. Если пользователь пытается снова записать звук, приложение должно корректно запросить разрешение.

iOS

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

Без разрешения. iOS автоматически блокирует доступ к функционалу и предоставляет уведомление с возможностью перейти в настройки для изменения разрешений.

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

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

Производительность и безопасность

Проверка на утечки данных. Смотрим на запрашиваемые разрешения в приложении и на прописанные разрешения файлах Info.plist и AndroidManifest.xml.

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

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

Тестирование на разных устройствах

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

https://habr.com/ru/articles/516160/
https://habr.com/ru/articles/513018/
https://habr.com/ru/companies/otus/articles/509596/

Использование реальных сценариев

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

Проверка документации и UI/UX

iOS

Проверка документации:Смотрим, что в Info.plist приложения чётко и точно описаны причины запроса доступа к микрофону через NSMicrophoneUsageDescription. Описание должно ясно сообщать пользователю, почему приложению необходим доступ к микрофону для функции записи звуковых заметок.

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

Android:

Проверка документации.Проверяем, что в AndroidManifest.xml корректно указаны разрешения RECORD_AUDIO и при необходимости WRITE_EXTERNAL_STORAGE для версий до Android 10. Документация приложения должна также объяснять, зачем эти разрешения требуются, особенно если приложение сохраняет записи в общедоступном месте.

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

Автоматизация тестирования

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

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

Пермишены (permissions) для тестировщика: зачем нужно, что такое и как с этим работать