第三个引入测试工具软件的工作，存在这样的落实难点：限于当前国内应用软件的现实价格平，开发/集成商一般无力承担这些测试工具的昂贵代价（根据一般的BOSS软件开发队伍规模，其至少三、四十人以上，需要购买的测试工具license价格动辄上百万美元。而目前BOSS应用软件的总体价格，不过才几十万美元。），如Mercury的WinRunner/ LoadRunner/ TestDirector系列等，或IBM的Rational系列工具等。实际上，直至今日，甚至很多开发/集成商连开发工具都是依赖运营商去购买的。比较现实的建议，还是通过运营商采购、开发/集成商使用的方式来解决这个矛盾。当然，具体采用哪些工具，采用什么样的测试工作流程，这是需要开发/集成商来提出方案，并由运营商认可的。
第四个搭建测试环境的工作，与测试工具软件类似，相对于目前应用软件的现实价格，这些设备和软件的价格都太昂贵，开发/集成商目前根本无力承担购买和维护一套这样的完整环境的代价。因为测试环境涉及到UNIX主机、存储、网络等昂贵的硬件设备，而且开发/集成商要开发运行于各种主流UNIX主机平台的应用软件，还必须拥有各种主流的主机台，才能真正解决问题。这个问题，同样只有通过运营商来解决。建议可以在设计BOSS系统方案时就考虑到这部分设备的提供，这样，就可以让开发/集成商的开发测试依赖于运营商提供的测试环境。
根据以往的BOSS系统建设经验，一方面往往在系统建设方案中对测试环境所需要的设备、系统软件的考虑不足，另一方面也没有严格区分开发环境和测试环境的区别。为了做好这个工作，建议运营商和开发/集成商在系统方案设计之初，就充分考虑这部分投入。一般来说，相对运行环境，只需要考虑一个按比例缩小的、具有典型代表意义的测试环境方案即可。
事实上，关于第三、四两个问题的实际解决，目前国内已经不乏这样的成功操作案例。
最后一个关于测试进度压力的问题，我们稍微研究即可发现：一般来说，由于测试主要侧重于“黑盒”测试，而“黑盒”测试必须依赖于软件集成成功的基础上，为此就造成了测试往往都是在开发结束后才开始，而这时往往都快要到系统上线时间了，这就导致了测试进度被压缩再压缩、测试内容被简化再简化的情况出现。那么，是否有什么方法可以让测试进度尽可能提前？近几年发展起来的极限编程理论中，有一个现成的方法可以解决该问题——持续集成。而这个方法，在微软等著名软件公司其实很早就有了很长时间、针对大型软件项目的成功运用经验（在微软它被称为“每日编译”）。对于BOSS系统的建设，建议也采用这种方法论来执行测试，从而通过尽可能早地开始软件测试，来确保紧张进度压力下的充分测试。
二、第二步：通过回归测试确保新业务上线
所谓“新上线业务功能导致原有正常业务功能出错”，实际上就是“回归测试”做得不够，或者说，回归测试就是为了预防这种问题的发生才被提出来。
1．要做好的具体工作
严格来说，软件开发/集成商正式发布的软件，在经过大量的测试后，会形成一个针对该软件的测试用例库，其中的测试用例覆盖了现有的全部软件功能。而当增加一个新业务功能，针对该新业务功能本身，固然要做测试，但为了验证该新业务功能的代码或配置信息是否对原有功能产生消极影响，还必须经过完整的回归测试。从实际操作的角度来看，开发/集成商和运营商需要这些具体工作。
1）开发/集成商建立完整的测试用例库，并执行自动化的回归测试。为了确保新业务上线，能对原有功能执行严格的回归测试，必须能将回归测试自动化，并且这种自动化是依赖于原有功能的完整测试用例库的基础之上。没有完整、涵盖原有软件所有功能的测试用例库，就不可能知道要执行哪些回归测试；没有对回归测试自动化，不可能手工执行工作量如此巨大的回归测试，也就不可能真正做到“严格”。
2)营商搭建完整的回归测试环境，并执行必要的回归确认测试。一般来说，运营商在新业务功能上线前，均会对新业务功能本身进行确认测试。但即使在开发/集成商做过严格的功能回归测试后，运营商仍然还需要对其进行必要的回归确认测试，尤其是针对相关联的业务功能来说更加如此。实际上，回归确认测试工作量往往数倍于新功能本身的确认测试，所以这部分工作不能忽视。
文章来源于领测软件测试网 https://www.ltesting.net/
