谈项目管理和软件测试过程.docx
- 文档编号:11008465
- 上传时间:2023-05-28
- 格式:DOCX
- 页数:26
- 大小:81.50KB
谈项目管理和软件测试过程.docx
《谈项目管理和软件测试过程.docx》由会员分享,可在线阅读,更多相关《谈项目管理和软件测试过程.docx(26页珍藏版)》请在冰点文库上搜索。
谈项目管理和软件测试过程
谈项目管理和软件测试过程
(一)
1.软件测试在公司的组织保障是基础
1.1研发部组织结构介绍
以华友公司研发部的组织结构为例,测试部门属于研发部副总裁直接管理,见如下结构图
公司研发部的组织结构图
对于从事软件研发的组织来说,工作类型至少包括项目管理、产品设计、编码、测试、质量保证和软件配置管理,以及其它人员,如文档编制人员和美工人员/系统硬件管理人员等。
根据职能需要,可以以半独立方式进行部门和项目的矩阵管理,即职员要对项目经理/组长负责,也要对部门经理/总监负责,工作考核由双方共同完成,标准的组织应包括技术开发部/组(主要是编码和设计人员),产品开发部/组(产品需求和项目管理),测试部/组,配置管理部/组(因为配置管理人员基本上是按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上很方便的得到.它的源码在ftp:
//202.113.29.4/pub1/unix/cvs它的说明文档在ftp:
//202.113.29.4/doc/cvs.任何人可以很方便的下载.目前他的最新版本是2..10.8。
不需要花钱,很快建立,重点在于使用和推广。
配合项目经理共同制定相应的配置管理策略,取得了很好的成效。
2.2.1.节约费用
(1)缩短开发周期
利用CVS对程序资源进行版本管理和跟踪,建立公司的代码知识库,保存开发过程中每一过程版本,这样大大提高了代码的重用率,还便于同时维护多个版本和进行新版本的开发,防止系统崩溃,最大限度地共享代码。
同时项目管理人员可以通过Version系统查看项目开发日志,测试人员可以根据开发日志和不同版本对软件进行测试,工程人员可以从版本控制系统上得到不同的运行版本,并且可以安装在WebServer或在Unix操作系统上命令行方式存取供外地施工人员存取最新版本,无需开发人员亲临现场。
利用CVS系统,可以大大提高开发效率,避免了代码覆盖、沟通不够、开发无序的混乱局面,如果利用了公司原有的知识库,则更能提高工作效率,缩短开发周期。
(2)减少施工费用
利用CVS进行软件配置管理后,建立开发管理规范,把版本管理档案挂接在公司内部的Web服务器上,工程人员可以通过远程进入内部网,获取所需的最新版本。
开发人员无需下现场,现场工程人员通过对方系统管理员收集反馈意见,书面提交到公司内部开发组项目经理,开发组内部讨论决定是否修改,并作出书面答复。
这样做,可以同时响应多个项目点,防止开发人员分配到各个项目点、分散力量、人员不够的毛病,同时节约大量的旅差费用。
2.2.2.有利于知识库的建立
(1)代码对象库
软件代码是软件开发人员脑力劳动的结晶,也是软件公司的宝贵财富,长期开发过程中形成的各种代码对象就像一个个零件坯一样,是快速生成系统的组成部分。
长期的一个事实是:
一旦某个开发人员离开工作岗位,其原来所作的代码便基本成为垃圾,无人过问。
究其原因,就是没有专门对各人的有用对象进行管理,把其使用范围扩大到公司一级,进行规范化,加以说明和普及。
CVS系统为开发管理提供了一个平台和仓库,有利于建立公司级的代码对象库。
(2)业务及经验库
通过CVS的注释,可形成完整的开发日志及问题集合,以文字方式伴随开发的整个过程,不依某个人的转移而消失,有利于公司积累业务经验,无论对版本整改或版本升级,都具有重要的指导作用。
2.2.3.规范管理
(1)量化工作量考核
传统的开发管理中,工作量一直是难以估量的指标,靠开发人员自已把握,随意性相当大;靠管理人员把握,主观性又太强。
采用CVS管理后,开发人员每天下班前对修改的文件CheckIn,其中记述当天修改细节描述,这些描述可以作为工作量的衡量指标。
(2)规范测试
采用CVS以后,测试有了实实在在的工作,测试工作人员根据每天的修改细节描述对每一天的工作做具体的测试,对测试人员也具有可考核性,这样环环相扣,大大减少了其工作的随意性。
(3)加强协调与沟通
采用CVS后,通过VSS文档共享系统和Bugzilla缺陷跟踪系统,大大加强了项目成员之间的沟通,做到有问题及时发现、及时修改、及时通知,但又不额外增加很多的工作量。
谈项目管理和软件测试过程(三)
3.性能测试是软件测试专业化的核心所在
从华友实践看,软件测试对于产品经理、开发经理和市场经理都有所认识,他们大部分人会认为功能测试工作他们能够很好的完成,产品经理是公司对于业务最熟悉的一批人,他们对于测试工程师最急切的需求是你帮我实施产品的性能测试工作,他们听说过性能测试,我们的产品投入在线运行后碰到的最大故障是大用户量访问业务是机器凼机,或停止正常的服务,每次故障,几乎给公司的收入都造成很大损失。
如果测试部门能有一套有效的性能测试手段,就确立了测试部门在项目开发过程中关键地位。
性能测试在华友软件的质量保证中起着非常重要的作用,将性能测试概括为四个方面:
Wap无线应用服务在手机用户端性能测试、Web/Wap应用服务在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。
通常情况下,四方面有效、合理的结合,可以达到对系统性能全面的分析和瓶颈的预测。
3.1Wap无线应用服务在手机用户端性能测试
如今人人用手机都追求时尚,时尚体现在款式,品牌和功能。
手机产品功能的日新月异,移动增值业务功能层出不穷,从最初的短信、彩信、铃声到GPRS,CDMA,K-Java,Brew手机,功能的多样性带来手机用户端软件系统测试的复杂性。
众所周知,Java手机吸引人之处是能提供智能的,个人化的互动服务,例如:
动态产生个人化的股市服务,显示图形,动画,实时路况,气象报告,数字照像,玩游戏等,部分服务能直接于用户端执行。
为了提供如此生动的服务,移动通信系统要能给终端用户在无线装置上提供接入互联网的功能,要能储存、提取、管理、计算、结帐、下载软件服务,并使内容提供商能提供丰富的声像多媒体内容,形成广大的个人化交互式服务环境。
而作为移动用户,可将手机视作虚拟机,能随时、随地在适当的装置上存取应用,享受服务。
这确是一种时尚。
当前,对于不同品牌的手机,它们所用的平台(指CPU和操作系统)各不相同,由于采用不同的设计方案,各设计之间缺乏兼容性,操作系统和二进制代码都不兼容。
当手机运行需要大量内存时,特别是随着接入互联网,手机用户要求能使用个性化的交互式应用软件,应用程序运行在虚拟运行环境下时,问题显得尤为突出。
所以,有必要建立一种标准的通用运行平台,达到在合适的成本下提供统一的交互式应用软件运行环境。
但是,除非该平台是基于完全标准的器件,否则是难以达到要求的。
标准的通用的运行平台是满足运营商,软件开发商,和终端用户三者综合要求的解决办法。
理想的环境必须具备以下性质:
(1)、平台应提供二进制兼容性。
可执行软件是二进制目标码,需要在处理器和应用软件目标码之间建立沟通;
(2)、平台必须包括微处理器,或一个与微处理器机器代码相离的通用机器码仿真器;
(3)、平台应包括带有应用程序接口API及支持一致性图形用户界面GUI相应功能的操作系统。
API是执行典型操作功能的软件功能库,例如打开文件,读写数据,配置和管理内存,处理事件,显示文档和图形等。
为使应用软件真正做到可移植,装置上必须有公共功能集,并让软件开发者能通过一致性API扩展功能;
(4)、平台不应要求过多的系统资源,可移植性设备不应使成本上升太多;
(5)、平台应对功率有高效率,尤其考虑用电池供电的设备;
(6)、由于要在互联网上应用,安全性也是重要因素。
以Java手机软件测试为例潜在的测试问题和解决办法
Java有移植性好和其它很多优势,但用在手机上,速率和功耗仍是个瓶颈。
Java带来的新问题是执行速度慢,消耗功率大。
与PC不同的是,手机资源有限,一般流行的手机中CPU的速率为26MHz,或52MHz,带128M闪存,8Mb,16M或64Mb内存,没有硬盘,由电池供电,体积小,空间窄。
系统慢的原因是:
(1)系统必须同时运行两套软件:
Java应用和虚拟机JVM;
(2)Java软件需要被翻译成自然CPU指令;
(3)Java平台是基于栈(相对于寄存器)结构的,导致更多的内存存取。
因而,如何对执行Java加速成为关键。
加速处理数据和图形,这对手机上互联网和多媒体的应用具有重要意义。
要克服这些问题,提高Java软件性能,可能的方法有四种:
(1)提高微处理器速率。
然而Java软件性能与时钟频率并不成线性关系,微处理器运行一般比内存存取时间高2-10倍,增加时钟频率只会增加等待周期。
(2)对JVM软件进行优化。
这可能涉及到要用汇编语言对字节码翻译环路进行编程,而这会导致JRE变得与微处理器类别有关。
而与可移植相抵触;
(3)编译。
将软件直接编译到微处理器的自然机器语言。
但是这会增加内存的开销,也不节省能量的消耗。
(4)采用基于硬件的加速器。
这可以做到提高性能,保障能量和成本的有效性。
被手机设计厂商认为是较理想的措施。
通用型Java加速芯片于今年年初问世。
3.2分析Web/Wap应用服务在客户端性能的测试
Web/Wap应用服务在客户端性能测试的目的是考察客户端应用的性能,测试的入口是客户端。
它主要包括并发性能测试、大数据量测试和速度测试等,其中并发性能测试是重点。
并发性能测试的过程是一个负载测试和压力测试的过程,即逐渐增加负载,直到系统的瓶颈或者不能接收的性能点,通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。
负载测试(LoadTesting)是确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统组成部分的相应输出项,例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。
负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用,从而来确定能够接收的性能过程。
压力测试(StressTesting)是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。
并发性能测试的目的主要体现在三个方面:
以真实的业务为依据,选择有代表性的、关键的业务操作设计测试案例,以评价系统的当前性能;当扩展应用程序的功能或者新的应用程序将要被部署时,负载测试会帮助确定系统是否还能够处理期望的用户负载,以预测系统的未来性能;通过模拟成百上千个用户,重复执行和运行测试,可以确认性能瓶颈并优化和调整应用,目的在于寻找到瓶颈问题。
我们公司自己组织力量同时委托第三方软件HG公司开发Hawa网站的一套应用Avatar形象系统的时候,Avatar形象在网站业务中占有着重要的位置,网站上的很多业务都是围绕Avatar开展。
这套系统能不能承受大量的并发用户同时访问?
成为这个网站能否成功的关键,也是这次两个公司合做开发能否顺利完成的关键。
这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。
这种问题的解决要借助于科学的软件测试手段和先进的测试工具。
Web软件测试实例说明:
哈哇网站Avatar形象系统软件。
Avatar形象系统在上线试运行三个月后,所有的功能测试顺利完成,软件功能缺陷也修改完毕。
但是,性能问题越来越成为项目经理关心的焦点,我们测试部门借助比较熟悉的压力测试工具WebStress实施客户端性能测试进行100,500,1000等并发用户访问。
每次测试主要在基于URL:
这个性能问题经过HG公司开发人员近三个月改进,/index.jsp页面的1000个用户并发响应时间10秒左右。
对于我方采用的WebStress性能测试工具HG公司也认同其测试结果的客观性,公司因为该软件性能问题推迟支付对方经费200万圆三个月,更重要的是软件的性能问题得到很好解决,并与HG公司的关系很好保持。
另外一个更大的收获是测试部门
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 管理 软件 测试 过程