支付测试方法分享
文摘
游戏
2024-03-01 18:00
浙江
过去的一年里，支付测试是笔者工作中的重要任务，负责了国内外的支付测试，涉及了各种渠道支付和第三方支付。作为这一年的总结，决定分享一下在支付测试中遇到的问题也希望能给之后负责支付测试的朋友们提供一些入门指导和踩坑提示。对于一个刚接触支付测试的新人来说，初次接触支付功能时似乎很简单。在正常运行时，只需点击商品，跳转到SDK界面进行支付，然后收到商品。每次进行周期回归测试时，只需逐个点击，就能完成整个流程。然而，一旦遇到问题，往往很难确定问题出现在哪个环节。因此，从入门的角度来看，对支付流程有一个简单明了的了解非常重要。这个图示流程清晰地展示了支付流程的关键要素，包括客户端、服务器、计费和渠道。当支付出现问题时，需要关注整个流程中的相关对象。由于渠道方没有提供查看日志的权限，通常只能分析客户端、服务器和计费平台的日志。计费平台作为重要的中间方，对整个支付流程的稳定性起着关键作用。在一个订单完整流转的时候，计费平台可以非常清晰地通过订单查询到整个订单流转的流程。 在接入和正式运营过程中，计费平台订单日志是需要时刻关注的部分。对于常见问题，比如用户支付后货物未到账，可以在计费日志中找到一些线索。在查看订单日志时，需要确保订单号、道具id、游戏id以及支付渠道等参数的正确性和一致性。对于由其他参数导致的特定问题，需要进行额外的分析。例如，在接入过程中，如果遇到订单状态返回值不正确的情况，应先核对对应渠道参数，再核对返回的参数是否有缺失。如果问题仍未解决，需要联系项目对接的计费支持同事，通过订单号查看更多计费侧日志以找出问题原因。计费商品在平台中分为游戏商品和渠道商品。这两部分不是独立配置的关系，而是一个游戏商品对应多个渠道商品。作为产品方、计费平台和渠道之间的重要链接，需要注意以下几个配置方面的要点。1. 最好不要将商品ID和渠道商品ID做区分，除非有特殊需求。对于大多数产品和渠道而言，商品ID和渠道商品ID是否一致并没有任何区别。然而，计费平台的商品ID配置逻辑和渠道商品ID之间存在一定关联性，如果配置不一致可能会出现渠道商品ID不正确/未配置的情况。在之前的华为渠道接入调试中，花了很长时间才发现这个问题。2. 在检查配置时，要确认游戏商品对应的平台数以及环境，以及每个商品应该配备多少个渠道商品。很多时候，一次性配置过多的商品可能会导致遗漏。3. 测试商品价格的配置时，如果需要接入多个支付渠道，建议保留一个或多个商品价格为1。价格小于1或非整数的商品可能会被部分渠道判定为非法并被拦截。内购项的策划表往往因为简单而容易被忽视，测试过程中往往只会关注里面数值上的配置是否正确，而可能对于后期具体业务实现和配置方式上缺乏考虑。各个游戏中对于内购项表格的配置和功能实现上都不一致，个人觉得需要关注的几个点有：1. 多语言多地区的配置方式以及各个地区价格的展示策略。3. 是否有考虑超买之后的补偿问题并在表格中体现。当然，内购项表格可能需要进一步扩展来满足功能需求，就需要具体问题具体分析了。在做支付相关测试时，会把更多的注意力放在上述计费平台上日志流转的完整性以及客户端发货的具体表现上。对于服务器相关日志，习惯性第一时间看看最后的结算日志就万事大吉，在接入和运营过程中才发现其实很多计费相关的日志存在格式、字段类型、字段含义错误或者不明确的情况，这些问题其实都可以在早期测试过程中发现。Google作为海外安卓端的主要发行平台，基本上所有涉及海发的项目都需要完成接入与测试，Google支付流程与国内渠道存在许多差异，测试上需要注意的地方也不完全一致。![]()
与国内渠道支付不同之处在于Google支付引入了Google Play商店作为中间交互对象。虽然通过这种方式，Google解决了许多区域限制和信用卡黑产等问题，但同时也给测试带来了许多问题和不确定性。
![]()
上述图例列举出了不同步骤出现问题以及对应的客户端表现，进一步从原因上来分析，拉起支付窗之前的阶段，主要存在商品参数的校验过程。商品参数的校验过程是多方的，因为商品参数在策划表、计费中台、Google后台都有相应配置，上文中提到了策划表和计费中台的配置，Google后台需要通过雷火发布平台进行配置。需要填写的内容主要有商品ID，价格和本地化商品信息。商品ID需要与计费中台的渠道商品ID参数一致，下面展开说一下价格配置的部分。首先需要根据发布账号地区确定基准价格。在多地区的情况下，有两种配置方式，一种是根据当日目标地区货币与基准货币的汇率进行计算，另一种是点击锁定汇率后输入目标地区货币价格。具体怎么配置由策划大佬们决定，对于测试工作来说，需要保证商品货币地区与发布地区一致，否则无法发现网络环境的影响。 填写完商品参数后，需要发布组的同学将内购项配置到Google后台，然后进行后续测试流程。需要注意的是，Google规定未经过签名并上传到Google Play的应用不能使用Google Play结算库。然而，许可测试人员可以绕过此检查。此外，软件包名称必须与针对Google Play配置的应用名称一致。在提交后，在之前有测试轨道成功发布的情况下测试环境可以正常进行沙盒支付。因此，在需要测试真钱支付的情况下，需要同时将包体和内购项提交到Google后台，以确保可以进行真钱支付。![]()
拉起支付窗之后的交互逻辑都依托Google Play商店实现，接下来重点讲述Google Play商店在测试中遇到的一些问题。在测试前需要通过VPN将网络环境切换到需要测试的地区（需保证在后台设置为发布地区）。Google为了提高api的响应速度，所以缓存了商店信息，在登陆多账号的情况下，可能会给测试结果造成相当的困扰。例如出现非当前测试地区的货币或者提示“无法购买您要购买的物品”。所以需要在测试前退出多余账号并清除缓存。 在进行沙盒支付时，登陆对应的沙盒支付账号。在进行真钱测试时，需要准备好对应地区的账号，Google的地区设置跟其他平台不太一样，在没有绑定支付方式前，其地区是根据用户所在的IP划分的，如果需要把账号限定在固定地区需要绑定对应的支付方式。目前Google充值卡的购买和使用都受到很多限制，所以需要测试时准备一张外币信用卡（需确保信用卡能支付测试地区当地货币），确定地区后输入邮编和姓名，就可以把支付地区锁定在测试地区了。在完成以上准备后，可能会遇到支付不成功的情况。最近的版本更新中出现了之前可以支付的账号无法进行支付的问题。经过与发布组和策划同学的沟通后，怀疑是被Google的风控机制所限制。频繁切换IP或设备可能会触发Google的风控机制。如果遇到账号无法进行支付的情况，可以考虑准备另一个账号或等待一段时间。 在完成付费之后，通过Google返回的渠道信息，进行到服务器发货的阶段，一般问题常见于计费后台配置不正确。在计费后台可以看到服务器对应HostID与发货地址配置，环境类型以及当前状态。发货地址是由游戏服务器开服的时候向计费中台请求注册的，在之前测试的时候遇到HostID是正确的，发货地址看起来也没有问题，但是存在偶尔没收到货的情况。后面经过排查发现内网有两个服务器使用了同一HostID，在非当前测试服务器重启的时候会进行发货地址的注册，顶掉了当前测试服务器的发货地址，导致没有在正确的服务器处理发货。 在沙盒支付测试时，需要提前申请沙盒支付服务器白名单，否则会出现无法发货的情况。不同渠道的接入要求各不相同，因此需要参考各渠道的文档来确认。接入第一时间需要注意渠道相关参数是否正确，在实际接入过程中遇到很早之前申请的渠道参数跟目前的配置无法对齐导致的支付流程不通的问题。渠道回调类型分为主动模式、商务配置和游戏客户端配置三种。主动模式类似于Google的逻辑，需要调起对应App进行支付流程。商务配置需要将内购项内容提交给渠道后台，并确保商品ID与计费中台的商品ID一致。此外，不同的渠道可能有不同的计费类型，比如小米默认使用按金额付费的方式，根据项目要求选择，接入时也需要确认UniSDK是否支持该功能。游戏客户端配置相对简单，渠道SDK直接使用产品客户端的配置，无需额外配置即可运行。在处理国内安卓渠道相关的接入工作时，通常需要多方共同解决问题。如果遇到不懂的情况，需要与各职能同学进行沟通。同时，QA同学也需要具备查阅渠道文档的能力，以便在初期能够大致确定问题的来源。项目在国内和海外都接入了网页第三方的支付，虽然两者在具体配置和接入时会有一定的区别，但是基本逻辑是一致的。从整体上来说网页第三方支付与客户端支付存在的主要区别在于：1. 限购逻辑不同于游戏客户端，需要服务器在查找角色接口中开放查询并委托网站实现逻辑用图例简单说明网页第三方支付的整体流程，网站充当了客户端的部分与游戏服务器和计费平台进行交互下面从上述提出的三个不同点入手，结合测试过程中的一些问题网站会向游戏请求玩家角色信息，由于当时海外和国内同期都在开发和调试，遇到的第一个坑点是海外和国内查找角色接口字段具体格式和要求不一致，接入时应注意。根据产品需求调整extra字段的内容，开发完成后需要着重对该字段的同步情况进行测试，是限购、首充等功能正确性的关键，所以一定要结合网站前端状态和服务器日志测试。玩家所处的阶段是否可以购买和商品的特殊性也需要一并进行考虑，由于新手流程的设计，通行证、月卡等活动的开放放到了玩家到达一定等级的时候，在临近开服的时候发现玩家在目标等级前购买通行证、月卡、终身卡没有正常发货导致限购信息并未正常进行更新。网站下单是不会受客户端状态控制的，客户端在任何状态下都可能收到服务器发来的商品发货请求，在测试阶段需要完整考虑到可能存在的客户端状态。例如，新手阶段是一个强制进行的阶段，客户端逻辑中正常是不允许玩家做流程之外的操作的，在接入第三方支付的时候没有考虑到验证新手引导流程阶段玩家购买道具的表现。当时国服渠道测试刚开的第一天，就有玩家在新手阶段打开客户端的情况下进行了网页第三方支付的购买，导致出现卡出新手引导流程进而出现流程循环卡死的bug。网页第三方下单是可以同单购买多个道具的，多个道具是否正确发货也是测试重点之一。对于未接入第三方支付的项目，可能会对订单的道具数量本身限制或者没有对应的考虑，随着商品数量增多或者商品本身性质比较特殊，程序在做更改的时候可能会出现遗漏，公测上线后，由于第三方支付发放月卡特权道具存在问题发生了月卡系统相关的事故。本次分享主要介绍了个人测试过程中比较棘手的Google、国内渠道和第三方支付的概要和遇到的问题。在最后从这一年的支付测试中有一些感受和对于后续工作的想法跟大家分享：支付相关的体验其实对用户来说非常重要，虽然无法避免渠道出现丢单、重复支付等问题，但是从项目组的角度出发需要考虑到用户在支付时应该有良好、快速的反馈。我们也是在运营中根据用户的反馈调整了再次拉起订单的间隔时间以及发货后给用户发送邮件让用户确认自己收到对应道具。这些问题测试的时候也可以把自己放在用户角度多想想，进而把这部分改进提前。支付涉及到的周边逻辑以及其本身的周转流程在服务器上都有相当完整的体现，花时间阅读相关服务器代码不论是对测试完整性的把握以及对测试重点的考虑都非常有帮助，代码阅读之后也可以从代码逻辑层面做粒度更细致的测试内容。在整个支付接入过程中，需要与程序、策划、计费、发布组、营销、商务以及网站组的同事进行各类事务的沟通。通过更好地提出问题和进行更精确的沟通可以事半功倍。
