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

发表于:2010-06-04来源:作者:点击数: 标签:死结应用软件BOSS
打开BOSS应用软件测试的死结[2] 软件测试 打开死结的三个步骤 一、第一步:加强上线前 开发 /集成商的软件测试 关于“新上线的系统BUG过多,功能不稳定”这一点,毋庸置疑就是开发/集成商对新开发的应用软件,没有在系统上线前做足够充分的测试,从而没有在

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

  打开死结的三个步骤

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

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

  1.要做好具体工作

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

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

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

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

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

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

  2.工作落实建议

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

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

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

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

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

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

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