我叫Sasha Zubarchuk。三年前，我以《初级手册》质量检查来到Solid。从那时起，我成为一名自动化工程师，从我们与之合作的第一家质量保证学校毕业，并转到产品经理一职。
在本文中，我将讨论测试支付系统的功能并分享我们团队的经验：我们正在测试什么，如何，我们面临什么挑战以及如何应对它们。这种经验对于在项目上建立测试过程的人员-质量检查工程师和产品/项目经理都是有用的。
我不会深入研究技术和特定工具，而是会讨论主要思想：如何使测试技术上复杂的服务的过程尽可能透明和平静。
它的组成和工作方式
Solid是一个网关，它使世界各地的企业都可以以各种方式接受在线客户付款，从银行卡和电子钱包到PayPal和Alipay。
在整个故事中，有四个主要参与者：
- 用户（他也是买家）；
- 商人-在互联网上出售其商品/服务并希望为他们收钱的任何企业；
- 支付网关-稳定；
- 银行（收单行） -使用真实货币进行交易的金融机构。
简而言之， 它看起来像这样：简单地说，我们帮助商家获利并赚钱。
您可能会有一个问题：如果商家可以直接与银行合作，为什么商家选择Solid？很简单：1）有很多银行，每个银行都有自己的特点-通过将来自不同国家的不同银行合并为一个基础设施，我们可以实现最大的转换和收益； 2）我们在支付逻辑和反欺诈方面拥有丰富的专业知识； 3）除银行付款外，我们接受在特定地区流行的所有其他付款方式，并且4）价格便宜。
让我们从第一点开始-在不同国家/地区进行付款有哪些特征？例如，在美国，奇怪的是，您将不能像乌克兰那样轻松地付款-仅使用卡的详细信息即可。在那里，银行需要检查其他付款人详细信息，例如帐单地址和邮政编码。
有许多相似之处。以及卡付款的替代方法。例如，在荷兰和德国，人们喜欢使用本地互联网钱包。在中国最受欢迎的支付方式是支付宝，微信支付和银联。在尼日利亚，要在互联网上付款，用户可以用现金去银行！
我们无一例外地接受所有流行的付款方式-从银行卡到PayPal，电子钱包，Google Pay，Apple Pay或SMS。在Solid的帮助下，商人可以一次集成使用所有类型的付款进行交易。此外，网关具有自己的防欺诈保护，付款路由系统，防止不合理拒付的工具等等。
为什么要测试支付系统以及不进行测试的风险
许多商人已连接到Solid。因此，我们不仅对我们的业务负责，而且对与我们联系的所有客户的获利负责。如果我们这边出了问题，那么我们会让太多的公司倒闭。反之亦然-通过测试和改进我们的付款服务，我们改进了其他业务的产品。
不幸的是，除了成功付款外，还会发生错误-系统和用户。重要的是要了解100％的付款永远不会在任何位置成功通过。但就我们而言，我们有义务尽一切可能使付款尽可能地转换。
测试支付网关不是一项日常任务，因为它是由数十种微服务和互连组成的相当复杂的机制。我们分三个阶段测试所有内容。首先，我们在隔离的环境中检查每个任务，然后在阶段将它们组合并在候选发布版本中进行检查，我们了解集成中的所有工作原理，然后在生产中再次发布并测试所有内容。
让我们仔细研究一下我们必须测试的内容。
测试支付系统的功能
支付系统包括API和Web界面。与其他任何产品不同，支付系统的API和网络测试没有根本的区别。主要功能是测试针对不同地区的特定付款以及所有辅助服务。
似乎测试付款并不困难：您需要付款，检查钱是否从一个帐户借记，然后记入另一个帐户。但是有细微差别。测试人员需要了解不同国家/地区的付款细节，有时还需要了解当地法律和银行法规的细微差别。
第二点是不同的付款方式：订阅，第一笔付款，授权（冻结帐户中的钱），通过电子钱包付款。他们每个人都有自己的测试细节。
应特别注意使用货币：并非所有货币都占一小部分。例如，格里夫纳汇率只有一分钱，而智利比索则没有。如果您在乌克兰转帐付款金额100，银行将核销1 UAH，即100戈比。在智利，这将意味着100比索。如您所见，这些时刻不容错过。
付款系统需要测试什么
我们所有的客户（网络，移动应用程序以及后端服务）都使用Solid API与我们通信。网关本身位于单独的群集上，并与各种系统（防欺诈，令牌生成器，银行等）进行通信。
扎实的开发人员致力于解决几种类型的问题（所有这些任务最终由质量检查小组处理）：
- ( , , , , );
- (PayPal, Alipay Visa Mastercard);
- : API, ;
- ( , );
- , (, , -);
- .
除了直接来自开发人员的任务外，我们还收到其他任务：在连接新商家时检查所有数据和UAT，检查来自DevOps团队的任务，设置反欺诈规则。
总而言之，我们测试的所有内容都可以分为以下几类：
可靠的后端服务：
- 反欺诈;
- 订阅服务；
- 付款路径；
- 会计和财务控制系统；
- 与外部服务集成。
与银行整合：
- 检查使用货币的正确性；
- 验证不同类型的付款（通过卡数据进行首次付款，通过令牌进行付款，退款，冻结资金等）；
- 处理通知。
替代（非卡）付款方式：
- 付款确认；
- 检查位置的功能。
管理员：
- 内部管理面板（所有有助于Solid分析人员进行A / B测试以转换付款形式，设置反欺诈规则的功能）；
- 商家管理面板。
用户界面：
- 付款表格和页面的外观；
- 表格是否以特定地区的语言显示（全球所有语言均提供Solid Payment表格）;
- 正确显示金额和货币；
- 跟踪用户对表单的操作；
- 页面状态。
其他：
- 将新商家连接到Solid时的UAT；
- 风险部门的任务以检查新配置；
- 功能健康研究（例如，Apple Pay是否可以在WKWebView中工作）。
测试成功的步骤
自动化
在使用大型IT解决方案（例如付款提供商）时，您不仅需要不断测试功能的各个元素的运行，还需要不断测试它们的交互。没有自动化，它将无法工作。如果自动测试未涵盖某些服务，则无法避免失败。尽可能运行自动测试。将任务倒入环境中-运行测试。将几个任务合并到一个候选发布版本中-运行测试。
就我们而言，它是这样的：
- 开发人员在执行任务时独立运行测试；
- 测试人员在隔离环境中测试任务时运行测试；
- 当构建新版本的构建时，将自动启动测试；
- 自动测试在Prod环境中不断运行。
运行自动测试需要花费时间，因此我们始终努力尽可能地优化此过程。测试以多线程方式运行，并且也按重要性分为任务。
我们只需要进行最少的测试，即可验证Solid的核心付款处理功能-不到一分钟即可运行。 Solid API和其他微服务的所有其他测试大约需要3-4分钟。 UI测试当然要慢一些。但是即使在这里，我们也不会停止改进和优化。
为什么在测试付款时孤立测试不是最佳选择？我将就我们的反欺诈案告诉您。
每个实体商户都有一个反欺诈帐户，该帐户与规则的设置，规则的工作方式有关。例如，如果用户每天与商家进行的付款超过三笔，则我们将第四笔付款屏蔽。或者，如果有五个以上的用户使用同一张卡付款，我们也会阻止并将其添加到黑名单中。我们进行了自动测试，但遇到了问题。
最初，我们复制了测试帐户的所有规则，模拟了欺诈行为，并且测试似乎可以正常工作。但是事实证明，商人本人经常遇到将反欺诈规则组合在一起的情况，例如，其中三个规则有效。
通过隔离每个特定规则的每个付款，我们摆脱了规则组合的可能性以及其他服务对付款过程的影响。
我们如何付款：我们清除了测试数据，创建了所有条件以使付款符合特定规则，然后就可以了。但是在工作环境中事实并非如此，因为永远不会有理想的情况来使付款落在一条规则之内。
我们决定将客户的真实反欺诈规则与测试商人联系起来。然后他们开始更清楚地进行锻炼。也就是说，有必要创建不是孤立的规则，而是像针对特定客户端那样对它们进行汇总测试。
现在，Solid客户可以为自己定制反欺诈规则。因为对于一个商人而言，看起来像欺诈的交易可能是另一种交易的规范。
如果某人每天在网上商店购买五笔商品，那么这就是常态：首先，他喜欢手机的外壳，然后是笔记本等。但是对于健身应用，这已经是一个异常。一个人不太可能一天购买五种锻炼计划。
自动化确实有助于建立平衡：只有手动检查了新功能以及那些需要人工关注的场景，其他所有东西都是自动化的。自动化可以帮助降低测试成本和人为风险。
技术规格阶段的测试
除了直接检查功能的功能之外，我们还花费大量时间来确保开发人员和管理人员以相同的方式感知已实现的功能。似乎很明显，但是很多人忽略了它。
所有配置服务都非常复杂，它们具有广泛的可能性，即使是最小的细节也可能导致服务无法按预期工作。
“早期测试”技术具有多个优点：
- 开发团队将正确理解任务，并且我们不会浪费时间进行修复；
- 编写良好的技术规范占良好文档的70％；
- 由于测试团队事先熟悉了技术规范，因此还提前考虑了测试方案，并且在实施的任务要进行测试时，过程进行得更快。
好的测试文档
测试时，真正好的结构化内部文档才是成功的一半。尽管几乎所有功能都应该是自动化的，但是手动工作永远不会白费。
各种功能的测试过程的描述，可能解决问题的文章以及各种手册可加快测试团队的工作。
Solid公司已经建立了自己的知识库。它描述了各家银行及其替代付款方式在不同位置的工作方式，银行支持的付款类型以及原则上如何在特定区域进行付款。
这样的基础是一项庞大而复杂的任务，已经成为我们的挑战。有必要将所有文档放在一起并以可访问的方式描述过程。但是现在，当有新员工来找我们时，就没有问题了。很难记住第一次应该如何工作，如果有测试文档，则犯错误的可能性很小。清晰的文档可以使测试人员准确确定付款失败的原因：这是一个错误还是该类型的付款根本不应该在该银行工作。
让我再举一个例子。一旦我们在付款表格上更改了国际支付系统的徽标。我们为客户提供200多种不同的设计，每种设计在表单上可以有几种字段配置。例如，对于巴西，添加了一个附加的CPF字段-与我们的识别码类似。
由于徽标的新大小，表单上的某些字段可能会移出，消失或无法单击。Solid测试团队中没有人会物理上知道所有200种形状的外观。
测试此任务非常麻烦，但是结果，我们为每个商人创建了具有参考表格的知识库，并进行了自动测试，现在我们不担心与设计相关的任何更改。
***
最后，我将告诉您一个来自处理世界的有趣的事实：在乌克兰，限制卡数量下降的比例非常低-1-2％。要么乌克兰银行擅长防止欺诈，要么没人愿意窃取乌克兰用户的卡数据……
尽管如此，没有一款产品具有理想的开发和测试流程，但是我们可以对其进行改进。毕竟，每个企业的任务都是发布高质量的产品。如果不是质量检查工程师，还有谁可以帮助您呢？
如果您在评论中分享良好测试过程的原则，我将非常高兴。