我叫Maria Snopok，是X5零售集团大数据产品开发和支持部门测试部门自动化方向的经理。在本文中，我将分享我们在实现自动测试和降低相关成本方面的经验。希望这些信息对正在努力过渡到自动化测试的团队有所帮助。
我们如何进行自动测试
在自动化问世之前，我曾在其中一种产品中担任测试经理。当在那里形成一个相当大的测试模型时，我们开始将回归测试池分发给整个开发团队-如果她负责发布，那么她也在进行测试。这样的团队回归解决了以下任务：
- 以前处理过单独功能的开发人员可以查看整个产品；
- 因此，我们使回归速度更快，并且发布频率更高；
- 我们不再减少追索权-质量有所提高。
但这很昂贵，因为测试是由昂贵的专家-开发人员和分析师执行的，我们开始转向自动化。
冒烟测试是第一个进行的测试-简单的检查以确保页面打开，加载，不会崩溃，并且所有基本功能都可用（到目前为止尚未检查逻辑和值）。
然后，我们自动执行积极的端到端脚本。此步骤带来了最大的好处：即使在负面，替代和次要情况下存在错误，测试也可以确保产品的主要业务流程正常运行。
最后，我们实现了高级回归检查和替代方案的自动化。
在每个阶段，我们都面临许多困难，这些困难严重减慢了速度并使整个过程变得复杂。哪些实际的解决方案帮助我们加快了自动化器的工作并为之提供了便利？
降低自动测试成本的四种方法
1.同意岸上测试属性的格式
开发人员和自动化测试人员需要事先就命名HTML元素的规则达成一致，以供以后在自动测试中用作定位符。对于所有产品，希望具有相同的格式。我们已经开发了一些要求，即使在功能转移到开发之前，也要了解如何命名属性。这种理解既存在于开发人员方面，也存在于测试人员方面。我们同意为每个可见的html元素分配一个自定义的data-qa属性，测试人员将通过该属性进行搜索。该属性是根据以下模式命名的：
[屏幕名称] [表单/表/窗口小部件名称] [项目名称]
示例：
data-qa =“ plu-list_filter-popover_search-input”
data-qa =“ common_toolbar_prev-state”
仅从文档和布局中分离出这样的属性很容易，并且每个人都知道其含义。当开发人员执行任务时，他会根据这些规则为所有可见的页面元素（标题，按钮，链接，选择器，表的行和列等）分配data-qa属性。结果，测试人员可以在开发功能期间基于以下条件开始编写自动测试：仅用于布局和文档，因为它已经知道如何命名属性。
测试属性的引入使我们通过减少更新测试和本地化自动测试元素的成本，与上一时期相比，平均将开发和支持自动测试的成本降低了23％。
2.我们编写手动测试，以使其易于自动化
手动测试人员和自动化工程师生活在不同的领域。手册的目的是用一个脚本检查附近几个不同的测试对象。另一方面，自动化程序倾向于在单个测试中构造所有内容并仅检查相同类型的对象。因此，手动测试并不总是很容易实现自动化。当我们收到用于自动化的手动案例时，我们遇到了许多问题，这些问题使我们无法逐字逐句地自动化接收到的脚本，因为它们是为便于活人执行而编写的。
如果自动化人员深深地沉浸在产品中，那么他就不需要“手动”情况，他可以为自动化编写脚本。如果他“从外部”来使用产品（在我们的部门中，除了测试人员，团队还提供测试作为专用服务），并且已经有手动测试人员准备的测试模型和脚本，您可能会被诱使他指导在这些“手动”测试用例的基础。
不要屈服于此：自动化器可以使用手动测试用例的最大目的只是从用户的角度了解系统的工作方式。
因此，有必要首先准备手动测试，以便可以将它们自动化，以应对常见问题。
问题1： 简化手动案例。
解决方案：详细说明案例。
让我们想象一下一个手动案例的描述：
- 打开修订版本列表页面
- 点击创建按钮
- 填表格
- 点击“创建”按钮
- 确保创建修订版本
对于自动化而言，这是一个糟糕的情况，因为它没有指定确切需要打开的内容，要填充的数据，我们希望看到的确切内容以及要查看的字段。 “确保成功创建版本”说明不足以实现自动化-机器需要特定的标准，据此可以使操作成功。
问题2：案例分支。
解决方案：案例只应具有线性方案。
带有“或”的结构通常出现在手持设备中。例如：“在用户1或2下打开修订版184”。这对于自动化是不可接受的，必须明确指出用户。应避免使用连词“或”。
问题3：大小写无关。
解决方案：在将案例提交给自动化之前检查案例。
对于我们来说，这是最大的痛苦：如果功能频繁更改，那么测试人员将没有时间更新测试用例。但是，如果手动测试人员遇到了无关紧要的案例，那么他就可以迅速更正脚本。自动化人员，特别是如果他没有沉浸在产品中的话，将无法做到这一点：他根本不会理解为什么外壳无法正常工作，并将其视为测试错误。将花费大量时间进行开发，之后事实证明，经过测试的功能已被切断很长时间，并且脚本是无关紧要的。因此，应检查所有自动化脚本的相关性。
问题4：前提条件不足。
决定：完整的辅助数据堆栈，用于执行案例。
手动测试人员会变得模糊，因此，在描述前提条件时，他们会错过一些对他们来说显而易见的细微差别，但对那些对产品不太熟悉的自动化员则不明显。例如，他们写道：“打开具有计算内容的页面”。他们知道要计算此内容，您需要运行一个计算脚本，并且第一次看到该项目的自动化程序将决定有必要采用已经计算的内容。
结论：在前提条件下，有必要写一份详尽的操作开始清单，然后再开始测试。
问题5：在一种情况下进行多次检查。
决定：每个方案最多检查三张（昂贵且难以重现的方案除外）。
手动测试人员通常希望节省案例的成本，尤其是在沉重的情况下，并在一种情况下进行尽可能多的测试，从而将大量测试塞入其中。不允许这样做，因为在手动和自动测试中，此方法都会产生相同的问题：第一次测试失败，而在自动化情况下，所有其他测试均未通过或根本未启动。因此，在自动测试脚本中，允许进行1到3个检查。异常是非常困难的场景，需要耗时的预计算，并且很难重现。尽管您最好不要破坏规则，但在这里您可以破坏规则。
问题6：重复检查。
解决方案：无需一遍又一遍地自动化相同的功能。
如果我们在多个页面上具有相同的功能（例如标准过滤器），则在回归测试期间无处检查它是没有意义的，将其放在一个地方就足够了（当然，除非我们在谈论一种新功能）。手动测试人员编写脚本并在每个页面上测试这种事情，仅仅是因为他们孤立地查看每个页面，而无需深入研究它的内部工作原理。但是，自动化人员应该理解，重复测试同一件东西会浪费时间和资源，并且使他们很容易检测到这种情况。
上述问题的解决使我们将开发自动测试的成本降低了16％。
3.与产品团队同步进行重构，重新设计，功能上的重大更改的问题，以免“在桌面上”编写测试
在我们开发了13种产品的大数据部门中，有两组自动化器：
- 直接在产品团队中的自动化人员；
- 产品团队外部的自动化流服务，从事框架和通用组件的开发，并通过现成的功能测试来处理产品的请求。
Stream自动化程序最初并没有那么深入到产品中，并且在他们没有参加每日团队会议之前，因为这会花费太多时间。一旦这种方法使我们失望：我们意外地从第三方来源获悉，一个团队将要重构他们的产品（将整体分解为微服务），这就是为什么我们编写的一些测试被发送到存档的原因。这是非常痛苦的。
为了防止将来发生这种情况，我们决定至少每周一次从工作流中选派一名自动化人员参加开发团队的会议，以了解产品的最新动态。
我们还同意，仅针对准备就绪且不会频繁更改（回归）的功能进行自动化测试。我们必须确保至少在接下来的三个月中，不会发生重构或重大返工，否则自动化器根本就没有时间进行测试。
实施这些措施所节省的成本更难以计算。我们花时间开发自动测试作为基础，由于计划将部分功能迁移到微服务，因此失去了它们的价值。如果我们提前知道此转换，我们将不会通过自动测试涵盖可变功能。总损失（也称为潜在节省）为7％。
4.将手动测试仪升级为自动化工程师
劳动力市场上很少有测试自动化器，特别是好的自动化器，我们正在积极寻找它们。我们还积极升级对自动化有需求和基本了解的现有手动测试人员。首先，我们以编程语言派遣此类人员，因为我们需要成熟的自动化器和成熟的自动测试，而且从记录器的角度来看，弊大于利。
在学习编程语言的同时，一个人从第2点开始学习编写正确，结构化的脚本而没有问题，阅读并分析自动测试报告的结果，纠正定位器中的小错误，简单的方法，然后维护现成的测试，然后自己编写。所有开发都是在流服务的经验丰富的同事的支持下进行的。将来，他们可以参与框架的定稿：我们拥有自己的库，可以对所有项目进行扩展，可以通过添加我们自己的库进行改进。
降低成本的方向尚处于起步阶段，因此，计算节省额还为时过早，但是有充分理由相信人员培训将有助于显着降低运营成本。同时，它将为我们的手动测试人员提供发展的机会。
结果
现在，我们已经对五种产品进行了约30％的测试自动化，这使回归测试时间缩短了2倍。
这是一个很好的结果，因为时间对我们非常重要：我们不能无限地测试，也不能未经检查就把产品赠与；另一方面，自动化使我们能够在最佳时间提供所需数量的产品检查。将来，我们计划将自动测试的百分比提高到80-90％，以便尽可能多地发布发行版，但与此同时，不要覆盖自动测试仍能带来更高利润的自动测试项目。