Merpay是日本最大的网购平台之一Mercari的无现金支付系统。Merpay 的主要功能是让用户在 Mercari的网站上购物，也可以在日本的许多实体店和餐厅使用它，也可以理解为日本的“支付宝”。以下为Merpay QA 团队在自动化方面的一些思考：
这几年，Merpay QA 团队一直关注的一件事是促进测试自动化。在这篇文章中，我将介绍我们在开发测试自动化时遇到的一些问题，并介绍我们用来支持产品的一些工具。
Merpay QA 团队致力于测试自动化有三个原因：减少工作量、加速发布、稳定质量。这些都非常简单，它们可能是大多数公司采用自动化的原因。
Merpay 积极参与 DevOps，以便“继续为客户提供更快、更可靠、更好的服务”。为此，我们需要加快质量保证、简化操作并用更少的人员处理更多的测试。这意味着在高影响领域有效地实现自动化测试至关重要。
Merpay QA 的一大特点是我们尝试帮助快速发布产品（而不是停止发布的 QA）。我们的目标是与开发团队建立一个合作体系，以便相互支持我们的职责。我们还致力于通过在开发阶段纳入许多测试来提高质量，并通过尝试从开发早期就纳入自动化测试来优化验证阶段的测试。
人们倾向于认为质量保证测试发生在发布前的最后阶段。然而，产品开发过程处于不断变化的状态，这导致了间歇性发布的周期。这就是为什么我们需要将 QA 视为“持续测试”，而不是“最后测试”。如果在这种环境下仅仅依靠手动测试，我们需要投入大量的资源来继续测试，每次扩大产品规模时都需要大量的质量保证资源。
此外，为了实现自动化，我们需要建立执行自动化所需的环境类型。任何通过通信处理的事情都需要进行重组，以使自动化变得更容易。为了实现这一目标，我们 Merpay 利用了非常适合我们开发文化的测试自动化工具。
Merpay使用的自动化工具
我们使用的主要测试自动化工具和项目管理工具可以大致分为后端、前端和本机应用程序，如下所示。
我不认为我们使用的工具与其他公司使用的工具有很大不同。话虽如此，值得一提的是，我认为非常像 Merpay 式的，那就是我们使用“Scenarigo”，它是由我们的一位开发人员内部开发的。
Scenarigo
“ Scenarigo ”是一款基于场景的测试自动化软件，由Merpay开发人员使用Go 语言 (Golang) 开发的开源软件。(地址：https://github.com/zoncoen/scenarigo)
Scenarigo是一个用于运行API服务器场景测试的工具。它类似于Postman，常用于后端测试。Scenarigo具有以下特点:
[场景特性]
• 测试场景可以用YAML编写
• YAML编写的测试场景可以重复使用
• 可以使用Go而不是JavaScript进行扩展
• HTTP和gRPC都可以使用
测试场景可以用YAML编写
当基于拉取请求管理测试场景时，Postman 要求处理导出的 json 测试定义。这些 json 文件结构复杂，对开发人员不友好，因为很难根据 Pull 请求在 GitHub 上检查差异。
相比之下，Scenarigo 测试场景的结构更加简单，使用 YAML，通常认为它比 json 更容易阅读。
测试场景可以重复使用
一个非常方便的功能是可以重用通用的测试场景和通用的测试流程。
例如，可以主动重用一般测试场景（例如创建用户和登录）和测试开始时经常使用的流程（例如授予剩余的 Merpay 余额），以创建高效的测试场景。
可以使用Go而不是JavaScript进行扩展
Scenarigo是Merpay开发工程师非常熟悉的工具，他们使用Golang进行实际开发。还可以创建 Golang 插件，并调用在YAML中创建的插件来进行测试场景。
例如，通常用Postman很难实现的测试场景（例如调用 API 后测试作业运行的结果）可以通过调用 Golang 编写的插件，用 Scenarigo 轻松实现。因此，我们能够增加可实施的测试场景的类型。
建立一个使开发工程师更容易维护测试的工具环境也有助于消除开发工程师和 QA 之间的界限。
HTTP和gRPC都可以使用
对于后端回归测试，我们一般会向每个微服务发送请求并验证响应结果。
Merpay架构的一个独特特征是，大多数微服务都是用Go实现并使用gRPC进行通信，因此能够同时使用HTTP和gRPC绝对是一个好处（因为HTTP请求需要通过API网关转换为gRPC）。
适用于特定微服务的内部工具
我们还有一个团队使用内部工具来实现特定微服务的自动化。
我们负责的微服务，有两个主要功能。第一种是，响应客户的固定费率支付申请，从指定信用信息机构Mercari或CIC获取信用信息，Merpay根据获取的信用信息进行固定费率支付审核。第二个功能是能够每月向 CIC 注册一次 Merpay 使用信息。
微服务中 QA 团队面临的挑战：
-
QA 方法很困难，这是一个封闭的后端服务，我们觉得很难，因为没有屏幕，需要使用工具进行QA。因此，返工往往会频繁发生，并且该功能只能由一个人进行 QA 认证。
-
规范复杂，这与QA方法结合起来，意味着需要时间才能赶上，并且很难简单地增加人员。
对于每个问题，我们至少希望简化 QA 方法，并努力自动化尽可能多的耗时步骤。
我们基本上使用由负责的微服务开发团队创建的内部QA工具。我们内部QA工具的初始版本仅能够初始化测试数据和执行作业。因此，所有输出结果均通过目视检查。例如，需要目视检查数据库数据、发送到 CIC 的文件、输出到 Google Cloud Storage 的文件、输出到替代 CIC 的存根服务器的文件等。
我们逐渐将小单位中耗时的步骤机械化。必要时，我会使用 shell 脚本或 Python 编写脚本，或者要求开发团队帮助我们改进内部 QA 工具。
-
目视检查数据库和创建的文件是最困难的部分，因此我请求修改内部 QA 工具，该工具允许我们编写断言处理，如本示例所示。就效果而言，消除了测试结果的目视确认，可以机械检查，从而大大提高了效率。
-
我们曾经使用浏览器查看并复制粘贴Docker镜像标签名称到ContainerRegistry中，但使用浏览器非常不方便。至于标签名称本身，可以使用gcloud命令获取列表并过滤它们，但为了获取特定名称的最新标签名称，必须解析gcloud命令的结果并提取标签名称。我们创建了一个Python脚本来检索标签名称，并且还可以使用shell脚本将标签名称复制到剪贴板。这样就可以通过一个命令检索特定的标签名称，而无需访问浏览器。
-
我们曾经使用浏览器直观地检查云存储中的文件，但这也相当繁琐。通过使用Cloud Storage的gsutil工具，可以操作Cloud Storage中的文件。因此，我们将这个过程自动化，使用Python执行gsutil命令，通过检查文件是否可以下载来检查文件是否存在。这使得可以使用单个命令检查文件，而无需使用浏览器访问它们。
-
创建一个简单 shell 脚本。因此，现在可以使用单个命令对每个函数执行回归测试。
说到自动化，可能大家还会关心可维护性。这可能是事后诸葛亮，但底线是几乎不需要维护，而且考虑到创建自动化系统的成本，它已经物超所值了。我想了一下原因，觉得是因为脚本是小单元写的，所以稍微改变一下流程不会有太大影响，也因为本来就很难改变流程从功能的角度来。而且，由于脚本单元很小，所以在跟上时很容易阅读和理解。即使脚本由于某种原因停止工作，我们基本上只是将之前手动执行的内容转换为脚本，因此如果我们部分切换到手动，QA 也不会停止。
“Cypress + TestRail”
“ Cypress ”是一个端到端测试框架，已成为前端端到端测试自动化的标准。
“ Cypress ”也用于前端开发过程中的测试，因此我们可以随时寻求帮助或审查我们的工作，非常方便。
我们对职责进行了划分，QA工程师负责发布前的回归测试，产品开发工程师负责单元测试和集成测试。
我们还使用“ TestRail ”来系统化测试用例管理，以继续改进工作流程。
自动化问题
老实说，我们在自动化方面遇到了很多问题。
-
可维护性
此问题涉及对已创建的测试用例的维护。准备一个允许其他人也可以执行维护的环境非常重要，是我们现在面临的主要问题之一。
-
个性化
我们的大多数测试都针对微服务，因此当测试出现问题时，可能很难找出问题到底发生在哪里。确定问题的原因可能需要时间。而且，即使我们找出原因，如果问题发生在另一个团队的工作中，并且您被迫在没有足够专业知识的情况下解决问题，那么解决问题可能需要时间。在这方面，我们必须努力减少这种情况的发生，让事情变得更容易理解，消除个别情况。我们还开始了解使用 Scenarigo 创建测试场景的问题。
-
门槛高
使用 Scenarigo 的一个好处是它是一个内部工具，因此我们可以预期它会得到改进。感谢我们工程师的“一体”合作，我们可以使用该工具做更多事情，并且比两年前更容易使用。然而，内部工具不可避免的缺点是组织外部的人不知道如何使用它。我们通过创建有关如何使用 Scenarigo 的手册并举办学习会议和讲座来弥补这一点。
-
可读性/可视化不足
我们正在解决的另一个问题是如何处理运行自动化测试的结果。我们在发布前使用结果做出决策，但我们还必须使用自动化测试来始终控制我们服务的健康状况。如果这些测试结果可以随时随地由任何人查看，那就太好了。我希望能够营造这样的环境。
未来的挑战
尽管我们已经引入了此类工具来自动化测试，但我们仍然存在基于手动测试编写自动化场景测试的情况。这就是为什么我要求我们的团队成员尝试在流程的早期阶段纳入自动化基础，以便我们可以在上游更高的流程中编写自动化场景。
从短期来看，对所有验证过程使用手动测试可能会让我们更快地发布产品和服务。然而，我希望团队中的每个人都能明白，自动化重复场景测试将使未来的测试更加高效，并有助于确保可靠的质量。我们想专注于构建一个允许自动化测试的环境。我们可能会继续在Merpay开发快速发布周期的产品，所以我认为我们每个人都有必要从中长期的角度来考虑我们的验证计划。
我们还想找到一种在整个产品中引入自动化的方法，而不必在后端、前端和本机应用程序之间分割自动化。QA团队的主要自动化测试仍然只用于后端。我们想研究一下前端和本机应用程序，以便我们可以研究适合整体而不仅仅是部分的自动化方法。
测试开发圈年度技术交流大会，MTSC2023｜深圳大会，你关心的技术话题都在这里！（点击查看）
MTSC 2023 第12届中国互联网测试开发大会（深圳站）即将于2023年11月25日，在『深圳登喜路国际大酒店】举办，大会将以“1个主会场+4个平行分会场”的形式呈现，聚集一众顶尖技术专家和行业领袖。他们将围绕如今备受关注的行业热点话题以及最前沿的实践经验，进行深入探讨和分享。
此外，大会前一天，11月24日，社区还组织了【AIGC主题 闭门研讨会】，面向对于Al软件测试应用、降本增效等技术管理等方向，组队针对特定议题进行讨论、提出解决方案，最后由讲师评审讨论投票选出优秀方案。感兴趣的同学，可以联系票务同学进行咨询报名。文章来源：https://www.toymoban.com/news/detail-741069.html
文章来源地址https://www.toymoban.com/news/detail-741069.html
到了这里，关于日本移动支付Merpay QA团队的自动化现状的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
