如何测试遗留系统？

      如何测试遗留系统？

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

　　系统晦涩难懂，可读性可理解性很差。理解原有系统往往占据了进行一个修改的大部分时间。

　　系统设计僵化，改动困难，一个小修改，会迫使系统很多部分的改动。

　　系统难以重用，大多软件单元缺乏可重用性。

　　系统脆弱，引入一个小功能会引入几个缺陷，修复一个缺陷又引起几个新缺陷。

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

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

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

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

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

　　首先，“非热点”区域，也就是暂时稳定的区域，在初期并不是最值得投入为其建立测试的。例如，有个Web系统，它有两个相对独立的组件，一个是社区，另一个是网店，如果前者是热点区域而后者不是，那么前者就更有价值在初期投入建立测试。

　　其次，遗留系统的脆弱性往往体现在“Bug重复出现”、“解决一个Bug，出现两个Bug”等情形。针对这些活跃区域添加测试可以对它们起到保护作用，减少出现上述情况出现的机会;同时，也是对这块区域的一个重构契机。

　　同时，选择合适粒度的测试也很重要。各类测试自己的优点，例如集成测试在功能保护上体现效果更快;而单元测试却会驱动内部质量的提升。如果条件允许，选择多 种粒度的测试结合，别忘了之前提到的测试金字塔。我们无法为整个系统一下子建立完善的测试，但为某一个区域，是有可能的。

　　功能测试处于测试金字塔的上端，它的稳定性相对较低，维护成本也较高。因此写功能测试一定要关注提升它的稳定性，并降低维护成本，遗留系统在这几个方面遇到的挑战可能会更大。

　　但在遗留系统中，有时会碰上更严峻的问题，系统依赖于第三方或其他不在控制范围内的测试系统。功能测试会影响到测试数据，因此我们的测试很有可能无法重复执 行。当然，建立一个测试替身系统是一种选择方案，但有时并不容易，至少短期之内。面对这种情况，我们的解决方案是让测试程序和测试数据解耦。想象一下，如 果同样的测试由一个软件测试工程师手工执行，每次执行时不需要选择相同的数据，而只需选择“符合同样要求”的数据。

      遗留系统的测试也是软件测试中的重点，希望大家能够好好的学习。

转载于:https://www.cnblogs.com/liyuchen8908/archive/2013/05/15/3079988.html