用测试覆盖率度量代码质量真的靠谱？.docxVIP

用测试覆盖率度量代码质量真的靠谱？ 测试覆盖率和代码质量是少数两个用于分析、跟踪和度量 IT 项目有效性的度量标准。测试覆盖率和代码质量在某种程度上是相互关联的，很少有其他指标是这样的。例 如，我们度量代码质量的方法之一是通过查看相应的测试覆盖率。然而问题隐藏在使用测 试覆盖率指标来度量代码质量的有效性上。 所以在这篇文章中，我们将带着批判的眼光来看待这个实践。我们将通过回顾关于使用测试覆盖率度量代码质量的普遍接受的观点，以及您如何应用一个适合您的情况的解决方案来做到这一点。 房间里的大象——测试覆盖率 让我们首先解决这个问题——即测试覆盖率。“多少测试覆盖率是足够的 ?” 足够的测试覆盖率有助于提高您捕获所有关键 / 高优先级 bug 的机会。这不仅仅是一个您祖母讲的故事，实际上是一个非常可靠的标准来建立对您的 IT 系统的代码质量的信心。 然而，业内关于测试覆盖率的主要分歧似乎集中在“多少是足够的 ?” 理论各不相同——从 60% 到 80% 甚至 100% 。每个支持者都有一个合理的理由来解释为什么他们认为一定的测试覆盖率是足够的还是不够的。 似乎没有人讨论的一件事是：您根据什么来度量测试覆盖率 ? 不要误解我——每个人都有一个传统上被接受的度量测试覆盖率的基础——被测试软件中的代码行数。 这是正确的方法吗 ?这正是我们今天要回答的问题。 根据代码行度量测试覆盖率 这是怎么做到的呢？你只需要 这是怎么做到的呢？你只需要 : 你正在测试的软件的总代码行数，以及 所有测试用例当前执行的代码行数 找到 (B 除以 A) 乘以 100 ——这将是您的测试覆盖率 %。例如 , 如果系统组件中的代码行总数为 1000 ，并且所有现有测试用例中实际执行的行数为 650 ，那么您的测试覆盖率为 : (650 / 1000) * 100 = 65% 当以执行的代码行数来度量时，通常被接受的“足够的”测试覆盖率是什么 ?对于关键系统，共识徘徊在 80% 或者更高 (关键系统的定义可能因行业、地理位置、用户基础等而 异) 。 重要的问题是 :这个度量标准是否有效 ? 嗯，这是一个难题。我有哪些信誉好的足球投注网站了互联网论坛寻找答案，发现一般来说，人们认为 80% 就足够了。然后，还有一个问题是，您是否使用了好的测试，而不是那些对覆盖率没有真正 用处的测试。 好的测试是什么样的 ? 这并不难回答。一个好的测试应该跟踪需求的实现。正常路径和异常路径的用例都是很好的测试。 那么，您如何确保您是用好的测试来提高测试覆盖率呢 ? 在回答这个问题之前，让我们先看一个更重要的问题。 您真正应该根据什么来衡量代码质量呢 ? 测试覆盖率 - 当然。但是您如何真正度量测试覆盖率呢 ? 流行的答案 流行的答案 :由测试用例执行的代码行数。 正确答案 :嗯，这就是有趣的地方。通过执行的代码行数来度量测试覆盖率 虽然传统上开发人员、测试人员和项目经理都倾向于使用这种方法，但是我一直在质疑使用这种方法来度量覆盖率的有效性。 为什么 ?正如这个论坛帖子告诉你的，确保 100% 的代码行覆盖率并不能真正得到高质 量的产品。 那么是什么呢 ? 我之前说过， 良好的测试用例和足够的测试覆盖率 为了实现这两个目标，您需要以批判的眼光看待您的参考点。 提高测试库中良好测试用例的比例 一个好的测试用例跟踪一个需求 (包括正常和异常路径 )到实现。为了确保您主要拥有良好的测试用例，您所要做的就是建立需求的可跟踪性。 我的团队通过清晰地规划测试场景来覆盖发布、项目、迭代、 sprint 范围内的所有需求，从而实现项目中的可跟踪性。通过建立需求的可追溯性，我知道——在任何给定的时 间点——需求的测试覆盖率。 在敏捷项目中，假定您只关注下一个即时版本的需求，如果您使用基本的跟踪矩阵， 那么通过需求实现 100% 的测试覆盖率应该是相当简单的。 如果您只测试需求，那么您的测试库中应该只有良好的测试用例。现在进入下一个挑战——足够的测试覆盖率。 好吧，我开始这一部分的时候并没有告诉你正确的答案是由测试用例执行的代码行 好吧，我开始这一部分的时候并没有告诉你正确的答案是由测试用例执行的代码行 数。 “如果你确保测试用例 100% 覆盖了你的需求，那么你就拥有了所有你需要的测试用例。” 我为什么要那么做 ? 因为我不相信这是衡量代码质量的正确方法。如果你还在想“为什么 ?”在你的嘴唇上，所以我要试着回答这个问题。 如何用测试覆盖率来度量代码质量 ? 需求可跟踪性为您提供了一种可靠的方法来构建良好的测试用例。让我们扩展一下， 思考一下为什么会这样。 如果您只编写可以追溯到需求的测试用例，那么您就有效地消除了任何冗余的、不必要的测试用例。这样可以提高团队休息的效率。 现在，如果你把它转过来，你会得到这样的