automation - 哪些类型的架构或架构层不适合自动化测试？

Question

我最近的任务是为我公司的一个遗留应用程序开发自动化构建和发布管道。经过一些调查，我不断听到经理和其他开发人员说某些应用程序层和架构不适合自动化，尤其是自动化测试。因此，通常建议我不应该尝试应用 DevOps 原则和 AT，除非我想重新构建整个应用程序。

常见的引用示例是 PL/SQL 后端或单体架构。我问为什么这些不合适，但从未得到真正明确的答案。有没有人知道什么时候不应该使用自动化测试来支持抛弃旧架构并重新开始？

Answer 1

简短的回答 - 那些遭受可测试性问题的人。

为了更深入地了解，让我们首先承认许多软件系统是不可测试的，或者不能立即测试。所以，努力

尝试应用 DevOps 原则和 AT

远远大于投资回报率。这样臭名昭著的例子是谷歌的 ReCAPTCHA，它给自动化测试人员（比如我）带来了一些痛苦。开发人员实际上说得对

重新构建整个应用程序

旅程，因为可测试性与其他关键软件质量高度相关，例如封装、耦合、内聚和冗余。

常见的引用示例是 PL/SQL 后端或单体架构

现在，完全不是这样的。第一个更以数据为中心，需要更深入的理解，但也有解决方案。至于单层软件应用程序——可以说，与 mSOA 相比，单片应用程序更容易调试和测试。由于单体应用程序是一个不可分割的单元，因此您可以更快/更轻松地运行端到端测试。

简而言之 - 如果您的应用程序是高度可测试的，那么它是高度可用的。以防万一，架构和设计符合非常非常具体的公司需求——难怪只能在一定程度上使用。