将自动测试从UI引入较低的（API / Unit）层的测试策略？

#1 楼

对我而言，一项关键策略是说服企业需要在何处进行测试，否则...他们最终将通过UI指导对所有内容进行测试...因此，我对我的业务提出的两个主要要点是需要在两个关键因素方面表现良好的测试自动化：


速度
可靠性

软件测试自动化的速度和可靠性均得到成功很难，大多数技术公司都为此而苦苦挣扎。

速度：
软件测试自动化的总体目标是为从开发团队到各个级别的各个级别的业务提供更快的反馈
对于软件测试自动化本身，使用UI创建测试数据或设置应用程序状态非常缓慢，在某些情况下甚至是不可能的，因此将无法提供及时的反馈。
就测试而言，这通常是10x +（通常是100x +）的因数速度并极大地影响开发和测试自动化的能力。如果自动化需要20分钟而不是7秒才能到达工作流中的特定位置，这将使质量自动化开发变得不切实际。还可以考虑然后尝试在20个不同的设备浏览器中运行同一测试，这意味着该7秒测试需要20x7 = 2+小时。想象一下，想尝试10种不同的更改以使其正确（常见）。
可靠性：
我们不控制或选择客户的设备，浏览器，版本或其他客户端特性（例如不同的javascript和渲染引擎）。现在，客户设备每天都会在后台更新，通信是异步的，网络连接可能会有所不同。这极大地限制了进行可靠的自动UI测试的能力，并且尽管尽了最大的努力，最终还是使我们无法获得100％的可靠性。这不是任何一家公司创建的问题，也不是一家公司可以解决的问题-通过我们可以允许并对其负责。主要含义之一是尽可能少地进行UI测试，而支持在几秒钟而不是几小时和几天内运行的单元和集成测试（测试金字塔与冰淇淋蛋筒）。我们应该仔细选择一些自动化UI测试，以确保它们避免在前端重复和测试数据组合。

内部，对于测试自动化开发，必须基于以下方面进行观察和构建测试：测试金字塔
和敏捷的测试象限



，以确保在整个开发过程中获得快速反馈的好处。 />
要解决两个关键的技术问题：


不使用UI设置测试条件和状态

控制测试和应用程序状态通过API

传统上，对测试自动化的需求还不足以作为关键的业务成功因素，足以证明为解决这两个关键技术问题而实际花费大量的应用程序开发工作，时间和金钱是合理的（它们当然可以解决付出足够的努力和决心）。现在，这种情况已经改变，并且测试自动化越来越被认为是至关重要的业务成功因素，它是当今业务的众多其他努力和计划的基础。

对于划分单元，集成测试和UI测试的详细策略，您会想到一些想法吗？


创建一些功能示例，例如60个单元，12个集成和4个UI测试以显示实际运行的测试金字塔
确保单元测试的模拟和存根依赖性
确保应用程序和自动化工程师共享彼此工作的代码审查
不断为功能测试暴露应用程序环境的稳定性在应用程序/自动化团队空间区域中
在应用程序和自动化开发区域中不断地暴露测试状态信息
确保应用程序开发人员编写单元测试，并使用代码覆盖率和质量度量工具作为其连续性的必要部分集成代码开发过程。
请确保应用程序开发人员和UI自动化开发人员在物理上彼此靠近，以方便进行直接聊天。
请考虑创建正式的分类系统（例如，在积压参考期间）实例）确定要在何处进行测试（就单元测试，int测试和uat测试而言），至少可以直觉地进行。

#2 楼

估计工作量，从UI测试中迁移多少个测试用例？
估计每个sprint中可以节省多少时间，并与团队负责人和其他成员讨论有关您想节省的时间在每个sprint中花一些时间来进行测试用例迁移。
优先考虑自动化UI测试，有可能不再需要其中的一部分。首先迁移优先级最高的测试。
根据您在第2步中进行的讨论，在每次sprint期间将工作量分配给自己。
即使替换了旧的UI测试，也要使其继续运行，并逐步淘汰它们。您可能不是唯一运行它们的人，从而使每个利益相关者保持最新状态。
记录下您的方法，因为有成千上万的UI测试，不太可能有人来帮助您，或者您在完成之前就离开了；好的文档将帮助其他人继续进行测试用例迁移。

#3 楼

如果我会像您一样实现目标，我会：


在您的前端和后端之间引入一些代理，以将请求记录到后端
对UI运行所有测试
解析代理日志，以便我将所有终结点调用按终结点地址分组（以及可能的参数-取决于我们可以承受的迁移成本）
按照上述分类，我将花费更少的时间来实施API测试。也许我什至会介绍该转换器，该转换器将根据上一步获得的分组自动构建测试。

#4 楼

添加到@Michael Durrant的很好的答案。

如果您想快速获胜，我想出了一个将硒测试转换为API测试的想法。这仅适用于您具有与UI逻辑无关的“ UI”测试且仅用于测试后端逻辑的情况。

其想法是在运行操作系统时捕获网络流量在HAR文件中进行硒测试，然后将该HAR文件隐藏到可重播的API测试中-该测试涉及识别请求-响应相关性并添加断言。