API +集成测试是否是CI中测试的最佳选择？您对此有什么看法和经验？
这篇关于Techbeacon的文章讨论了CI中的GUI测试问题。
eShopOnContainers中的功能测试是API测试（专门针对微服务，但是还是很好的参考资料，对吧？）。
#1 楼
正如您在TechBeacon文章中已经提到的，团队确实经常在测试自动化金字塔的顶部花费过多。通常，金字塔是一个很好的经验法则，但（一如既往）它取决于项目。许多系统都经过精心设计，因此GUI只是用户和基础API之间的粘合剂，这就是为什么此类系统通常根本不需要基于GUI的E2E测试的原因。本质上，您无法决定是否需要基于GUI的E2E测试-如果您需要它们，则需要它们。问题是，如今您可以轻松扩展这些测试。例如，“使用AWS Lambda进行大规模UI测试”展示了如何利用功能即服务（FaaS）并行运行每个测试。这样，您的整个GUI测试可能会在一分钟内运行。
因此，我想说您可以在CI管道中进行基于GUI的快速E2E测试，但这并不总是可行的。分析给定的项目，计算风险，确定权衡，决定。
评论
+1为测试金字塔。但是，如果您可以在一分钟内运行它们，那么您的系统（和您的测试）还不够复杂。我们的测试最多需要五分钟才能使用UI准备所有测试数据（并且这些数据是时间敏感的，因此它们无法重用，并且足够复杂，因此不能仅将其注入DB）
–Peter M.-代表莫妮卡（Monica）
18年4月4日在17:06
@PeterMasiar感谢您的输入。正如所说的，这是一个很好的例子，“仅仅做到”并不总是可行的。
–beatngu13
18年4月4日在18:28
#2 楼
考虑测试金字塔。使用帕累托原理（也称为80/20规则），您只需花费20％的精力专注于单元测试，就可以从测试中获得80％的收益。如果您专注于API /服务测试，那么剩下的80％就会受益。 API /服务测试中有16％（其余20％的80％）。您的整体测试：足够小，可以维护和敏捷，而足够大，可以使管理人员和客户确信系统可以按预期运行。评论
+1好答案彼得
–迈克尔·杜兰特（Michael Durrant）
18年4月4日在21:11
#3 楼
请使用彼得·马西亚（Peter Masiar）提到的测试金字塔。 。我的解决方法是确保UI测试集中于UI本身的功能。换句话说，从用户的角度来看，文本和链接可以正确显示，尤其是HTML表单和输入字段可以按预期工作。
避免大量UI情况的方法是：避免使用我所说的“数据组合测试”。我的意思是说，给出“ x”后，我应该看到“ y”的任何测试。 “ x”可以是用户输入的数据，从数据存储中检索的数据，来自外部服务的数据等。应在后端进行测试。
示例可能会有所帮助：
企业在50个州经营。每个州都有针对当地文化的不同欢迎信息。商家可能会问：“请问我们可以进行50项测试，以确保所有消息正确无误吗？”。可以编写50个浏览器UI测试，每个状态用于验证信息。但是，执行此操作的正确方法是识别出不是文本的“浏览器”。后端上写着“当我通过文本“怀俄明州”时（例如），我将返回文本“黄石之家”，等等。”因此，我们应该编写后端单元/集成测试，以测试每个状态传递给确定消息的例程的结果将进行正确的测试，然后我们在浏览器中测试一种状态以确保查找正常。
假设浏览器测试每个可能需要30秒（包括一些导航以获取相关页面），这意味着50 x 30将是1500秒或30分钟的测试运行时间。单元测试可能会在1秒（或更短的时间内）内运行，因此（30 * 1）+ 30（对于1个浏览器测试）= 1分钟的测试时间-与30个浏览器测试相比，时间的1/30。 />
对于“ API +集成测试是CI中测试的最佳选择”的问题，我不这么认为。 CI对于单元/ api测试和UI测试都是不错的选择。在这两种情况下，您都具有以下优点：
在始终良好的其他计算机上运行
并行化和弹性云
在已知配置下运行测试/>能够创建自动devops管道的能力
事实上，UI测试非常缓慢，并且受益于CI的并行化优势，而这些正是我经常希望在CI中运行的那些。同样，由于单元测试和开发测试旨在向开发人员即时反馈，因此确保至少在最初在本地运行以最简单的方式尽可能“接近”更为合适。没有CI，本地代码。 UI测试通常是在后期或UAT测试中，此时代码与时间已经分开，因此可以减少在本地运行它们的需要。
评论
您的示例中的集成测试是什么？@AlexeyR。例如，调用不同的API和查询数据库。
重新链接标题为“ GUI测试自动化是否是连续交付失败的秘诀？”的文章。 -贝特里奇（Betteridge）的标题定律-“任何以问号结尾的标题都可以用“否”字回答。但是作者有一点，正如我在回答中解释的那样
在很好且非常有效的问题之间，以及很好的linkedin文章。
我认为，没有黑白答案，这完全取决于项目的细节。