Комментарии 88
Задаю вопрос не с 13, потому что это всё-таки рабочий день и с 13 до 20 я работаю.
Какую роль выполняет Каспрессо, я так и не понял, честно говоря. Посмотрел примеры отсюда github.com/KasperskyLab/Kaspresso и всё равно не понял. В пример много строчек (правда из-за скобок), которые делают в итоге полтора действия.
Вот код, который сейчас у меня под рукой:
/**
* Пин запрашивается после сворачивания по Home при включенном блоке на сворачивании
*/
@Test
fun pinLockByCollapse() {
enablePin(withCollapse = true)
mUiDevice.pressDeviceHomeButton(false)
mUiDevice.clickPassphraseUnlockedNotification()
mPinLockScreen.verifyEnterPinInLockScreen()
}
Здесь гораздо меньше строк и гораздо больше проверок. Каждая из этих строк делает полные проверки экранов, всех элементов, то есть тут десятки проверок. Зачем бы мне завязываться на внешний фреймворк, по которому нет вообще никаких гарантий? Типа, завтра из компании уйдёт человек, который вот этим рулит и проект будет заброшен и быстро устареет.
Что касается взаимодействия и распараллеливания, то для этого достаточно несколько строчек на питоне (прошу прощения у не знаю кого, ибо на начало написания тех скриптов я ещё не ведал, что творил) или го (сейчас наступаю на те же грабли, но на новом языке :)) и тесты будут гоняться одновременно на любом количестве устройств, а также будут работать e2e тесты между несколькими устройствами одновременно.
При этом сопровождение будет несоизмеримо легче, потому что каждый дополнительный фреймворк тащит с собой дополнительные ошибки и проблемы обновлений. В случае ошибок частенько бывает так, что тестировщик напишет какой-то костыль, который её обходит. Через сколько-то времени выходит новая версия с исправлением, но никто не читает все изменения, потому что некогда, и костыли не убирают и так они остаются мусором. Сквозь этот мусор через несколько лет продираются совершенно другие люди со словами «ну и нафига, ведь и так всё работает нормально».
А ещё возникает проблема обновления, когда зависимости не обновляют по несколько лет, а потом ррраз! И ничего не работает, всё сдохло, нужно теперь разбираться с каждой отдельной проблемой, коих тут вагон. Каждый androidTestImplementation приносит свои проблемы и люди стараются в итоге как можно дольше не обновлять зависимости. Что в итоге выливается в полную неработоспособность системы, когда обновление всё-таки приходится делать.
В общем, я не понимаю сути Каспрессо, его преимуществ. Можете объяснить скептику? Только, пожалуйста, не нужно ставить в преимущества фреймворка Page Object, потому что это не является его заслугой.
Ну и вопрос общий. Как вы выбираете, тянуть какую-то библиотеку в проект или нет? Скажем, вот есть офигенный RxJava, давайте его тащить, без него жизни нет. А тут бах и корутины. Оставляем эрыкс? А зачем? Убираем? А зачем тащили? А не боитесь, что очередная библиотека притащит с собой уязвимость, о которой не предполагали? Притащили, скажем, библиотеку для отображения svg на Андроид 1.2, а потом выяснилось, что если на /sdcard/ лежит файл debug-template-lib-test.svg, то либа пытается вгрузить этот файл, чем бы он на самом деле ни был. Не боитесь такого?
Я выделил несколько основных вопросов:
1) Какую роль выполняет Каспрессо?
2) Зачем бы мне завязываться на внешний фреймворк, по которому нет вообще никаких гарантий?
3) Как вы выбираете, тянуть какую-то библиотеку в проект или нет?
Отвечу по частям.
1) Kaspresso – это многофункциональный фреймворк, который облегчает написание UI-автотестов для Android. Разработчики начинали с создания обертки над Kakao и Espresso для уменьшения количества флаков в тестах. По мере накопления опыта автотестирования у нас – развивался и Kaspresso. Получилось, например, ускорить в 10 раз работу с UI Automator. В планах – помощь с настройкой инфраструктуры для запуска тестов.
Более подробную информацию о фичах Kaspresso можно посмотреть в репозитории.
2) Фреймворк развивается несколькими людьми внутри компании, плюс сообществом разработчиков вне её. Код полностью open-source, поэтому его можно форкать, развивать, и использовать без завязки на наш репозиторий. Если вы сможете помочь нам в его развитии – Pull Request-ы приветствуются.
3) Уязвимости в используемых библиотеках, а также возможность их использования в соотвествии с лицензионным соглашением проверяются отдельными командами Лаборатории.
Первоначальное решение о необходимости затянуть библиотеку принимают разработчики. Если это достаточно узко специализированная библиотека, на которую не завязывается весь проект – тут всё просто.
На вашем примере перехода с RxJava2 на Coroutines расскажу про процедуру принятия решения.
Инициатор внедрения должен детально изучить новую библиотеку. После чего он предлагает команде рассмотреть плюсы от такого перехода и возможные проблемы. Если решение о внедрении принимается – мы стараемся подтянуть уровень знаний всей команды о ней. А инициатор становится неким "евангелистом", которому уходят наиболее сложные кейсы. Только после этого происходит переход.
В новом проекте без RxJava2 мы можем сразу начать использовать Coroutines.
Библиотека втягивается только в случае, если она несет значимый функционал, самостоятельная разработка которого сложна и займет длительное время. Примером тут может быть openssl, — самостоятельно данный функционал реализовать затруднительно, и подобная реализация неизбежно будет значительно хуже оригинала.
Библиотеки, предлагающие решение какие-либо архитектурные проблем, в SDK не затягиваем.
Причин на это несколько:
— Возможные конфликты между версиями библиотек, используемых в SDK, и аналогичными библиотеками в проектах, в которые данный SDK будет встраиваться.
— Увеличение объема бинарного кода SDK.
— Появление зависимостей на сторонний код, план развития которого в будущем нами не контролируется. В качестве примера могу привести недавний коммит в код библиотеки Sqlite, полностью убравший из новых версий данной библиотеки поддержку крипто кодеков. Чем больше подобных зависимостей в проекте, тем больше вероятность того, что часть из этих внешних библиотек в какой-то момент перестанут поддерживаться их авторами. В этом случае придется их поддерживаться самостоятельно или искать какую-то замену. В случае с SDK подобные замены могут приводить к нарушению обратной совместимости и вызывать дополнительные сложности по переходу на новую версию SDK у клиентов, которые его используют.
Кроме того, исследовать поведение подозрительного приложения можно в специально созданной для этого контролируемой среде. Такую среду можно создать и на устройстве пользователя, но чаще дистрибутивы подозрительных приложений анализируются в специально предназначенной для этого облачной инфраструктуре.
На Android также есть API, позволяющий перехватывать трафик других приложений. С его помощью можно анализировать сетевую активность приложений, обнаруживать аномалии и сетевые атаки. Для использования этого API необходимы специальные разрешения пользователя, кроме того, одновременно его может использовать только одно приложение на устройстве. Из-за подобных ограничений используют этот API для обнаружения вредоносного ПО не часто, но, тем не менее, такая возможность на Android есть.
2. Использовали ли ферму STF? Расскажете по поводу примеров интеграции?
Ферма — у нас своя, как раз на базе OpenSTF.
Примеры интеграции:
- ферму используют ручные тестировщики и разработчики, как инструмент, позволяющий иметь доступные под рукой устройства в режиме 24/7 (что стало особенно критично в текущих условиях вынужденной удаленной работы).
- автотесты используют ферму через разработанный в компании jenkins-плагин.
- благодаря мониторингу использования устройств можно максимально оптимизировать пул устройств доступных для тестирования.
Когда приложение под Android, и KIS и KES начнут поддерживать работу с MS Edge? Завтраками кормите уже несколько месяцев. Десктопные версии с этим браузер ом дружат. Неужели MS внесли в chromium столько изменений, что совместимость трудно реализовать?
2. Когда в Kaspersky Internet Security для Android появится возможность добавить «Резервный код»?
3. Когда можно будет делать резервную копию базы паролей на мобильном устройстве с Kaspersky Password Manager для Android?
4. Когда будут Push уведомления в приложении Kaspersky Safe Kids, чтобы разрешить ребенку то или иное приложение? Будет ли приложение когда-нибудь блокировать Google Assistant, как ваши конкуренты?
5. Почему разработчики очень редко или вообще не отвечают своим бета-тестерам?
1. Уже реализовано. В Kaspersky Internet Security поддерживается, например, браузер Huawei, что особенно актуально для всех новых HMS-only устройств без google play services и браузера Chrome.
2. Рискну предположить, что под “Резервным кодом” вы понимаете некий запасной код доступа, используемый в таких фичах KIS for Android, как Anti Theft и App Lock. Резервный код вы можете забыть так же, как и основной. Если боитесь забыть код, рекомендуем использовать доступ по отпечатку пальца.
3. Поддерживать не планируем, так как непонятна потребность. Пароли в Kaspersky Password Manager хранятся в облаке, локальный бекап – это потенциальная дыра в безопасности, какую проблему решает локальный бекап при наличии облачного – непонятно. Если поясните, смогу ответить более точно.
4. «Request for Access» для приложений в Kaspersky Safe Kids уже реализован. Мы не считаем правильным решением полностью блокировать Google Assistant, так как он может быть полезен ребенку, при этом мы блокируем нежелательный для ребенка контент в поисковой выдаче Google Asistant. Поясните, в каких сценариях работы с Google Assisst конкурентные решения с вашей точки зрения работают лучше, тогда я смогу дать более развернутый комментарий…
5. Приносим извинения, если уделяем недостаточно времени. Фанклуб ЛК – это классная команда! Приглашайте – пообщаемся, ответим на все вопросы, вот такой, например, формат в свое время хорошо зашел.
Вспомнил почему мне нужна была резервная копия. Случайно удалил не ту папку с данными и эти изменения успели синхронизироваться с облаком и на других устройствах. При обращении в поддержку предложили откатить на неделю назад, то есть я терял больше данных (очень активно пользуюсь программой каждый день), чем сам ошибочно удалил. А так смог бы перед изменениями сделать резервную копию и откатить на нужный мне срок. Пришлось восстанавливать данные для нескольких сайтов вручную.
P.S. По ссылке написано, что "Если вы перешли на бесплатную версию и количество записей в вашем хранилище превышает ограничение бесплатной версии, вам требуется выбрать записи для дальнейшего использования". Вы сами выбираете, какие записи оставить.
И какие сейчас открытые вакансии есть?
Привет. Расскажу про навыки Android-разработчиков, которые делают пользовательские продукты.
Мы следим за развитием индустрии. У нас используются как новейшие библиотеки из Jetpack, Coroutines, так и проверенные временем Clean Architecture, RxJava2, Moxy и многое другое. Весь новый код пишем на Kotlin. Конкретный стек зависит от проекта. Мы всегда за "обновление", если это помогает нам в работе (подробнее о выборе библиотек отвечал выше).
Мы также активно смотрим за новинками в библиотеках и подходах Android-разработки, такими как Compose и многомодульность.
Разработчикам так же полезно разбираться в базовом уровне в C++ и JNI для обертки используемых нативных библиотек.
Более подробно про такую вакансию можно посмотреть тут.
Это старый и глубоко пустивший корни стереотип, что в Касперском сидят только бородатые хакеры и пишут на C++.
Расскажу про iOS.
На текущий момент вся платформенная разработка ведется на Swift. Objective-C осталось не так много и, в основном, в стареньких, редко меняющихся кросспроектных фреймворках, которые “переписывать ради переписывания” выглядит расточительным. Еще, конечно, мы используем ObjectiveC/C++ в качестве бриджа между продуктовым Swift-кодом и компонентами на С++, поставляемыми другими командами Лаборатории, не относящимися к мобильному штабу. Но, повторюсь, основная разработка ведется на Swift, поэтому мы ожидаем, что разработчик нашего направления хорошо знаком именно с этим языком, его сильными и слабыми сторонами, понимает, как писать эффективный, производительный и понятный код именно на Swift, осознает, как происходит диспетчеризация вызовов и как с этим “не напортачить” в критических модулях =)
В работе, в основном, опираемся на нативные фреймворки и собственные наработки, не используя “десять популярных библиотек для отрисовки таблиц”. Но это не значит, что это скучно. В настоящий момент, например, мы активно пробуем Mac Catalyst, некоторые реактивные подходы, предоставляемые Combine и даже, признаюсь, попробовали SwiftUI, но он, честно говоря, оказался пока не готов к продакшн-разработке — продолжим следить. В качестве единой архитектуры iOS-приложений используем собственную интерпретацию RIBs, отлично подходящую для наших требований к безопасной и легко расширяемой разработке.
На данный момент у нас открыта вакансия «iOS Developer», где можно чуть более детально и формально узнать об ожидаемых нами компетенциях.
Привет!
Хочу добавить, что С++ разработчики нам также очень нужны.
Общий код, используемый на разных платформах, объединен в компоненты (PDK – product development kit). Данный код разрабатывается выделенным подразделением, и используется в большинстве продуктов компании, в том числе и в Mobile продуктах. Эти компоненты пишутся преимущественно на C++.
Разработка на С/С++ ведется и внутри мобильного подразделения. У нас есть свои, специфичные для мобильных продуктов, базовые компоненты. Ряд мобильных операционных систем, таких, например, как «Аврора», поддерживают разработку исключительно на С/C++.
В связи с этим С++ разработчики востребованы во многих подразделениях ЛК, в том числе и у нас.
Более подробно про вакансию C++ разработчика под Mobile можно посмотреть тут
Ищем тестировщиков с врожденной любознательностью, приобретенным скиллом шустрых пальцев или же с достаточным количество опыта и маны, чтобы заставить телефоны самим проходить тесты.
Присоединяйтесь к команде увлеченных своим делом специалистов. Это возможность осуществить вашу мечту — весь день вдумчиво тыкать в телефон и получать за это деньги.
Если заинтересовало, откликайтесь на открытую вакансию.
4. Специально ограничиваю ребенку интернет, но эта уязвимость с Google Assistant не дает нужного эффекта, ребенок использует его для просмотра всего, то есть он действительно полезен обходить ограничения вашей же программы. Сделайте отдельную настройку для таких пользователей, как я. Поставил галочку и это приложение недоступно, кому нужно будет, тот оставит.
6. Раз решили поднять вопрос с кодами блокировки, заметил, что у вас при блокировки Анти-Вором сейчас запрашивается ПИН-код, но вот никакой информации об этом нет в вашей справке и как можно разблокировать тоже. Куда вводить в таких случаях код восстановления не ясно.
Также рекомендую присмотреться к подпискам, они сапопродляемые, не требуют ввода новых активационных кодов.
Пользуюсь лицензиями Kaspersky Internet Security и Kaspersky Total Security.
Минусы подписки на сегодняшний день:
Не могу изменить количество устройств при продлении или же сразу с учетом скидки, как в обычной лицензии. Допустим, у меня истекает лицензия на 3 устройства KIS и я хочу уменьшить количество устройств при продлении с учетом скидки, я просто покупаю на 2 устройства (1350р) и активирую это продление на 12 месяцев. А при использование подписки мне придется отключать подписку, потом уже покупать лицензию за полную стоимость (1800р). Нет гибкости в этом у ваших продуктов. У конкурентов более гибкие варианты, нужно 4 устройства, поставил галочку и взял на 4. Нужно на 7 устройств, также поставил галочку и взял. У вас же выбор строго ограничен: 2,3,5 и 10. Будто других цифр нет.
Для лицензий подписок нет никаких акций, всегда покупаешь по фиксированной цене или уже повышенной. А для обычных у вас бывают акции и можно купить с хорошей скидкой.
Не люблю когда работа продукта зависит от подключения каким то кабинетам.
Блокировать полностью Google Assistant неправильно, так как он довольно глубоко интегрирован в OS, зачастую являясь частью лочнера. Блокировка может привести к проблемам, превратить устройство в «кирпич».
Также, если вы видите примеры другой, более устраивающей вас реализации подхода к блокировке, укажите ее в запросе.
Спасибо!
Можно ли реализовать так, чтобы ребенок не мог использовать совсем для выхода в интернет Google Assistant? Мне нужен именно этот функционал, как многим моим знакомым. Поможет ли мне эта настройка для этого?
Просматриваете ли вы отзывы продукта на 4PDA?
Под настройкой вы имеете ввиду полное блокирование доступа всего устройства в Internet? Если да, то запрос понятен, такая фича в будущем может появиться. И я все-таки не совсем понимаю, почему вы говорите об уязвимости и отсутствии защиты при текущей реализации фильтрации контента. Дайте, пожалуйста, больше информации, к какому нежелательному контенту и как Ребенок получает доступ. Как я уже сказал, запросы к «взрослому» контенту в Google Assistant должны блокироваться.
Отзывы на специализированных форумах, таких как 4PDA, просматриваем и анализируем. Форумы являются одним из источников сбора обратной связи, работу с которой мы, как мне кажется, выстроили довольно системно. Весь фидбэк (обращения в саппорт, отзывы в магазинах приложений, e-mail обращения из продукта, посты на форумах, обратная связь от партнеров и т.п.) поступает, агрегируется и обрабатывается в одной системе.
Ребенок спокойно запускает приложение и сидит вконтакте и других ресурсах, вместо учебы.
Что касается полной блокировки Google Assistant — подумаем.
Также скажите, пожалуйста, когда будет подобный раздел в справке Safe Kids? Начинает надоедать бегать по разным справкам продуктов, чтобы настроить программу корректно.
Спасибо, надеюсь он будет обновляться (дополняться) и доступен всем: support.kaspersky.com/help/ru, а не только по прямой ссылке здесь.
Возник вопрос: как разрешить это в приложении, судя по справке, я могу через приложение дать доп. время ребенку, но в итоге всегда даю через My Kaspersky. а не родительское приложение: support.kaspersky.com/KSK/Win1.5/ru-RU/151284.htm
Где сбой: неверная информация в справке или глюк в родительском приложении на мобильном устройстве? Я так понимаю такая возможность есть только для Windows. Планируется ли ее реализовать для мобильных устройств и в какие сроки?
Спасибо
Эксперименты, поиск инсайдов, принятие решений на основе данных/аналитики с реальных пользователей – это один из базовых столпов современных подходов к развитию продуктов.
1. Как обработать в тесте свайпы (имеется в виду свайп одним пальцем)? Можно без привязки к конкретной вьюхе, а просто свайп по экрану. Стандартный
swipeDown()
от androidx.test.espresso.action.ViewActions.swipeDown
что-то не очень работает.2. Как написать просто ожидание
flakySafely
без привязки? Иногда это очень помогает визуально понять на чём интерфейс застрял.- Если не получается через Espresso, можно попробовать с помощью UI Automator. В Kaspresso есть обертка над ним (Kautomator), которая содержит функцию
device.uiDevice.swipe(startX, startY, endX, endY, steps)
. - FlakySafely работает посредством перехвата эксепшнов, возникающих при определенном действии над View. Поэтому его нужно обернуть в
flakySafely{}
. Если нужно просто ожидание, то в крайних случаях можно использовать какую-нибудь реализациюwait()
(например,Thread.sleep()
).
Любые вопросы про Kaspresso можно также задавать в чатике.
Для мониторинга качества в проде, оперативного отлова проблем, вызванных внешними факторами, такими как деплои инфраструктурных обновлений, были выделены так называемые «критически пользовательские сценарии», они были покрыты аналитикой по качеству, были определены пороги для мониторинга. В этом случае обычных событий аналитики недостаточно, так как они появляются в Firebase-консоли с задержкой в сутки. На помощь пришла интеграция с Big Query, который позволяет получать данные практически в реальном времени. За счет данных мы значительно повысили качество продуктов и повысили удовлетворенность наших пользователей.
— сколько у вас кандидатов на место?
— откуда приходят самые желанные кандидаты?
— как вам опыт удаленной работы? Не пробовали нанимать людей из других городов и сёл без релокации?
1. Этот вопрос ставит меня немного в тупик, т.к. это скорее термин для “приемной комиссии”. Но попробую ответить так: мы постоянно в поиске талантливых разработчиков и рады новым коллегам. Вакансии в мобильный штаб, как правило, открыты постоянно и команды HR отслеживают кандидатов на ежедневной основе. Они же проводят первичный скрининг. На позицию iOS Developer, например, за прошедший год до технического скрининга и интервью дошли в районе 120 кандидатов, из которых, в результате, в команду попали 6 человек. Так же у нас широко развита практика стажировок, которой, как правило, пользуются студенты старших курсов, которые “горят” мобильной разработкой, но по тем или иным причинам не могут пока выходить на фуллтайм.
2. У нас нет “любимчиков”, мы рады видеть в своих стенах всех и каждого! Но наиболее успешное и плодотворное сотрудничество, если говорить про образование кандидатов, в последнее время выходит с выпускниками НИУ ВШЭ. Это просто факт, которому я пока не готов дать какого-то объяснения =)
3. Опыт интересный, неожиданный, но успешный. Ничто, конечно, не заменит живого общения, но многие признают, что продуктивность удаленной работы в мобильном штабе не упала. Наверное это специфика “мобильности”. Насколько я знаю, в период карантина, несколько наших коллег присоединились к нам именно “без релокации”. Вся необходимая техника для работы им были предоставлены “на место”, поэтому они смогли приступить к работе без лишнего стресса. Насколько подобная практика приживется в будущем — не могу судить об этом.
Мне просто интересно как это работает в больших компаниях. Чтобы не допрашиваться, у нас сейчас примерно 1300 поданных резюме на одного нанятого человека, но это удаленка в европе. И команда явно меньше вашей.
2. Тут больше про то, откуда приходят люди, с которыми оказываются самые приятные собеседования в среднем. Или самые ценные сотрудники в будующем в среднем. Стажировки? Или знакомые знакомых? Или нынче можно на хх.ру найти замечательных людей в команду?
3. А знаете ли что-то про других программистов? Где-то оказалось неэффективно? Насколько я понял, текущих наняли под обязательство релокации в будующем? Приятно видеть, как люди пробуют новые способы работать и выбирают то, что показывает лучшие результаты.
Я физическое общение в удаленной команде безусловно нужно. 1-3 раза в год.
Чего мы не делаем: мы не скупаем кандидатов, это работает плохо. Почему – ну примерно потому же, почему “купить” Гуса Хиддинка, Роберто Карлоса, Юрия Жиркова, Самуэля Это'О и т.п. – это не то же самое, что создать хорошую футбольную команду.
Что мы делаем: мы верим в молодых, работаем со студентами, создаем условия, при которых они могли бы расти, “заражаться” нашей миссией, становиться частью ДНК-компании. Поиск и отбор стажеров происходит на периодической основе через программу Kaspersky Safe Board: safeboard.kaspersky.ru, а также для желающих и при наличии запросов — в течение года.
Наш компания дала возможность продолжить удаленную работу, при этом желающим выйти в офис, была предоставлена такая возможность. Сотрудников, нанятых в последнее время в регионах, мы брали без требования обязательного переезда в один из городов, где есть наши офисы, при этом среди новых сотрудников были и те, которые сами планировали переезд и которым как раз компания дала гарантии помощи в релокации.
2. Награждаете ли вы как-нибудь своих активных мобильных бета-тестеров, как ранее или уже нет?
Регистрация так или иначе приводит к некоторому «отвалу» пользователей, поэтому на данном этапе мы ее делать не стали. В будущем не исключаю, что регистрация Who Calls на My Kaspersky все-таки появиться. Также не исключаю, что Who Calls трансформируется, станет частью более общей B2C-истории. Пользователям это невидно, но мы экспериментируем, начинали с бесплатной утилиты, сейчас перешли к Freemium-сервису, а дальше… — время покажет.
Что касается кодов активации — это все-таки не мобильный опыт, для кроссплатформенных сервисов — это ОК, для чисто мобильного приложения — вряд ли. Откуда его возьмет органический мобильный пользователь (тот, что пришел в приложение путем поиска по ключевикам в магазине приложение)? Google и Apple опять же запрещают сторонний биллинг. Если же со временем Who Calls станет частью комплексного сервиса, тогда, конечно, появится совместимость лицензий.
Android: бета-тестерам премиум-версия никогда не давалась.
iOS: премиум-лицензия бета-тестерам предоставляется и сейчас. Вот ссылка на вступление в бету: testflight.apple.com/join/S253Y4l8
У вас Android, чтобы вас стать бета-тестером, достаточно открыть страничку продукта в Google Play и начать кнопку «Become a tester». Вам будут автоматически устанавливать бета-версии, которые нам необходимо будет проверить, мы будем видеть метрики качества и использовать их для принятия решения о начале поэтапной раскатки бета-сборки на продакшен-пользователей. Если у вас появится замечание, вы можете оставить его в Google Play обычным способом, написав отзыв. Все очень удобно.
Kaspersky Security Cloud — это комплексный продукт, в состав которого входит несколько технологий обеспечения безопасного существования в цифровом пространстве. Одной из таких технологий является возможность сканирования Wi-Fi сетей, к которым подключается устройство, на безопасность. Для обеспечения непрерывной защиты наших пользователей анализ сети происходит “в фоне” с некоторой периодичностью. Настройка «Backgroud App Refresh» относится только к возможности основного приложения периодически “просыпаться” в фоне для проверки наличия обновлений внутренних модулей и не влияет на функциональность непрерывной защиты в Wi-Fi сетях.
Но Вы правы, что “съедать 15-20%” — это выглядит “многовато”. Если Вы готовы помочь нам детальнее разобраться в причинах такого потребления ресурсов и улучшить продукт, то я прошу Вас связаться с нами через support.kaspersky.ru/b2c/#product или написать на mobilesupport@kaspersky.com.
Может сразу скажите какие логи вам нужны и я постараюсь их собрать без участие посредников в виде «поддержки»? Или сами попробуете воспроизвести проблему? Это очень просто: устанавливаете последнюю версию приложения Kaspersky Security Cloud ( или Kaspersky Secure Connection), все обновления iOS, отключаете в настройках «Backgroud App Refresh» подключаете устройство к Wi-Fi, заряжаете устройство на 100%, отключаете от зарядки, ложитесь спать, просыпаетесь через часов 7-8, смотрите расход аккумулятора.
Со своей стороны мы начнем анализировать озвученную проблему не дожидаясь «официальной» части. Спасибо за четкие шаги воспроизведения =)
Можете подсказать? Где можно посмотреть описание классов, методов, параметров методов и т.д. Kaspresso? Может есть где-нибудь общий список?
Добрый день.
Можно посмотреть документацию в репозитории. Для старта может быть полезным также почитать Wiki. Там же есть ссылки на обзорные видео.
Как бороться с looped for xxxx iterations в андроид тестах?
Очень зависит от конкретной проблемы.
Можно для начала попробовать отключить анимации при прогоне теста.
Если это не поможет, можно использовать функцию KautomatorWaitForIdleSettings.boost()
при конфигурации Kaspresso. Она отключает waitForIdleTimeout
, который не дает совершить действие теста. А механизм flakySafely
повторит действие, если оно не удалось в первый раз. Подробнее можно почитать тут.
Как выстроен релизный процесс для андроид приложения?
Наш инструментарий:
1. Monorepo
2. CI/CD на базе TFS (автоматизированная выкладка билдов в Google Play/Apple Store/Huawei)
3. RealTime monitoring на базе BigQuery и дашборды с метриками качества
Для каждой сборки вычисляется скоуп, происходит сравнение со скоупом последнего выпущенного в паблик билда, ответственному менеджеру робот дает возможность принять решение, нужно ли запустить раскатку за пределы проектной команды. Далее каналы – опциональные раскатки на сотрудников компании (Internal Rollout), на внешних бета-пользователей, либо начало поэтапной раскатки на всех пользователей. Перед стартом раскатки есть несколько гейтов, на которых проверяется готовность маркетинговых материалов, собираются и визируются артефакты релиза. Скорость раскатки зависит от скуопа и результатов импакт-анализа. Если релиз содержит точечные изменения, этап бета-тестирования пропускается. В релизах с рискованными изменениями кроме бета-тестирования происходит более медленная раскатка на небольшой процент пользователей, который зависит от объёмом пользовательской базы. В ходе раскатки собираются и анализируются метрики качества (Crashes, ANRs, отзывы, аналитика по проходимости сценариев).
Как часто проходят релизы, как долго занимают все проверки со сборки релизного билда и до его заливки в сторы?
Мы стараемся выпускать релизы часто для того, чтобы сокращать time-to-market для ценных изменений в продукте. Жесткой фиксированной сетки релизов у нас нет, мы предпочитаем выпускать обновления продуктов по мере готовности фич. При наших размерах проектных команд мы в среднем доставляем пользователям что-то ценное раз в 2-3 недели, с учетом релизов, направленных на повышение качества, в среднем получается – примерно раз в 2 недели. Выпускаться чаще, чем раз в 7-10 дней, никакого смысла нет, предыдущий билд не успевает раскатиться. Между принятием решения о том, что скоуп достаточен для релиза и началом публикации проходит от нескольких часов до 2-3 дней. За счет высокой доли автоматизации мы сильно сократили время на приемку каждого релиза.
Спасибо за ответ. Вы не коснулись этапа тестирования релизного билда, используете ли помимо автотестов ручное тестирование, или после автотестов начинаете разливать на внутренних/бета пользователей?
При реализации новой функциональности, на первом этапе проверок всегда пишутся и прогоняются ручные E2E сценарии, которые в дальнейшем могут стать базой для E2E автотестов регрессионного набора.
На этапе стабилизации присутствуют как ручные тесты, так и автоматизированные тесты. Объем выполняемого регресса зависит от объема изменений, вызванных имплементацией нового функционала или исправлением багов. При частых релизах изменения делаются не масштабные, и их зачатую можно локализовать в рамках какой-то функциональной области продукта, тем самым максимально сократить необходимый объем проверок.
Финальный этап приемки RC почти во всех проектах автоматизировать по максимуму, т.к. это проверка основных сценариев продукта, а следовательно наиболее часто использующийся набор тестов.
Мы стараемся достичь оптимального уровня, некоторого баланса между затратами и выигрышам, которые приносит автоматизация. Нельзя ведь забывать, что затраты – это не только время на создание автотеста и окружения, но и дальнейшая его поддержка в рабочем состоянии. Основные выигрыши же будут только от тех тестов, которые регулярно используются, а не гонятются один раз в год. Поэтому не все ручные сценарии становятся автотестами. Важен баланс.
Так что… увы… нет, у нас нет волшебной кнопки «Проверь билд и выложи в продакшион», человеческий фактов всё ещё важен и ценен. :)
IRO и бета тестирование проходят в параллель со внутренним тестированием, помогая выявлять различные специфические сценарии или проблемы на специфических устройствах, а так же дают возможность оценить массовость крэшей и ANR-ов, которые в нашем окружении могут воспроизводиться лишь единично.
Если немного подробнее…
В уже устоявшихся продуктах обычно процесс такой:
Когда определен скоуп итерации и появляется требование/user story, проработанное системным аналитиком, проводится его реврью и далее в параллель с разработкой фичи пишутся тест кейсы. Как только фича готова (частично или полностью), она передается разработкой в тестирование вместе с написанными интеграционными и/или E2E автотестами. Далее проходит приемка автотестов и проверка новой функциональности, а так же регресса вызванного этими изменениями. В этот же период может проходить дописывание E2E автотестов на основе ручных тест кейсов. При достижении критериев готовности фича выводится из под фича флага, и проводится еще один раунд релизного регресса (в основном автоматизированного). При достижении критериев готовности к релизу, собирается RC, на котором проводиться финальное аксептанс тестирование, и этот билд уже попадет в релизный канал в сторе.
Раскатка билдов в IRO и бета каналы проходит в параллель со внутренним тестирование. Первые билды могу попасть в тестовые каналы на самых ранних этапах, дополнительно давая возможность получить первый фидбек по новой фиче, до того как она доделана окончательно. RC билд так же сперва попадает в бета канал, а по окончании аксептанса переходит в релизный канал.
Как уже писал Виктор, раскатка релизного билда происходит поэтапно с отслеживанием и анализом метрик качества (Crashes, ANRs, отзывы, аналитика по проходимости сценариев).
В случае же новых пилотных продуктов…
Тут может быть менее строгий процесс. Может варьироваться объем и глубина проводимых проверок, может отсутствовать детальное написание тест кейсов и автоматизация… Однако выполнение оговоренных в начале проекта критериев качества – обязательно для релиза в продакшион.
Ask me anything! Задай вопрос команде мобильной разработки «Лаборатории Касперского»