还剩8页未读,继续阅读
本资源只提供10页预览,全部文档请下载后查看!喜欢就下载吧,查找使用更方便
文本内容:
项目测试经验总结说明以下项目测试经验是我在原来公司工作中的实际经验,拿出来和大家一起交流我相信之前的项目测试工作中有不少可以改进的地方,还希翼大家多多交流项目测试经验JudyShen本文是对我近几年测试工作经验的总结,并以简报的方式在研发中心内进行分享及交流测试团队介绍1在介绍我们之前项目测试工作之前,需要首先介绍一下之前我所在团队的组织架构及测试人员在项目中的工作我们的测试团队属于质量改进中心下的测试部,它和研发团队属于两个不同的中心测试团队有6个人,从图一可以看出来,一个人可以参预多个处于不同阶段的项目测试工作图一测试团队组织架构参预项目的测试人员以测试组的形式进入项目,测试组和需求组、开辟组并列每一个测试组有一个测试组长负责项目测试工作项目经理不直接面对测试组成员,而是通过测试组长进行任务安排、协调、沟通测试部经理知情测试人员的项目测试工作,项目测试组的工作汇报均需要抄送给测试部经理如图二所示图二项目组织架构I0上面说到的是用的测试人员工作模式,在去年年底,为了有效利用公司测试人员资源,我们开始了测试外包的尝试这里的测试外包模式是指,测试组不进入项目,而是由项目组将测试工第三步测试团队内部的职责分工明确测试团队内部各类测试人员的职责分工可以使测试团队内部各类测试人员能集中精力在较短的时间内完成特定岗位必需的知识储备和经验积累,同时也使得测试团队的管理更科学,真正做到“用其所长,避其所短”第四步测试流程建设我们可以通过以下步骤来建立适合本单位的测试流程
1.测试团队负责人员根据对公司现有测试状况的了解,及个人的测试经验,起草测试流程及相关的模板
2.通过一到两个项目的实践,记录测试流程草稿中的问题及不足之处
3.根据实施经验,完善测试流程,得到测试流程初稿,并起草相关实施指南;
4.选择一个到多个项目,实践上述测试流程初稿及实施指南,记录实践过程中浮现的问题;
5.根据上述实践工作的反馈,组织修改测试流程初稿及实施指南,并把修改后的测试流程继续应用到项目实践中去,根据反馈进一步完善成熟
6.测试流程及其相关文件基本趋于稳定状态时,可以考虑发布测试流程(含测试流程、模板、表格、指南),并在以后的实践中不断改进和完善第五步团队成员能力的逐步提高有了明确、合理的职责分工后,需要针对这些分工对团队成员进行故意识的引导,稳步提升团队成员的技能测试团队负责人需要负起监督和促进员工能力提升的任务监督和促进测试团队成员能力提高,主要做好如下三个方面的工作一是,提倡资深测试人员在测试团队内部进行时常性的培训和测试经验交流,通过该渠道帮助资历浅的测试人员大幅提升业务技能,做到新老员工之间的知识传播和继承二是,测试团队应充分利用好测试件知识库,对于纳入到测试团队知识库的测试件应充分消化和学习,在此基础上进一步鼓励测试团队成员对这些测试件提出改进性意见三是,测试人员除了需要注重自身的测试技能提升,在条件许可的情况还应适度开辟部门的基本知识,这样能减少与开辟团队协同工作时的领域障碍作以一个项目的方式分包给测试部,由测试部根据项目组提供的信息,进行计划、执行测试,并按照项目要求提交测试成果给项目组这个模式还在探索中,如图三所示,测试部经理直接负责项目的测试工作,测试组的工作情况抄送给项目经理这种模式需要进行独立核算,包括成本估算、预算、结算等但是这种模式的整体思路还不是很成熟,从这个组织架构上大家也可以看出来,不少东西还没有理顺,所以一直都处于尝试过程中后面提到的内容,如果没有特殊说明,都是在旧的模式下进行的图三项目组织架构(测试外包方式)我想不可否认,大家都认为测试人员应该是测试技术上的专家,但是,测试人员是否需要熟悉并擅长一定的业务呢?不管答案是什么都没有关系,但是我认为一个好的测试人员不仅是测试专家,他同时也是业务专家有一些测试人员,因为系统的业务知识很复杂,就一头扎进去,几乎全力去学习业务知识,测试技术的学习和研究没有跟上,结果不是设计出大量冗余的测试用例,就是不少方面没考虑到,面对客户的不当请求,也没有底气说测试应该怎么做,弄得做起项目来辛苦异常,个个苦不堪言!有看样的说法“软件测试人员要两条腿走路,左腿是测试技术,右腿是业务知识惟独两条腿的茁壮差不多,走路才稳当”出于这种思想的考虑,在原来的测试团队,我们每一个人都有两个学习、研究方向,一个是技术方向,一个是业务方向例如•技术方向曰功能自动化测试忆性能测试单元测试测试管理•业务方向曰物流业务匕7智能交通知识管理但这种方式在工作开展上有些艰难如果公司认为测试人员应该绝大部份时间用在项目测试工作上,那末测试团队既要研究测试技术,又要挤出时间学习业务知识,在操作上是比较艰难的在我们以前的测试团队的工作中,有一部份工作时间是用来进行部门建设的,部门建设工作中包括前面说到的技术研究、业务学习,还有就是部门搭建所需要进行的一些工作(如部门制度建设)当时公司允许我们团队有30%的工作量投入部门建设上将部门建设工作分开,主要是用于统计部门成本和测试成本用的前面说到了测试人员是以测试组身份进入项目开展测试工作的,但不是每一个成员上去都从事同样的工作在进入项目组工作时,每一个测试人员所充当的角色是不同的,项目的测试角色划分为以卜.四种,如表一所示在实际工作中因为测试人员数量有限,所以时常是一个人担任多个角色角色职责测试管理员负责测试项目的管理测试过程问题的处理与反馈系统/性能测试组织和计划测试过程状态报告测试设计员测试需求的描述系统/性能测试用例的设计测试工具、方法的引入测试执行员根据需要开辟测试脚本按照测试用例、测试脚本执行测试项目测试工作指导测试监督与度量员测试度量测试过程问题的汇总与反馈开辟产品的质量抽检与评定表一测试角色划分了解了原来测试团队的分工之后,下面介绍一下测试团队的工作内容原来的测试团队承接的工作内容包括•承担系统测试、用户测试、性能测试•进行测试技术研究及培训其中,测试技术研窕,属于提高团队工作技能的工作,在整个部门范围内进行,这里属于部门建设工作对于项目中的测试人员有可能需要进行,如果项目采用新的测试技术或者测试工具,那末就需要项目测试组成员研究测试技术了,这部份属于项目测试工作培训,是指把内部研究的成果在团队内使用,在适当的时机在公司内传播我们测试团队在2004年开展了21次内部培训,7次公司级培训因为每一个人各有研窕重点,所以我们每一个人都是团队内部培训的讲师说到测试工程师的工作内容,那末就涉及到测试工程师该做的和不该做的固然这和公司对测试人员定位有关,这里仅指以前的组织要说该做的,那末我们需要先明确为什么我们要测试?这是因为存在“系统错误不少、系统不是客户想要的东西、系统实现没有遵照系统需求”等这样的背景在这样的背景下,产生了测试,但是又因为开辟人员自己测试自己的东西,难免测试不全面,所以产生了测试工程师这个角色因此,测试人员他该做的,就是测试软件产品和用户需求不一致的地方,并尽可能多的发现缺陷,能够向项目经理汇报软件质量状态但是在实际工作中,测试人员时常主动或者被动的去做了一些不该做的事情例如说,测试人员认为自己或者测试能够保证软件的质量,以及故意识或者无意识的接受了决定软件是否发布的这个权利为什么测试无法保证软件的质量,是因为项目的质量,需要项目组的所有成员共同努力,才能达到质量保证的目的单纯靠测试工程师的力量,是无法实现软件质量保证的目的为什么测试人员不适合承担决定软件是否发布的权利,是因为软件的发布,是需要项目组各个小组负责人等相关人一起对系统现在的缺陷、质量状况进行评估后,由项目经理(或者预会者)做出是否发布的决定在这个过程中,测试工程师可以提供测试数据、系统当前质量状态报告给预会者参考固然,我知道这两点会有不少人不认同,但是没有关系的我接触的同行中对两点时常有争论但是,有一些质量大师等权威人士还是全部或者部份赞同这两个观点的,如菲利普.克劳士比曾经在他的书中提到软件质量的保证需要全员努力,需要过程的控制的,而不是某个英雄可以保证软件质量的等项目测试工作2做了背景介绍后,下面我介绍之前项目如何开展测试工作的因为测试过程是整个测试工作的一个纲要,所以首先得从测试过程讲起测试过程
2.1测试计划测试过程,我们包括四个环节测试计划、测试设计、测试执行、测试分析图四测试过程
2.
1.1测试计划测试计划主要是进行描述测试需求、分析制定测试计划工作在制定测试计划时,时常有人认为测试计划是在整个项目计划制定之后才开始进行测试计划的,事实上并非这样的测试计划和项目计划是互相影响的举个例子假设项目有进行性能测试的需求,但是测试工具又需要学习,那末我们在测试计划中就需要预留这部份的时间,还有,测试用例的评审,也需要预留时间或者,如果某部份比较复杂,可能测试需要的时间会较多,或者需要测试的次数会比较多,那末可能要求开辟组先安排这个核心模块的开辟,这样需要调整开辟计划的顺序所以,测试计划和项目计划是互相影响的在测试计划环节还包括测试需求的描述,主要是确认需求是可测试的,并将需求细化为具体的可测试点,保证测试设计时可以根据测试需求编写测试用例,而避免遗漏测试点我们的测试需求需要得到业务分析人员的评审,测试计划要得到项目经理的审批认可对于测试计划,还需要说明的是,在具体的每一个测试阶段工作计划中,我们需要定义本阶段测试需要进行的次数每一轮测试是一个完整的测试周期,按照这里介绍的测试过程进行通常我们是一天一轮测试,最多是两天一轮测试通过这种方式,减少了测试和开辟之间的空挡时间,即测试等开辟,开辟等测试例子如图五所示:在本系统中的测试,采用系代冽试的方式,母天测忒一个轮回,每次测均L第一个轮回,重点是客事管理、会员世界部分./基本图五测试迭代例子肯定会有人疑问,如果
2.第二个轮回,重点是业务流程、第三信息.一个系统很庞大的话,怎么能在一两天内完成测试呢?是的,如果系个轮回,重点、是霎事管理、统比较大的话,确实没法在一两天内完成所有
3.会员世界部分.”测试点的全面测试,有第四个轮回,重点是业务旅程、会员世见.~可能需要一周或者更长的时间,但是这样的话,
4.就浮现了测试、开辟互相等待的情况了所以,在我们制定的测试阶段计划时,需要指明本次测试的测试重点,测试范围我可以这一轮测试进行A、B模块基本功能测试,第二轮测试进行C、D模块基本功能测试,第三轮测试,进行主要业务流程测试,第四轮测试,关注负面测试在我之前的实践中,发现这种方法还是比较有效的可能大家也注意到了,这个例子是另一个项目的没错,在今天提到的挪移的这个项目中我们没有按照这种策略进行测试,弄得当时我们测试小组工作很累,很被动,时常是开辟说测试我们就要即将开始测试,而缺乏冲划实施这种方法后,测试的计划性就比较强,测试不用总是被打搅
2.
1.2测试设计测试设计,主要是根据需求、设计文档进行的测试用例设计工作如何从需求导出测试用例并设计测试用例,是整个测试过程中很重要的一部份工作,关系到测试执行效果但是在刚开始时,系统没有界面,所以我们只能根据系统用例搭建测试用例的初步框架,能写多少写多少随着对系统的理解深入,加之后面也开辟了系统原型,我们就可以不断完善测试用例即使是在测试阶段,我们仍不断修改测试用例测试用例我们分为两种,一种是内部测试用例,项目组内部使用;一种是验收测试用例,偏重于业务,供客户使用项目组内部用的测试用例例子如图六所示:恻试需*■试用例■n测试点据注腑试次行及扁%事文际%景粕号■弓优先概呻8BC K11O-鬼务用同MitW*”已2tM.款汽的文档汾行第ft,KMOTR021EC niQ-KJJ02小寡乜的功事L.0G II1C KKIC22g平把看出*AF
52.02上年美出-c»pr的工«
2.03工1工工出•己主匕.注国芟出•校饭度r的又村
3.QQ d撵六竹壬出U后库存的仁三1年”小•产..力丁件看电侦于,T彳*必K-K110-EC-EIia-工务用网两优31rm传电者木陵授效可以修酎.第分KR1O2-TB022E7J02-TUC021非速的均狙L.0C151F--H1A际“2--匚1£
2.00EH五出下尾干又1%彳境^口的吊户图六测试用例例子(项目内用)从图中大家也可以感觉到项目组内部使用的测试用例在维护上比较不方便因为我们的需求并没有做到很细,加之需求本身就是变化的,所以我们的测试需求时常修改,一旦测试需求新增、修改、删除时,测试用例要相应进行调整这就造成为了1)定位测试用例比较不方便,2)测试用例编号修改不方便,3)阅读、执行测试用例不方便所以,我在2004年底开始准备在团队内自主开辟一个测试用例管理系统
2.
1.3测试执行在测试执行阶段,主要进行测试的执行工作如果项目在需要编写或者录制测试脚本的话,那么也在这个阶段进行测试执行结果是在原有测试用例的副本上编写实际执行结果而形成在东南融通,它是把这个活动单独为“测试实施”环节
2.
1.4测试分析在测试执行结束后,我们开始对测试执行结果进行测试分析并编写测试报告测试报告的编写上,主要的内容在于对投入的资源、测试结果、缺陷进行分析,并对整体测试情况进行总结分析对于资源的分析,包括各个测试任务投入的人力情况、实际工作量与计划工作量的对照,并进行分析测试结果分析,可以通过对测试需求的覆盖情况、测试用例的覆盖情况及测试用例执行结果情况进行统计,并进行分析缺陷分析,可以通过对严重性、优先级、模块缺陷数、缺陷修复情况等方面进行统计,并分析例如,对系统缺陷进行统计后,发现存在比较多的可用性问题,如修改操作员所属的组后,无法登录系统等整体情况的总结可以从测试充分性、软件质量情况、测试活动情况、经验教训等方面进行总结测试分析中有个很重要的活动是对测试活动和测试过程进行经验教训的总结因为测试经验教训是很重要的,所以我们团队有专人负责对每一个项目测试报告中的经验教训进行汇总,目的是让后面项目测试工作可以吸取前面项目测试的经验,避免犯前面项目测试工作同样的错误注本测试过程对于每一个阶段的测试活动、每一轮测试活动、测试团队承接的各种测试类型均合用也就是说,每一轮测试之前,测试组组长都需要准备测试计划,确定测试执行重点、目标、测试内容等,选取测试用例,并按照预先选取的测试用例执行测试,测试执行结束,需要进行测试汇报
2.
1.5测试准则在测试过程中有个很重要的内容是测试准则在实际执行中,我们不难碰到以下类似情况提交测试的系统时常在测试执行初期,就浮现页面访问失败或者正常功能失效的情况测试人员不知道提交测试的版本改了什么内容或者新增了什么功能,改了哪些缺陷,导致时常碰到开辟人员说测试人员提交的某些缺陷所对应的功能不属于本版本集成内容等等存在这些情况的很大一部份的原因是因为在项目策划阶段时,测试组未就测试准则和项目组达成一致意见,或者已经达成一致,但是并没有严格执行我们今天要讲的测试准则,主要是针对前者,后者属于管理层面问题,不在我们的考虑范围内设置测试准时需要注重实用性测试准则,通常包括测试进入、暂停、恢复、退出准则这些测试准则的例子如表二所示进入准则暂停准则恢复准则退出准则描述系统在什么情况下含义描述开始执行测试的时描述系统恢复测试的必要条描述测试退出的条件,有正暂停全部或者部份测试机件常退出,也有非正常或者意工_____________________外的退出_______________集成测试测试环境被破坏;主要功能测试环境重新搭建好主要完成已提交内容所能完测试环境已经准备好;页面点击错误功能不会浮现页面点击错误成的测试己经完成提交测试的模块内的情况容;主要功能无页面点击错误;测试所需的文档资料已经完整系统测试测试环境被破坏;系统基本测试环境重新搭建好系统测试内容已经完成阻塞测测试环境已经准备好;系统业务流程不通基本业务流程可以走通;试的内容(即测试暂停的产基本业务流程能走通任何功能的页面点击错误页面点击错误问题解决生原因)在短期内无法解决无任何功能的页面点击错误;测试所需的文档资料已经完整内部确认测测试环境已经准备好;系统测试环境被破坏;系统业务测成环境重新搭建好;系统试/UAT正常功能已正确实现流程不通;正常功能未正确业务流程能走通正常功能业务流程能走通实现;用户很容易重现的严实现;重缺陷产生需要解决的缺陷解决测试内容已经全部完成PM根据测试报告,认为系统可以满足客户的要求PM要求修改的缺陷已经全部修复;到了时间,系统必须发布验收测试测试环境被破坏;测试环境重新搭建好;修改测试环境已经准备好;客户发现需要修改的缺陷完需要修改的缺陷所有要求的测试用例和测试要求的功能都已经完成程序都已经执行,并且没有业务流程可以走通发现新的必须修改的缺陷性能测试测试环境已经准备好系统测试环境被破坏系统流程测试环境重新搭建好解决所有要求的测试用例和测试的功能正常实现;不存在影存在缺陷;被测试功能存在影响性能测试的缺陷脚本都已执行;完成性能分响系统流程的缺陷缺陷;程序的版本更新,存析工作在影响系统功能实现的缺陷表二测试准则例子恢复测试时,普通是需要把前面测试内容重新进行测试,因为会花贽较大的工作量,所以测试组长在决定笆停测试时需要很谨慎在表二显示的集成测试的退出准则中写到“完成已提交测试内容所能完成的测试”,这里的“所能完成的测试”是指,在当前版本所能进行的测试内容,如在系统刚集成时,可进行界面测试,基本模块的基本功能的测试上面的测试准则的例子,也不是很恰当及规范,至少缺少了数据度量部份,这里只是拿出来和大家一起交流这部份内容我向来认为是很重要的,如果做的不好,测试组的负担会很重需要注意的一点是测试准则,是在制定测试计划时沟通确定的,它需要和相关人沟通,且得到项目经理审批通过的测试准则是固定的,实际处理方式是灵便的在实际测试过程中碰到同样的问题,是否继续测试,或者需要暂停测试,处理方式不是一成不变的,这是需要根据项目所处阶段来具体情况具体分析的下面举个例子,这个例子是时常性的一种情况假设在测试过程中,我们发现了一个阻塞性错误(流程无法继续往下走等类似情况),是否继续进行测试呢?•在项目初期,进行单个或者多个模块的测试时因为可以执行界面测试及熟悉系统,我们可以接受该版木,继续进行测试“这就属于已提交测试内容所能完成的测试在项目测试初期,要求不可过于严格•系统测试基本流程必须走通如果基本业务流程(主干)不能走通,则需要根据实际情况来灵便处理(是否暂停测试或者继续测试?)如果是整个流程的初始节点失效,没有这个节点的数据,后面所有节点均无法进行,那末这种情况下就只能暂停测试如果说是分支流程浮现阻塞,那末可以考虑继续测试,然后在测试报告中说明该分支未测试此时不暂停测试,主要是考虑重新集成一个版本的性价比,也就是是否值得.重:新集成•发布前的确认测试一旦有阻塞性缺陷,即将住手测试测试实施过程
2.2上面说的是测试过程下面简单介绍一下我们实际的测试工作我们的测试组普通是在项目启动时进入项目组的在项目立项时,项目经理会向测试部经理申请测试资源经过评估衡量后,测试部经理会安排一个测试人员作为项目测试组长当项目启动时,测试组长进入项目,开始了解项目用户需求,起草项目测试计划在到了一定阶段,例如测试设计阶段,测试部经理会根据项目规模,项目在公司的重要性以及团队其他人员工作负荷情况,安排其他人进入项目组普通来说,我们一个项目是2~3名测试人员在项目进入维护阶段时,则是一个测试人员跟进项目测试组长根据项目情况及项目阶段计划,定义项目本阶段测试次数项目经理参考测试组长提供的测试次数建议,以及项目开辟的情况,和项目组各个小组负责人沟通后,定义了系统本阶段版本集成时间在我们的项目里.,有一个开辟人员兼职做集成人员在指定的版本集成时间之前的一段时间,各个开辟人员将他们的程序提交配置库,由集成人员进行集成(不同语言有不同的集成方式)集成后,集成人员会进行简单的自测,验证是否集成成功如果集成成功,就在服务器上给该版木程序打上标签如果集成不成功,那末返工给相应开辟人员修改并重新集成,如此反复直至集成成功集成成功后,集成人员会提交一份集成说明给测试组长集成说明内容包括集成版本路径、版本标签、修改内容、新增内容等测试组长则根据预先准备好的测试计划开始测试在开始测试时测试组长会通知项目组,告诉他们测试开始,请勿更新测试环境测试结束后,也会通知项目组测试结束这里要很注意一点的是,对于数据库的更新也需要采用同样的管理,即数据库维护也是需要进行统一管理,避免浮现客户环境和测试环境不一致的情况在正常情况下,开辟组是在预定的集成H期的当天晚上集成,测试组第二天上班后开始测试如果遇到特殊情况需要当天集成当天测试的话,我们的开辟人员会等到测试组发出测试结束的通知后,才离岗如果在完成计划的测试次数后,系统质量仍不稳定或者没有达到预期目标的话,那末测试组长将和项目经理沟通,相应增加测试次数关于测试用例的执行,我不知道公司现在是采用怎样的一种方式的在我原来的团队中,测试用例的主要作用是保证系统功能的测试覆盖率,避免某些功能因为测试周期长而导致测试遗漏但是我们也采用经验法、试探法、转换思维的方式进行测试,所以,我们普通使用测试用例执行3~4次测试这可能和我们的测试用例设计能力有关在缺陷管理上,整体流程基本类似,但是在缺陷分配上,我们测试人员是直接分配给项目缺陷分配专员,缺陷分配专员普通是由业务分析员担任缺陷分配专员对缺陷进行分析后,再进行缺陷的再分配对于缺陷分配专员处理为不修改的缺陷,测试人员需要进行确认如果测试人员不认可缺陷分配专员的处理意见,可以同他进行沟通,或者向相关人员(如项目经理)提出自己的意见,最终以项目经理的意见为准在系统阶段确认测试前的2~3天,测试组长会将系统未解决的缺陷清单给项目经理确认,并要求项目经理提供缺陷应对方案缺陷应对方案在系统发布时,作为项目发布说明的附件我们是采用公司自主开辟的缺陷管理系统进行缺陷管理的,使用excel.word进行其他测试工件的编写的如何搭建一个高效的测试团队3俗话说“工欲善其事,必先利其器”,要做好测试工作,首先需要建立并维护一个高效的测试团队然而,许多小型软件企业却将测试作为产品面临发布时的一个小插曲,往往暂时抽调几名程序员对产品的功能粗略测试一下即交付客户(甚至在进度和成本不足时首先砍掉这一块)这种仓促完成的产品通常质量问题不少,所以我们首先应抛弃小企、也惯常的思维模式,不计较一时一地之利益,立足长远,着手组建高效测试团队第一步招募测试人员在国内的软件企业中有一种普遍做法,那就是把那些刚涉足软件行业的技术新手或者业绩不突出的开辟人员安排去做测试工作笔者认为这绝对是一种欠妥当的行为事实上,对一个系统进行有效测试所需要的技能绝对不比进行软件开辟所需要的技能少,测试从业者甚至可能面对许多开辟人员都不会遇到的技术难题那末,测试团队需要招募什么样的成员呢?这里,笔者总结了以下两点首先,测试人员要具备良好的沟通能力、自信心、外交能力、迁移能力以及怀疑精神其次,测试组成员应具备良好的专业技能或者技术学习能力固然,新招募的测试人员不可能像上而说的那末理想关键是他们是否热爱测试这项工作,对相关的工作内容是否感兴趣以及他们的学习能力如何第二步测试团队制度建设良好的制度可以规范测试团队的工作开展,同时也便于对团队成员进行业绩考评相反,则很有可能导致人心涣散,滋长负面风气建设良好的测试团队制度,可以考虑以下几个方面・汇报制度团队成员汇报本周工作情况及卜.周工作计划、遇到的问题以及需要提供的匡助,培养团队成员的汇报及计划习惯・工作总结制度成员每一个阶段汇报上阶段工作经验和教训,并在部门例会上交流、分享经验及教训,避免同样的问题重复浮现・奖惩制度对于贡献突出的成员予以奖励,对于业绩差的提出批评,有效地保持测试团队的工作热情・测试件审核制度对测试件进行审核,去粗存精•,鼓励测试人员使用和提出改进,保证提交到测试团队知识库的测试件的质量・会议制度定期召开部门例会,讨论、解决工作中的问题,并提供部门内的学习平台目前,已有不少软件企业推行给测试人员区分级别的制度,奖优罚劣这无疑是一个好的做法,但成员业绩的具体考评办法,目前尚无可供参考的标准文件,所以笔者建议应尽量做到公正客观,以免挫伤团队成员的工作积极性。