敏捷测试技术

测试是软件开发的一个组成部分，它与需求创建活动密切相关。在敏捷项目中也可以有结构化和系统化的测试方法。由于敏捷项目中通常定义多个版本，因此测试在产品或服务的质量控制中起着重要作用。

在敏捷中，重点放在需求分析讨论上，团队成员需要与产品负责人和业务分析师密切合作，以开发用户故事及其验收标准。测试人员从项目开始就必须参与，这样他们才能积极参与定义完成的定义、探索用户故事等。测试人员不应闲置或等待需求。他们应该跟进验证标准，以了解对新功能的预期或对系统进行的更改。在敏捷项目中，无论工作如何，每个团队成员都必须在解释需求时变得更加主动、热情和前瞻性。

敏捷性不仅改进了软件测试过程，而且增加了灵活性并增强了易用性。因此，敏捷性会导致“持续的流程改进”，由于对流程的满意度，这会显着增加测试量。

关键概念

在敏捷框架中，测试和开发都在同一个 sprint 中进行。一旦测试团队对正在开发的内容有一个清晰的认识，测试人员的工作就是在合并新更改后系统将如何运行，以及它是否满足业务需求或验收标准。在开发团队进行设计和代码更改时，测试团队致力于测试方法并提出测试场景和测试脚本。一旦代码准备好进行测试，测试团队就会开始测试，测试需要在 sprint 结束时完成。在某些情况下，当业务需求的一个模块可供测试时，这是很有可能的。测试团队应该在较小的模块上工作，并在提供时测试它们，而不是完全开发整个功能。

1. 测试策略与规划

测试策略是测试项目的重要工件。测试团队有责任在项目中拥有结构化和明确的测试方法和策略。与传统方式不同，在敏捷中，作为需求范围，因此测试确实经常变化，通常建议在每个 sprint 开始时更新测试策略。此测试策略的文档从发布启动阶段开始，并在整个发布过程中充当活文档。每个 sprint 都有自己需要交付的故事范围。作为测试团队的一部分，他们可以创建测试计划。该计划必须在每个 Sprint 中更新，并一直持续到发布。

传统上，在软件项目中，系统测试是在开发团队完成集成后开始，然后业务负责人在系统测试后进行 UAT（用户验收测试）。然而，当谈到敏捷时，所有这些界限都是非常多孔的。作为敏捷团队成员，一个人必须同时测试一个功能，同时为另一个编写测试计划，同时审查另一个故事的设计，并在同一时间点执行许多类似的活动。测试人员参与敏捷项目的设计讨论。这有助于他们以更好的方式计划测试用例。

在敏捷中，在每个 sprint 结束时，团队都会与业务一起参与 Sprint 评审。在这些审查中，参与测试的团队成员主要负责准备测试数据表并在业务利益相关者、产品所有者面前运行测试并向他们展示产品如何工作以及它是否满足他们的接受标准。这是敏捷中的一个关键过程，可以帮助团队从客户和其他利益相关者那里收集关于冲刺中开发的用户故事的反馈。测试团队在这个过程中扮演着举足轻重的角色。

2. 自动化对敏捷测试的重要性

敏捷需要对过去 Sprint 中开发的功能进行持续测试。自动化的使用有助于按时完成此回归测试。它最大限度地减少了由于容易出错的手动过程而可能发生的返工。它有助于为作为 Sprint 测试的一部分运行的测试带来可预测性。有助于覆盖比手动完成更多的回归测试。这在敏捷中是非常需要的，因为它具有更多的构建和更频繁的更改，因为它具有迭代性质。该资源可用于其他任务——测试人员可以将精力集中在需要手动干预的部分新功能上，而不是重新测试现有功能。连续回归测试需要大量的测试工作，因为我们必须根据迭代多次重复测试。自动化的使用有助于减少这种工作量。在每个 sprint 中聚合的较小的自动化测试用例在项目结束期间形成一个详尽的回归套件，从系统、回归和验收测试的角度来看，它几乎涵盖了所有功能。因此，它有助于最大限度地降低发布 Sprint（发布中的最后一个 Sprint）中的项目成本——因为大多数测试都可以通过现有的自动化来处理。

3. 敏捷中的测试覆盖率

考虑到 Sprint 完成测试的有限时间范围，识别和最终确定用户故事的测试覆盖率是敏捷项目中最重要和最具挑战性的任务之一。测试覆盖率不足可能会导致某些需求的关键测试丢失。用户故事的测试覆盖率通常在待办事项梳理会议期间以及稍后在 Sprint 计划会议期间进行讨论和最终确定。在某些情况下，测试覆盖率可能会导致遗漏一些测试场景，可以通过在需求、用户故事和测试用例之间创建可追溯性矩阵来缓解这种情况。也可以在测试用例和用户故事之间创建链接。

当代码更改没有完整的影响分析、审查和所需的测试用例中的相应更改可能导致不完整的测试覆盖时，可能会出现另一种情况。这可以通过分析影响、查看源代码以识别要更改的模块并确保所有更改的代码都经过适当测试来缓解。此外，作为自动化工作的一部分，必须利用代码覆盖工具的使用来实现可验证的彻底性。

4. 敏捷中的测试数据管理

测试数据是测试中最重要的因素之一。创建和操作用于测试各种测试用例的数据是测试中具有挑战性的任务之一。当系统依赖于另一个团队来获取测试数据时，Sprint 中的敏捷测试会变得很困难。 Sprint 时间线没有为数据设置中的任何延迟提供足够的空间。设置测试数据是在 Sprint 中完成的，以便至少在开发人员签入他的代码以声明它“已完成”时及时（如果不是更早）及时 (JIT) 提供它们。由于所有的开发人员通常都会为单元测试和集成测试实践测试自动化，并且有时使用“测试驱动开发”方法来完成他们的用户故事，因此测试团队同步提供测试数据是必不可少的。

数据需求分析在待办事项梳理会议和 Sprint 计划会议期间完成，以确保完整的数据设置需求。分析完成后，将相应地联系相关团队。这有时也可能不会富有成效，因为如果数据复杂且庞大，我们可能无法从拥有数据的团队那里获得足够的支持。因此，理想情况下，讨论应该从业务开始，至少提前一个 Sprint 或根据适用的 SLA 在适当的时间获取数据。

此外，如果可能，负责数据的成员（来自企业）应作为 Sprint 的 Scrum 团队的一部分，在需要他们的支持时加入。通过这种方式，他们可以更清楚地了解所需的确切数据，并且团队可以衡量/改进他们的进度。

此外，敏捷是一种迭代模型，在不同的 sprint 中可能存在类似的用户故事，其中在早期 sprint 中创建的测试数据可以直接重用或稍作修改使用，以避免冗余数据请求/设置并减少周转时间测试数据的创建和操作。

5. 敏捷中的影响分析

在传统的实践中，Team 过去常常通过业务需求和孤立地开发测试场景。他们仅在开发团队完成设计评审时才参与设计评审。因此，测试团队在这些评论中的贡献微乎其微。然而，在敏捷中，测试团队在影响分析和设计评审中扮演着更重要的角色，因为他们参与了故事的设计讨论。这有助于开发人员对问题进行影响分析和调试。很多时候，测试团队成员会与开发人员一起进入代码级别分析或调试问题。在敏捷中，由于时间短，整个团队有责任确保从第一天开始正确地开发事物，从而为成功交付做出贡献。

敏捷测试实践：

1. 测试类型：

• 单元测试
• 集成测试
• 冒烟测试
• 系统测试
• 回归测试
• 性能测试
• 探索性测试
• 客户/用户验收测试

2.敏捷中的缺陷管理：

有一种说法是敏捷中不需要缺陷管理。但是，重要的是要了解当存在需要更多努力且无法在规定的冲刺时间内修复的错误时，它是如何工作的。在这种情况下，敏捷项目也需要缺陷管理。只要故事可供测试，测试团队就会开始测试并发现错误。通常的做法是，如果 bug 或问题可以在一天内修复，则不会提出缺陷，并与开发团队进行沟通以解决问题。如果发现的问题一天没有解决，那么就会提出缺陷，让团队和相关的利益相关者意识到这个问题。这必须在缺陷管理工具中正式跟踪。与团队一起讨论关键缺陷，产品负责人最终确定缺陷的关键性以及记录缺陷的故事的关键性。

以下是敏捷中如何进行缺陷管理的描述：

缺陷的优先级如下：

• 对测试覆盖率的影响
• 对满足故事接受标准的影响

如果在 sprint 期间出现了一个缺陷，或者某个缺陷与 sprint 中的任何故事没有直接关系，该怎么办？在这种情况下，会提出一个缺陷并讨论它是否可以在同一个 sprint 中修复，以及修复和重新测试它需要多少努力。如果工作量太大，并且如果预测它不能作为当前 Sprint 的一部分交付，则要么将其移至与缺陷相关的故事，然后在未来的 Sprint 中进行计划，要么将其转换为新故事并被分配到未来的 sprint。

捕获团队部署的测试技术的有效性细节非常重要。以下是团队可以跟踪和分析的一些建议指标，作为缺陷管理活动的一部分：

缺陷去除有效性 (DRE)：缺陷去除有效性是一个指标，它告诉测试人员可以在测试中识别出多少缺陷，以及其中有多少进入下一阶段，即 UAT 或生产或保修期等。DRE 以百分比表示。

Defect Removal Effectiveness (DRE) = (No. of In-process defects / Total no. of defects)* 100  
(Total number of defects = In-process defects + Defects found in Sprint/Release review)

测试覆盖率（使用代码覆盖率）：当使用黑盒技术测试用户故事时，团队会进行验证以比较输出对于给定输入是否正确。但是当重点放在测试覆盖率上时，测试人员可以查看黑盒代码并分析测试集实际执行了多少代码。团队可以使用商业上可用的测试覆盖工具来做到这一点，如“语义设计”测试覆盖工具、“靶心覆盖”等。如果关注测试覆盖，它还将黑盒测试的视野扩展到白盒测试。这就是高级流程的方式：首先编译代码并集成测试覆盖工具。然后使用该代码来测试您的测试用例。测试完成后，检查工具报告以查看刚刚执行的测试所达到的代码覆盖率 o 根据报告和与开发人员的讨论，测试人员应决定添加/更新测试套件，以获得额外的代码覆盖率。测试甚至没有达到。当执行软件以运行测试套件时，工具报告会报告哪些路径/类/分支/文件被覆盖。根据报告和与开发人员的讨论，测试人员必须决定是否要创建额外/更新的测试，以便通过测试获得更好的代码覆盖率，并确保代码的每个角落都经过测试 o 很多时候，这些工具提供了额外的细节不仅仅是 % 代码覆盖率。它们是产品质量指标 (PQM)，如内存问题、死代码、克隆识别等。最终帮助开发人员进一步清理和优化代码。因此，使用代码覆盖工具可以帮助测试人员了解代码的哪些部分被测试了，还有哪些需要测试。它还可以帮助开发人员进一步微调和重构代码。

Test Coverage % = % of Code covered through the Test Suit.  
Test coverage targets should be 90% to 100%.

自动化测试覆盖率：从测试的角度来看，测试覆盖率的自动化提供了对作为项目一部分自动化的测试用例的百分比的洞察。每个 Sprint 都涵盖了某些要自动化的测试用例，这些测试用例可以在未来的 Sprint 中以自动化方式运行。通过这种方式，自动化测试用例的数量增加了 Sprint，Sprint 减少了手动测试用例的数量，从而提供了更高百分比的自动化，可以在发布级别测试期间覆盖系统用例，而不是手动执行用例。

Automation test coverage metrics = (Number of automation test cases/ 
Total number of test cases)*100

具有较高自动化百分比的团队可以更多地专注于探索性和临时测试，以便可以通过自动化覆盖常规测试用例。

自动化覆盖有效性：自动化的有效性用于通过自动化测试捕获的缺陷数量来定义自动化测试用例的有效性。通过运行自动化测试用例捕获的缺陷越多，有效性就越高。该团队致力于识别可以修改的组件，以识别更多缺陷。

Automation coverage effectiveness = (Number of defects caught by automation
/ Total number of defects caught)*100

在每个 Sprint 中，团队可以处理在早期 sprint 中手动捕获的缺陷，以结合自动化中的更改，从而提高自动化测试用例的有效性。如果有效性保持不变/下降，那么团队需要努力对自动化测试策略进行一些更改。

项目/发布启动阶段：测试人员应该从项目启动开始就参与进来，以更好地理解需求。 o 在项目的早期阶段了解高层需求并突出问题（如果有的话）。在产品待办列表中设置业务优先级时，向产品负责人或业务分析师提供输入。

了解业务优先级并在发布计划中提供帮助：

• 项目/发布计划和规模调整：开发人员和测试人员都应该参与产品待办列表梳理会议。开发人员和测试人员应该一起参与规划扑克游戏，这有助于不准确的估计和故事大小。自定义估计模板用于根据过去的敏捷项目经验捕获缺陷率、注入缺陷率和回归周期轮次。
• 冲刺计划：测试人员应强制参加需求演练会议，以在早期捕获更多数量需求/设计结果和生产问题。始终建议在 Sprint 级别需求分析之后重新访问和修改估算。应采用模块化方法进行测试计划和脚本编写。在计划阶段结束时与团队一起进行测试场景演练将始终帮助每个成员获得更广泛的想法。
• Sprint 执行：测试数据设置活动的整合/模块化方法。测试数据存储库以增加可重用性。基于指标的测试执行，以实现更好的跟踪和覆盖。在危急情况下进行基于风险的测试。要最大化测试覆盖率，请使用“Sprint Traceability Metrics”。敏捷审查清单以提高可交付成果的质量。与瀑布团队密切合作，在危机期间平衡工作量。