游戏测试 游戏支付测试分享

TesterHome小助手 · 2022年07月27日 · 最后由 于先生 回复于 2024年02月20日 · 10974 次阅读

文章来源:字节跳动技术质量 ,作者金峰
写在前面:

1、本文主要介绍支付测试的通用方法、基础概念和一些容易踩坑的点,包括国内安卓渠道和 iOS、海外 Google Play 和 iOS 支付,希望通过阅读本文,可以帮助大家顺利完成支付测试;
2、本文主要站在 QA 验收的视角介绍,对于一些发行向或研发向的配置,会选择略过或简述,请理解;
3、本文面向的测试对象,是那些已经接入完成,自测,笔支付订单的游戏,接入过程中遇到的问题,不在本文介绍的范围内;
4、部分流程图、引用内容文中标注了引用来源,详情可以点击链接了解;
5、 水平有限,不清晰或有误之处,烦请不吝指正。

支付测试的目标

支付测试,是游戏 QA 功能测试中的一小块,不过因为参与方比较多,往往发生问题后,排查比较困难,因此需要梳理一下流程,为一些常见的问题提供清晰明了的排查思路。
个人理解的支付测试点大体包括两个层面:
确保支付能力接入正确,可以完整地完成支付流程;
确认各处商品配置正确,所有商品均能正常支付并最后到账。

下文将从这两点展开,分别介绍 Google Play(以下多简称为 GP)、iOS、国内渠道和一些其他的支付渠道的测试。

01

Google Play 支付测试

1.1 支付流程图

时序图取自 GP 官方文档:https://developer.android.com/google/play/billing/api
普通 IAP:

订阅

  1. 订阅的首次购买和普通的 IAP 流程差异不大;
  2. 相较于一次性 IAP 消费,订阅有状态的概念,在订阅状态发生变更时需要通过回调进行状态维护。

1.2 测试准备

接入侧研发使用提测包体,完成过一次成功的支付到账流程;

为了确保提测的包体,已经完成了商号申请、参数配置、基本的商品配置、服务器的支付回调等一系列的前置步骤,避免出现提测包体本身不满足测试条件的乌龙。
QA 准备测试账号,主要有以下几步:

  • 和发行确认当前游戏选择的上架区域,在公用测试账号池中借用对应地区有真实支付能力谷歌账号,建议借到账号后,先根据下方测试流程中的步骤 3,验证当前测试机和测试账号付费能力正常(配置为目标国家的网络环境,创建当地的 GP 账号,付费建议绑定有海外支付能力的信用卡,使用礼品卡可能出现奇怪的问题);
  • 联系商店账号管理同学将该测试账号加入测试计划(同时需要注意包体需要在 alpha/beta 轨道上),并且提供一个测试邀请链接;
  • 使用测试账号登录浏览器(手机或者 PC 均可,注意清除浏览器 cookie,保证登录的是测试账号),接受该测试邀请,这样一个账号就成功加入了测试计划。

  • 请商店账号管理同学将测试账号加入应用的许可测试人员,这样这个账号之后支付就不需要支付真实货币了,而是直接走谷歌沙盒支付,支付拉起时的弹窗中会如下显示,需要注意的是:这里的沙盒支付指的是谷歌这边的,和 SDK 的沙箱环境无关,换种表达方式是:SDK 沙箱环境和正式环境都可以进行谷歌的沙盒支付和真钱支付,但对 SDK 正式环境而言,想跑通沙盒支付需要在 SDK 管理端配置沙盒支付白名单。

alpha/beta 轨道:详情可通过谷歌官方链接了解,一般内部小规模测试 alpha 轨道即可,对外开放的测试一般放在 beta 轨道上,是否已提审 or 过审 alpha/beta 轨道,询问商店管理的同学或者通过发行询问即可。

谷歌沙盒支付:谷歌自身提供沙盒支付能力(在后台设置里这个能力叫 “许可测试”),与 GSDK 的沙箱环境无关,配置路径为:打开 Play 管理中心 --> 依次点击设置 > 许可测试 --> 在 “添加许可测试人员” 框中,输入测试人员的 Gmail 地址 --> 在屏幕右下角,选择保存更改。

使用沙盒支付有几点好处:

  • 不需要付真钱, 线上的计费点可以按实际价格直接配置,我们验收所有计费点时的结论也更准确;
  • 官方说法:

翻译一下,意思是来说我们上传到 GP 的包体是会带签名 +versionCode 的,在真钱支付的场景下,使用 GP 的支付能力会验证这个签名,如果签名验证失败,则会提示 “该版本的应用未配置商品” 之类的错误。支付调试过程中,往往我们的包体也在不断升级,包体的签名信息是在变化的,而上传到商店的操作却不会有那么频繁,所以实际测试时用的包体会和 GP 的包有签名差异,最终导致支付走不通,这里推荐两个测试的姿势:

沙盒账号支付:打包时,包体 versionCode 与最后一次上传的包设置成一致,使用沙盒账号支付,绕过签名检查;

真钱支付:完全使用上传的包体进行安装,或者直接从 GP 商店进行下载安装,支付时,使用对应地区的 GP 账号 + 配置为目标国家的网络环境,直接进行支付,但建议只支付一笔;

测试订阅很方便,一个月的续订周期,沙盒账号只要 5 分钟就可以触发续订逻辑,详情可以参考:https://developer.android.com/google/play/billing/test
沙盒支付白名单: GSDK 为了避免沙盒测试账号流出到正式环境,造成安全风险(你懂的,无限购买),特意在 SDK 正式环境的后台增加了沙盒支付白名单的功能,只有给沙盒支付订单对应的游戏角色/设备加了白名单,才能完成支付。

准备好网络环境和设备环境,并确认测试手机和该账号付费能力可用,具体操作为:
a. 选择一台支付框架可用的海外手机(推荐三星、pixel 这种机器);
b. 退出 Google Play 上所有账号,并清除 Google Play 应用的所有数据;
c. 配置为目标国家的网络环境,确认网络正常后打开 Google Play 登录测试账号;
d. 打开 Google Play 商店 --> 点击付费 tab --> 查看是否有内容(如果有,则表示支付环境 ok)。

如果需要测试游戏内所有的付费点,不要忘了找发行要一份游戏内所有计费点的清单文档,放心,他会有的,毕竟商品配置都需要走发行同学这边。

1.3 测试流程

普通商品
游戏内大部分的内购项,包括游戏币购买、道具直购,不自动续费的月卡,在 GP 这边都认为是普通商品,测试普通商品比较简单,作为 QA,主要关注以下几点即可:

  • 游戏内显示的货币与价格,符合预期 默认情况下,游戏商品的定价显示会按发行配置时使用币种由 GP 管理后台根据汇率和税率实时换算成当地的价格,此时可以根据计费点中的价格大致换算一下对应的上即可; GP 支持根据不同国家,指定商品的价格,此时应需要发行提供测试账号所在国家的价格配置;
  • 支付流程能正常完成,商品也成功到账(到账不仅要查看购买成功的弹窗,也要实际去背包中查看或使用,确保是东西是真的进背包了);
  • 游戏币的充值,不仅要关注游戏内游戏币的数量和到账情况,同时需要关注管理后台上角色信息中的游戏币变化情况,具体有: a.充值游戏币后,查询角色信息,游戏币数量增加符合预期; b.消费游戏币后,查询角色信息,游戏币数量增加符合预期; c.游戏玩法赠送游戏币后,查询角色信息,游戏币数量增加符合预期;
  • 验证发行提供的所有计费点的实际支付和到账情况;
  • 游戏内的限购、随机直购等逻辑要根据游戏设定自己写 case;
  • 正常来说,支付测试不太需要使用真钱支付,沙盒支付全量验收后其实就可以保证游戏真钱支付能力无问题,但一般咱们为了做最后的确认,还是在最终包上会使用真钱支付一次,验证最终包的真钱支付能力,一般会买计费点里最便宜的那个。

** 游戏币:((对应游戏内充值可以直接获得的代币,在游戏里是点券、钻石这类充值才能获得的珍贵货币,目前接入 GSDK 支付能力的游戏,基本都会接入游戏币托管。游戏支付提供游戏币托管服务,托管指用户的游戏币账户余额记录在游戏支付提供的托管服务,用户购买游戏币商品后,由托管服务增加账户余额;同时游戏内的赠予、消费游戏币行为,需要调用托管服务的接口完成。游戏币托管服务具有如下特点:

  • 保障用户支付权益,防止发生用户支付完成但未获得游戏币的场景;
  • 复用数据、营销等相关能力,无需各项目单独开发;
  • 满足财务审计的递延结算合规要求。

订阅
由于涉及到续订、退订、体验期、首次折扣价格等操作,订阅的测试相对来说更复杂一些,可能是出于这个原因,谷歌官方也直接给出了测试用例,QA 侧需要额外关注以下几点:

  1. 和普通商品类似,需要验证所有的价格显示、支付流程、到账流程、涉及游戏币的变化等通用 case;
  2. 根据游戏内订阅商品的实际配置,如是否有免费试用、是否有首次购买折扣等,参考官方用例,完成游戏自己的测试用例。

1.4 常见问题

提示 “支付成功”,但实际没有到账
建议先查看订单查询中,查看对应订单状态,如果订单状态显示 “支付失败”,那基本上可以确认是,在正式环境中尝试谷歌沙盒支付,但该账号没有添加沙盒支付白名单,将账号加白即可。

如果账号已经加白,但还是无法到账,建议反馈给程序和运维同学,查询相关日志,确定发货回调地址是否配置正确和服务端发货逻辑是否正确。

点击购买商品,无法拉起支付界面
建议按 测试准备 中提及的几个准备步骤一一检查,账号问题或网络问题均有可能导致该问题。

Google Play 返回错误提示 “Item unavailable” 或者提示 “该版本的应用商品信息未配置
出现上述情况,请检查(重点排查前三项):

  • Google play 是否登录了多个账号,如果是,将其他账号删除;
  • 检查支付的账号是否是测试账号(打开手机 Google play,可以查看当前账号);
  • 测试账号是否加入到了测试计划(点击邀请链接后,需要手动点击成为测试人员);
  • 是否上传到了开发者后台,并使用 alpha/beta 通道;
  • Apk 在开发者后台不应该是 Draft(草稿)模式;
  • Apk 的 VersionCode 与 VersionName 与开发者后台配置的是否一致;
  • 开发者后台配置的商品是否有效;

其他报错信息,如无法完成支付:
按 测试准备 中提及的几个准备步骤一一检查,重点是网络,建议 GP 清除数据,第一次打开 GP 的时候配置为目标国家的网络环境。
此外,如果已经在 GP 发布的应用,进行一些配置更新,使得该应用进入到审核状态,此时支付服务可能会出现奇怪的问题,导致部分账号无法支付,可以检查下版本概览中包体的状态。

部分账号真钱支付失败,提示付款拒绝 or 更换支付方式,同时有账号可以使用真钱支付成功

有账号可以支付成功说明基本配置没有问题,很大概率可能是失败的账号被谷歌 or 银行风控了,这部分只能检查下个人账户的付款资料是否有安全提醒,或者找 GP 的客服进一步核实。

iOS 支付测试

2.1 支付流程图

基本与 GP 支付流程相同。

2.2 测试注意事项

1、首先和 GP 支付一致,接入侧研发使用提测包体,完成过一次成功的支付到账流程。
2、准备 iOS 沙盒支付账号,测试机无限制,一般来说 iPhone6 以上均可,但注意不能使用越狱机器,也不能使用模拟器。

iOS 沙盒支付账号:和 GP 不同的是,iOS 的沙盒支付账号是在 Apple 后台生成一个账号,具体路径为,登录苹果开发者后台--App Store Connect--用户和访问 -- 沙盒 -- 测试员 -- 添加,注意生成的账号的地区与最终上线地区一致,这个测试账号只能用于测试支付,无法实际登录(当然,你也可以拿一个实际能登录的 AppleID 和密码去创建这个账号,但这样比较容易让别人误解)。

已经登录的沙盒测试账号,在 iOS 设备的 设置--App Store--沙盒 一栏中可以看到,如果一台设备上之前登录过其他沙盒账号,可以在这里退出。
3、测试机退出原来登录的 Apple 账号,注意哦,这里只需要退出账号,退出之后,不需要在这里登录沙盒账号,因为你压根就登录不了,如果强行登陆,会出现以下报错提示(或者要求输入短信验证码)。

4、dev 证书和 adhoc 证书的包为测试包,只能用沙盒账号进行支付。
iOS 证书:iOS 证书如下图所示,主要分为 dev、App Store、inhouse、adhoc 这几种,其中 dev 的包主要用于前期测试,使用的是开发证书,需要打包时加入测试机的 udid 才能安装;与 dev 包不同,adhoc 和 inhouse 证书使用了发布证书,它们自己的区别在于 adhoc 是个人签,打包时也需要加入 udid 才能安装,但 inhouse 证书为企业签,随便一台手机就可以安装了;App Store 的包是上传至 App Store 时需要选择的。一般我们用的都是 gameflow 重签后的企业签包,对支付测试而言:
dev:仅能使用沙盒支付;
adhoc 和 inhouse:仅能使用沙盒支付;
App store:仅用于正式包体上传,正式上架后,才可以使用真实 AppleID 进行支付,需要注意,并且该正式线上包是无法使用沙盒账号支付的(也就是商店里下载的包,无法使用沙盒支付);
可以看到,iOS 的特点就是,没有正式上线之前,我们都无法使用真实的 AppleID 进行真钱支付,不过不用担心,我们测试时只需要验证沙盒支付即可,苹果会保证正式包支付可用的。

5、 在游戏内购买商品,系统会让你进行登录,这里点击 “使用现有的 AppleID” 就可以输入刚才创建好的沙盒测试账号进行登录(当然也可以在设置->AppStore->沙盒账号处先登录好)。

6、和 GP 类似,想要在 SDK 正式环境和正式服,使用 iOS 的沙盒支付测试,也需要在 SDK 管理端进行白名单配置,配置地址如下。

7、iOS 端的订阅支付测试和 GP 类似,使用沙盒账号即可快速验证订阅续订,对应关系可以参考:https://help.apple.com/app-store-connect/?lang=zh-cn#/dev7e89e149d

国内渠道支付测试

国内各渠道,包括字节官方渠道的测试相对海外支付而言,会简单很多,主要是既没有沙盒支付,也没有网络访问问题,支付宝微信这样的支付拉起一般也都会比较顺利。

测试注意事项

  • 由于国内各个渠道没有像 GP 和 iOS 的沙盒支付账号,只能使用真钱支付,所以测试前建议联系发行将商品价格都改成 1 分钱,验证所有商品的配置和到账情况;
  • 验证商品配置和到账情况后,还需要将价格恢复,并拉起支付验证- 价格配置,这一步在正式上线前必须完成,并确保线上价格配置符合预期;
  • 订阅商品一般国内比较少,大部分常见的月卡、通行证等,都是不带自动续费的,这种商品需要配置成道具,并在财经侧配置成可消耗商品,才能完成支付流程;
  • 华为、酷派、联想这 3 个渠道,由于其渠道侧还需要完整配置商品信息,所以对这 3 个渠道,需要完整验证所有支付点,其他渠道,在字节官包已完整验证支付点的情况下,只需要验证道具、游戏币、订阅这几种类型的商品各一次即可;
  • 商品信息的变更,需要及时同步,并在变更后及时完成对应商品的购买验证。

一点补充经验

1、支付测试虽然从用例设计和执行上看,更偏向于黑盒测试,但了解支付接入时实际的实现细节,也有助于我们发现问题。举一个例子,如果我们足够了解游戏币的几个接口的调用时机,在发现游戏内游戏币和管理后台上查询到的不一致时,就可以通过游戏币的变更信息,定位到不一致发生的具体原因,可以有效推动问题的解决;

2、使用在正式服(可以理解为玩家使用的服务器)上最好不要进行沙箱支付,避免业务方记录的消费数据和中台侧对不上(因为对业务侧而言,可能无法通过支付回调判断订单是沙盒还是正式的);

3、除了发现问题,作为 QA,更好的是能够帮助定位到问题发生在哪个环节,或给技术同学提供更多准确的背景信息,这需要 QA 同学对支付流程有一个清晰的了解,能看懂流程中各个节点的日志信息,并熟练掌握各个信息查询工具的使用。

共收到 5 条回复 时间 点赞

好像之前看过了这篇。
总结得很到位,把我们之前游戏支付的逻辑都介绍得很清晰了

先码,有空再来膜拜

写的很好,去年 5 月份刚整了一遍,很详细,要是早点遇到这篇文章,当时也不至于那么难受😂

海外 app 被 google 莫名其妙下架过,想问下,测试中较高频的请求 google 支付相关的接口有风险吗?

很详细

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册