如何在敏捷环境中使用测试指标

最新推荐文章于 2024-11-12 23:14:56 发布

danpu1174

最新推荐文章于 2024-11-12 23:14:56 发布

阅读量259

点赞数

文章标签：软件测试大数据 python 人工智能 java

敏捷方法用于项目管理的思想是鼓励协作，透明度和对集成团队之间反馈的响应。敏捷软件开发是指使用敏捷宣言中概述的一组原则来频繁开发高质量的工作软件。

敏捷方法论着重软件开发的快节奏，这意味着软件测试还必须在保持足够透彻的速度以确保高质量的同时进行。

对于敏捷团队来说，找到一种评估和改进测试工作的方法至关重要。测试指标对于提供敏捷团队中任何软件测试工作的有效性的基本度量非常有用。

这篇文章通过将测试与旧的瀑布式框架软件开发中的传统测试进行比较，概述了敏捷开发中的确切测试。您还将了解有关敏捷测试计划的信息，并对一些有用的敏捷测试指标进行了深入了解。

我们重点关注与敏捷团队中的测试相关的六个关键指标。请参阅SeaLights的“ 测试指标学习”部分，以获取更广泛的建议指标列表。

阅读这篇文章后，您将更好地了解如何衡量软件开发团队的测试工作并对其进行改进，从而带来更高质量的软件和更高效的开发。换句话说，您将更容易实现敏捷开发的目标。

什么是敏捷测试和敏捷测试计划？

在敏捷框架流行之前，质量检查是由独立的测试团队执行的单独活动。如今，敏捷测试意味着像敏捷开发团队一样对软件进行缺陷测试。

借助敏捷测试，开发人员可以在工作中自行改进测试，并借助增强的自动化和快速反馈，敏捷团队可以交付更高质量的软件，并更快地将产品交付生产。

测试计划是正式概述软件测试范围和活动的重要文档。敏捷测试计划不同于旧瀑布方法中使用的传统测试计划。

Waterfall是一种非迭代的顺序软件开发方法，该方法将开发划分为预定义的阶段。由于在软件设计阶段之前已定义了详细的要求，所以瀑布式测试计划是静态的。这样的计划在项目的整个生命周期中不需要太多修改。

与瀑布式方法相反，敏捷方法需要动态测试计划，该计划具有适应不断变化的需求的适应性。测试策略至关重要，因为它可以帮助团队：

了解在冲刺中哪些点需要测试功能；
主动创建测试数据以测试仍在开发中的组件之间的依赖关系；和
了解谁负责单元测试，何时开始自动化测试以及使用哪些工具进行测试。

因此，动态测试计划可以通过确保软件测试的透彻准备以及由于测试策略和过程透明性而提高的效率来提高敏捷团队的生产率。这种测试计划可以帮助敏捷团队提前计划，同时允许团队适应不断变化的需求。

敏捷测试指标

在创建测试计划并开始软件测试之后，通过查看相关指标形式的数据来评估软件测试的有效性非常重要。以下度量标准是可以帮助敏捷团队更好地实现其目标的度量类型的示例。

燃尽图

精简表非常有用，因为它作为度量标准很简单。燃尽图绘制了出色的工作与时间的关系。时间单位可以是天，迭代或冲刺。您可以评估故事点，功能和功能方面的出色工作。

理想线是从迭代或项目的开始绘制的，并以直线连接到项目的终点。您可以使用Microsoft Excel或多个项目管理工具（例如Team Foundation Server）中的任何一个来创建燃尽图。

资源

实际生产线应尽可能紧密地跟踪估计。燃尽图中实际与理想之间的差异可以快速衡量团队的生产力。假设团队根据理想的线准确地估计了其生产率，则燃尽图提供了简单的视觉帮助，可以在实际剩余工作远远超出估计任务时Swift解决任何问题。

在敏捷中，当开发和测试都完成时，任务被视为完成。定义完成的常用术语是“完成即完成”，表示燃尽图上显示的已完成任务已经过测试，并且没有其他相关活动。

运行经过测试的功能

运行测试功能（RTF）是一种敏捷度量标准，用于度量经过软件测试验证可以正常运行的客户定义软件功能的数量。该指标很有用，因为它可以通过以下方式使团队更加敏捷：

关注功能而不是设计或基础架构，以及
验证每个功能是否正常运行，并在每次迭代时生成随时可用的软件。

资源

通过测量给定项目的RTF增长，团队可以轻松分析软件编码或用于验证功能是否正常的测试是否存在问题。数据根据运行中的测试功能的数量以线形图的形式直观地表示，从而轻松验证运行中的测试功能的数量是否随每次迭代（预期）增长。

累积流量

累积流程图映射了整个项目的工作流程，包括团队仍需要完成的任务和已经完成的任务。由于测试是团队工作流程的一部分，因此通常包含在累积流程图中。

资源

通过绘制整个项目工作流程的图，敏捷团队可以对最终成为瓶颈的区域进行有价值的度量，而非生产性工作则显示为在项目过程中不断扩大的垂直带。例如，在上图中，以红色区域表示的进行中的工作在项目过程中不断扩大，表示项目中存在瓶颈。可以使用此度量标准来识别和解决此类关注的领域。您可以在Excel中创建CFD。

缺陷循环时间

敏捷团队应努力尽快修复错误。实际上，协作敏捷方法的主要目标之一是更快地修复错误，以便更快地发布软件。仅当编写了良好的测试并且测试人员与开发人员就缺陷进行有效沟通时，才能实现这种快速修复。周期时间衡量从完成一项任务开始完成一项任务所花费的总时间。因此，缺陷循环时间是一个有用的敏捷度量标准，因为它传达了敏捷团队作为一个团队修复缺陷的能力。

资源

可以使用Office应用程序将缺陷循环时间绘制成图形，以图表形式显示在y轴上修复缺陷所需的时间与在x轴上进行迭代（或其他间隔）的时间。最终目的是通过精心设计的测试，从测试团队快速而彻底的反馈以及开发人员Swift修复的结果，缩短缺陷周期。上图中的迭代6、7和8的缺陷循环时间短于阈值。

缺陷溢出

敏捷团队的目标是在每次迭代时都产生可运行的软件。缺陷溢出可以通过简单地计算每次冲刺或迭代开始时剩余的缺陷来衡量在给定的迭代或冲刺中未修复的缺陷。

当团队忽略这些缺陷时，这些缺陷会随着时间累积，从而导致技术欠债，从而降低生产率。衡量此指标可使敏捷团队了解他们如何有效地处理出现的问题。一个简单的条形图提供了直观的帮助，显示了每个sprint或迭代的剩余缺陷。理想情况下，几乎没有缺陷应该在两次间隔之间溢出。

资源

速度

速度是单个团队的有用指标。该指标仅将给定长度的冲刺期间完成的工作单位与交付该冲刺所需的估计工作单位进行比较。

资源

速度是衡量敏捷团队随着时间推移成熟程度的好方法。理想情况下，每次冲刺都应提高速度，然后在团队达到最佳生产力时达到一个峰值。您可以在项目管理软件（例如Atlassian）中查看速度图表。

常见的敏捷测试问题

即使要衡量许多不同的指标，测试本身对于敏捷团队也是一个问题。在发布软件之前，对软件进行彻底的测试显然很重要，但是测试会减慢软件的上市时间。因此，主要的敏捷测试问题围绕着实施解决方案以提高效率和生产率。敏捷测试的一些主要挑战是：

缺乏测试覆盖率。 快速推出软件的压力可能导致团队为用户案例编写的测试太少。拥有对所有代码更改的可见性以编写足够的测试以覆盖给定用户故事中的代码，这一点很重要。
密码破损。 团队交付构建的频率越高，破坏现有代码的机会就越大。每日回归测试与手动测试运行不切实际。此外，随着微服务的使用变得越来越普遍，每个微服务都在其自己的生产管道中运行，因此必须验证所有活动部件是否正常工作并正确集成。
赶上缺陷太迟了。 在开发周期后期发现的缺陷修复成本要比早期发现的缺陷高得多。无论您的项目框架如何，都适用此规则。面临的挑战是在敏捷框架中尽早找出最好的识别缺陷的方法。需要左移，这意味着在开发周期中尽早进行软件测试。
性能瓶颈。 敏捷团队需要了解如何最好地监视软件性能，以使其他功能不会导致系统严重下降。

跟踪某些测试指标还存在许多问题。这样的度量标准会产生问题，因为它们可能引起混乱，违反敏捷原则或提供很少的价值。例如：

跟踪个人指标 。这违反了敏捷精神，因为它鼓励同一团队成员之间的过度竞争。例如，通过计算书面测试的数量来衡量生产率。太多的竞争会损害团队合作精神并产生质量测试问题。
跟踪无意义的指标。 毫无意义的指标是那些没有告诉您测试生产力的指标。例如，将两个敏捷Scrum团队以各自的速度进行比较是一个糟糕的指标，因为速度对于每个团队都是唯一的，因为速度取决于每个团队唯一的估计。比较团队之间的速度会鼓励团队弄乱他们的估计，从而导致对冲刺的计划不周。

克服潜在使用有问题的测试指标或不正确使用测试指标的唯一方法是在团队成员和项目经理之间提高对敏捷团队中有用的测试指标构成的认识。