打开BOSS应用软件测试的死结

MILY: 宋体; mso-bidi-font-size: 12.0pt">作为运营商的核心生产系统之一，BOSS系统的稳定性运行非常关键，其每次发生的重大故障都会引起运营商严重的经济损失。而BOSS系统的稳定运行，与应用开发/集成商提供的应用软件本身的稳定性密切相关。甚至可以不夸张地认为，目前国内BOSS系统的大部分稳定性问题，主要集中在BOSS应用软件的不稳定上。

何谓系统的稳定性？无非就是这三方面：系统功能稳定，不要动辄操作失败；系统运行效率好，实时性高；系统运行平稳，不要动辄重启甚至宕机。而要做到这三方面，不对应用软件进行充分的测试,是无法保证的。

那么，为什么BOSS应用软件的测试没有做好？如何解决这个问题？

从运营商的角度理解，是开发/集成商没有对软件进行充分的测试，导致系统出现大量BUG，所以开发/集成商应该加强测试，从而提高自身软件的质量。如果说开发/集成商要提高自身软件的价值，必须首先提高自身软件的质量。这是简单、勿庸置疑的道理。

而从开发/集成商的角度来理解，是运营商的业务需求繁杂多变，开发周期短，难以进行充分的测试即被迫匆匆上线。而且目前BOSS软件的报价一般仅考虑开发成本，无法考虑包括测试环境、测试工具等成本，要搭建这些测试环境、引入这些测试工具将消耗几倍于现在的开发成本，所以无法也无力进行严格的软件测试。要加强测试，提高质量，首先要运营商给予更大的成本空间，否则无法实现。

这是个典型的“鸡”与“蛋”的问题，看起来是个死结，难以解开。本文的目的，就是从分析当前BOSS应用软件测试方面存在的问题入手，立足于实际可操作的角度，对如何打开这个“死结”做出积极探讨。

应用软件不稳定问题总结

在BOSS的实际建设和维护过程中，关于应用软件导致的系统不稳定（主机、存储等设备，数据库、中间件等系统软件导致的不稳定，本文不作讨论），可以大致归结为以下几种。

1.新上线系统的BUG过多，功能不稳定。某个新系统上线后，才发现应用软件的BUG很多，营业员时不时的操作失败，而又不是每次都操作失败，让人难以琢磨该系统的“性格”。

2.新上线业务功能导致原有正常业务功能出错。这可以说是BOSS系统维护中最常发生的不稳定问题，实际上就是新功能开发时，只对新功能进行了测试，而没有对原有功能的影响进行测试，导致上线前没有发现问题，而仓促上线所致。

3.新上线业务越来越多，系统越来越慢，直至系统宕机。这属于典型的性能、压力的测试和分析不够，并进而对系统支撑业务能力估算不足所致。

这三个问题，从另一个角度来看，可以理解为解决当前BOSS应用软件测试问题的三个步骤。首先必须加强上线前开发/集成商的软件测试，建立完整的测试流程和测试环境，这样才能解决新上线系统BUG过多的问题；其次，在此基础上，对每个新上线的业务功能，除了执行新功能本身的测试外，还通过建立丰富的测试用例库来确保执行严格的功能回归测试，才能确保新上线业务没有对原有正常业务功能产生不良影响；最后，有了这些测试流程、测试环境、测试用例库，才可以进行严格的性能测试和分析，为新业务上线对系统荷载造成的影响进行科学客观的分析，从而准确地把握系统实际运行荷载的变化趋势，并进而尽早发现系统支撑能力的“临界点”，最终做到对系统宕机现象的“防患于未然”。

下面将对这三个步骤进行深入的剖析和阐述。

打开死结的三个步骤

一、第一步：加强上线前开发/集成商的软件测试

关于“新上线的系统BUG过多，功能不稳定”这一点，毋庸置疑就是开发/集成商对新开发的应用软件，没有在系统上线前做足够充分的测试，从而没有在上线前发现并解决足够的BUG。如何解决这个问题，在当前现实市场条件下，则需要开发/集成商、运营商双方面的努力。

1．要做好具体工作

为了做好软件测试，开发/集成商需要做好这些具体的工作内容。

1）建立真正完整而务实的测试工作流程。在“玩”测试这个“游戏”之前，首先要确定如何测试的游戏规则。其内容包括：测试工作分为几个阶段；这些阶段的工作内容分别如何与开发对应；在各个阶段，测试人员如何与开发人员交互；测试发现的BUG如何落实解决；测试的争议如何解决；测试环境如何维护；测试的软件版本如何获取；测试版本和开发版本之间又如何交互演进；软件发布的标准如何依赖测试结果等。

2）组建技术、业务均合格并掌握测试方法论的独立测试队伍。设计出一个完整、务实、适应于本企业内部环境和文化的测试流程，只需要依赖企业内部少数熟悉公司内部环境的人才就可实现。而建立合格的测试技术队伍，则需要一个团队的努力，甚至涉及到软件企业文化的改变。这是软件企业当前最难解决的问题。目前的现状，无论是高校还是社会，普遍没有形成有效的软件测试人员的培养经验，甚至连起码的认识都欠缺。

3）引入适当的测试工具软件。一方面，即使针对正在研发中的软件，由于在开发过程中不断引入的变更（发现错误进行的变更，业务需求变化引起的变更等），对于已经测试通过的功能，也需要在每次修改代码后进行回归测试，只有这样才能保证即使在代码不断修改的情况下，软件发布时相应的功能测试仍然是通过的。而这种回归测试的工作量非常之巨，以至于如果完全人工来做，是不可能实际做到的。另一方面，对于像内存泄漏、Core Dump、性能压力等方面测试，如果全部采用人工进行，也将变得非常困难和低效。为此，开发/集成商需要引入相应的自动化测试（包括自动回归、模拟压力、代码分析等）工具，才能真正做好测试。

4）搭建完整的测试环境。没有开发环境就没法开发。同样，没有测试环境就无法测试。测试环境之于开发环境的区别，一方面是测试环境下不会修改任何代码，而是测试人员利用开发人员提交到源代码版本服务器的代码，编译而形成可执行软件，进而进行测绘；另一方面，测试环境下要始终维护着状态一致的业务数据，只有这样才能保证测试用例的完整运行（一般来说，每个测试用例运行完成后，它要保证下次该用例在同样的测试数据上仍然能够运行成功，否则无法执行自动的回归测试）。

5)工程进度紧张的情况下确保测试的完整性。由于实际的市场压力，现有大部分BOSS系统建设的进度压力都非常大，这直接导致软件测试的进度压力也非常大，甚至变得不现实。必须考虑如何结合实际情况，确保在非常紧张的进度压力下，仍然能够开展充分的测试。

2．工作落实建议

第一、二项工作，是开发/集成商无法推卸的责任，而且也是其应该能够解决的问题。至于如何解决，则需要依靠开发/集成商自身在管理上的努力。但一般来说，建立完整务实的测试流程，和组建技术、业务均合格并掌握测试方法论的独立测试队伍，少则1年、多则2、3年才能真正实现。

第三个引入测试工具软件的工作，存在这样的落实难点：限于当前国内应用软件的现实价格平，开发/集成商一般无力承担这些测试工具的昂贵代价（根据一般的BOSS软件开发队伍规模，其至少三、四十人以上，需要购买的测试工具license价格动辄上百万美元。而目前BOSS应用软件的总体价格，不过才几十万美元。），如Mercury的WinRunner/ LoadRunner/ TestDirector系列等，或IBM的Rational系列工具等。实际上，直至今日，甚至很多开发/集成商连开发工具都是依赖运营商去购买的。比较现实的建议，还是通过运营商采购、开发/集成商使用的方式来解决这个矛盾。当然，具体采用哪些工具，采用什么样的测试工作流程，这是需要开发/集成商来提出方案，并由运营商认可的。

第四个搭建测试环境的工作，与测试工具软件类似，相对于目前应用软件的现实价格，这些设备和软件的价格都太昂贵，开发/集成商目前根本无力承担购买和维护一套这样的完整环境的代价。因为测试环境涉及到UNIX主机、存储、网络等昂贵的硬件设备，而且开发/集成商要开发运行于各种主流UNIX主机平台的应用软件，还必须拥有各种主流的主机台，才能真正解决问题。这个问题，同样只有通过运营商来解决。建议可以在设计BOSS系统方案时就考虑到这部分设备的提供，这样，就可以让开发/集成商的开发测试依赖于运营商提供的测试环境。

根据以往的BOSS系统建设经验，一方面往往在系统建设方案中对测试环境所需要的设备、系统软件的考虑不足，另一方面也没有严格区分开发环境和测试环境的区别。为了做好这个工作，建议运营商和开发/集成商在系统方案设计之初，就充分考虑这部分投入。一般来说，相对运行环境，只需要考虑一个按比例缩小的、具有典型代表意义的测试环境方案即可。

事实上，关于第三、四两个问题的实际解决，目前国内已经不乏这样的成功操作案例。

最后一个关于测试进度压力的问题，我们稍微研究即可发现：一般来说，由于测试主要侧重于“黑盒”测试，而“黑盒”测试必须依赖于软件集成成功的基础上，为此就造成了测试往往都是在开发结束后才开始，而这时往往都快要到系统上线时间了，这就导致了测试进度被压缩再压缩、测试内容被简化再简化的情况出现。那么，是否有什么方法可以让测试进度尽可能提前？近几年发展起来的极限编程理论中，有一个现成的方法可以解决该问题——持续集成。而这个方法，在微软等著名软件公司其实很早就有了很长时间、针对大型软件项目的成功运用经验（在微软它被称为“每日编译”）。对于BOSS系统的建设，建议也采用这种方法论来执行测试，从而通过尽可能早地开始软件测试，来确保紧张进度压力下的充分测试。

二、第二步：通过回归测试确保新业务上线

所谓“新上线业务功能导致原有正常业务功能出错”，实际上就是“回归测试”做得不够，或者说，回归测试就是为了预防这种问题的发生才被提出来。

1．要做好的具体工作

严格来说，软件开发/集成商正式发布的软件，在经过大量的测试后，会形成一个针对该软件的测试用例库，其中的测试用例覆盖了现有的全部软件功能。而当增加一个新业务功能，针对该新业务功能本身，固然要做测试，但为了验证该新业务功能的代码或配置信息是否对原有功能产生消极影响，还必须经过完整的回归测试。从实际操作的角度来看，开发/集成商和运营商需要这些具体工作。

1）开发/集成商建立完整的测试用例库，并执行自动化的回归测试。为了确保新业务上线，能对原有功能执行严格的回归测试，必须能将回归测试自动化，并且这种自动化是依赖于原有功能的完整测试用例库的基础之上。没有完整、涵盖原有软件所有功能的测试用例库，就不可能知道要执行哪些回归测试；没有对回归测试自动化，不可能手工执行工作量如此巨大的回归测试，也就不可能真正做到“严格”。

2)营商搭建完整的回归测试环境，并执行必要的回归确认测试。一般来说，运营商在新业务功能上线前，均会对新业务功能本身进行确认测试。但即使在开发/集成商做过严格的功能回归测试后，运营商仍然还需要对其进行必要的回归确认测试，尤其是针对相关联的业务功能来说更加如此。实际上，回归确认测试工作量往往数倍于新功能本身的确认测试，所以这部分工作不能忽视。

2．工作落实建议

第一个工作实际上是以第一步“加强上线前开发/集成商的软件测试”的所有工作内容为基础。没有完整而务实的测试工作流程，就不可能有完整的测试用例库；没有自动化回归测试工具，就无法录制这些测试用例的自动化回归测试脚本（开发/集成商自行编码实现自动回归测试，工作量一样很大，不现实），也就不可能进行严格的回归测试（对于BOSS这样的大型应用软件，回归测试是不可能通过手工测试能够做好的）。做不到第一步中的五点工作内容，“执行严格的回归测试”将会成为一句空谈。

第二个工作，一方面需要运营商提供设备、开发/集成商负责搭建并维护一套完整的测试环境。另一方面，作为客户，运营商在安排新业务功能的确认测试工作量和工作时间时，要充分考虑到回归确认测试。如果不承认这个必要的工作，往往不可避免会出现“新上线业务功能导致原有正常业务功能出错”这样的问题。

三、第三步：通过性能测试保证系统支撑能力

1．要做好的具体工作

之所以出现系统性能越来越差，越来越慢，直至某天系统开始宕机这样的现象，完全是因为随着系统新业务功能的不断开通，以及系统支撑用户量、数据量的增长，没有量化地把握系统支撑能力变化趋势，从而无法掌控系统支撑能力的发展所致。为此，需要做好以下这些工作。

1)对新上线业务功能执行量化的性能测试和分析。由于缺乏新上线业务功能对生产系统产生多大影响的量化性能测试和分析结果，所以无法把握新功能所消耗部分的系统资源所代表的设备成本。而通过对所有新上线业务功能的量化性能测试和分析，就可以做到心中有数，准确地掌控系统荷载情况的变化趋势，从而及早地预测出系统支撑能力的“临界点”。

2)及时对新业务发展或系统支撑能力做出调整。仅仅有了上述的工作基础，仍然不能彻底解决问题，还需要将这些量化的数据作为决策的依据，是在系统支撑能力限制下有选择的调整新业务的实现方式，还是及时、有计划地扩充系统支撑能力，都是必须要执行的工作内容。

2．工作落实建议

对于第一项工作，在运营商提供完整测试环境和工具软件的前提下，开发/集成商应当在运营商的明确要求下，认真落实执行这个工作要求，并定期向运营商提交量化的测试分析数据，以及针对业务实现方式或系统扩容的实际可行的调整建议。

在开发/集成商做好第一个工作内容的基础上，运营商要做到的，就是及时关注这些测试分析数据和调整建议，并有计划地安排和落实执行。只有这样通过双方的共同努力，才能确保应用系统的真正稳定可靠运行。

总结

总的来说，切实做好第一步工作，或者说解决好第一个问题，才是打开BOSS应用软件测试死结的关键所在。没有了第一步的落实执行，后两步的工作缺乏基础，就显得空洞而不务实。而做好第一步的工作，关键是开发/集成商和运营商双方面的努力：一方面开发/集成商要在管理上建立完整而实用的测试流程并确保执行，和培养合格的测试队伍；另一方面运营商要在系统建设之初就充分考虑测试环境方案，以及要求开发/集成商引入并使用好相应的自动回归和性能测试工具。

原文转自：http://www.ltesting.net