以自动化测试撬动遗留系统

发表于:2015-04-24来源:uml.org.cn作者:不详点击数: 标签:自动化测试
面对遗留系统,选择合适的测试策略,能让自动化测试的投入在一定时期内看到效果,并且建立可持续进行的机制。同为自动化测试,每种测试在面对遗留系统时遇到的挑战是不同的,

面对遗留系统,选择合适的测试策略,能让自动化测试的投入在一定时期内看到效果,并且建立可持续进行的机制。同为自动化测试,每种测试在面对遗留系统时遇到的挑战是不同的,起到的效果也不尽相同。
背景

我目前所服务的企业大部分系统是遗留系统,其中多数处于相对需求平稳阶段,即需求并不多,也没有大需求。但这些系统牵制了和需求所需人力不成比例的大量人力,从系统本身的原因看,有这么几点。

  • 系统晦涩难懂,可读性可理解性很差。理解原有系统往往占据了进行一个修改的大部分时间。
  • 系统设计僵化,改动困难,一个小修改,会迫使系统很多部分的改动。
  • 系统难以重用,大多软件单元缺乏可重用性。
  • 系统脆弱,引入一个小功能会引入几个缺陷,修复一个缺陷又引起几个新缺陷。

投入大量人力,产生的价值却微乎其微。面对激烈的市场,同质化的竞争,成本和质量问题日益凸显。而所谓遗留系统,即没有自动化测试保护的系统。客户很希望通过引入“自动化测试”来提升系统质量,最终帮助他们建立自动化测试机制。

过去几个月里,我先后投入到几个遗留系统的自动化测试提升工作中。这些工作都进展不错,很多系统的核心模块都有了自动化测试的覆盖。另外,这次专门针对“遗留系统”所做的自动化测试工作,也带给我一些新想法:自动化测试,很可能是我们撬动遗留系统的一个支点。

测试策略选择

图1是测试金字塔模型,从上至下分别是验收测试、API测试、集成测试和单元测试。你可以有不一样的分类,但从上至下,测试粒度越来越小,测试数量越来越多。一个具备完善自动化测试的系统,应该具备类似的测试分布。

图1 测试金字塔模型

当我们面对的是遗留系统时,追求理想模型肯定是不现实的,那么应该选择何种测试策略呢?

每 个遗留系统的状况都不尽相同,可能选择的策略也会不一样。但有一点是一致的——所有的测试都不是没有成本的,在人力并不宽裕的情况下,必须让测试投入“值 回票价”。而且,必须让测试投入到短期最有价值的地方,才能让团队尽快看到效果和建立信心。我们选择的策略之一是:快速建立稳定性较高的功能测试防护墙, 以此保护系统的核心功能不被任意破坏。这里有两个关键点。

  • 快速,要选择可以快速建立的测试,让一定的价值在短期之内就能得到体现。
  • 稳定,指的是测试本身的稳定——不因系统变化而对测试产生太大的冲击,因而维护成本也就相对较低。

这里的功能测试可以是验收测试、API测试或集成测试,根据每个系统的情况选择更好满足上面两个关键点的测试类型。

例如,我们曾面对一个Web系统,大部分页面逻辑比较简单,主要是呈现内容;前端通过REST接口跟业务后台交互数据。刚开始我们选择基于 WebDriver的验收测试,但随后即发现这类测试编写成本较高,需要学员掌握较多技能,无法在短期内快速为整个系统建立一个防护墙;另一方面,它的稳 定性也较低,测试较易受到页面布局的影响,维护成本较高。在这种情况下,最后我们转而选择了基于REST接口的测试,因为它的建立成本更低,稳定性也更高 (REST接口变化较少),而且也可以覆盖所有核心功能,相比而言,是个更好的选择。

我们还选择了另一个策略:针对热点区域(包括需求热点和缺陷热点等)添加测试。选择这些区域主要基于两点理由。

  • 首先,“非热点”区域,也就是暂时稳定的区域,在初期并不是最值得投入为其建立测试的。例如,有个Web系统,它有两个相对独立的组件,一个是社区,另一个是网店,如果前者是热点区域而后者不是,那么前者就更有价值在初期投入建立测试。
  • 其次,遗留系统的脆弱性往往体现在“Bug重复出现”、“解决一个Bug,出现两个Bug”等情形。针对这些活跃区域添加测试可以对它们起到保护作用,减少出现上述情况出现的机会;同时,也是对这块区域的一个重构契机。

    原文转自:http://www.uml.org.cn/Test/201305025.asp