成本高、耗时长的回归测试对整个交付团队来说是一个令人烦恼的难题。幸运的是,我们有机会让回归测试变得更轻松、更有效。要做到这一点,应该设计一个有效的回归测试策略,充分满足产品的需求,以最佳的成本保证产品质量。这需要了解回归测试的本质,采用它的原因以及执行它的方法。
软件的回归是指某个事件(例如,一个软件补丁或升级)发生后出现的一个缺陷。回归测试则确保了最近变更的代码不会影响其他代码,从而防止软件回归。
变更是回归测试中的关键概念。变更的原因通常分为四大类:
了解这两种测试之间的差异很重要。重新运行功能测试用例,然后产生错误报告。测试工程师再次执行它们以检查错误状态(已修复、未修复等)。如果错误仍然存在,开发团队会收到一个错误报告以进一步排错。排错完成后,测试团队运行回归测试来确保应用程序仍可正确工作。
根据测试目的的不同,回归测试可分为三种类型:
分析了回归测试的原因及其类型后,我们可以开始制定一个有效的回归测试策略。在设计回归测试策略时,团队依赖于两个因素:
如果考虑到这些因素,测试团队就可以选择到合适的回归测试方式和方法。
回归测试遵循两种实现方法:手工和自动。
手工回归
无论采用何种方法论(瀑布、敏捷和其他),手工回归测试是对产品进行回归测试的基本方法。回归测试套件包含了应用程序最近发生变更及其相关部分的测试案例。这种类型的测试总是先于自动化测试,在某些情况下比后者更有效。例如,想要测试与应用程序发生变更部分相关的功能,通过编写自动化测试脚本是不可能做到的。
手工回归测试,在产品交付过程的早期阶段是有效的。我们开发的一个产品,比如iOS图像处理应用程序,手动回归测试可以帮助检测出影响应用程序用户体验的多个错误。手工回归测试发现该应用无法正确地生成图像,当用户改变屏幕方向时会发生崩溃。
尽管如此,测试团队仍然试图采用自动化的回归测试,因为手工回归测试的主要问题是费时、费力。对于复杂的产品,手工运行回归测试套件,不可避免地影响了测试工程师的注意力和效率。因此,在这种情况下,团队更喜欢借助自动化。
自动回归
一个大中型项目(时长六个月或更久),当项目处于稳定阶段(预期的业务逻辑和用户界面已不会发生重大变化),自动化回归测试是典型的方法。有了全面的回归测试规划,自动化降低了测试团队花费在繁琐、重复任务上的精力,省下时间去参与那些需要人工介入的测试,比如探索性和用户体验测试。
然而,现今的团队往往在早期阶段就开始自动化回归测试。它适用于敏捷开发,团队至少每周部署一个产品,没有时间准备手动回归测试。通过与整个团队(利益相关者、管理者、业务分析师等)沟通并研究用例文档,测试人员可以了解利益相关者的需求、产品业务逻辑以及测试的预期结果。在项目早期,自动化的主要任务是选择测试框架,它应该提供简单的脚本和低成本的测试维护。创建的基础架构可以重用于未来的产品,并能加速测试自动化。
在某些情况下,自动化可以帮助检测手动回归测试未发现的错误。最能说明问题的例子,是那些随机出现的错误。当我们测试上面描述的图像处理应用程序时,自动化超时有助于检测出一些随机错误。如果一个脚本发生超时,它会自动被标记为失败。结果是,同一个脚本一次又一次地运行,直到通过,这样就可以发现出现在某个确定位置的随机错误。
回归测试提供了两种可能的实现方式:
完全回归
这种回归测试方法包含了覆盖所有产品的回归测试案例。质量团队通常在产品交付流程的最后阶段,或主要版本发布前执行此操作。当产品需要进行显著的功能性或非功能性变更,或这些变更影响基础代码时,也会使用完全回归测试。幸运的是,测试团队不需要编写完整的回归测试套件。他们通常会修改功能性、非功能性、单元和集成测试套件,并选择那些在整个产品交付过程中不断发现错误的测试用例,这些测试用例构成了一个回归测试套件。
虽然冗长、乏味,但这种重新测试的方法非常有效,因为它有助于发现整个应用程序中可能存在的问题。然而,经常进行这类测试是没有意义的,团队通常会在改变开发环境之前运行这类测试。例如上面的图像处理程序,该应用最初是为 iOS8 开发的,因此该团队使用了 XCode6 IDE。但后来客户要求用户在 iOS9 的新设备上运行该产品,这需要切换到 Xcode7。切换后,测试工程师必须运行完整的回归测试,确保在 Xcode6 下的所有特性能继续工作。
而当客户希望拥有完全稳定、满足需求的产品时,可以要求进行完全回归测试。
部分回归
部分回归测试的特征是只包含产品的修改部分和可能受到影响的相关部分。测试团队使用特定的策略,来确保部分回归测试能产生良好的结果。它的主要策略是以风险作为依据,测试工程师挑选出应用程序受到最近变更影响的部分,并从测试套件中选择相关的测试用例。
当产品获得任何类型的新功能时,质量团队可以进一步将这种基于风险的方法应用于回归测试套件。这种方式大大减少了测试时间和工作量,对于以敏捷方式来交付产品的团队来说,如果他们时间紧迫,那么这种方式不失为一种很好的迭代回归测试方案。部分回归还有助于在最终开发阶段重新考虑完整的回归测试套件,并丢弃那些没用的测试用例。
要选择哪一种方法,取决于产品交付过程中变化的范围、方法和阶段。在测试实践中,我们会尽可能坚持基于风险的部分回归测试。
选择合适的回归测试策略,产品开发方法论是要考虑的关键因素之一。对于瀑布方法论,测试是在产品完全开发完毕之后才开始进行的。瀑布过程中的测试通常分为三个阶段:
因此,在瀑布方法论中,稳定性和完全回归是测试的最关键和耗时的部分。
在敏捷开发中,回归测试通常属于上述两种子类型:部分(迭代)回归,覆盖了迭代期间和相关部分的特性;以及在主要版本和部署之前执行完全(主要)回归。然而,为了提高效率,回归测试套件需要进行这样的维护:测试团队应该添加新的相关测试用例,并及时地删除已废弃的测试用例。这种方法大大减少了乏味的测试所花费的时间和精力,并且不会损害产品质量。
无论他们遵循何种方法论(瀑布或敏捷),产品团队还可以选择一些特定的优化方法。
看板方法包括使用产品的仪表板,有助于清晰地可视化工作,并跟踪进度和改进。这样,每个团队成员可以估算他们的工作量,与团队工作联系起来,设定最后期限并确保效率。在瀑布过程中,看板有助于估计达到稳定性所需的时间,并更仔细地规划测试工作。看板仪表板帮助选择迭代回归的测试用例,以及需要进行完全回归的关键时间点。
DevOps 包括持续集成(CI)、持续交付(CD)和持续部署。这种方法很大程度上依赖于自动化:一小部分代码被发送到存储库,其中 CI 确保将代码部分自动集成到一个部署(build)。然后这次部署被发布到临时(staging)环境(CD),然后测试人员运行自动化测试。这种方法极大地减少了与回归有关的问题,从而加速了敏捷项目中的测试和部署。
软件产品包含功能性和非功能性特性,代码的变更会和这两种类型都有关,回归测试也可以被分为两类:
功能回归测试 功能测试包括客户需求、业务逻辑以及产品规格,并验证应用程序是否按预期工作。在这种情况下,回归测试的目的是验证最近的变更没有破坏或影响已经存在的功能特性。
非功能回归测试 回归测试也可以成为非功能测试工作的一部分,以下是几类最常见的需要回归测试的非功能性测试工作:
应对回归测试的最好方法,是设计一个适当的测试策略。它应该包含三个关键要素:
利益相关者需求支配产品的这一特点,为选择正确的回归测试策略奠定了基石。另一个重要的因素是产品规模(小、中、大)。一个好的回归测试策略能减少测试时间和精力、提高产品质量,并使之完全符合顾客的需要。