移植（Porting）测试的困惑

近段时间，我的主要工作之一是管理一个移植项目的测试，移植过程包括：从Oracle数据库移植到Informix数据库、从HP-Unix移植到Solaris，上层PC应用基本不变，只需要在数据库访问部分进行部分的代码修改。当然，和所有的移植项目一样，被移植的应用还需要进行一些功能上的调整。
    初看起来，移植项目的测试应该会比普通项目测试简单，因为有下面一些优势：
    1、测试用例可以重用；
    2、需求已明确定义；
    3、系统架构经过了其他项目的考验，一般不需要担心架构的问题；
    4、代码修改不大，可能不需要全面测试。
    但真正开始进行移植项目的测试准备之后，我开始发现，移植测试并不像想象的那么简单：
    1、测试用例可以重用，但需要小心确定可以重用的用例，对不能重用的用例进行修改；
    2、需求已经明确定义了，但需要区分新增、不变、修改的需求（对于修改的需求，有些是系统限制导致的）；
    3、系统架构基本不需要变化，但细节上的变化不少；
    4、代码修改不大，但为了保证代码的一致性（相信我，这个很关键），可能会需要对部分模块的局部设计进行调整，导致需要为移植前的项目进行重新测试；
    5、代码的修改可能分散在许多地方，对系统的影响很难评估，这样的直接后果就是只能对移植后的系统进行全面的测试，测试开销很大。
    MinderFire的网站上有一篇关于移植测试技术的文章：Porting-Test Technique (http://www.mindfiresolutions.com/whitepapers.htm#PortTest)，简单描述了一个移植测试的框架，但这篇白皮书一大部分侧重在界面移植方面，对于我关注的数据库部分的移植只是略略带过，不过其中提到的步骤、移植项目的分层次识别和风险识别策略还是比较有借鉴意义的。
    对我现在的这个项目来说，最头痛的问题包括几个：
    1、数据库的移植；其实在上一个项目（被移植项目）设计的时候，就考虑到了为将来的移植提供便利，因此采用存储过程的方式，访问数据库的应用都只通过存储过程访问，本来这是很好的想法，但在本次移植过程中发现，由于上一个项目（基于Oracle数据库）的存储过程采用了多数据集返回的方式，而Informix并不支持这种方式，导致需要对部分存储过程进行分拆。另外，由于上一个项目的数据库还会有变动，为了保持两边的同步，也需要额外的流程支持；
    2、为了保持代码的一致性，应用部分需要调整设计，对数据库的访问增加一层封装，屏蔽数据库之间的差异，这样一来就将代码修改造成的影响扩散了；
    3、项目的配置项管理；是为所有的工件建立配置项还是为项目建立配置项？一方面想统一，另一方面，统一到工件需要对我们现有的配置管理工作增加部分工作内容，而且，配置项的划分也需要相应调整，总之是工作量比较大。
    4、测试策略；如何确定需要新增的测试用例？如何确定用例的优先级？看来还需要摸索啊。
    摸索中，希望能在这次测试完成后总结一下。