利用大数据和人工智能彻底改变移动测试

移动应用程序是按需提供的公司品牌。它是了解组织提供的任何服务或产品的窗口。在 Kobiton，他们明白这一点 — 他们的使命是通过测试改进移动应用程序。Kobiton 是一个移动测试平台，允许客户在世界任何地方对真实移动设备执行手动和自动测试。它最初是一项云服务，但最近利用 MinIO 提供具有 AI 功能的本地解决方案。

云端真实设备测试

从 CI/CD 管道中在真实的移动设备上进行测试似乎是不可能的，但事实并非如此。这就是使用 Kobiton 的工作原理。管道在合并代码时启动。第一步是创建用于移动测试的 build。这是 Android Package Kit （APK）文件或 iOS App Store Package （IPA）文件。这些文件包含应用程序在设备上安装所需的所有元素，并且它们是需要创建以提交到应用程序商店的相同文件。构建版本通过 API 调用上传到云中 Kobiton 的应用程序存储库。（Kobiton 与 Jenkins、CircleCI 和 Bitrise 集成，这使得这很容易。上传后，下一步是启动之前在 Kobiton 中设置的自动化测试套件。有多种自动化框架可用于设置这些测试。Appium 是最受欢迎的，因为它同时支持 Android 和 iOS。但是，客户也可以使用原生 iOS 框架 XCUITest 和原生 Android 框架 Espresso。执行测试后，客户可以通过调用 Kobiton 的 API 来检查结果，然后确定是否在其 CI-CD 管道中继续进行。当您考虑到移动应用程序必须在多个操作系统和各种设备上运行时，事情就会变得有趣。例如，一个应用程序必须支持 Android 操作系统的最后 5 个版本和 iOS 的最后 5 个版本。每个版本都需要一台设备，在本例中为 10。但是，当您需要测试不同的设备版本时，这个数字会像滚雪球一样越滚越大，而当您想要测试各种操作系统和设备组合时，这个数字会增加更多。归根结底，这需要管理大量设备，并且每个测试都需要在每个设备上运行 - 因此也有很多测试需要管理。好消息是，Kobiton 云中的测试可以访问一机架上准备好进行测试的真实移动设备，并且 Kobiton 管理测试。

本地解决方案的市场

当 Kobiton 开始时，他们在 Amazon Web Services （AWS）中设计了他们的产品。但是，他们很快意识到本地部署有市场，因此他们着手创建 Kobiton 的本地版本。上一节中提到的设备耗尽存储在 AWS S3 中。因此，他们的代码利用了大量 S3 接口。他们还发现，当您还要负责从裸踏板开始的所有事情时，设计性能要困难得多。在云中，硬件被抽象出来，因此更容易获得所需的性能。为了解决存储问题，他们寻求具有 S3 接口且高性能、可扩展、可扩展和容错的产品。这就是他们来到 MinIO 的原因。当他们开始深入研究 MinIO 时，突出的主要因素是容错和性能。它的容错能力超出了他们从 RAID 解决方案中获得的能力。他们还发现，他们可以扩展或扩展存储容量，而不会对性能产生不利影响。

使用 AI 进行移动测试

当 Kobiton 测试移动应用程序时，会生成大量数据，因为 Kobiton 的作用不仅仅是保存测试结果。相反，它们会保存与测试运行时每个设备内发生的所有情况相关的指标。设备耗尽是 Kobiton 所说的设备在测试期间发出的所有数据。这包括：

使用 XML 格式的详细信息测试步骤
屏幕截图
以每秒 30 帧的速度拍摄完整视频
设备日志
系统指标
网络负载
设备运行状况统计信息

Kobiton 的差异化因素之一是他们能够在运行测试时有效地提取这些废气。只要有数据，就有机会使用 AI 提供更深入的见解。然后，Kobiton 使用所有这些设备耗尽（存储在 MinIO 中用于其本地产品）来创建能够修复失败脚本的模型。当测试脚本因开发人员更改了应用程序中的某些内容而失败时，脚本不会失败，而是在先前测试的设备上耗尽训练的模型可以自动更正并找出允许脚本继续的最佳匹配元素。他们还使用深度学习模型来帮助识别应用程序用户界面的问题。例如，许多与 UI 相关的测试使用基线屏幕截图来表示特定屏幕的正确外观。运行 UI 测试时，它将截取屏幕截图并将其与基线进行比较。通常，当 UI 没有问题时，这两个屏幕截图会略有不同。如果您想防止烦人的假阴性，可以帮助您明智地了解差异的模型非常重要。