bnv

发布新日志

  • 转载频繁的版本变更

    2008-11-10 13:44:11

    我答“测试过程中如何应对频繁的版本变更?”

    2008-03-04 17:54:13

    51testing本周的问题:测试过程中如何应对频繁的版本变更?

    http://bbs.51testing.com/thread-107290-1-1.html

    在软件开发过程不规范的项目组中,这种情况是非常常见的。2001年,我接触过的一个公司,它刚刚成立软件测试部,当时的测试部遇到的情况和上面讲的几乎如出一辙,搞得测试员叫苦不迭,开发部的程序员也天天抱怨头疼。

    具体到当前这个项目遇到的情况,从上面的问题分析,我认为主要原因是:开发部提供的测试版本太过随意,导致质量太差。要解决它,我认为有以下几个关键点:

    ×在项目开始时,最好能先开发一个原型出来,原型基本上要确定整体界面的风格、统一的操作习惯等,以后的开发要以原型为基础进行;

    ×开发部使用版本控制工具,比如CVS、VSS等,并且要保证每天定时Check-in和Check-out,避免积累大量代码,同时要强调在Check-out和Check-in的时候要注明缘由,是为了修改某个bug还是增加新功能等;

    ×每日构建(Daily Build):每日构建要形成制度,构建过程最好能自动进行,如果因为是第一次这样做,没有经验,遇到技术问题,在这种情况下,建议由测试部指派一名测试员加入到开发部,协助开发部进行人工构建,每日能集成一个能运行起来的完整的软件系统;

    ×强化冒烟测试(Smoke testing):加入开发部的测试员在构建后,集成了一个完整的软件系统,要及时对每一个build进行验证(Build Verification Test ),也可以称之为“冒烟测试”,对软件的基本功能点进行验证;

    ×强化测试的准入条件:软件测试启动是有条件的,并不是说开发部拿个软件过来,开发部就要测试,比如要启动测试活动,必须要有需求规格说明书、设计书、单元测试报告、冒烟测试报告等,这是前提。满足不了这个前提条件,测试活动不会启动。当然这个制度需要公司管理高层的认可,在项目启动时要和项目经理协调好的;

    ×强化BUG管理:测试组要使用BUG管理工具,例如bugzilla、JiRA等,要保证 bug、版本、以及人员的对应关系,同时分析在不同的版本、不同的时间段、不同的模块中BUG的走势,确定“危险模块”为重点测试对象,预测未来的BUG走势和工作量等。

    ×积极的态度:无论是开发部还是测试部,在这个困难的过程中都要有积极的态度,遇到问题要及时沟通,以最高效的方式解决问题。

    要从根本上根治这种矛盾,需要一套完整的、规范的开发过程。以上的措施只是一部分,只能在最短的时间内缓解矛盾。

  • 一点感悟

    2008-08-25 09:26:35

    以前喜欢逛论坛,最近喜欢上逛博客.看看测试同行们的感悟.自己今天就深受感触.

    一位高人说到,他非常害怕的就是测试被开发说服,当然测试被说服有一个重要原因是能力上不足的一个体现,但关键是不要轻易被说服,在遇上这类问题时,一定要多沟通,多方面验证,不要轻易的就放弃!

     

  • 测试部

    2008-04-16 17:08:44

    今天老总打电话让我过去!有点紧张,不知道是有什么事情 !他说测试部5月份成立,自己下去准备准备阿!

    晕阿!5月份正好赶上手头负责项目的正式集成测试!不知道自己能不能带好这个测试部!心里没底!

    只能告诉自己努力吧!人生现在不拼,更待何时!

    努力努力努力

Open Toolbar