我一直在听说有关在端到端测试（例如Selenium测试）中测量代码覆盖率的想法，即使在技术上可行，我也确实看不出这样做的原因。
有一个测试金字塔的概念，它表示在单元级别上，您应该拥有最多的测试数量，在集成级别上，您应该拥有最多的测试数量，而在端到端（Selenium）上，您应该拥有较少的测试数量，因为它们是最难维护，最长执行，最不稳定（因为未隔离SUT）。因此，几乎没有什么变化，您将涵盖端到端测试中的所有代码。另外，在代码的较低层中可能存在某些区域，例如，到目前为止，尚未通过API公开这些区域（例如，因为该功能将在下一发行版中访问），并且只能使用单元测试进行测试。

我认为Selenium或端到端测试的想法是验证不同的业务场景，因此它更多地涉及功能/功能覆盖范围。

在端到端测试中测量代码覆盖率是否除了单元测试的代码覆盖率之外还具有其他价值？

#1 楼

我一直很喜欢功能测试的代码覆盖率，但不是因为我想达到一定比例的代码覆盖率。我喜欢它是因为：


它使我指出了代码中未涵盖的区域。
如果没有整个系统到位并进行端到端测试，那么代码的某些部分很难进行单元/集成测试，因此我想将单元/集成测试的覆盖范围与我的覆盖范围进行比较功能测试，并查看在端到端测试中是否应该或可能涵盖某些在早期阶段可能会更加困难的事情。
我想知道我的哪些测试是等效的，所以我可以看看每个测试涵盖哪些内容，看看是否可以消除或合并以提高效率的测试。


评论

有趣的答案，山姆。我猜想是相反的，也就是说，功能测试突出了通过代码的更现实的路径，并可能指出单元测试中的缺陷。如果目标是扩大线路覆盖范围，这是否会使拔出比其他线路更重要的线路更难？

– wheresmycookie
20年11月9日，16：10
也只是好奇-什么可能是一个难以用单元测试覆盖的示例，并且可能更适合用集成测试进行测试？

– wheresmycookie
20年11月9日在16:12

#2 楼

您真正想用功能测试衡量的是功能覆盖率：已经测试了程序的多少功能？不幸的是，这很难以自动化的方式进行衡量。最好的衡量方法是手工完成，将测试与需求关联起来，并计算未涵盖的内容。

代码覆盖率可以用作功能覆盖率的指标：如果没有涉及到很大的部分，则可以推断出代码旨在实现的功能，并检查为什么未进行测试。代码覆盖范围很容易实现，而且，如果您还要进行单元测试，则可能已经存在；它几乎不需要花费额外的成本来进行测量，因此仅作为后备设备仍然有用，这一事实仍然值得进行。

#3 楼

理想情况下，获得整个测试套件（单元，功能和端到端）的代码覆盖率指标非常好，但是我发现实际上很难获得这种度量。另外，我不确定该措施的具体用途-除了要确信该指标正在上升（而不是下降）。

在实践中，很难获得此数字，因为我们拥有系统中的各种技术（Java，JavaScript，HTML），通常意味着用于测量覆盖率的不同工具。

知道单元测试的代码覆盖范围非常有价值，因为我们可以看到测试和设计测试未涵盖哪些代码来执行该代码。对于端到端测试，您会怀疑未发现的代码在系统级别上是否可以访问（例如，没有故障注入），还是由于不良的测试而未被发现。

坦率地说，如果我们具有较高的单元测试覆盖率和良好的功能覆盖率，那么我会找到一个要解决的问题，而不是尝试获得混合的覆盖率指标。