😳 📿 🤵🏿 如何在黑匣子中不赔钱：计费测试方法 👨🏻‍🎨 🌎 👩🏾‍🍳

付费服务的验证是测试Badoo的关键工程问题之一。我们的应用程序已与全球250个国家/地区的70个付款服务提供商集成在一起，并且其中至少一个错误可能导致不可预测的后果。

在本文中，我将讨论我们在Badoo中使用的测试方法，以及这些方法的适用范围-最有效的测试阶段。

本文对于测试人员，开发人员和产品经理非常有用，他们的项目已经与付款提供商集成，或者集成过程才刚刚开始。如果您在工作中遇到选择用于此类集成的测试方法的问题，欢迎加入我们！

我叫Vladimir Solodov，我是Badoo的Billing质量检查工程师：我从事测试集成和付款处理的验证。 我的同事Viktor Koronevich帮助我准备了案文：我们与他一起在Heisenbug会议上做了报告（视频）。 在本文中，我们将描述区域扩展到与Badoo中使用的支付提供者的所有集成，分类并更详细地描述了删除外部依赖项的做法。

以业务案例研究为例，我将解释为什么您应该更多地关注测试付费服务，以及即使出现问题也不会加剧问题。然后，我们将继续描述测试集成的技术问题及其解决方法。

在本文的第二部分，我们在这里更多地讨论在iOS应用程序中测试付费服务的自动化。

走吧

帐单测试细节

通常，企业的目标是产生收入。在约会的社交网络Badoo中，收入是通过贷款和高级订阅获得的。贷款是Badoo的内部货币。例如，在他们的帮助下，您可以首先在搜索结果中提升个人资料，为其他用户做礼物，等等。付费订阅的有效期为一定时期，一次即可为您提供多种选择：打开“隐形”模式，查看对您感兴趣的人，确认您帐户的真实性等等。

为了使这些付费服务正常工作，我们使用了与70多家付款提供商的集成。供应商的选择取决于平台，国家/地区，设备，移动运营商和其他因素。因此，测试付费服务的问题非常紧迫。

首先，请考虑为什么应该特别注意测试付费服务的方法。有两个原因。

1.帐单错误对业务至关重要。

第一个问题是声誉。付费服务的用户对应用程序中的错误变得更加敏感（并且容忍度较低）。遇到付费服务中的错误的用户，在公共空间中收到的任何反馈（无论是对博客应用程序的评论还是对App Store或Google Play的评论）都会引起更多的情感动荡-这是导致声誉损失的一个因素。

第二个问题是，一旦您开始从用户收取服务费用，您就会成为保护服务消费者的法律的对象。声誉损失很容易变成经济损失。

公司通过三种方式亏损。

第一种方法是退款。假设用户发现您向他出售了一项服务，该服务不能完全满足他的期望。在这种情况下，他将与您的支持团队联系。它的员工进行了调查，发现由于应用程序中的错误，用户的期望确实没有实现。您发起退款。在这种情况下，会有退款：结果，公司面临利润损失，这是最无害的赔钱方式。

第二种方法是拒付。假设发生相同的情况，只有用户未与您的支持服务联系，而是与向他发行卡的银行或付款提供商联系。银行/提供商会退款。在这种情况下，我们正在处理拒付。在这里经营的危险不仅在于利润损失。经过一定数量的退款后，该公司会受到罚款，其风险评级会降低。降级又导致支付提供商的服务成本上升。

第三种方式- 诉讼（索赔） 。在最被忽视的情况下，可能会发生诉讼（包括集体诉讼），从而导致最严重的后果。因此，在2015年，在Ofgem监管机构提起诉讼之后，由于收费系统错误，英国天然气公司被迫向收费较高的用户支付数百万美元的赔偿。在此处阅读有关此内容的更多信息。

2.对于测试集成，需要知识和专业知识。

刚开始与支付提供商进行集成的团队经常会遇到此问题。由于不知道所有可能的计费情况，当他们意识到系统对付款提供商的通知作出反应时，他们错过了重要的细微差别。

这可能导致不可预测的后果-从利润损失到用户不满意。

让我们看一下列出付费服务类型的方案，并更仔细地考虑问题。

图1.可能的计费情况

主要有以下三种情况：错误，成功付款和退款给用户。但是每种情况都有细节，您的系统必须处理不同的情况。

错误可能很严重，也很不严重。通知错误可归因于非关键-当付款提供商通知用户帐户中资金不足时，以及非关键-阻止用户的付款方式。如果在第一种情况下您可以尝试稍后付款，那么在第二种情况下-找出阻止该方法的原因将非常好。也许用户被发现存在欺诈行为，因此您应该更加谨慎对待他的交易。

退款。您已经知道退货有两种类型：退款和退款。您的系统对它们的响应必须不同。例如，在扣款后，考虑为用户阻止应用程序的某些功能是很有意义的，因为扣款是最流行的欺诈方法之一。

成功的付款可以是一次性付款，也可以是订阅。

一次性付款可以是消耗性的，也可以是非消耗性的。我们在文章的开头检查了一个花销支付的示例-这些是Badoo中的贷款。非消耗性支付的示例可以从游戏中给出。假设您有一个扮演的角色。您想为他购买已经存在一段时间的超级大国。在这种情况下，购买属于非消耗性付款的类别。

订阅内容 这是最大的案例。除了最初购买的订阅外，您还可以：

续订（续订）；
封闭订阅（取消订阅）；
试用订阅（试用版）；
宽限期订阅：当我们无法续订该订阅并尝试在称为宽限期的一段时间内再次付款时。对于用户，宽限期如下所示。假设您购买了每月报纸订阅。向您发送报纸的公司正试图在第一个月月底前注销下个月的订阅付款，但不能这样做（由于卡锁，帐户资金不足等）。如果宽限期的有效期为十天，则在此期间，公司将尝试注销付款，而订阅仍然有效。如果公司无法注销该笔款项，则取消订阅。如果是，则从上次付款日期起续订；
部分付款（部分结算）。例如，如果用户的帐户中没有足够的资金，PayPal允许您进行部分付款（部分付款），或者将付款分为多个部分（部分发票）。

您还需要考虑两个完全取决于支付提供商的特征：订阅可以由您的应用程序控制或从外部进行管理。

内部管理的订阅是，例如，使用信用卡或PayPal进行的订阅，在第一次付款后，您会得到一个令牌，您可以使用该令牌重新向提供者重新申请，而无需用户的付款详细信息。
外部管理的订阅是指付款聚合器完全控制您的订阅并仅向您发送有关其当前状态的通知。

在图中，最明显的区域（通常首先是针对该区域的反应）以紫色突出显示。随着专业知识的积累，所有其他因素都开始被考虑到很晚。计费领域中迭代开发方法的错误应用在很大程度上促进了这一点。

图2.主要在系统中实现的计费案例

这样分阶段的实施会导致不可预测的后果。例如，在我在Badoo之前从事的一个项目中，没有考虑退款的可能性。结果，所有回报都不是通过退款获得的，而是通过拒付而获得的，这对公司的风险评级产生了负面影响，并导致收集收入统计信息失败。对各种计费案例的无知会导致利润损失或使公司容易受到欺骗。

因此，一方面，应在发布之前发现付款处理中的错误，因为它们可能导致最不利的后果。如果无法做到这一点，重要的是尽快了解该错误已进入应用程序的发行版本，对其进行修复，最重要的是，让许多人忘记的是，“放心”遇到该错误的用户。

另一方面，由于与支付提供商的集成总是与黑匣子互动，因此情况变得复杂，这给测试过程增加了很多变量。

帐单测试期间的技术问题

让我们在Badoo与App Store集成的示例中考虑它们。

App Store上的订阅属于外部管理的类别，也就是说，它们是在提供商方面完全托管的，我们的系统只能请求当前状态或接收其更改通知。

我们特别选择了这种集成，因为它是最复杂的，并且包含在将服务与其他付款提供商集成的过程中可以找到的各种情况。

首先，我们转向一次性消费。

图3.一次性支出的过程

在步骤1，用户发出购买服务的请求。应用程序决定应该付款，然后在步骤2中，控制权转移到付款提供商（App Store）。步骤3：向用户显示要付款的表格。步骤4：用户提供付款数据。步骤5：提供者完成交易并将结果报告给应用程序，返回包含有关购买的完整信息（日期，服务，状态等）的收据。步骤6：将补充有用户数据的支票发送到服务器进行处理。服务器在第七步中处理检查数据并为应用程序生成推送通知。在第八步中，将通知显示给用户。

问题在于，步骤3、4和5是在付款提供商一方执行的，实际上不受我们的控制，并且可能会有各种变化。因此，该过程实际上没有如图2所示的线性结构，而是一个分支（请参见图4），并且每个分支必须由应用程序以不同的方式处理。

图4.分支一次付款状态图

购买订阅的方式与一次性付款的方式相同，但是对流程的进一步控制非常难以控制。

图5.外部管理的订阅状态

让我提醒您，我们以Apple订阅为例进行了外部管理。这意味着购买后的用户可以对其进行异步管理：关闭，更改到期日期，要求退款。我们在步骤9中看到了这一点。由于该动作发生在系统之外，因此在图中用虚线标记了它。

在步骤10中，App Store可以更改订阅状态：续订，关闭，在窗口中输入宽限期。

为了了解订阅的状态，请执行步骤11，该步骤特定于诸如App Store和Google Wallet之类的聚合商。在此步骤中，系统发送令牌，该令牌用作在购买订阅之初或之前的续订后收到的收据。

步骤12是提供者的响应。我们收到支票，其中包含订阅的当前状态。此步骤中的结果取决于异步步骤9和10。

在2018年秋季，Apple所有人都实现了服务器到服务器通知的机制，该机制使您可以通知订阅发生的更改。在步骤13中显示了此类通知的接收。对于大多数其他提供程序，服务器到服务器的通知机制是唯一的机制，因此可以说Apple的示例涵盖了所有情况。对于其他提供程序，步骤13允许您从方案中排除步骤11和12。

在步骤14，服务器为应用程序生成更改订阅状态的响应。

因此，我们得到了一个完整的状态图，必须检查这些状态才能检查付费服务。

图6.更改付款状态的完整过程（以外部管理的订阅为例）

我们在系统中无法控制的零件以橙色显示，对于我们来说它们是黑匣子。

计费测试方法

因此，测试付费服务时的主要技术问题是“黑匣子”的存在，我们对其状态几乎没有控制。这定义了一组可以涵盖所有情况的方法。

这些方法并不多，我们将它们分为三类：实际付款，沙箱以及从“黑匣子”中消除外部依赖。

实际付款

实际付款作为一种测试方法是有好处的，因为它们可以清楚地说明集成状态。实际付款中的错误是错误的无条件证据。

否则，实际付款是不好的。首先，它很昂贵：很明显，要进行真实付款，您需要花费真实金钱。如果您认为最终将全部金额退还给公司，那将是您的错误：首先，提供商会为每笔交易收取一定费用，如上所述，交易的规模取决于组织的风险等级，并且可以达到40％（甚至更高）。 ; 其次，在其他国家/地区进行付款测试时，您可能会由于货币差价（即货币的购买和销售价格之差）而亏损（您将以银行的外币销售价格进行购买，而回报将以购买价格计算）。

此外，此方法可能会花费很长时间，因为您必须等待订阅续订期的结束，宽限期的完成，并且这些时间可能长达数月。

沙箱

沙盒很漂亮。实际上，这与付款提供商在实际付款的情况下提供给我们的功能相同，但无需花费实际资金。提供商完全支持它，这意味着与沙盒的集成很便宜。

通常，使用各种技巧来解决随时间推移进行测试的冗长问题。例如，App Store沙箱使用以下订阅到期转换。

实时订阅	苹果沙盒订阅时间
1个星期	3分钟
1个月	5分钟
2个月	10分钟
3个月	15分钟
6个月	30分钟
1年	1小时

表1.实际订阅的有效期与Apple沙箱中的订阅的有效期比率

表2列出了默认的Google Wallet沙箱订阅，可以在卖家的控制台中对其进行配置。

实时订阅	Google沙盒订阅时间
1个星期	5分钟
1个月	5分钟
3个月	10分钟
6个月	15分钟
1年	30分钟

表2.在Google沙箱中设置订阅的持续时间

与Apple沙箱不同，您还可以使用表3中的比率在Google沙箱中检查试用版，宽限期等。

实时订阅	Google沙盒订阅时间
试用期	3分钟
试用期（入门）	等于相应订阅时间
宽限期（3/7天）	5分钟
临时帐户锁定（保留）	10分钟
暂停（1/2/3个月）	5/10/15分钟（分别）

表3. Google沙箱中其他订阅功能的有效性

关闭订阅也可以通过不同的方式来实现：在App Store的沙盒中，关闭是在第五次续订后完成的，而在Google Wallet中是通过卖方的控制台或在Play Store的设备上完成的。

沙箱的问题在于提供商对质量的态度不同。我们的经验表明，集成到Badoo的70多家支付服务提供商中，只有两个沙箱具有完整的功能和稳定的操作。这些是Adyen和PayPal的沙箱。其他提供程序具有稳定的功能，但在功能沙箱方面被截断（如Google Wallet），或者具有不稳定的功能，并且在功能上受到极大的截断（如App Store和Fortumo）。而且有些提供商根本没有，也根本不会拥有沙盒。

图7.按稳定性和功能分类的沙箱

删除外部依赖

如果我们说服您使用实际付款进行的测试昂贵且效率低下，并且付款提供商未提供质量适当的沙盒，则有必要寻求各种方法来消除外部依赖性。它们只有三种：moki，假货和存根。

Moki在计费中是系统对具有预定参数的请求的反应的形成，而无需真正调用支付提供商（请参见图8）。例如，在向SMS支付提供者发送请求到提供商的阶段，截获了对SMS支付提供者的号码+ 7111-111-11-11的请求，并以成功付款的形式生成了系统响应。对号码+ 7111-111-11-12的请求也被拦截，但导致对错误代码“没有足够的钱来完成交易”的反应。