如果您要构建一个旗舰应用程序，该应用程序由一些现代的未开发子系统（如微服务、云、事件驱动）和遗留的单体应用程序组成，所有这些都在一个生态系统中，那么构建自动化（或手动）的方法有哪些？端到端测试过程，以确保您可以测试和验证任何一个部分中的代码何时更改/发布？
目标也是不减慢任何单个部分的开发/发布（没有瀑布或高度手动协调的软件发布）。每个团队和应用程序或子系统仍然需要独立运行。 TIA
【问题讨论】：
标签： testing automated-tests integration-testing qa
从使命宣言开始。我订阅以下内容： QA 是风险降低和缓解而不是风险消除
的实践我喜欢它，因为这是我可以对企业做出的切实可行的承诺。所有开发变更都会带来风险。不进行更改也需要自己承担风险。 QA 的目标是使“破产风险”尽可能接近于零，同时让我们能够快速创新和交付代码。
你是怎么做到的？ 首先确定哪些业务功能是绝对关键的。在这里尽可能窄。通常这是“如果出现问题，您可能会遇到麻烦”的东西。可能导致人员伤亡、造成财务损失、导致法律/监管影响、安全问题或对您的公司造成声誉或财务损失的事情。同样，与分阶段推出/分区相关的测试通常也属于这一类，以确保这些流程按预期运行，因为您将在许多情况下（在适当的情况下）使用这些工具来代替详尽的 QA。
您的 QA 策略应侧重于将上述领域的风险降低到尽可能低的水平。
一旦你能胜任地做到这一点，将剩余的功能分为两类：
通过分阶段推出和分区更好地测试/缓解的东西，并且只做基本的理智（非详尽测试）。努力做到这一点，而不是详尽地测试那些可以搞砸一小部分用户的功能。
不那么关键的功能，不能分阶段发布，不超过“不能搞砸”的门槛，但仍需要测试。在这些情况下，您需要练习降低风险。充分测试事物，但不一定要详尽无遗。这就是优秀的 QA Leads / 测试人员赚取收入的地方。如果这不是“我们绝对不能搞砸”的领域之一，那么决定在哪里划定平衡“风险缓解”和“详尽测试”的界限的就是脚踏实地。当做出错误的决定时，进行回顾并考虑如何更改流程/指南以随着时间的推移提高决策的质量
对于您进行测试/自动化的工作，实施平衡的测试金字塔 (https://martinfowler.com/tags/test%20categories.html)。通常广泛的堆栈测试、狭义的集成测试、组件测试和单元测试就足够了。注意某些类型的 UI 测试自动化（想想 Selenium）。原则上问题不在于这种测试方法，而是人们把它们走得太远了。这通常是一项巨大的投资，从长远来看是脆弱的，而且价值很低，因为人们试图在这个不属于他们的级别上塞进一堆测试（导致倒置的测试金字塔）。 TBC 我不考虑像 JEST 这样测试视觉元素如何呈现的东西，因为它们快速、可靠和有用，我认为这些更多的是在单元/组件测试的类别中
尽可能多的自动化测试应该在构建服务器上在线进行。这样就没有人需要“记住运行测试”或“考虑回归爆炸半径”。这对于上面定义的“超级关键”的东西尤其紧迫。这个测试作为每个 PR 的一部分运行，如果你的组织也在那里使用发布分支。这可以确保您不断测试重要的东西，但不会因为尝试详尽地测试所有内容而减慢流程，因为您最好投资于弄清楚如何让用户为您进行测试（以受控的分阶段方式） ) 在适当的地方。
【讨论】：