大家好，我是阿萨。昨天了解了敏捷测试的测试方法。那么如何知道敏捷测试做得好与不好呢？有哪些度量指标呢？今天就来看看度量指标
与过去的瀑布式软件开发、需求文件和外包的QA部门开始，测试已经有了长足的进步，测试指标也是如此。根据许多专家的意见，QA团队过去所依赖的许多旧指标，如测试用例的数量，已经不再适用了。那么，在敏捷开发环境中，哪些指标是相关的，有助于改善测试？
在这篇文章中，我们将描述从瀑布到敏捷测试指标的转变，重要的敏捷开发指标和它们与测试的关系，以及敏捷团队用来量化测试和衡量软件质量的新指标。
敏捷之前的测试指标
在旧的软件开发瀑布模型中，QA是一个独立于开发的活动，由一个单独的团队执行。瀑布模型采取非迭代的开发方法，每个阶段都需要在下一个阶段开始之前完成。在这种模式中，一个独立的质量保证团队定义了测试用例，确定软件是否满足最初的要求。
缺陷类型
仅仅知道是否发现了缺陷是不够的，重要的是对缺陷进行分类，以获得关于缺陷的定性信息。你可以将软件缺陷分成若干类别，包括：
功能性错误
通信错误
安全错误
性能缺陷
你可以将缺陷归类，并使用帕累托图对数据进行可视化表示。
使用帕累托图和帕累托原则，你可以确定20%的缺陷类别会导致80%的软件问题。
通过强调缺陷最多的类别，团队就能更好地了解他们需要努力改进的地方。
缺陷修复周期
缺陷修复周期衡量的是，从开始修复一个缺陷到完全解决这个缺陷需要多少时间。敏捷控制图直观地表示不同敏捷任务的周期时间。
在一个快节奏的敏捷团队中，快速解决缺陷有利于加快发布时间。
通过测量缺陷周期时间与定义的阈值，你可以准确衡量敏捷团队解决问题的速度，以及他们是否在越来越多的冲刺或迭代中显示出预期的进展。
缺陷逃逸率
缺陷溢出衡量的是在一个特定的冲刺或迭代中没有得到解决的缺陷数量。你也可以衡量从一个冲刺溢出的缺陷是否在下一个冲刺中得到解决。
敏捷团队的主要目标是在每个迭代完成后生产出可以使用的软件。测量溢出量可以最大限度地减少团队因技术债务的积累而在未来陷入困境的可能性。
衡量每个冲刺阶段的缺陷溢出率有助于敏捷团队清楚地了解他们处理问题的效率。
请注意，敏捷团队的大多数测试指标可以用多种方式来衡量，如
每个Epic
每次发布
每个迭代
每个特性
每个用户故事
缺少的测试指标--软件质量
在我们所涉及的所有Scrum指标中，一直缺少一个东西--软件质量。一些指标，如逃逸的缺陷、缺陷类别和缺陷周期时间，对质量有一些启发。但它们并没有一针见血地告诉你你的版本到底有多好。
当你发布的时候，在所有的测试和错误修复的努力之后，你真的有信心新的版本会在生产中运行良好吗？你能确定你已经识别并覆盖了所有重要的质量风险吗？很少有敏捷团队能这样说。
在瀑布模型中，QA仪表盘关注的是整个软件应用，并测量四个关键维度。
产品质量。
测量缺陷的数量和缺陷率来衡量软件质量。
测试有效性。
检查代码覆盖率以了解测试的有效性。此外，QA还关注基于需求的测试和功能测试。
测试状态。
测试运行的数量，通过的数量，或被阻止的数量将检查测试的状态。
测试资源。
测试软件所需的时间和该测试的成本。
现代的敏捷开发环境依赖于跨职能团队的协作努力。因此，在旧的独立瀑布模型中具有如此重要意义的指标在今天已经不那么重要了--测试现在是整个开发过程中的一个组成部分。
随着QA团队成为跨职能的Agile努力的一部分，新的指标出现了，反映了这种综合环境。新的目标和期望导致了新的衡量标准，可以从一个统一的角度帮助整个团队。
敏捷测试指标有两种类型。
1. 与软件测试相关的一般敏捷指标。
2. 适用于敏捷开发环境的特定测试指标。
为什么软件质量在敏捷度量中缺失？
下面我们详细介绍了所有常见的敏捷度量标准。但有一个指标你不会在那里找到，因为大多数敏捷团队没有这个指标。这就是软件质量。
有了所有的测试指标，团队就不能衡量他们发布的质量？
好吧，有一些部分指标，如逃逸的缺陷、缺陷修复周期时间和自动测试覆盖率。但它们都不能说明问题--你的团队是在发布一个高质量的产品，还是一个有缺陷和不稳定的产品。
应用于测试的一般敏捷指标：
冲刺进度表
敏捷团队使用Sprint Burndown图表来描述团队完成任务的速度，以及在规定的冲刺期间还有多少工作。
典型的下线图是用Y轴上的剩余工作时间和X轴上的冲刺日期来绘制完成任务的理想工作时间。敏捷团队然后绘制出冲刺阶段的实际剩余时间。
例如，在下图中，团队未能按时完成冲刺，剩下100小时的工作没有完成。
测试通常构成了敏捷团队使用的已完成退出标准的定义的一部分。
完成的定义可能包括一个条件，如 "以100%的单元测试代码覆盖率测试"。
因为敏捷团队完成的每一个 "故事 "都必须经过测试，完成的故事反映了客户要求的关键功能的测试进展。
工作测试功能/运行测试功能的数量
运行中的测试功能（RTF）指标告诉你有多少软件功能已经完全开发完成，并通过了所有的验收测试，从而成为集成产品的实施。
左边项目的RTF指标显示，随着冲刺的进行，有更多的功能被完全开发，使得RTF健康增长。右边的项目似乎有问题，这可能是由于缺陷、测试失败和需求变化等因素造成的。
由于RTF指标衡量的是经过全面测试的功能，所以指标中包含的所有功能都通过了所有的测试。
更多的功能交付给客户意味着软件的更多部分已经过测试。
速度
速度采用一种数学方法来衡量一个团队在每个冲刺阶段平均完成多少工作，将实际完成的任务与团队的估计努力进行比较。
敏捷经理通过比较以前冲刺阶段承诺和完成的平均故事点或小时数，使用速度指标来预测团队实现某个目标的速度。
一个团队的速度越快，该团队生产软件功能的速度就越快。因此，更高的速度意味着软件测试的快速发展。
速度的注意事项是，技术债务可以歪曲速度指标。团队可能会在软件中留下空白，包括测试自动化中的空白，并可能选择更容易、更快速的解决方案来解决可能是部分或不正确的问题。
累积流程图
累积流程图（CFD）显示了一个项目的摘要信息，包括正在进行的工作、已完成的任务、测试、速度和当前的积压。
测试是敏捷工作流程的一部分，它被包含在大多数累积流程图中。
通过使用CFD，你可以衡量软件测试的进展。
CFD可以用来分析测试是否是一个瓶颈，或者CFD中的其他因素是否是瓶颈，这可能会影响测试。
如果你的CFD中的垂直区域随着时间的推移而扩大，说明存在瓶颈。
挣值分析
挣值管理包括一系列的测量，将项目开始前的计划基线值与实际技术进展和项目花费的时间进行比较。
这种比较通常是以美元价值的形式进行的，它需要特别的准备，以便在敏捷框架中使用，结合故事点来衡量挣值和计划值。你可以在很多层面上使用EVM方法，从单一任务层面到整个项目层面。
你可以在Agile中使用EVM技术来确定你的软件测试的经济价值。
在单一任务层面上，EVM方法可以帮助你了解你的软件测试是否具有成本效益，通过比较计划价值和挣得价值。
敏捷环境下的具体测试指标
自动测试覆盖率的百分比
这个指标衡量的是自动测试所达到的测试覆盖率的百分比。随着时间的推移，越来越多的测试被自动化，你应该期待更高的测试覆盖率，从而提高软件质量。
测试自动化代表了在敏捷团队中实现高测试覆盖率的唯一方法，因为测试用例随着每个冲刺阶段增加的功能而增长。
自动化测试覆盖率为敏捷团队提供了一个基本的风险衡量标准。自动化测试覆盖率越高，发布中出现生产缺陷的几率就越低。
代码复杂度和静态代码分析
代码复杂度通常是通过一个名为 "循环复杂度 "的措施得出的，代码复杂度的指标是计算通过程序源代码的线性独立路径的数量。
静态代码分析使用一组工具来检查代码，而不执行它。例如，编译器可以通过分析代码来发现词法错误、语法错误，有时还有语义错误。因此，静态分析是检查程序中是否有健全的编码标准的一个好方法。
开发人员努力构建简单、可读的代码以减少缺陷数量。因此，循环复杂性指标对敏捷团队来说是有用的，可以确定不稳定或容易出错的代码的风险。确定复杂性可以让你评估功能或版本出错的可能性有多大。
静态代码分析工具可以帮助敏捷团队检查用于构建程序的代码结构，确保其符合既定的行业标准，如缩进、内联注释和正确使用间距。
生产中发现的缺陷/逃逸的缺陷
逃逸缺陷是一个简单的指标，它统计了某一版本在发布日期之后发现的缺陷。这些缺陷是由客户发现的，而不是由敏捷开发团队发现的。由于逃逸的缺陷往往是相当昂贵的，所以仔细分析它们并努力看到这个指标的减少是很有帮助的。
分析逃逸的缺陷有助于确保测试和开发过程的持续改进。界定逃逸缺陷的根本原因有助于防止同样的问题在后续版本中再次出现。
敏捷团队可以捕获每个单位时间、每个冲刺阶段或每个版本的逃逸缺陷指标，提供关于项目特定部分的开发或测试出错的具体洞察力。
