Pull to refresh
0

Ошибки при проверке внутренних платежей Android-iOS и их решение

Reading time 6 min
Views 18K
Disclaimer. Этот пост написан на основе доклада на SQADays’15. Вы можете также посмотреть видео выступления или полистать презентацию. Обращаю внимание, что доклад был начального уровня, то есть пост будет интересен в основном менеджерам и начинающим тестировщикам. А также на то, что автор — ненастоящий сварщик и местами делает довольно грубые округления.

Меня зовут Алёна, и я релиз-менеджер. Отдел компании i-Free, в котором я работаю, в основном занимается приложениями под iOS и Android. Ещё мы поддерживаем Tizen, Windows Phone, альтернативные сторы, но в данном посте речь пойдёт об Apple iOS Appstore и Google Play.
В обоих маркетах, помимо платных и бесплатных приложений, есть возможность проводить внутренние платежи — ин-аппы (In-App Purchases).

Почему я рассказываю про тестирование ин-аппов? Потому что могу!
Будучи релиз-менеджером, я участвую в проектах обычно в начале разработки и в конце тех итераций, которые заканчиваются выкладкой в сторы. Перед началом проекта выдаю разработчикам ключи и сертификаты, а к концу работы над версией разработчики отдают мне билды для релиза. Но между этими точками есть момент, когда надо завести внутренние платежи — ин-аппы и выдать тестировщикам тестовые аккаунты. И вот на этом этапе иногда случается что-то странное, когда разработчики считают, что у них всё хорошо, а тестировщики — что всё плохо.


Общая информация про тестирование ин-аппов


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

Итак, в том или ином виде в обоих маркетах есть:
  • Песочница для тестирования платежей
  • Механизм тестовых аккаунтов, чтобы не тратить деньги
  • Тестовые билды и тестовые девайсы

Стандартная схема покупки ин-аппов в мобильных сторах:
  1. Сначала пользователь жмёт на кнопочку «купить» и вводит пароль. Проходит сама покупка, работают механизмы площадки
  2. Информация о покупке передаётся в приложение
  3. Потребление купленного ин-аппа (consume)
  4. Ин-апп становится доступным для повторного приобретения

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

Специфика тестирования Google Play In-App Purchases


Как тестировать и что для этого нужно


Начнём с того, что в случае Google Play мы имеем дело с полупесочницей. Мы будем использовать реальные аккаунты, которые отмечены в девелоперском аккаунте как «тестовые». При этом к аккаунту должна быть привязана банковская карта, но фактически списаний с неё не будет. Ну и благодаря открытости самой платформы, мы имеем полноценные логи и простую установку билдов.
Итак, что нужно:
  • Девелоперский аккаунт с объявленными в нём тестовыми аккаунтами
  • Тестовый аккаунт с привязанной к нему карточкой и участвующий в бета-тесте
  • Опубликованный в бета-тест билд приложения
  • Тестовое устройство, залогиненное в тестовый аккаунт. На него скачиваем билд из бета-теста.


Как выглядит, когда всё хорошо:




При нажатии на ин-апп мы видим окно с подписью «это тестовый платёж». Покупка проходит почти мгновенно и завершается успешно, деньги с карты не списываются.
В приложении нам начисляются положенные блага

Что может быть, когда всё плохо?




Ошибка -№1 несоответствие версии билда




Тестировать платежи можно только на билде той же версии, что и в админке. Но с тех пор, как введено тестирование не с помощью черновиков билда, а через бета-тест, эта ошибка должна встречаться гораздо реже.
Что делать:
  • проверить совпадение версий на устройстве и в админке
  • подождать — только что загруженная версия может быть не видна приложению часа два-четыре.


Ошибка №2 — плохое соединение:



Если фактически с интернетом всё хорошо, практически всегда лечится переключением с 3g на wi-fi или с wi-fi на другой wi-fi.

Ошибка №3 — купить купленное:




Обещанное отступление. Во многих маркетах есть различие между одноразовыми и многоразовыми ин-аппами. В Google Play оно тоже было, но с февраля 2013 был введён биллинг версии 3. С тех пор ин-аппы бывают “управляемые Google” и “управляемые разработчиком”, а можно ли их купить несколько раз — зависит от того, как разработчик их обрабатывает (консьюмит или нет).

На самом деле пользователь никогда не должен видеть эту ошибку. Если же это происходит, либо разработчик обращается к одноразовым ин-аппам как к многоразовым, либо Google закрутил покупку между Google Checkout и Google Play, надо подождать пару часов и/или перезагрузиться.

Ошибка №4 — [буквы и цифры в квадратных скобках]



Обычно это проблема покупателей из-за неверно настроенного Google Checkout.
Что делать:
  • стандартные ритуалы: перезагрузиться и подождать немного
  • крайняя мера – очистить данные Google Services


Вроде бы всё хорошо, но ин-апп не начислился



Или Google сказал, что платёж прошёл успешно, а приложение сказало, что нет.
Важно понимать, что в данном случае проблема на стороне приложения. То есть если Google ответил, что платёж прошёл успешно — он всегда однозначно посылает именно такой ответ. Но приложение должно ещё суметь его обработать!
  1. Что делать? Подождать, пока программисты починят
  2. Это критикал, такие ин-аппы пропадают бесследно!
  3. Скорее всего, это серверная ошибка, связанная с подписью

Ещё можно запомнить слова license key. Дело в том, что небольшая строка цифр и букв, которая удостоверяет ин-аппы, платные приложения и докачку дополнительного контента, сейчас уникальна для каждого приложения. И если вы по каким-то причинам делаете две версии приложения (на русский и международный рынок, или платную и бесплатную версии, например), есть вероятность, что кто-то где-то забудет поменять эту строчку. Вовремя произнесённые слова “а у нас всё в порядке с лицензионным ключом?” могут сэкономить несколько хлопков одной ладонью по лбу.

Специфика тестирования iOS


Как тестировать


А вот у Apple нас ожидает полноценная песочница. Но значит ли это, что нам будет легче?
Итак, никаких реальных карточек и реальных аккаунтов. При этом тестовый аккаунт привязывается к стору определённой страны, это важно. Ещё не нужно никуда в админку заливать билды, так что за исключением выдачи тестовых аккаунтов эта часть проходит без моего участия.
Но всё не так просто — провижены! Грубо говоря, это списки, в которых перечисляется, какие разработчики имеют право собирать приложение с определённым идентификатором, и на какие девайсы можно ставить получившийся билд.
Ну и две админки — Tunes Connect для промо-материалов, Member Center для разработчиков.

Что нужно для тестирования:


  • «Cкелет» приложения в iTunes Connect, только после этого можно завести ин-аппы
  • Тестовый аккаунт страны, на которую заведено приложение
  • Тестовый девайс, заведённый в Member Center
  • Правильно собранный билд, установленный на правильный девайс


Что происходит, когда всё хорошо:



При нажатии на ин-апп появляется окно с подписью [Enviroment: Sandbox].

Что делать, когда что-то не так?




Прежде всего — важная информация о тестовых аккаунтах iOS


Это полностью несуществующий аккаунт, но e-mail должен быть уникальным среди как тестовых, так и реальных акаунтов. У него не нужно вводить информацию о кредитной карте, а дата рождения вводится один раз при создании в админке. Если тестовый аккаунт на устройстве просит ввести что- то, кроме логина и пароля – вы его сломали. Совсем. Надо делать новый.

Ошибка №1 — вам нужно ввести платёжную информацию



Если на такой табличке нажать кнопку “продолжить”, вас попросят ввести информацию о платёжном средстве. Это значит, что вы неправильно привязали тестовый аккаунт. Он может быть привязан к устройству лишь одним способом:
  1. Надо отвязать от устройства все настоящие аккаунты
  2. Зайти в приложение
  3. Тапнуть на ин-апп
  4. И ввести логин-пароль

Все остальные способы не сработают и сломают аккаунт, придётся делать новый.

Ошибка №2 — вы не можете совершить эту покупку



Тоже связанная с аккаунтом ошибка. Что это может значить:
  1. Заведённое приложение недоступно в стране тестового аккаунта
  2. Приложение и тестовый аккаунт принадлежат разным девелоперским аккаунтам
  3. Вы используете реальный аккаунт


Ошибка №3 — ограничение на количество покупок



Очень странная ошибка, такого ограничения нет. Но вы можете встретить похожую при упорном тестировании подписок. Лично не встречала, единственный совет — будьте осторожны при тестировании iOS-подписок :)

Ошибка №4 — да вы же не тестовый пользователь!



Может появиться на устройстве с jailbreak или при крайне плохом соединении с интернетом. Лично не встречала, совет — по возможности не тестируйте на устройствах с jailbreak. Если, конечно, это не часть вашей целевой аудитории.

Доклад был прочитан 18 апреля, с тех пор ситуация изменилась не сильно, за исключением способа выкладки билдов в Google Play для тестирования. Раньше было достаточно просто завести билд как черновик, теперь же надо опубликовать в бета-тест, что, с одной стороны, увеличивает количество необходимых материалов на этой стадии (надо сразу иметь иконку, скриншоты и описание), но с другой — облегчает обновление билда тем, кто является заинтересованной стороной в разработке, но при этом не углубляется в тестирование. Например, ПМ или дизайнеры, они просто получают пуш «новая версия» как от обычного приложения.

Если вы встречали какие-то иные ошибки самого стора при осуществлении внутренних платежей — будет интересно прочитать о них в комментариях.
Tags:
Hubs:
+25
Comments 5
Comments Comments 5

Articles

Information

Website
www.i-free.com
Registered
Founded
Employees
501–1,000 employees
Location
Россия