谈项目管理和软件测试过程

谈项目管理和软件测试过程1.软件测试在公司的组织保障是基础1.1研发部组织结构介绍以华友公司研发部的组织结构为例，测试部门属于研发部副总裁直接管理，公司研发部的组织结构图#FormatImgID_0#对于从事软件研发的组织来说，工作类型至少包括项目管理、产品设计、编码、测试、质量保证和软件配置管理，以及其它人员，如文档编制人员和美工人员/系统硬件管理人员等。根据职能需要，可以以半独立方式进行部门和项目的矩阵管理，即职员要对项目经理/组长负责，也要对部门经理/总监负责，工作考核由双方共同完成，标准的组织应包括技术开发部/组（主要是编码和设计人员），产品开发部/组（产品需求和项目管理），测试部/组，配置管理部/组（因为配置管理人员基本上是按20个技术人员配一个配置管理人员，所以一般部门规模较小，或者只是配置管理组），软件质量保障部/组，其它部/组（如系统/文档/美工等）。华友公司组织结构中，研发部是公司软件研发的核心部门产品研发Ⅰ部、Ⅱ部、和应用研发部主要负责：与软件产品部或内容产品部配合，协助完成内容产品的可行性、合理性分析；平台、网关、应用产品的研发项目的立项和方案评审；研发项目的概要设计、详细设计工作；研发项目的编码、单元测试工作；组织公司相关部门进行研发产品的培训；协助相关部门做好产品的售前技术支持工作；协助相关部门进行软件的安装与调试；根据相关部门的要求做好产品的售后服务工作，保障软件的运行正常。测试部隶属研发部，主要职责如下：与内容产品部和软件产品部配合完成软件需求分析讨论，并根据需求说明书制订《项目测试方案》，编写《测试用例》，建立测试环境；负责完成研发部各开发组研发的软件产品开发过程和投入运营之前的新增软件和修改升级软件的模块测试和系统测试；建立、推广并维护实施软件版本管理系统CVS和VSS；使用并维护软件缺陷管理系统Bugzilla，负责软件问题解决过程跟踪记录；负责推广实施软件开发文档规范化工作，管理研发产品相关文档；负责配合软件运维部门等对于新业务软件或修改升级业务软件的上线测试工作，并提供上线测试报告；负责监督软件开发流程的执行，并负责提出软件开发过程改进建议，提高软件产品质量。1.2软件产品研发各部门的组织结构分解1)华友公司从2003年10月开始，对项目组制订明确指标的独立考核，各开发部门是技术总监带队，再细分各项目经理具体负责项目计划和执行，对项目具体开发成员进行分工。对于测试部门制订年度测试部门任务计划/考核表，如SMS业务销售额指标完成：目标1：9900万（奖金提取比例为0.01％）；目标2：16800万（奖金提取比例为0.02％）；目标3：23200万（奖金提取比例为0.03％）详细给出财务目标和业务运营目标。在每周的开发经理工作会议上交流报告任务进展情况，并提出最近测试需求，测试部门经理负责制订测试计划、测试用例和测试实施方案，安排测试工程师与对应的开发人员交流完成测试执行工作。测试部经理负责开发流程管理和人力资源、测试用软硬件资源调配，需要与研发之外的部门定期交流掌握下周或近期可能测试任务，所有其他外部接口都由测试部经理负责完成，与其他项目组和产品部门协调项目进度。2)工作汇报关系为:开发部门：TeamMember-TeamLeader-研发总监-研发部副总裁-总裁。测试部门：测试工程师-测试小组经理-测试部经理/总监-研发部副总裁-总裁。3）项目成员结构：公司通常的开发项目组为6到8个开发人员，最多不超过10人。华友公司的经过三次改造后的组织结构和项目组结构，各个业务部门分类非常细，任务明确，软件开发的每一个步骤都有专门的部门、专门的人员负责，从最基础的开发人员到负责统领全局的总监和副总裁，层层管理，沟通渠道畅通。而在软件测试上，由于有限的测试资源，首先体现在公司的组织结构上，集中表现为测试部门不得不面对公司级管理部门的缺失和管理的交叉上，没有质量管理部门，部门质量管理工作测试部门兼做。公司从成本角度考虑，测试部门规模较小，测试人员总数不超过10人，几乎每个测试人员接收处理10个开发人员的测试任务需求。从实际情况出发，首先明确测试部门和软件开发部门相对独立的组织关系，保证测试人员的工作不受开发小组的控制，实现测试客观、公证。华友公司要想有效地保障产品质量，首先就要在构架合理的组织结构和测试流程上下功夫，这就如同盖高楼首先要打好地基一样，地基不打牢，结构和流程不合理，其他方面再下功夫也是徒劳。从实践经验看，一年前首先成立测试部，把属于开发部门的测试工程师归口到独立的测试部门管理，其次建立规范的测试流程，与开发部门交流，要求每周提出测试需求，再根据现有的资源制订每周测试计划，同时向人力资源部门提出招聘计划，随着测试工作的成绩不断被开发部门和上级领导认可，再推广实施软件开发过程规范化的管理，通过测试实践的优良成绩来确立测试部门在公司的地位和作用，经过一年的奋斗测试部门从无到有，从最初两人到现在十人，软件配置管理和缺陷跟踪系统已经被60%的开发人员自愿使用和接收。总结本人在华友一年多测试工作经验，深深体会到在国内从事软件项目开发难、从事软件测试和质量保证工作更难，需要具备扎实的技术功底同时，不断提高测试项目管理能力，寻找工作的突破口。世上无难事，只怕有心人，但是只要你努力献身于软件测试工作，打出一片天地是有可能的。2.配置管理系统是项目经理的眼睛，是软件测试有效实施的前提在软件质量体系的诸多支持活动中,配置管理系统处在支持活动的中心位置,它有机地把其它支持活动结合起来,形成一个整体,相互促进,相互影响,有力地保证了质量体系的实施。建立公司配置管理系统很容易得到公司领导层的支持，几乎没人反对。更重要的是建立配置管理系统后测试人员的工作有了系统保证，测试工作的矿藏资源有了明确的位置，可以主动积极开展测试工作。2.1项目管理存在的主要问题华友公司测试部门去年刚成立时，以建立、规范和推广使用配置管理系统CVS为突破口，同时建立缺陷跟踪系统Bugzilla提高测试流程的管理水平。我做为测试负责人首先分析华友公司几个软件项目在开发管理上的现状,。存在问题一、公司几个核心项目仍然过分分依赖少数个人的作用,没有建立起协同作战的氛围,没有科学的软件配置管理流程;技术上只重视系统和数据库、开发工具的选择,而忽视配置管理工具的选择,导致即使有些项目有配置管理的规程,也由于可操作性差而搁浅。以上种种原因导致开发过程中普遍存在如下一些问题:调查说明华友研发成员的变动的比率达到30%，几乎每周都有新加入的员工或者辞职人员，一个新成员熟悉项目的最佳途径就是通过配置管理系统阅读项目文档，甚至阅读同行代码，达到快速学习、共同提高的目的。一个辞职人员可以利用配置管理系统保留部分一段时间工作，最大程度减少对项目开发造成的损失。存在问题二、开发管理松散。领导了解工作完成情况重视口头交流，忽视书面文档。有些部门主管无法确切得知项目的进展情况,项目经理也不知道各开发人员的具体工作,项目进展随意性很大,可左可右。左时按领导下达的期限进行,到期时,似乎一切已顺利完成,大家一阵胡弄,交差完成,反正领导看的是界面,至于里面是什么,留到施工时再说。施工时的工作因此变成了无法汇报、无法理清的无休止的维护。右时则项目工期无休止地延期。对我们软件工程来说,总的特点是先左后右。在领导面前表现左,在用户面前表现右。有个测试人员经常利用上班时间学习英语，过了一个多月，看她依然如此，我做为项目领导进行批评教育，这名员工并不认为自己错了，她争辩，公司采取弹性工作时间，考核员工是分配的任务是否完成等理由。同时、我对她批评结果遭到她的恶意报复，她给有关领导报告新来的经理如何不懂公司业务，采取不适合公司的管理方式等，由于领导无法了解真相，使得我的工作在一段时间开展很困难，直到过去半年，这名员工辞职出国学习领导才明白发生了什么。存在问题三、项目之间沟通不够。各个开发人员各自为政,每个项目经理都像个地主，编写的代码不仅风格各异,而且编码和设计脱节。每个项目组的人力资源和硬件资源成了私有财产，自己人员即使暂时空闲，让他从事所谓的新技术研究，也不考虑友邻项目需要他们帮助的现状。本来开发中错误在所难免,进展早一点的项目组或者人力资源强的项目组已经积累类似问题的解决经验，也不愿意分享给其它项目组。开发大量重复,留下大量难维护的代码。典型案例是有个短信项目D两年来在这个开发人员Y的研发支持下运转效益很好，但是三个月之前，开发人员Y因为待遇问题和公司领导谈判失败，提出辞职。项目D仍然在运行，但是最近移动公司规范修改、系统升级，需要修改程序，没人能看到及时更新的文档，尽管有一堆代码库，但是后来的程序员都没办法分析明白程序结构。公司领导出面请开发人员Y来协助，因为没有文档记录，Y忙于新公司的工作也不能解决修改。存在问题四、文档与程序严重脱节。软件产品是公司的宝贵财富,代码的重用率是相当高的,如何建好知识库,用好知识库对公司优质高效开发产品,具有重大的影响。但开发人员的一句名口号是:叫我干什么都可以,但别叫我看别人的程序。当然,开发人员的工作态度要转变,但客观上有一个很重要的原因是:前人留下的程序既无像样的文档(即使留下了文档,其与源程序也严重脱节),开发风格又不统一,就像一堆垃圾,要开发人员到垃圾中去捡破烂,从这个角度上看,开发人员的要求是合理的。存在问题五、测试工作不规范。仍然停留在小姑娘做测试的底水平上，传统的开发方式中,测试工作只是人们的一种主观愿望,根本无法提出具体的测试要求,加之开发人员的遮丑,测试工作往往是走一走过场,测试结果既无法考核又无法量化,当然就无法对以后的开发工作起指导作用。存在问题六、虽然项目施工时间不长，但软件版本更新周期过短,几乎每天都修改在线运行系统，且开发人员必须亲自现场或远程登陆操作，全国十几个地点软件内容多少都有点差别，这些差别都记录在几个骨干人物的脑袋里。由于应用软件的特点,各个不同的施工点有不同的要求,开发人员要手工地保持多份不同的拷贝,即使是相同的问题,但由于在不同地方提出,由不同人解决,其做法也不同,程序的可维护性越来越差。久而久之,最后连自已都分不清楚了,代码的相互覆盖现象时有发生,且这苦水还无法倾诉,因为怕别人笑话,甚至别人问起,还得想法搪塞,可谓费尽苦心。2.2建立配置管理系统,规范项目管理流程，建立知识库的同时节约项目费用针对以上问题,利用自己在BeijingPrecomInc,普天润汇等公司积累的经验，建立配置管理系统CVS,CVS的全称是CurrentVersionControl.CVS是一种GNU软件包.由Intersolv公司开发，它明确的将源文件的存储和用户的工作空间独立开来,并使其有利与并行开发.这个工具属于OpenSource，,CVS可以在intenet上很方便的得到.它的源码在它的说明文档在任何人可以很方便的下载.目前他的最新版本是2..10.8。不需要花钱，很快建立，重点在于使用和推广。配合项目经理共同制定相应的配置管理策略,取得了很好的成效。2.2.1.节约费用(1)缩短开发周期利用CVS对程序资源进行版本管理和跟踪,建立公司的代码知识库,保存开发过程中每一过程版本,这样大大提高了代码的重用率,还便于同时维护多个版本和进行新版本的开发,防止系统崩溃,最大限度地共享代码。同时项目管理人员可以通过Version系统查看项目开发日志,测试人员可以根据开发日志和不同版本对软件进行测试,工程人员可以从版本控制系统上得到不同的运行版本,并且可以安装在WebServer或在Unix操作系统上命令行方式存取供外地施工人员存取最新版本,无需开发人员亲临现场。利用CVS系统,可以大大提高开发效率,避免了代码覆盖、沟通不够、开发无序的混乱局面,如果利用了公司原有的知识库,则更能提高工作效率,缩短开发周期。(2)减少施工费用利用CVS进行软件配置管理后,建立开发管理规范,把版本管理档案挂接在公