答案。

历史上，随着项目自动化测试数量的增加，出现了许多问题：测试混淆，超出执行时间限制，难以理解各自的职责。此外，不同测试系统部分之间的依赖风险增加，以及整个管道工作减慢的风险。

当测试数量增长超过测试基础设施的架构支持时，问题出现了。没有可扩展的解决方案，测试变得缓慢，维护变得复杂，缺陷的查找和定位变得困难，技术债务迅速增加。

解决方案在于实施特殊策略：

• 按模块和级别（单元，集成，E2E）对测试进行集群，使用相应的标签和过滤器。
• 并行运行测试（分片，分布式测试套件）以加快执行速度。
• 在测试基础设施中使用微服务方法：标准DSL抽象，管理测试基础设施的单独服务。
• 自动化识别重复和过时的测试，定期重构和覆盖审计。

关键特点：

• 测试和测试库的模块化和可重用性。
• 完全自动化的CI/CD集成和资源自动扩展的能力。
• 实施监控自动化测试质量和代码覆盖率的工具。

带有陷阱的问题。

是否可以使所有测试仅为集成测试，以便立即覆盖更多代码？

不，这种方法降低了缺陷的定位能力，导致高昂的维护成本，同时减慢回归测试的执行。

自动化测试的可扩展性是否仅意味着加速？

可扩展性包括架构、可维护性、加速和灵活的基础设施。加速只是良好设计的大型系统的结果。

如何正确扩展在不同时区工作的团队的测试？

重要的是要考虑本地运行和测试环境独立的可能性，否则会在团队任务之间出现“冲突”。

常见错误和反模式

• 所有测试在一个目录中编写，没有按领域进行结构化。
• 直接重用测试数据（“复制粘贴”而不是库/夹具）。
• 缺乏关于执行时间和测试稳定性的监控/指标。

生活实例

负面案例

公司一下子出现了多个团队，它们将新的自动化测试添加到同一个文件夹中，而没有协商自己的更改。几周后，由于数据和依赖性的不一致，自动化测试开始失败，启动时间超过了2小时。

优点：

• 对初学者的低门槛。
• 自动化快速启动。

缺点：

• 缺乏可扩展性。
• 难以寻找和分析错误。
• 产品发布的延迟。

积极案例

在其中一个团队中，建立了模块化结构，按代码领域引入了单独的CI，提升了稳定性，实施了关于无效测试的自动警报。

优点：

• 便于维护。
• 快速反馈。所有缺陷快速定位。
• 可以在不降低测试质量的情况下扩展负载。

缺点：

• 需要预先进行架构分析和团队之间的协议。