代码覆盖率与测试覆盖率选哪一个?

代码覆盖率与测试覆盖率选哪一个?

重要的是“其中哪一项最适合项目”?这个问题没有确切的答案，因为解决方案取决于项目的类型和复杂性。在大多数情况下，使用测试覆盖率和代码覆盖率，因为它们在软件项目中同等重要。

测试覆盖范围的优势

一种测试软件功能并比较不同规范文档(需求，功能，产品，UI/UX等)结果的好方法。

由于作为覆盖范围一部分执行的测试实际上是黑盒，因此执行这些测试可能不需要太多的专业知识。

测试覆盖范围的缺点

由于测试主要是黑盒测试，因此没有自动化范围。测试结果必须与预期的输出进行手动比较，因为这些测试是在功能级别而非代码级别执行的。

没有测量测试覆盖率的具体方法。因此，覆盖范围的结果在很大程度上取决于正在执行测试的测试人员的领域能力，并且可能因一个测试人员而异。

代码覆盖范围的优势

· 提供测试代码的有效性以及如何提高覆盖率。

· 无论使用哪种工具(开源，高级)，设置代码覆盖率工具都不会花费太多时间。

· 通过捕获代码中的错误来帮助提高代码质量。

代码覆盖范围的缺点

大多数代码覆盖率工具仅限于单元测试。因此，工具使用的方法可能会有所不同;可能无法将一种工具的代码覆盖率结果与另一种工具进行比较。

搜索最适合的工具可能是一项艰巨的任务，因为需要先从这些工具中比较并尝试功能，然后再选择最适合项目需求的工具。

提供很少支持不同编程语言(例如Java，Python，C#等)的工具。因此，如果团队使用多种编程语言(用于测试代码开发)，则需要多个工具。

测试团队应花费大量时间来了解总体要求并确定测试活动的优先级。为了跟踪进度，他们应该有一个清单，该清单应定期更新(至少在每次发行之后)。测试团队还必须与质量保证(QA)团队保持频繁的沟通，这是很重要的，因为他们具有要发布给客户/客户的产品/项目必须达到的目标(测试/代码)覆盖范围的详细信息。没有专门的经验法则提到测试产品时需要达到的最小代码覆盖率或测试覆盖率百分比。

不要为了覆盖而覆盖

追求覆盖率只是手段而不是目的。测试同学的终极目的还是要在首先的资源情况下最大显得保障产品质量。不能因为KPI就盲目追求手段的极致，反而本末倒置，最终陷入泥潭不能自拔。