Comments 12
1. Если есть сторонний сервис — он обязательно подведет. Недавняя авария у FB повлияла на работу некоторых приложений и сайтов. Например, пару версий назад приложение Habrahabr «расшаривало» статьи с блокированием UI без индикатора активности. В момент, когда «тормозил» Facebook или Интернет, «шаринг» вешал всё приложение до тех пор, пока процесс не завершался.
Я представляю разработчиков официального приложения Хабра.
О какой платформе идет речь?
2. Также уделяйте внимание сторонним клавиатурам. Например, в iOS9 есть баг, который приведет к крашу приложения, если в модальном окне в WebView вводить текст с помощью сторонней клавиатуры.
Какой-то кастомный случай именно клавиатуры Swype, не?
1. Речь шла о платформе iOS. Проблемы уже нет, либо уже пофикшена была либо с переходом на FB Graph API — фейсбук сам прогресс показывает. Собственно говоря, поэтому и написал что «пару версий назад», перед публикацией проверял — проблемы нет (последний раз видел проблему когда еще первый API использовался и был разрешен автопостинг).
2. У нас проблема не только со Swype, но и как минимум со SwiftKey — y нас в модальном окне авторизации через OAuth при его закрытии если долго отвечает сервис или медленное интернет соединении (Twitter, Instagram). Судя по нашим краш-репортам в iOS9.1 проблемы уже нет (как минимум в нашем приложении)
2. У нас проблема не только со Swype, но и как минимум со SwiftKey — y нас в модальном окне авторизации через OAuth при его закрытии если долго отвечает сервис или медленное интернет соединении (Twitter, Instagram). Судя по нашим краш-репортам в iOS9.1 проблемы уже нет (как минимум в нашем приложении)
В наших приложениях очень много фич можно выключить со стороны сервера напрямую или, в зависимости от решения команды, с помощью специального интерфейса.
Как это реализовано на мобильной стороне? Не могли бы вы привести не большой пример.
У нас есть как минимум три варианта:
1. Новая фича или рефакторинг старой «прячется» под фича флаг и мы через определенный интерфейс контролируем ее состояние. Иначе говоря мы ее можем «раскатывать» постепенно:
— на определенное приложение (у нас их несколько);
— на определенный процент пользователей или на по определенным правилам (например на 10% пользователей или на отдельную страну).
Или же совсем отключить новый функционал по решению команд тестирования, разработки, продуктовой команды. После того как фичу обкатали мы можем сказать клиенту «не спрашивай ее больше с сервера и закэшируй состояние» или же выключить фича флаг на клиенте к следующему релизу (и убрать старый код если мы переписывали определенный функционал).
2. С другой стороны, мы сообщаем серверу какие фичи клиент поддерживает и сервер контролирует доступны ли она клиенту.
Например, в определенных странах мы не поддерживаем платежи или платные функции не должны быть доступны несовершеннолетним. Сервер говорит такому клиенту «ты поддерживаешь фичу, но не включай ее» и для такого клиента не будут доступны платежи.
Как только платежи стали доступны (договорились о платежах или юзер стал совершеннолетним) сервер даже в этой сессии может прислать модифицированное состояние фичи и она станет доступна пользователям.
3. А также мы можем быть подстрахованы со стороны фреймворка A/B-тестирования. Если мы уже приняли решение какая группа лидирует или что-то не так с мобильным приложением, мы можем завершить тест досрочно или перевести всех пользователей в другую группу.
1. Новая фича или рефакторинг старой «прячется» под фича флаг и мы через определенный интерфейс контролируем ее состояние. Иначе говоря мы ее можем «раскатывать» постепенно:
— на определенное приложение (у нас их несколько);
— на определенный процент пользователей или на по определенным правилам (например на 10% пользователей или на отдельную страну).
Или же совсем отключить новый функционал по решению команд тестирования, разработки, продуктовой команды. После того как фичу обкатали мы можем сказать клиенту «не спрашивай ее больше с сервера и закэшируй состояние» или же выключить фича флаг на клиенте к следующему релизу (и убрать старый код если мы переписывали определенный функционал).
2. С другой стороны, мы сообщаем серверу какие фичи клиент поддерживает и сервер контролирует доступны ли она клиенту.
Например, в определенных странах мы не поддерживаем платежи или платные функции не должны быть доступны несовершеннолетним. Сервер говорит такому клиенту «ты поддерживаешь фичу, но не включай ее» и для такого клиента не будут доступны платежи.
Как только платежи стали доступны (договорились о платежах или юзер стал совершеннолетним) сервер даже в этой сессии может прислать модифицированное состояние фичи и она станет доступна пользователям.
3. А также мы можем быть подстрахованы со стороны фреймворка A/B-тестирования. Если мы уже приняли решение какая группа лидирует или что-то не так с мобильным приложением, мы можем завершить тест досрочно или перевести всех пользователей в другую группу.
Статья шик. Расскажите плз, как QA ставят билды. Руколами качают с CI или же есть веб страница/ftp с более удобным списочком?
Насчет логов есть вариант сделать кнопку в девелоперском меню которая будет слать файловые логов приложения на внутренний сервис. Можно не утруждаться снятием логов и логи без системного хлама будут. Но подозреваю что у вас уже и это сделано.
Еще добавлю к девелоперскому меню. Очень удобно иметь возможность перевести девайс юзера с релизной прилагой в диагностический режим, чтобы там писались полные логи и он их мог отправить в саппорт. Бывают инциденты в продакшне когда без этого понять что же происходит почти нереально.
Насчет логов есть вариант сделать кнопку в девелоперском меню которая будет слать файловые логов приложения на внутренний сервис. Можно не утруждаться снятием логов и логи без системного хлама будут. Но подозреваю что у вас уже и это сделано.
Еще добавлю к девелоперскому меню. Очень удобно иметь возможность перевести девайс юзера с релизной прилагой в диагностический режим, чтобы там писались полные логи и он их мог отправить в саппорт. Бывают инциденты в продакшне когда без этого понять что же происходит почти нереально.
Качают руколами… руколами качают… руколы…
Григорий, спасибо :)
1. Билды собираются в TeamCity. У каждой из команд если свое приложение, которое позволяет ставить нужный билд. Команду релиз-инжиниринга это расстроило, они написали HTML5 приложение, теперь у нас их 4 :)
У Win Phone/Android с этим вообще никаких трудностей нет. Для iOS мы распространяем Enterprise билды, чтобы любой человек из компании мог их поставить без добавления девайса в provision-profile. Но они не поддерживают пуши, поэтому если необходимо протестировать пуш-нотификации, приходится ставить руками на активированные для разработки устройства.
2. Логи, да именно так и есть — мы логи можем слать на e-mail на Android/WinPhone причем если послать на определенный мейл с указанием тикета, то лог автоматически прикрепится. Если такого тикета нет — он создастся пустой. Удобно если где-то в поездке закрашилось приложение :)
3. Мы такое не реализовывали если честно, подам идею разработчикам. В большинстве случаев от саппорта приходят уже отфильтрованные жалобы в которых более-менее понятно что и как. Так же у нас есть beta для iOS и Android, билды которого обернуты в TestFairy, мы там видео сессии прокликиваем время от времени, если пришел краш или жалоба от бета-пользователя
1. Билды собираются в TeamCity. У каждой из команд если свое приложение, которое позволяет ставить нужный билд. Команду релиз-инжиниринга это расстроило, они написали HTML5 приложение, теперь у нас их 4 :)
У Win Phone/Android с этим вообще никаких трудностей нет. Для iOS мы распространяем Enterprise билды, чтобы любой человек из компании мог их поставить без добавления девайса в provision-profile. Но они не поддерживают пуши, поэтому если необходимо протестировать пуш-нотификации, приходится ставить руками на активированные для разработки устройства.
2. Логи, да именно так и есть — мы логи можем слать на e-mail на Android/WinPhone причем если послать на определенный мейл с указанием тикета, то лог автоматически прикрепится. Если такого тикета нет — он создастся пустой. Удобно если где-то в поездке закрашилось приложение :)
3. Мы такое не реализовывали если честно, подам идею разработчикам. В большинстве случаев от саппорта приходят уже отфильтрованные жалобы в которых более-менее понятно что и как. Так же у нас есть beta для iOS и Android, билды которого обернуты в TestFairy, мы там видео сессии прокликиваем время от времени, если пришел краш или жалоба от бета-пользователя
Спасибо, очень полезно. Почти все советы знал, но есть моменты, которые пригодились. Например, мы как-то пропустили появление поэтапного внедрения в андроид, а штука феерически полезная. В этом плане гугл гораздо оперативнее эппл, конечно. С другой стороны то, какие круги ада мы прошли в процессе внедрения подписки, заставило меня пересмотреть отношение к гуглу :)
Еще дополню по «мусору» при ответе от сервиса.
Столкнулись с тем, что провайдеры по-разному отвечают на запросы приложения, если у пользователя закончились деньги за интернет:
— код 404 + html
— код 200(!) + js. Этим отличился МТС. В результате краш у пользователей, так как программист сделал проверку с привязкой к статус коду.
Столкнулись с тем, что провайдеры по-разному отвечают на запросы приложения, если у пользователя закончились деньги за интернет:
— код 404 + html
— код 200(!) + js. Этим отличился МТС. В результате краш у пользователей, так как программист сделал проверку с привязкой к статус коду.
Также кейсы, описанные выше подходят для сетей где надо авторизоваться в браузере/веб-вью перед тем как пустят в Интернет
— кейс про 404 я описал — наверное не очень понятно просто обрисовал
— про 200 + JS не слышал — сейчас добавлю, спасибо!
— кейс про 404 я описал — наверное не очень понятно просто обрисовал
— про 200 + JS не слышал — сейчас добавлю, спасибо!
Нет, нет, про 404 все понятно было написано.
Про МТС еще. У них в ответе, например, нет вообще заголовка «Content-Type». Ответ вот такого плана:
RESPONSE
internet.mts.ru/?MSISDN=79859218907&REDIRECT_PACKAGE=package_1Gb_Smart_1_msk
Code: 200
{
«Content-Length» = 405;
Date = «Mon, 07 Sep 2015 15:08:52 GMT»;
Server = «Microsoft-IIS/8.5»;
}
Data:
Про МТС еще. У них в ответе, например, нет вообще заголовка «Content-Type». Ответ вот такого плана:
RESPONSE
internet.mts.ru/?MSISDN=79859218907&REDIRECT_PACKAGE=package_1Gb_Smart_1_msk
Code: 200
{
«Content-Length» = 405;
Date = «Mon, 07 Sep 2015 15:08:52 GMT»;
Server = «Microsoft-IIS/8.5»;
}
Data:
<html>
<body>
<script type='text/javascript' charset='utf-8'>
window.location.href = '/?'+ window.location.search.substring(1).split('&')[1];
</script>
</body>
</html>
Для облегчения тестирования мобильных приложений, я бы порекомендовал использовать сторонние платформы, например:
— Ubertesters
или
— uTest
— Ubertesters
или
— uTest
Sign up to leave a comment.
Тестирование мобильных приложений: tips & tricks