如果没有组织的智能测试功能， 随着系统复杂性的增加， 新开发的成本可能非常高。构建、部署、更新、创新等将会变得麻烦，因为现有的代码库需要更多的努力来验证。保持系统的可靠性和稳定性将获得对开发和创新的所有权。

现在需要做的是提高发展与创新的比例。那么只需将验证和验证系统完整性的人工工作转移到机器时间即可。人力资源部门有更多的时间来验证和提高目前正在开发的内容的质量和稳定性。

有人会说测试不适用于 IT 架构。但事实是，软件的设计和治理方式最终会成为测试完成和自动化方式的蓝图。

在实施和改进自动化测试架构的后期，通常存在技术缺陷。通过这些方式，我将上下文表述并定位为“自动测试化架构”。它包含一个测试策略框架，作为架构的一部分，即技术策略。

1.测试级别

以前的模型将业务和 IT 定义为联合连接。我们确保技术以预期的方式实现业务 - 以及该业务的IT计数提供基本的构建区域 - 计划- 以满足期望。

此模型显示了测试覆盖率如何从业务需求开始。但表示产品如何重新连接到最终产品中商定的质量和批准方面的测试级别。本文的其余部分将介绍这三个中的更多内容。

自动化测试以及新的开发旨在减少确保系统稳定性和完整性所需的时间、精力和频率，同时由于开发和外部压力因素而发生变化和修改。

2.有意义的测试方法

计算每个测试级别的测试次数，应形成如下金字塔结构。定义和维护测试通常越复杂，金字塔中的位置越高。从权衡创新的角度来看，意义更重大。

最好确保级别之间的测试不重叠。最佳情况下，由于级别的层次结构，测试覆盖范围得到扩展和完成。原因是我们不想引入浪费和不必要的维护。因此，这种“经典”的金字塔可视化并不完全正确。

如果金字塔在上层区域正下方有白色间隙，那就更真实了。像左边这样的图表可能更具描述性。

当测试失败时，这一原则为从哪里开始分析的结论提供了更高的准确性。如下图所示，将其视为可以根据失败/成功而更改的颜色。

即，如果 API 和 UI 出现故障，则问题可能出在 API 中。如果 API 已修复，但 UI 仍然失败，请继续在 UI 或单元/代码测试中进行调查。

“如果它在生产或单元测试中失败，但在 UI 或 API 测试中没有失败，我们是否需要考虑扩展测试范围？”— 是的，很可能。每个生产校正都可能候选在有意义的级别添加测试。

3.测试覆盖率

自动化测试覆盖率在三个测试自动化管道中解决。把一个完整的产品想象成一个寓言。

代码级方法，单元测试，验证构成产品的每件作品的完整性、功能和预期结果。这些通常应该非常小，并且只验证它们构建的目的。

API 级别方法提高了视野，其目的是确保依赖外部资源按预期工作。即管道、道路、应急、电力、信件等都可以连接到产品提供服务。它可能被称为集成测试，但 API 级别用于验证其他操作组件或服务的有效性和可操作性。即通过充当系统并进行简单的数据请求和响应查询，以验证连接性 - 数据和响应时间。验证系统代码内部的实际响应，是单元测试，而不是API。

最后，UI 级别的方法是按照用户的行为行事。当一个人真正把车停在以上产品的车库里时。这需要系统的某些部分像现实一样工作。此方法可以快速添加复杂的依赖项和条件以工作。此级别的测试将主要以业务为重点进行选择和定义。希望与企业一起，这有助于设定目标和期望。作为回报，测试报告将定期创建和交付。即每个月。这些测试的设置可能很复杂，并且涉及许多步骤和集成。但它们的维护不能复杂或片状。不允许测试数据因环境中的预期条件更改而失败。

通常对于所有级别 — 对于每个环境，测试不必完全相同（但应该完全相同，以避免手动异常和配置的额外工作）。自动化可以而且应该在常见的支持的CI / CD工具（如TeamCity或Azure / Amazon DevOps）中自动化。

4.报告、描述和样式

UI测试必须是每个正在运行的测试环境单独的套件和配置。在（行为驱动开发）编写测试场景时使用 BDD 编写的样式，通过使用“给定x当y然后z”。例;

Story: A user that access the application As a user In order to do my daily intended work I want to be able to use the application Scenario: Availability of Application Given that I have visited the webpage-url And stated my login credentials When i was requested those in the start page Then I should be able to start work directly

理想情况下，报告与级别测试一起在 DevOps 管道中自动构建。即通过测试工具就可以完成。报告可以作为链接、电子邮件或附件自动发送给相关利益相关者，即业务用户或产品所有者。

API 测试验证并验证与预期的数据交换。即验证响应模式或响应中的某些元素。给定的BDD，当样式完全可以，但在这里定义可能是不必要的开销。API 测试应该是多变的。下表是 API 级别测试中的实时报告示例。

实时报告的示例显示，acc & dit 中部署的代码可能具有相同的问题。即无响应的 API

列描述;集合 - 在脚本中执行的预期/测试的集合。命名约定推断每个测试环境、每个系统透视和每个依赖终结点都有一个测试集合。基础 - 服务的基本可访问性及其响应时间。验证 - 获取并验证所需的每个 API 方法的架构。如有必要，请验证响应中的相关值。例外-引发错误方案，并根据预期验证错误响应。

建议以 BDD 样式编写单元测试，但可以通过任何有意义且对实际测试情况有意义的方式进行。格式和命名的限制较少，因为它们通常不会向 IT 开发团队以外的任何人公开。在正常情况下，报告应该完全保留在开发团队和 CI/CD 工具中。

5.自动化测试

严格来说，测试架构并不控制自动化和 CI/CD 的建立方式。广泛接受的工具或平台有助于跟踪部署、提交、历史记录和可访问的配置。但是，任何能够执行自动化并使开发团队能够将手动测试工作集中在新开发上的方法或技术都可能成功。