На старте тестирования, вне зависимости от того, новый это проект или такой, что его стоило бы уже похоронить, в целом всегда ясно, с чего начинать. Если, конечно, к момент старта тестирования ни одно из звеньев цепи не слажало. Обычно тестировщики вычитывают требования и прочие документы с нерусскими названиями, типа «БиЭрКью», «ЭсАрки» и «Юзер стори» и прикидывают, как написать тест кейс, чтобы он проверил выполенения всех этих документов. Это всё понятно, на поверхности и нет смысла на этом задерживаться. Но есть ещё поведение самого Android, о котором иногда не знают не то что аналитики, но даже архитекторы и некоторые разработчики. А помня, что с AOSP никто не работает, только с кастомами, таких особенностей всплывает довольно много. И я говорю не о стрессовых сценариях, когда памяти нет или батарейку внезапно вынули (как-то встречал негодование человека на терминал GNU/Linux, что тот не показывает пароль при вводе, а у него глючная клавиатура и он не понимает, вводит пароль или же это клавиатура снова не работает), а о штатном поведении кастомизации Android и даже поведении, заложенном в AOSP. То есть штатные поведения системы, которые могут отрицательно сказаться на тестируемом продукте. Так называемые, негативные сценарии.
Я кратко опишу некоторые негативные сценарии и попытаюсь дать конкретные примеры.
- Проблемы связи. Самый просто пример — Fly Mode. К примеру, приложение для заметок Google Keep либо не тестировали в режиме полёта, либо найденные баги не повлияли на релиз. Воспроизвести проблему очень просто:
- Включаем режим полёта
- Тапаем на строку Take a note…
- На появившемся экране выполняем действие Delete
- Наслаждаемся покадровой анимацией движения сохранённых ранее заметок
Кроме Fly Mode есть и не стабильное подключение с потерей пакетов, и очень медленное подключение, и закрытые порты, через которые работает ваше приложение, и наличие Wi-Fi подключения, но без доступа к Интернету.
- Нет доступа к магазину приложений. К примеру, чтобы протестировать покупки внутри приложений, нужно, чтобы сборка была выложена в магазин в специальный раздел. Если её там нет, либо там лежит не та же самая версия (речь про version code — внутреннюю версию), то покупки вы не протестируете. Если пользователь улетел в отпуск в Китай, где с подключением к Google Play всё очень печально, у него не должна отваливаться лицензия, за которую он заплатил деньги.
- Работа приложения при ограничении разрешений, если Target API Level ниже 23, то есть меньше Android 6, и когда версия API 23 и выше. В первом случае приложение является легаси, но разрешения отобрать всё равно можно. Во втором случае оно ещё начнёт получать новые исключения, которых не знавало раньше.
- Режим экономии заряда батареи. Реализация как Doze и App Standby, так и альтернативные реализации альтернативно одарённых производителей типа Samsung (да и STAMINA от Sony в первой версии), когда всё реализовано ужасно неправильно, но с этим придётся жить. Приложению допустимо не выполнять проверки в срок, не отправлять статистики, не обновлять данные. Но не допустимо падать, зависать, никогда не выполнять запланированные задачи.
- Изменение даты, времени, часового пояса. Люди могут летать в отпуски и командировки в другие страны, где другой часовой пояс. Если самолёт пересечёт 180-ый меридиан, то пользователь вполне может попасть «во вчера» с точки зрения приложения.
Реальная история провала. Родительский контроль в KIS для Windows появился в версии 7.0 в 2006 году. В то же время в продукте существовал встроенный новостной агент, вовсе не такой, как сейчас. Предполагалось, что через него будут рассылаться разные новости об угрозах, всякие «что нового» и подобное. В релизной версии, которая уже была установлена у пользователей, был баг. Если перевести время в Windows назад, до начала действия лицензии, то защита отключалась. Строго говоря, не администраторы не могут переводить время, но 10 лет назад в фирмах особо не следили за правами пользователей и там каждый бухгалтер был локальным администратором. Один из наших клиентов в своём маленьком офисе настроил родительский контроль так, чтобы пользователи не могли шариться по Интернету, кроме как в дозволенные сайты. Драконовски настроил и паролем защитил настройки. Всё работало нормально до тех пор, пока во встроенный новостной агент не прислали новость, что пора обновиться на новую версию 7.0.1 где, помимо прочего, исправлена ошибка, из-за которой отключается защита при переводе времени в обратную сторону до начала старта лицензии. Пользователь прочёл новость, обрадовался и вырубил защиту предложенным методом. Через несколько дней эта история от него попала на тогда ещё популярный bash.org.ru. С тех пор новости подобного рода больше не приходили пользователям.
И не думайте, что подобные ошибки не допускает. Вспомните историю с iOS, которая произошла в этом году, хотя прошло то всего 3 месяца с начала года (Примечание: да, это достаточно старая лекция, я давно хотел её выложить). Телефоны вырубались, если перевести время ближе к началу исчисления unix time. И как Apple исправил эту ошибку? Они запретили переводить время дальше, чем критичная дата, что НЕ являлось исправлением проблемы. Злоумышленники стали поднимать свои Wi-Fi точки с названиями, которые обычно есть во всяких МакДоналдсах и через них передавать поддельное время. Устройства подключались к таким точкам автоматически и обнаруживали NTP серверы, у которых запрашивали время. Apple банально не позаботилась о том, чтобы iOS не использовала поддельные NTP серверы. Таким образом iOS вновь окирпичивались. - Изменение локали системы, языка интерфейса. Пользователь вправе менять язык системы по сто раз на день и никто не может ему этого запретить. Задача тестировщика — убедиться, что продукт во-первых правильно реагирует на это (меняет язык на нужный автоматически), во-вторых вообще не падает. Кроме локали пользователь вправе менять гарнитуры и кегли, подбирая такие, которые ему комфортно читать. Приложение не должно расползаться, если пользователь вносит разумные изменения.
- Tapjaking. Я упомянал об этой штке в самой первой лекции. Напомню, это перехват тапов, которые принимает активити приложения А, тогда как пользователь пытался добраться до приложения Б. Просто активити приложения А прозрачное. Это выглядит как не безопасное решение Google, но так работают приложения по управлению яркостью и цветовой температурой на устройствах. Пользователям удобны такие приложения и раз Android позволяет им работать без наличия root, это нужно учитывать. К примеру, если у вас приложение, которое для авторизации использует код или, скажем, рисунок, вы обязаны использовать защиту от тапджекинга, например выставить filterTouchesWhenObscured в true.
- Прямой вызов Activity. Я уже говорил об этом, но повторим. Активити — это одна из точек входа в приложение. Вполне допустимо иметь несколько разных активити, которые могут вызывать внешние приложения, мало ли зачем. Это будут exported активити. Но может быть так, что для вызова некоторого активити нужно ему передать параметры. А стороннее приложение не передаст их. В лучшем случае пользователь увидит какой-то кривой экран, в худшем — ваше приложение упадёт. Так что не стоит, так сказать, светить голой жопой наружу без необходимости. По умолчанию флаг exported выставлен в true и, если вы уверены, что внешние приложения не должны вызывать их, стоит выставить false. Ну а тестировщик должен проверить, как будет вести себя приложение, если вызывать его активити из других приложений.
- Системный киллер. Вообще он называется OOM Killer — Out Of Memory Killer. Система начинает УБИВАТЬ, если приложению, с которым взаимодействует пользователь в данный конкретный момент, не хватает памяти для работы. Конечно, киллер не тупой, подчиняется опредлённым алгоритмам, выбирая цели (к примеру, система легко убьёт background service, но до последнего будет спасать foreground service; форэгранд сервис это, обычно, тот самы, который рисует свою иконку в области уведомлений, например — плеер), но суть такова. Как правило, на современных устройствах OOM Killer сильно не лютует. Сейчас памяти ставят от одного гигабайта и выше. Но это не касается игр. Игры настолько тяжёлые, так много отжирают памяти, что сколько не отсыпь — всё равно будет мало. И вообще, чем больше оперативной памяти будут засовывать в аппараты, тем жирнее будут приложения, а игры будут самыми жирными. При этом они останутся всё такими же унылыми и ненужными.
Итог таков, что ваш продукт гарантированно попадёт под ООМ Киллер. Ваша задача состоит в том, чтобы убедиться, что ни к чему плохому это не приводит и продукт поднимется, как только приложение-жиробасина будет схлопнута системой (если это требуется от продукта, конечно). А система сделает это при первой возможности, жить в фоне такой жиробасине она не даст.
Ещё один вывод — ваше приложение также не должно быть жиробасиной. Любые утечки должны обнаруживаться разработчиком ещё до того, как он напишет реальный код. Ваши тесты производительности обязательно должны иметь сценарии проверки, когда monkey генерирует тонну событий. Если код написан качественно, то сборщик мусора освободит память и система не убьёт процесс приложения. Если всё плохо и приложение течёт из всех щелей, система его пристрелит. Конечно, оно взлетит после этого вновь и память есть уже не будет, потому что после убийства процесса сборщик мусора подчищает всё, но если манки показал, что приложение течёт в его тесте за 15 минут, то у пользователя эти течи хоть и позже, но всё равно проявят себя. - Большие данные. Если ваше приложение работает с пользовательскими данными, будьте готовы к тому, что пользователь скормит что-то очень большое безо всякой задней мысли. Например, я, как пользователь, вполне ожидаю, что клиент Youtube загрузит мой ролик, каким бы тяжёлым этот ролик не был. Я ожидаю, что архиватор влезет на любую глубину архива, который весит в 5 раз больше, чем вся доступная оперативная память устройства. Это — нормально. Если кто-то вам говорит, что «никто никогда не будет скармливать такие большие файлы», то, скорее всего, говорящий просто не очень хороший разработчик.
- Самым глупой и от того смешной ситуацией, вызывающей неправильную работу приложения, вплоть до падения, является простой поворот экрана. Сколько подобных падений было выявлено на этапе тестирования! Особенно если появляется какой-нибудь попап. На попапах опытный тестировщик сразу начинает переворачивать телефон! Бывало и такое, что вся команда тестировала продукт на одних только телефонах, где поворот экрана для приложения был заблокирован. А потом, когда завезли планшетов, оказалось, что на планшетах приложения падает чуть ли не в каждом экране. А потому что фрагменты. На экране и на телефоне были разные интерфейсы и неправильное использование фрагментов приводило к печальному итогу.
- Двойные, тройные тапы. Почему-то некоторые считают, что никто не делает множественные тапы по элементам интерфейса. Но нет! Я делаю! И не потому что тестирую, а потому что у меня в руках может быть старый телефон на Android 4.0, который и так еле ворочается, так ещё и экран у него не очень отзывчивый. Может быть не понятно, было нажатие или нет и получаются двойные тапы. Не потому что они «дабл» (в смысле не те, которые делаются с интервалом менее секунды), а потому что их получилось два и больше, пока приложение «думало». Например, пока формировало список из множества элементов.
- Одна из удобных фич Android 6 при недостаточном тестировании приводит к ужасным результатам. Вплоть до того, что её использование явно запрещается в приложении, что, пока, допускается со стороны Google. Эта фича — бэкап и восстановление из бекапа. Она, кстати, не нова, бэкап появился ещё в Android 2.2, но я не знаю ни одного приложения, которое бы использовало эту плюшку.
Сами по себе создание резервной копии и её восстановление не страшны. Проблемы начинаются, если в продукте используется привязка к идентификатору устройства и идентификатору инсталляции. Даже в пределах одного устройства это может приводить к проблемам, а ведь восстановление из бекапа допускается самим Android на любое устройство с Android 6 на борту: система бекапит приложения с устройства А, а пользователь покупает устройство Б и восстанавливает их все на нём. И работают эти приложения одновременно на двух устройствах, хотя идентификаторы у них разные. Если это клиент-сервереное приложение, где всё общение делается на токенах, здесь возникают куча проблем.
Боевым примером могу назвать классное приложение Talon for Twitter. Я не делал сброс устройства уже очень давно и потому не знаю, исправил ли автор эту ошибку. Когда я сообщил ему о ней, он мне ответил, почему ошибка возникла (хотя я и так знаю, почему!), но не сказал, будет ли он исправлять поведение. В общем, в этом приложении есть своеобразный мастер установки, который рассказывает о возможностях этого Twitter клиента, по пути запрашивая нужные пермишены. Всё чётко по гайдлайнам Google, прямо по нотам. Когда мастер настройки пройден и нужные пермишены получены, взводился флаг об этом, чтобы повторно не проходить настройку каждый раз. И приложение бэкапилось вместе с этим флагом. Вместе с ним оно и восстанавливалось. Хотя по умолчанию для всех приложений нового типа (т.е. targetApi level >= 23) разрешения отключены. Запускаешь приложение, а оно не может нормально работать. Потому что нет проверки на доступность пермишенов, все проверки остались в мастере первоначальной настройки, который не запускался, потому что флаг был выставлен в значение «мастер уже пройден». Кроме того, после запуска клиент не загружал твиты, давая отлуп от самого Twitter. Потому что прикопанный токен был не валиден на новой инсталляции и нужно было запрашивать новый, а этот запрос также делался в мастере установки на первом же шаге! - В Android, начиная с версии (если мне не изменяет память) 2.2.1, появилась возможность штатно перемещать часть данных приложения на карту памяти. Потихоньку эту возможность стали зарезать, пока в Android 6 Google не дал ей вторую жизнь, значительно улучшив. Если производитель устройства в своём кастоме не сломал поведение AOSP в этой ситуации, то, как только Android обнаруживает карту памяти, он предлагает сделать выбор, будет ли пользователь её иногда вытаскивать или нет. Если пользователь говорит, что не планирует её отключать, то Android форматирует карту в свою файловую систему и подключает как часть основной памяти, позволяя устанавливать туда приложения. И здесь несколько подводных камней:
- Если приложение использует захардкоженные пути, то всё пропало. Но это настолько плохой тон, что, надеюсь, никто так не делает.
- Если приложение запросило у системы пути при первом запуске и прикопало их навсегда, то будет ровно тоже самое, что и с захардкоженными
- По мере обновления приложений, пользователи будут получать новые версии из магазина приложений и ставить их поверх существующей. Потому проверка обновления приложения на новую версию — обязательный сценарий. В обычной ситуации всё должно быть нормально, но когда приходится поддерживать множество специфичных устройств своим специфичным поведением, формат настроек может меняться. Почти никогда это не приводит к падениям, если код написан более менее качественно, обрабатывает различные исключения. Но просто потеря части настроек — это уже плохо. К примеру у нас была ситуация, когда пользователи месяцами формировали список антиспама, блокируя номера такси, банков, коллекторских служб, а затем, после обновления на новую версию, все списки терялись. Именно потому что сменился формат настроек и именно здесь, именно в этом месте, настройки не читались новой версией продукта.
- Кроме обновления продукта на новую версию, бывает более редкий, но гораздо более хардкорный вариант — обновление самой прошивки на новую версию, да при работающем продукте. Я приведу в пример два случая, один из которых уже рассказывал.
- Обычный Security Update для Android 5.1, который взял и отключил работающие всю жизнь фишки ОС, которым пользовалось приложение
- После обновления Android 4.4 на Android 5.0, менялись пути установленных приложений. Раньше установленные приложения хранились по одному привычному пути (/data/app/com.package.name.apk). В одном из наших продуктов для внутренних целей, связанных с безопасностью, есть проверка на то, по какому пути защищаемое приложение доступно и не менялся ли он. Прилетело обновление до 5.0 и абсолютные пути изменились для уже установленных приложений (data/app/com.package.name/base.apk). Продукт бил тревогу, что приложение скомпрометировано. Поправили, конечно.
Ну, пока всё. Сейчас я пишу доклад про проблемы, специфичные только для конкретных версий Android, только для конкретных прошивок, только для конкретных устройств. Так что не отключайтесь! Впрочем, часть вы и так знаете — описаны прямо в этой серии записей.
Пока-пока!
Комментариев нет:
Отправить комментарий