😕 👩🏽‍🎤 👩🏻‍💻 自动测试是否考虑到电子错误 🎛️ 🍡 🚶🏾

最近，测试自动化被称为项目的所有问题的“银弹”。许多人非常自然而轻松地开始自动化，而没有计算所有的利弊，利弊，维护和回报。

通常，测试自动化是非常昂贵且特定的工具。因此，必须以适当的代码成熟度和项目本身来进行处理。否则，您可能要花费数百万小时和金钱，而效果却微乎其微。

在本文中，我尝试了：

阐明测试管理的“孩子们的痛处”，力求使没有固定的一切自动化，
在不详细分析其范围和适当准备的情况下，说明测试自动化如何使项目预算受益，
编制路线图，为项目自动化做准备。

资源

趋势是现在测试自动化会堵塞所有项目的漏洞，实际上是用显微镜钉钉子。关键是没有自动化技能的测试人员很难找到工作，因为在大多数职位空缺中，缺少测试分析和测试设计技能，但是需要自动化某些方面的经验。

我想相信，随着时间的流逝，我们所有人都会渴望一次全部完成所有任务，但是现在，清单将有助于我们确定项目中是否需要自动测试以及项目是否已准备就绪。

实际上，出于这些想法，我去做一个关于“ Strike-2019”的演讲，然后在此基础上写这篇文章。

我们将讨论大型的，严格的端到端自动测试，这些测试可以根据UI和Web服务自动进行回归。以及与他们有什么联系。我们不会涉及开发人员编写或应该编写的单元测试的主题。这是独立的自我测试层，并且已经撰写了许多文章：

我不会命名该项目，我只会说这是一个为数千万用户设计的信息系统。它与几个州门户网站以及数十个（如果不是数百个）区域和商业门户网站集成在一起。因此，对可靠性，容错性和安全性的需求增加。好吧，总的来说，这样一切都会“旋转并且不会掉落”。

我们对所有LANIT测试项目的信条是不断改进。总的来说，所有使我们能够更快，更好，更高，更强地进行测试的方法，可以节省测试人员的时间和精力，并因此节省预算。我们已经在这个项目上实施了可能使我们能够按时完成任务的所有最佳实践。结果，在大型未实现的芯片中，仅保留了回归自动化。这个话题本身已经出现了很长一段时间，很长一段时间我们都拒绝了这个话题，因为利润不是很明显。但最终他们决定实现自动化。然后进入冷水的时间延长了。

一个小题外话。自动化方法

有两种主要的方法可以自动执行UI测试。

资源

手动测试仪自动化

您不必走得太远，举例说明-一切都在Habré上。我不会给公司命名。对该主题感兴趣的人可能会看到这些一个半小时的网络研讨会，它们有多酷，有多酷，整个手持测试人员团队如何从他们那里学习Java，实现自动化，涵盖所有内容，一切都很棒，一切正常，光明的未来已经到来。有这种方法。

设计方法

还有第二种方法：招聘一支自动测试人员的团队-拥有经验，具有OOP的知识和技能，并由该团队的力量直接执行自动化，而一组手动测试人员则充当客户和专家。是的，他们可以在经过培训，选拔后进入自动化团队，但是他们永远不会同时兼任两个角色。

在下文中，我描述了这些方法的功能，但是我没有将它们具体标记为“加”或“减”，每个人都将自己确定标志。

自动化功能“自行”

资料来源

1）当我们在手动测试仪的帮助下实现自动化时，我们很快就会收到“效果，这个测试花了一天的时间，现在我可以用机器人替换它，花了2天的时间，但是我不在这里参加”。当然，这可以提高资格并拓宽专家的视野：他们开始了解守则。但是，这笔业务没有明确的实际结果。在开发上花了多少时间？如果有经验的人这样做会花多少时间？可以节省几个小时？测试用例多久启动一次？哪里？谁陪？它要多少钱？这对我来说不是很好，因为不幸的是，我还没有看到愿意为此过程无休止地付款的客户。因此，清晰，切实的结果对我始终很重要。

2）没有截止日期。一方面，这很好：没有人鼓励团队，“让一切快速自动化，让我们快速学习”，一个人的压力不会增加。他继续用手进行测试，并从容地投入自动化。另一方面，没有截止日期，我们不能询问结果，我们也不知道什么时候准备好。

3）没有代码支持和连续性。一方面，通过不同的方法，调查产生了更好的书写方法，有时，从头开始重写，可以多次提高自动测试的速度。但这是超级轨道。另外，如果专家离开项目，谁会陪伴所有这一切，而如果他们离开另一个业务领域或另一个团队，会发生这种情况吗？也不太清楚。

项目方式的特点

来源

1）在这种情况下，我们已经在谈论该项目。这个项目是什么？这些是资源，时间，金钱。因此，此处是在考虑到该项目中所有细微差别的情况下计算预算的。计算所有风险，计算所有其他工作。并且只有在预算达成一致后，才决定启动。

2）基于此，准备阶段可能不会很快，因为应该为某事建立预算计算。

3）当然，对参加该项目的专家提出了更高的要求。

4）在这里，我还将写下复杂的基础架构解决方案，但稍后会详细介绍。

5）现有测试和发布流程的现代化。因为自动测试是团队的新元素。如果以前没有提供，则需要将其集成到流程中。自动测试仪不应挂在项目的右侧，左侧。

6）项目方法具有规律性，一致性，但另一方面，其实施可能比第一种方法的实施慢。

7）好，报告。很多报告。因为对于任何预算，您都会被询问。因此，您应该了解自动测试的工作方式（坏，好），什么趋势，什么趋势，需要增加什么，应该改善什么。这由报告控制。

通往美好未来的漫长道路

免责声明：我们很聪明（实际上不是）。

来源

这是我们遇到的问题的分类。我将分别分析每个人。我会故意这样做，以便您考虑到此“耙”。因为这些问题（在项目开始时未解决）将至少在最大程度上直接影响其工期-它们将增加预算，甚至可能关闭项目。

资源

不同的团队-不同的方法。
自动化在功能中的沉浸式功能。
测试用例的非最佳结构。
框架文档。
沟通问题。
及时购买许可证。

自动化的不同方法

资源

折磨次数

我们进行的第一次尝试是根据第一个模型进行的（请参见方法1）。一小群（但引以为傲）的测试人员决定尝试自动化。总的来说，我们想看看一切。现在，我们当然不会这样做，但是那时没有经验，我们决定尝试一下。

资料来源

我们拥有一支具有自动化经验的团队负责人，其中三人渴望使测试仪实现自动化，并且渴望掌握这条道路。的确，蒂姆利德（Timlid）是一个新来者，不能花很多时间在该项目上，但是他的工作的积极影响是我们编写了自己的框架。我们查看了那些昂贵，凉爽或免费的框架，并在“组装后，修改文件以使其符合口味”中附加了说明。通常，由于多种原因，我们无法使用它们。因此，我们决定编写自己的框架。选择本身和写作过程是另一篇文章的主题，甚至不是一篇。

并不是说这种尝试是失败的，它只是活了下来就结束了。当我们意识到我们需要预算，我们需要更多的力量，我们需要技能，我们需要另一个团队组织时。我们自动处理了约100个案例，并认为它可以解决，并且四舍五入。

尝试第二

来源

没有什么比被咬的三明治更吸引人了。

一段时间后，我们再次回到自动化的主题。

但是，记住第一个实验，我们切换到方法2。在这里，我们已经有一个相当“熟练”的团队，可以自动化多个项目。但是这里我们面临着另一场灾难。该团队遵循UI测试团队的领导。这怎么发生的？

“我们要使它自动化！”
-也许我们会考虑的。
-不，我们什么都不想，我们想要这些自动测试。

经过巨大的努力，他们实现了自动化，甚至奏效。但是随着时间的流逝，发射的稳定性开始下降，当我们组建自己的自动化工程师团队并开始将项目移交给他们时，事实证明，一半的测试是在拐杖上进行的，一半的检查了机器的意图，而不是手动测试器的意图。

所有这些都是因为自动测试是基于原始代码运行的，因此每天都会进行更正。那些。最初的一组案例不正确。从自动化（以下简称黄油）的角度来看，我们不得不投入我们要自动化的主题。处理我们为自动化而放弃的案例，并在某些时候丢弃其中的某些案例，将其中的某些案例分开，以此类推，这一点至关重要。但是我们没有。

结果是什么。我们又自动化了大约300个案例，之后该项目结束了，因为发射过程也没有稳定性，也不了解如何进行发射。我们知道第二次不这样做。

尝试三号

来源

对于第三次尝试，我们像害羞的母鹿一样走近水坑。

周围看到了风险（以及术语分解）。首先，他们以批判性的态度来测试案例及其作者（UI测试人员）作为流程客户。我们找到了同一批具有批判性思维的自动化工程师团队，并开始了一个经过正常计算（如我们所认为的），充分准备（哈哈）的项目。

耙子已经在撒谎，在等我们。

自动化功能沉浸在功能中

来源

在第一阶段（以下称为第三次尝试），当仍然无法建立通信时，自动测试器将在特定的屏幕后进行工作：他们接收任务，并在那里进行自动化。我们进行了自动测试。我们看到的统计数据显示，一切都对我们不利。挖掘自动测试日志。而且，例如，由于要上传的文件名存在拼写错误。显然，用双手测试了此功能的测试人员将启动未成年人并跳至进一步检查。自动测试会落下并敲打整个链，这取决于它的基础。

然后，当我们开始将自动测试器浸入功能中，解释我们在情况下要检查的内容时，他们便开始理解这些“孩子的”错误，如何避免它们以及如何解决它们。是的，有错别字，有一些不一致之处，但是自动测试不会失败，它只是记录它们。

非最佳测试用例结构

来源

这可能是我们最大的头痛。她给了我们最多的问题，最多的时间成本，最多的时间和金钱。结果，如果我们使其他东西自动化，那么我们首先将解决这个问题。

我们的项目相当大，数十个信息系统在其中旋转，它们由工作组联合在一起。似乎每个人编写案例的标准都是相同的，但是在一个组中，这一部分称为“功能”，在另一组中，称为“权威”，而自动测试仪会同时读取“功能”和“权威”，并陷入混乱。这只是一个例子。实际上，有数百种这样的情况。我必须将所有这些标准化，梳理头发。

除了这些歧义，您还遇到了什么？我们没有找到原子测试用例。这些是测试用例，在某些步骤中可以可变地执行。例如，在这种情况下，它说“您可以在这样的权限下并在这样的权限下执行步骤2”，而在步骤3中，例如，根据所使用的权限，“按下按钮“ A”或按钮“ C”。从手动测试仪的角度来看，一切都很好。测试员了解如何通过它，自动测试员不了解如何通过它。在不好的版本中，他本人会选择路径，在好的版本中，他会澄清。我们花费了大量时间转换非原子测试用例。

框架文件

来源

您始终需要考虑那些追随您的人。他们将如何解析您的代码，进行分析等。如果有能干的工程师，程序员，这是很好的。如果不是，那就不好。然后，您还可以面对这样一个事实，您需要分解过去的“胜利”的遗产，重新记录下来，吸引更多的人，花费更多的时间。

沟通问题

来源

1.缺乏交互方面的法规：

一个自动化团队来了，他们不知道如何与手动功能测试团队进行交流，事实上，没有人知道他们是什么样的人。是的，有些线索可以相互交流，其余的只是项目的邻居。

2.交互规则的存在

然后编写了规则，但是伙计们互相工作了一段时间，当编写规则时，他们将其视为唯一的交互工具。超出范围的所有内容都将被忽略。

也就是说，最初，这些家伙根本不知道如何进行通信，他们似乎在同一个聊天室中，但是他们是否可以提出问题，他们也不知道。当他们已经在这样的条件下工作了一段时间后，他们建立了自己的非正式，封闭的社区：我们是“护手”，我们是自动化者。如何沟通？在这里，我们有法规-根据法规。

及时购买专用软件许可证

在某些时候，事实证明，对于某些情况的开发，我们仍然需要付费软件，但是没有许可证。我不得不以消防令的形式购买它（同样，金钱和停机时间所产生的额外费用）。

路线图

Istonik

因此，现在我们有了路线图，如何启动这样的项目，它实际上由阶段组成，每个阶段都分为某些点。

初步阶段

资源

我们需要团队领导

蒂姆利德（Timlid），通常是一名建筑师，他将一路与我们同在，是一位了解自动化的人，他在技术上精通，胜任。建议这是一名在我们项目中使用的某些编程语言上有5年经验的开发人员。因为一种或另一种方式，我们的框架将与我们的项目一起使用。因此，最好是框架和项目都使用相同的技术堆栈。

必须有一个焦点小组

而且，这不应该是自动化的焦点小组。这些人应该是将来会做出决定的人。最好在开始时就让他们成为朋友，这样才能了解他们做出的决定，原因和原因。

评估测试用例库的状态

我已经在上面分别谈到了对测试用例库状态的评估，这也是在非常初步的阶段进行的。

我们找出不需要自动化的东西

通常，人们希望将所有移动的东西（以及所有不移动的东西，移动和自动化的东西）自动化，实际上，大约40％的测试用例通常非常昂贵，以至于实施起来在原则上讲它们永远都不会付清回报。因此，在这里您需要非常清楚自己想要的是什么：自动化一切并飞入管道，或者您想要自动化某项功能测试以帮助您。

评估试点项目

我们在初期阶段评估试点项目（将花费多少），并在最困难的（注）案例中执行它。

飞行员

资源

测试用例的规范化

收集到的案例库需要进行规范化。消除了歧义和不必要的前提条件。

框架准备

我们编写框架，添加现有框架或使用某种购买的框架。

基础设施

我们正在准备基础架构解决方案。

在这里重要的是不要丢失：您将不可抗拒地希望在第一阶段使用桌子下的某种家用计算机来运行自动测试。这不是必需的（当有人不小心将计算机摔倒或将咖啡洒在计算机上时，测试速度会变慢并下降）。有必要使用现成的基础架构解决方案，虚拟机，观察应用程序的实践。因此，立即为该项目和下一个大型项目计算其功率。为此，我们需要一名自动化专家。

小计和调整

我们正在写第一个案例。我们评估所有幸福的速度。我们正在评估人员的额外需求，因为我们已经知道这些案例将实现多少自动化。也就是说，我们自动化了五件，现在我们需要了解有多少人才能有条件地自动化另外五千人。一些其他许可证，用于机架的硬件，用于将运行自动测试的机架以及用于应用程序本身的机架。好吧，事实上，需要最终确定测试用例-一切有多糟糕。

总结飞行员

我们进行总结，编写报告并决定是否要进行自动化。

之前我已经写过，如果我们不去可能会发生。也就是说，例如，如果投资回收期为18年，而您的项目期限为5，则应考虑为什么需要它。

发射阶段

源

项目按顺序列出，但实际上，它们应同时进行。

我们开始选择团队。
我们确定线索。
让我们优先考虑案例研究。
我们规范测试用例。
我们解决“基础设施难题”。
我们编写法规和说明，建立联系，消除瓶颈。
我们改进了同时执行多个自动测试和并行运行测试组的框架。
我们制作一个报告和统计模块（一次性和累计）。
我们开始编写自动测试。

主舞台

来源

在主要阶段，一切都很简单（哈哈）：编写自动测试，提供书面支持，评估启动结果，制定管理决策，加紧权限，添加流以及实际上与UI团队进行沟通和再次沟通。每个人都应在同一条船上航行，并向一个方向划船。

护航阶段

来源

押运阶段与主要阶段略有不同。持续时间存在显着差异。此外，它所开发的新自动测试的比例要小得多。根据我们的估计，每个发行版占6-10％，否则与主要阶段非常相似。

结果是什么？

我们自动化了大约1,500个端到端案例。成功发布的稳定性使多个版本保持在92-95％左右。

追索成本降低了近2.5倍。运行本身要在3-4个小时内进行，这是在晚上进行的，因此早上可以得到现成的结果。

我的同事在一系列文章中概述了技术实施的细节：

如果我们现在开始，考虑到我所写的一切，我认为我们将大大节省我们的神经，时间和预算。

谢谢您的关注。提出问题，我们将进行讨论。

资源

我们也正在等待年轻的测试人员团队！

, , .

自动测试是否考虑到电子错误