内容


使用敏捷方法测试 Fix Pack

简介

Fix Pack 是定期发布的针对在用产品的修复包集合。Fix Pack 测试的最重要目标之一就是确保修复包不会造成损害。在一个常规 Fix Pack 流程中,测试团队在建议修复包列表确定之后才登场。测试团队要花费相当大量的时间来验证修复包,因为存在多种因素,例如缺陷文档中缺少信息、服务成员要回忆信息、测试成员要花费时间理解和解决问题。这会产生较长的测试周期、影响其他 Fix Pack 增值测试的作用域。这种折衷办法可能影响 Fix Pack 的质量。

敏捷方法可以引入到 Fix Pack 测试流程中,以提高效率、确保优质的可交付成果并消除浪费/等待时间。

常规 Fix Pack 测试

常规 Fix Pack 流程首先要确定建议的授权程序分析报告 (Authorized Program Analysis Report, APAR) 修复包列表,列表中的修复包要加入到 Fix Pack 中。测试团队从这一阶段才参与到流程中。测试成员理解各种修复包,并寻找与修复包可能带来的损害。

图 1. 常规 Fix Pack 流程
常规 Fix Pack 流程
常规 Fix Pack 流程

常规 Fix Pack 测试流程的劣势如下:

  • 只有在建议修复包列表确定之后,测试人员才参与到流程中。这导致要花费大量时间来理解 APAR 和开发测试案例。
  • 服务文档中会丢失信息是较长测试周期的成因。
  • 服务团队用于修复损害问题的时间有限。
  • 要隔离导致损害的修复包需要大量工作。
  • 所交付的 Fix Pack 的质量可能受到损害。

这些劣势的最终结果就是测试周期更长,增值测试范围更窄。

敏捷方法

“敏捷可使用持续的涉众反馈,通过用例(或用户案例)以及一系列较短的定时迭代,来交付优质的可消费代码。”

在上面的定义中,根据项目情况,涉众可能包括负责人、内部人员、合作伙伴和最终用户。可消费代码应当确保整体用户满意度。用例根据客户情况或问题而开发,其构成包含角色、目标和商业价值。定时迭代可帮助流程客服传统瀑布模型的缺点。每个迭代都生成软件的一个工件作为输出。

敏捷的关键特征

自主团队:敏捷主张由一个技能多样、功能丰富的团队为目标而努力。该团队有能力独立解决问题。在此原则之下,不存在 “老板” 的概念。

可持续步调:敏捷相信要以可持续步调工作,这样团队就能持久工作。

持续整合:持续整合是一种实践,可持续构建和测试软件,以便及早检测出问题并验证软件质量。这可在任何时候生成可部署的软件。它以自动测试的方法降低了风险。

自动化:伴随持续整合而发生的自动测试有助于实现敏捷的主要益处。

Sprint 和迭代:Sprint 和迭代遵循相同的基础原则,只是持续时间不同。将进行重复活动直到项目结束。一次迭代可能具有固定数目的 Sprint。一次 Sprint 是最小单元,不能进一步划分。

待办事项:代码实现是一组要在固定时间范围内完成的优先任务。可以针对项目、迭代和 Sprint 而定义。

技术死角:这指的是不能在计划 Sprint 或迭代中完成的工作。可根据需要在下一次 Sprint/迭代或者一次稳定性 Sprint/迭代中完成。

Scrum:Scrum 是由自主团队举行的日常行动计划会议。在 scrum 中还可以识别路线障碍。

MoSCoW 原则:这是一组用于为待办事项划分优先级的原则。它根据 “必须有”、“应当有”、“可以有” 和 “不会有” 这 4 个级别来区分待办事项。

敏捷和紧凑:敏捷和紧凑彼此互补,携手存在。敏捷是一种严格的软件开发方法。紧凑是一组用于杜绝浪费的原则。这两者都有助于改善工作流程的性能和效率。消除浪费、保证质量、关注学习,这些紧凑原则是本文的重点。

在 Fix Pack 测试流程中实现敏捷

Fix Pack 测试流程可采用敏捷原则进行简化,从而确保质量和更快速的交付。图 2 例示了 Fix Pack 测试流程的完整概览,此流程适当地采用了敏捷原则。

图 2. 采用了敏捷原则的 Fix Pack 流程
采用了敏捷原则的 Fix Pack 流程
采用了敏捷原则的 Fix Pack 流程

流程概览

当 APAR 或者 SIP(Service Improvement Plan,服务改进计划)确定时,就可形成 Sprint 团队。Sprint 团队的成员(服务和测试代表)就指定的 APAR 或 SIP 彼此紧密合作,确保特定 APAR 得到完全处理,以便在后续 Fix Pack 中提供。Sprint 团队中的测试代表识别出测试方案,开发测试案例,用于处理 APAR 或 SIP。开发出的这些测试案例然后整合到自动化测试套件中。

根据服务水平协议 (SLA),每隔一段时间,由 APAR 修复包或 SIP 而引起的产品变更就会整合到 Forward Service Build (FSB) 中。这种间隔定义了定时迭代的持续时间。自动测试套件然后对照可用 FSB 而运行,包含了 Sprint 团队所确定的全部测试案例。对照修复包或损害问题在测试流程中找出的缺陷计划在后续迭代中得到处理。每个迭代都生成一个可能发布的 Fix Pack。

当满足了交付 Fix Pack 的标准时(例如:根据服务版本中修复包的累计数量,或者与提交给客户的产品年度计划相一致),最新可用的 FSB 可以作为 Fix Pack 而交付。

以下部分详述了整体流程,并重点介绍了底层敏捷原则。

Fix Pack 团队

Fix Pack (FP) 团队包含来自每个服务团队、测试团队和构建团队的协调者。这种较高层次的协调工作可负责保证质量并促进 Fix Pack 的交付。图 3 列出了 Fix Pack 团队中成员扮演的角色及其职责。

顾名思义,FP Owner 负责 Fix Pack 的交付。FP Owner 确定要在 Fix Pack 中提供的修复包和 SIP 集合,并根据 MoSCow 原则为之划分优先级。这些修复包和 SIP 共同组成了 Fix Pack 待办事项。

图 3. 角色和职责
角色和职责
角色和职责

Fix Pack 团队的主要目标如图 4 所示。Fix Pack 团队的成员朝着这些共同目标而努力。

图 4. Fix Pack 团队—主要目标
Fix Pack 团队—主要目标
Fix Pack 团队—主要目标

Sprint 团队

Sprint 是迭代的一部分,由 Sprint 团队执行。Sprint 团队是自主的跨功能团队,朝着理解 APAR 这一共同目标而努力。当 APAR 固定或 SIP 确定时,包含相关测试和服务代表的 Sprint 团队就由 Fix Pack 团队构成了。图 5 显示了 Sprint 团队。

图 5. Sprint 团队
Sprint 团队及其目标
Sprint 团队及其目标

Sprint 团队中的 TR 和 SR 彼此紧密合作,更好地洞察问题、理解用于解决问题的修复包。(用户案例能够以客户问题为源,根据敏捷原则而构建)。

用于处理修复包以及潜在损害的测试方案是由 TR 确定的。测试架构师会在内部审查这些方案。被认可的测试方案将开发成为测试案例。然后测试案例会整合到自动化测试套件中。服务代表作为测试代表的评估者。在每个迭代中都查找评估者的持续反馈,这帮助改进测试质量。Sprint 团队的形成过程是一个不断学习的过程。

在每个迭代中,所有整合到 FSB 中的 APAR 修复包或者 SIP 都由 Sprint 团队以相同方式解决。图 6 显示了 Sprint 的完整描述。

图 6. Sprint 概述
Sprint 概览
Sprint 概览

Sprint 待办事项:Sprint 待办事项是为解决特定 APAR/SIP 而开发的测试案例集合。Sprint 团队拥有待办事项,FP 团队监视之。Sprint 死角(不能在 Sprint 内开发的测试案例)必须尽可能地避免。如果不能避免 Sprint 死角,那么要有计划一个稳定性 Sprint 来包含所有 Sprint 的死角。确保在交付 Fix Pack 之前执行此稳定性 Sprint 这是很重要的。

迭代

图 7. 迭代概述
迭代概述
迭代概述

持续整合和验证是迭代的关键原则。这构成了以下两个主要阶段:

  1. 每个 Sprint 团队为各自 APAR 持续地将测试案例整合到自动化测试套件中。
  2. 持续地将产品变更(APAR/SIP 修复包)整合到 FSB 及其后续验证之中。

迭代的界限是在两个 FSB 之间。( FP 团队之间的)SLA 确定了迭代的持续时间。这有助于使迭代短暂而且定时。在迭代中发现的缺陷计划在下一次迭代中处理。在本质上后续迭代会累积,而且不妨碍修复包及其验证。每个迭代都输出可能发布的产品工件。

迭代待办事项包括以下这些:

  • 整合在此迭代中处理的 APAR 修复包。
  • 将针对前一个迭代中所提出的缺陷的修复包整合到 FSB 中。
  • 在特定迭代过程中的组件 Sprint 中开发和整合测试案例。
  • 对照 FSB 验证 APAR 修复包,确保没有损害。

由 Sprint 死角成分会产生迭代死角。

交付 Fix Pack

应当只有在满足以下标准时才交付 Fix Pack:

  • 完成了所有迭代。
  • 解决了提出的所有缺陷。
  • 成功执行了增值测试。
  • 实现了目标质量。

一旦满足了 Fix Pack 出口标准,最新的 FSB 就可打包,并作为 Fix Pack 交付给客户。

主要领域

  • 测试案例自动化是成功实现此流程的关键。
  • 构建和测试执行自动化可改善性能和效率。
  • 必须确保在迭代中发现的缺陷在后续迭代中将弥补。
  • 必须定义切实可行的 SLA,以塑造 FSB 的整合性和可用性,因为这是迭代中的工作。

关键获益

在 Fix Pack 测试流程中采用敏捷,可使流程更有效,并提供以下益处:

  • Sprint 团队结构产生了一种途径,可借以更好地理解客户对产品的使用情况。这又可辅助开发以客户为中心的测试。
  • 测试团队及早介入,于是在编写有效的测试案例时,尽可能不依赖支持文档。TR 在确定 APAR 的同时理解 APAR,而不像常规流程中在很后期的阶段才能理解 APAR。
  • 每个迭代都处理一定数量的 APAR,而不像常规流程中要处理大量的 APAR。这有助于实现可持续的工作步调。
  • 短暂的定时迭代简化了对损害原因的诊断和隔离。
  • 连续整合原则确保及早检测出损害、及早验证软件质量。
  • 针对未来版本复制并执行自动化测试案例,可使之避免类似问题。
  • 显著缩短了 Fix Pack 的面世时间。

术语

FP:Fix Pack —— 交付给客户的修复包集合。

APAR:授权程序分析报告(缩写为 APAR)是一种发送给开发部门的 IBM 内部正式报告,用于报告程序故障。

SIP:服务改进计划。

SR:服务代表(或成员)

TR:测试代表(或成员)

FSB:Forward Service Build —— 包含所有最新修复包的在职产品的累积版本。

SLA:服务水平协议 —— 关于一个迭代期间修复工作的协议。

结束语

一句话,在 Fix Pack 测试流程中采用敏捷方法可增强交付 Fix Pack 的效率。在敏捷方法领导下,将相关测试工作分割到定时迭代中,可确保持续验证产品变更、确保交付改进的 Fix Pack。


相关主题

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=456200
ArticleTitle=使用敏捷方法测试 Fix Pack
publish-date=12142009