游戏支付测试分享

写在前面：

1. 本文主要介绍支付测试的通用方法、基础概念和一些容易踩坑的点，包括国内安卓渠道和iOS、海外Google Play和iOS支付，希望通过阅读本文，可以帮助大家顺利完成支付测试；

1. 本文主要站在QA验收的视角介绍，对于一些发行向或研发向的配置，会选择略过或简述，请理解；

1. 本文面向的测试对象，是那些已经接入完成，自测，笔支付订单的游戏，接入过程中遇到的问题，不在本文介绍的范围内；

1. 部分流程图、引用内容文中标注了引用来源，详情可以点击链接了解；

1. 水平有限，不清晰或有误之处，烦请不吝指正。

支付测试的目标

支付测试，是游戏QA功能测试中的一小块，不过因为参与方比较多，往往发生问题后，排查比较困难，因此需要梳理一下流程，为一些常见的问题提供清晰明了的排查思路。

个人理解的支付测试点大体包括两个层面：

1. 确保支付能力接入正确，可以完整地完成支付流程；

1. 确认各处商品配置正确，所有商品均能正常支付并最后到账。

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

Google Play支付测试

支付流程图

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

普通IAP：

订阅

1. 订阅的首次购买和普通的IAP流程差异不大；

1. 相较于一次性IAP消费，订阅有状态的概念，在订阅状态发生变更时需要通过回调进行状态维护。

测试准备

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

• 为了确保提测的包体，已经完成了商号申请、参数配置、基本的商品配置、服务器的支付回调等一系列的前置步骤，避免出现提测包体本身不满足测试条件的乌龙。

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

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

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

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

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

1. 不需要付真钱， 线上的计费点可以按实际价格直接配置，我们验收所有计费点时的结论也更准确；

1. 官方说法：

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

• 沙盒账号支付：打包时，包体versionCode与最后一次上传的包设置成一致，使用沙盒账号支付，绕过签名检查；
• 真钱支付：完全使用上传的包体进行安装，或者直接从GP商店进行下载安装，支付时，使用对应地区的GP账号+配置为目标国家的网络环境，直接进行支付，但建议只支付一笔；

1. 测试订阅很方便，一个月的续订周期，沙盒账号只要5分钟就可以触发续订逻辑，详情可以参考：https://developer.android.com/google/play/billing/test

沙盒支付白名单: GSDK为了避免沙盒测试账号流出到正式环境，造成安全风险（你懂的，无限购买），特意在SDK正式环境的后台增加了沙盒支付白名单的功能，只有给沙盒支付订单对应的游戏角色/设备加了白名单，才能完成支付。

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

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

测试流程

普通商品

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

1. 游戏内显示的货币与价格，符合预期
1. 默认情况下，游戏商品的定价显示会按发行配置时使用币种由GP管理后台根据汇率和税率实时换算成当地的价格，此时可以根据计费点中的价格大致换算一下对应的上即可；
2. GP支持根据不同国家，指定商品的价格，此时应需要发行提供测试账号所在国家的价格配置；
2. 支付流程能正常完成，商品也成功到账（到账不仅要查看购买成功的弹窗，也要实际去背包中查看或使用，确保是东西是真的进背包了）；
3. 游戏币的充值，不仅要关注游戏内游戏币的数量和到账情况，同时需要关注管理后台上角色信息中的游戏币变化情况，具体有：
1. 充值游戏币后，查询角色信息，游戏币数量增加符合预期；
2. 消费游戏币后，查询角色信息，游戏币数量增加符合预期；
3. 游戏玩法赠送游戏币后，查询角色信息，游戏币数量增加符合预期；

1. 验证发行提供的所有计费点的实际支付和到账情况；

1. 游戏内的限购、随机直购等逻辑要根据游戏设定自己写case；

1. 正常来说，支付测试不太需要使用真钱支付，沙盒支付全量验收后其实就可以保证游戏真钱支付能力无问题，但一般咱们为了做最后的确认，还是在最终包上会使用真钱支付一次，验证最终包的真钱支付能力，一般会买计费点里最便宜的那个。

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

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

订阅

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

1. 和普通商品类似，需要验证所有的价格显示、支付流程、到账流程、涉及游戏币的变化等通用case；

1. 根据游戏内订阅商品的实际配置，如是否有免费试用、是否有首次购买折扣等，参考官方用例，完成游戏自己的测试用例。

常见问题

1. 提示“支付成功”，但实际没有到账

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

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

1. 点击购买商品，无法拉起支付界面

建议按 测试准备 中提及的几个准备步骤一一检查，账号问题或网络问题均有可能导致该问题。

1. Google Play返回错误提示“Item unavailable”或者提示“该版本的应用商品信息未配置

出现上述情况，请检查（重点排查前三项）：

1. Google play是否登录了多个账号，如果是，将其他账号删除；
2. 检查支付的账号是否是测试账号（打开手机Google play，可以查看当前账号）；
3. 测试账号是否加入到了测试计划（点击邀请链接后，需要手动点击成为测试人员）；

1. Apk是否上传到了开发者后台，并使用alpha/beta通道；

1. Apk在开发者后台不应该是Draft（草稿）模式；

1. Apk的VersionCode与VersionName与开发者后台配置的是否一致；

1. 开发者后台配置的商品是否有效；

1. 其他报错信息，如无法完成支付：

按 测试准备 中提及的几个准备步骤一一检查，重点是网络，建议GP清除数据，第一次打开GP的时候配置为目标国家的网络环境。

此外，如果已经在GP发布的应用，进行一些配置更新，使得该应用进入到审核状态，此时支付服务可能会出现奇怪的问题，导致部分账号无法支付，可以检查下版本概览中包体的状态。

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

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

iOS支付测试

支付流程图

基本与GP支付流程相同。

测试注意事项

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

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

已经登录的沙盒测试账号，在iOS设备的 设置--App Store--沙盒 一栏中可以看到，如果一台设备上之前登录过其他沙盒账号，可以在这里退出。

1. 测试机退出原来登录的Apple账号，注意哦，这里只需要退出账号，退出之后，不需要在这里登录沙盒账号，因为你压根就登录不了，如果强行登陆，会出现以下报错提示（或者要求输入短信验证码）。

1. 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进行真钱支付，不过不用担心，我们测试时只需要验证沙盒支付即可，苹果会保证正式包支付可用的。

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

1. 和GP类似，想要在SDK正式环境和正式服，使用iOS的沙盒支付测试，也需要在SDK管理端进行白名单配置，配置地址如下。
2. iOS端的订阅支付测试和GP类似，使用沙盒账号即可快速验证订阅续订，对应关系可以参考：https://help.apple.com/app-store-connect/?lang=zh-cn#/dev7e89e149d

国内渠道支付测试

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

测试注意事项

1. 由于国内各个渠道没有像GP和iOS的沙盒支付账号，只能使用真钱支付，所以测试前建议联系发行将商品价格都改成1分钱，验证所有商品的配置和到账情况；

1. 验证商品配置和到账情况后，还需要将价格恢复，并拉起支付验证价格配置，这一步在正式上线前必须完成，并确保线上价格配置符合预期；

1. 订阅商品一般国内比较少，大部分常见的月卡、通行证等，都是不带自动续费的，这种商品需要配置成道具，并在财经侧配置成可消耗商品，才能完成支付流程；

1. 华为、酷派、联想这3个渠道，由于其渠道侧还需要完整配置商品信息，所以对这3个渠道，需要完整验证所有支付点，其他渠道，在字节官包已完整验证支付点的情况下，只需要验证道具、游戏币、订阅这几种类型的商品各一次即可；

1. 商品信息的变更，需要及时同步，并在变更后及时完成对应商品的购买验证。

一点补充经验

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

1. 使用在正式服（可以理解为玩家使用的服务器）上最好不要进行沙箱支付，避免业务方记录的消费数据和中台侧对不上（因为对业务侧而言，可能无法通过支付回调判断订单是沙盒还是正式的）；
2. 除了发现问题，作为QA，更好的是能够帮助定位到问题发生在哪个环节，或给技术同学提供更多准确的背景信息，这需要QA同学对支付流程有一个清晰的了解，能看懂流程中各个节点的日志信息，并熟练掌握各个信息查询工具的使用。