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

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 同学对支付流程有一个清晰的了解，能看懂流程中各个节点的日志信息，并熟练掌握各个信息查询工具的使用。