迟早每个人都会来AT。这种情况发生得较晚的情况是可以理解的，那么什么时候早呢？以及如何理解已经存在的可能性？本文基于一个团队的经验：我将向您介绍引入自动测试的先决条件和原因，为AT就绪选择的标准以及最终使用的工具。剧透：最后，使用Xamarin.UITest取得了一些成功而不是非常成功的案例。产品介绍. , , , , , . offline.
-.
理论怎么说
考虑以测试金字塔为例的自动化方法。作为金字塔的等级，我将介绍我们使用的测试类型。即，单元测试，集成测试和端到端（E2E）测试。
单元测试（单元测试）验证系统各个小部分（功能，方法）的运行。它们体积小，通过迅速，不需要大量的开发和维护成本。集成测试使用外部组件测试应用程序的操作。例如，具有数据库或各种服务。他们花费更多的时间来编写和支持测试以及运行。对于此类测试，大多数情况下，您需要配置和支持某种环境。在这种情况下，它们通常变得更脆弱，因为 环境容易破裂。端到端测试可以验证整个系统的运行情况，模拟最终用户的操作。他们最经常通过用户界面访问系统：他们以用户的身份按下按钮，填写字段等。但是它们也可以在没有接口的系统中使用。这些测试比上面考虑的测试昂贵得多，因为需要更多时间来开发和支持测试本身以及整个环境。此外，它们非常脆弱，因为它们会受到系统任何部分的更改的影响，并且模拟器或浏览器的异常行为可能会影响特定测试的结果。这种测试的运行时间也比其他测试要长得多：要执行任何单独的用户操作，您需要进行许多其他操作。例如，登录或转到所需的菜单项。根据金字塔原理，测试越容易，越快和越便宜，则它们应占测试总数的百分比越高。那些。通过测试不应检查将不同的值分配给一个字段（除非在这种情况下需要检查UI的操作）。为所有这些类型的测试分配了一个角色。在应用程序生命周期的某个时刻，需要一种或另一种测试自动化。您的产品仅需单元测试即可轻松完成，并且可以迅速发展为端到端测试的需求。计划自动化的主要目的是了解您的产品当前将确切受益以及您可能会浪费时间。实现自动化时，不要忘记手动测试，即使自动化程度很高，总会有一些需要手动检查的事情。至少，新功能不适合立即编写测试。但是，我认为所有自动化都应主要旨在减少手动测试的数量。在计划手动测试时，值得考虑哪些案例已经自动化。如何与我们组织自动测试？
每个产品单独都有在每个PR上运行的单元测试。它们是开发人员的责任。
集成测试验证了Web服务与EDMS的交互作用。它们模拟客户端应用程序的操作。他们转向用于获取和修改EDS数据的Web服务方法。在每次构建新版本的服务器端之后运行。
端到端测试可模拟最终用户的性能。他们按下移动应用程序界面中的按钮，然后该应用程序通过Web服务与EDMS一起使用。测试人员现在正在完成集成和端到端测试。为什么我们需要端到端AT移动应用程序？
在开始自动化之前，值得考虑一下您想通过引入解决什么问题。除非您有特定的目标，否则您将无法向主管或产品负责人解释为什么要花时间进行自动测试。很难评估其实施的好处。我们长期以来一直手动测试移动应用程序。尽管这是一个功能很少的应用程序，但我们成功地应对了。开发的所有内容都集中在一个区域中，并且可以以一种快速而轻松地测试应用程序所有功能的方式来组织手动测试。但是一段时间后，该应用程序开始具有新功能，这些功能非常独立，需要更多关注。旧功能中的错误存在问题，我们只能在项目的最后阶段才能找到这些错误。因此，为我们介绍移动应用程序的UI测试的最初目标是：- AT覆盖主要应用案例；
- 在发布之前减少回归中的错误数量。
实现第一个目标应该自动导致第二个目标的实现，因为 在整个项目中对基本功能的常规测试应在早期阶段发现错误。一段时间后，又增加了另一个目标-减少手动回归测试的次数。何时该将自动化引入测试？
在开始测试自动化之前，您应该评估应用程序的自动化准备情况。您也准备为此过程做好准备。功能稳定
为了使AT有机会使用，该应用程序必须具有稳定的功能。她值得进行自动测试。否则，由于应用程序更改，您将花费大量时间和精力来更新和更新测试。发展计划
仅当您的应用程序具有未来几年的未来发展计划时，才应实施自动化。为什么要为不变的应用程序进行自动测试？资源资源
您必须具有开发测试的资源，最重要的是，它们还需要进一步的支持。那些。在计划实施自动化时，重要的是要理解，编写测试不仅需要资源。由于某些原因，测试肯定会失败。运行结果将需要进行分析并采取措施。包含 在测试中进行更改。好吧，除了支持，别忘了他们的发展需求。如何决定？
考虑移动应用程序的UI测试时，我们立即想出了带有设备或出租设备的农场的大架子。由于需要检查不同的尺寸和屏幕分辨率，因此测试中存在很多问题。是的，并且没有太多的开发经验。一切令人恐惧，被迫搁置计划。较早制定的目标得以拯救，主要目标是功能测试。因此，我们从小做起。结果，我们的测试：- 每天运行一次（如果发生问题，这足以查找问题的根源）；
- 在我们的服务器上本地运行；
- 在两个设备（iOS和Android）上；
- 对于Android，现在大约有50个测试，运行大约需要一个小时（与程序集一起）；
- 对于iOS-大约40次测试，运行大约需要30分钟；
- 测试是使用Xamarin.UITest编写的；
- 它们由TFS中的版本自动启动，我们在TFS中的同一位置监视运行结果。
关于Xamarin.UITest的一些知识
这是一个针对Xamarin.iOS和Xamarin.Android上的项目进行自动UI测试的框架（还宣布了对Objective-C / Swift和Java的支持）。使用NUnit以C＃编写测试。内容项目可以轻松集成。框架的操作原理基于两个部分：搜索元素（查询）和对其执行任何操作（动作），例如，按下或执行滑动。例如，这里是一个测试，用于在输入无效的登录名时检查错误显示：public void ShowErrIncorrectLoginOrPassword_IfLoginIsWrong()
{
var wrongLogin = TestsSettings.UserLogin + "1";
app.EnterLoginAndPassword(wrongLogin, TestsSettings.UserPassword);
app.WaitForElement(Resources.Identifiers.ErrorMessage, "Login is incorrect, alert message wasn't shown.", TestsSettings.Delay);
Assert.AreEqual(CoreResources.ErrIncorrectLoginOrPassword, ErrorMessage);
}
private string ErrorMessage =>
app.Query(x => x.Marked(Resources.Identifiers.ErrorMessage)).First().Text;
其中使用的凭证输入法：public static void EnterLoginAndPassword(this AndroidApp app, string login, string password)
{
app.WaitForElement(Resources.Identifiers.LoginEdit, TestsSettings.Delay);
app.EnterText(Resources.Identifiers.LoginEdit, login);
app.EnterText(Resources.Identifiers.PasswordEdit, password);
app.Tap(Resources.Identifiers.LoginButton);
}
在此示例中，使用了标准框架方法-等待元素，输入文本，单击元素。在开发和调试测试时，使用内置的控制台实用程序REPL（read-eval-print-loop）很方便，它允许您查看屏幕上现在位于的元素树并执行标准框架方法。对我们来说是意外的
解决接口元素有时并不能达到我们的预期。例如，当在同一活动中使用片段打开应用程序中的新窗口时，用户在屏幕上只能看到该新窗口。但是在这种情况下，可见元素树中会存在用户现在看不到的那些元素。搜索此类“不可见”元素将成功，您可以使用该元素执行操作。只需单击即可在用户看到的窗口中执行。那些。实际上，这将是一个误报。该树可能包含几个相同的元素；默认情况下，将使用树的第一个合适元素来执行该操作。并且，如果在测试中您通过标签访问了一个元素，然后某个元素的某个地方具有相同的标签，则该测试将开始下降（或者如果您需要的元素是第一个，则可能不会）。我们有一个案例，即在首次战斗发射时书面和调试测试就落下了帷幕。因为测试是在具有不同屏幕尺寸的设备上运行的。在此设备上单击的元素出现在另一个界面元素下面。
发件箱文件夹位于“创建任务”按钮下，在这种情况下单击该文件夹会导致单击该按钮。对于用户来说这是一种熟悉的情况，他只需滚动屏幕即可。但是在元素树中，此叠加层不可见。这样的问题会给您带来不便，使您在进行某些测试时更加谨慎。有时，我们只是将数据放入数据库中，以免影响测试。毕竟，此示例中的目标是打开一个文件夹，而不是检查是否阻止打开该文件夹。另一个惊喜和失望是无法从Visual Studio for Windows运行和调试iOS测试。此功能尚未实现。我必须在MacOS的工作室工作。一些队长结果
如果可行，实施自动化。让您的测试使用最少的配置，让它们手动运行，并且每月仅运行一次，但是如果它们可以解决您的问题并为您提供帮助-为什么不呢？好吧，不要忘记金字塔的原理。