Краткий ответ

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

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

Семь областей доказательств перед production

Область Минимальные проходные доказательства Что должно блокировать production
1. Область и кандидат Согласованные API, модель кошелька, область игр, версия кандидата, список конфигураций и исключения Кандидат все еще меняется или протестированная область отличается от области релиза
2. Функциональные пути Проверяемые результаты для согласованных случаев запуска, возврата, кошелька и запросов записей Критически важный бизнес-путь не проходит или проверено только отображение во фронтенде
3. Пути исключений Выводы для тайм-аута, дубликата, разрыва соединения, бизнес-сбоя, частичного успеха и неизвестного состояния Нельзя установить окончательное состояние, а восстановление зависит от слепых повторов
4. Сверка и согласованность Стабильные идентификаторы сопоставляют запросы, транзакции, раунды, суммы, валюты и движения баланса Записи нельзя связать или у расхождений нет пути запроса, обработки и закрытия
5. Безопасность и изоляция сред Проверены учетные данные, доступ, данные, журналы и границы конфигурации staging и production Повторно используются тестовые учетные данные, секреты попадают в код или журналы либо разрешения production неясны
6. Ответственность и операционная готовность Подтверждены принимающий решение о запуске, инженерное реагирование, владельцы сверки, безопасности и эскалации Есть только контакт отдела продаж или у инцидентов и финансовых расхождений нет владельца
7. Откат, остановка и восстановление Подтверждены триггеры, исполнитель, работа с данными, проверка восстановления и каналы коммуникации Интеграцию нельзя безопасно остановить или после отката никто не сверяет состояние

Шаг 0: зафиксируйте область и формат доказательств

Перед тестированием установите следующую базовую линию:

  • кандидат релиза, версия документации API и версия конфигурации;
  • провайдеры, игры, модель кошелька, валюты, языки и рынки, предназначенные для запуска;
  • явные исключения из этого релиза;
  • различия между staging и production;
  • предварительные условия, входные данные, ожидаемые бизнес-результаты, фактические результаты и местоположение доказательств для каждого случая;
  • серьезность дефектов, утверждающее лицо для исключений и владелец окончательного решения go/no-go.

Если кандидат релиза не является той версией, которая тестировалась, повторно оцените затронутые области приемки. Не переносите выводы вперед без оценки воздействия.

1. Функциональная приемка

Охватите всю согласованную бизнес-цепочку, а не один экран игры:

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

Формулируйте условия прохождения как наблюдаемые результаты — например, «тестовая транзакция возвращается по указанному бизнес-ID и соответствует движению в реестре», — а не как «кошелек работает».

2. Приемка исключений

Выбирайте случаи исключений, исходя из риска проекта и фактического протокола. Обычно они включают:

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

Этот контрольный список требует протестированного результата для путей исключений. Он не выдумывает ключ идемпотентности, число повторов или значение задержки для проекта. См. идемпотентность, повторы и сверку Slots API для структуры проектирования и используйте формальный протокол сторон для деталей реализации.

3. Приемка записей и сверки

Используйте как минимум одну обычную транзакцию и один сценарий исключения или неизвестного состояния. Проверьте:

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

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

4. Безопасность, конфигурация и изоляция сред

Production — не конфигурация staging, скопированная на другой хост. Перед релизом проверьте как минимум следующее:

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

Технические стандарты Комиссии по азартным играм Великобритании включают разделение систем разработки, тестирования и production в пределах применимой области безопасности. Это полезная ссылка для изоляции сред, но каждый рынок и проект все равно требуют собственной проверки. Она не устанавливает полного регуляторного соответствия или соответствия безопасности.

5. Ответственность и операционная готовность

Превратите список контактов в исполнимую матрицу ответственности:

Сценарий Ответственность, которую необходимо установить до запуска
Инцидент API или сессии Первый реагирующий, требования к доказательствам, инженерная эскалация и внешняя коммуникация
Финансовое расхождение или расхождение записей Условие паузы, владелец сверки, принимающий бизнес-решение и стандарт закрытия
Изменение каталога или версии Инициатор изменения, оценка воздействия, уведомление и регрессионное тестирование
Инцидент учетных данных или безопасности Изоляция, ротация, расследование, уведомление и одобрение восстановления
Релиз и откат Go/no-go, выполнение, проверка и владение итоговой записью

Если целевые показатели реагирования, доступность сервиса или средства защиты являются условиями запуска, поместите их в договор или другой формально согласованный операционный документ.

6. Откат, остановка и восстановление

Не каждую интеграцию API можно отменить откатом кода. Когда задействованы кошельки и транзакции, план должен также охватывать бизнес-события, созданные в окне релиза или отката. Подтвердите:

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

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

Итоговая запись решения go/no-go

Перед production зафиксируйте одну краткую запись решения:

  • версию кандидата и конфигурацию;
  • статус всех семи областей доказательств: проверено, условно принято или заблокировано;
  • неразрешенные дефекты и исключения, включая риск, владельца и утверждающее лицо;
  • ответственность за мониторинг, эскалацию, остановку и восстановление;
  • отдельное одобрение доступа к production и коммерческой области;
  • решение: go, go с ограниченной областью или no-go;
  • дату решения и подписывающие роли без предположения о фиксированной дате запуска.

Что в настоящее время можно оценить на этом сайте

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

Границы, о которых следует помнить

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

Часто задаваемые вопросы

Если staging пройден, может ли команда немедленно выпустить релиз?

Не автоматически. Идентичность кандидата, различия сред, доступ к production, ответственность, мониторинг, коммерческая область и условия отката все еще требуют проверки, после которой принимается согласованное решение go/no-go.

Достаточно ли тестирования успешного сценария?

Нет. Тайм-ауты, дубликаты, разрывы соединения, бизнес-сбои и неизвестные состояния — распространенные источники повторной обработки и финансовых расхождений. Случаи исключений должны входить в приемку в соответствии с протоколом и риском.

Кто подписывает решение для production?

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

Должен ли каждый проект использовать совершенно одинаковые тестовые сценарии?

Семь областей доказательств — общая основа. Конкретные сценарии должны быть адаптированы к модели кошелька, области, целевому рынку, текущей платформе и риску изменения. Само решение об адаптации также следует зафиксировать и утвердить.

Связанные материалы и следующие шаги

Чтобы определить область приемки проекта, используйте раздел «Связаться с нами» и укажите модель кошелька, целевые игры, границу текущей платформы и ожидаемые среды. Затем AG сможет совместно определить сценарии и доказательства по подтвержденному протоколу, не обещая заранее дату запуска или допуск в production.

Источники и область применения

Для области продукта см. процесс интеграции, обзор Slots API и публичную справку API.

Общие методы релизов основаны на Release Engineering и развивающихся практиках участия SRE Google SRE. Пример изоляции среды, специфичный для рынка, взят из Remote Gambling and Software Technical Standards: security requirements Комиссии по азартным играм Великобритании.

Эти источники объясняют общие практики приемки. Они не устанавливают, что AG реализует каждый упомянутый процесс или что проект соответствует конкретному рынку. Условия production должны быть согласованы ответственными ролями разработки, QA, операционной деятельности или финансов, безопасности, коммерции и комплаенса.

Нужно превратить это руководство в план проекта?

Материал помогает оценить проект, но не заменяет техническое, договорное, сертификационное или правовое подтверждение.

Связаться с нами