项目测试经验总结_第1页
项目测试经验总结_第2页
项目测试经验总结_第3页
项目测试经验总结_第4页
项目测试经验总结_第5页
已阅读5页,还剩5页未读, 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、项目测试经验总结说明:以下项目测试经验是我在原来公司工作中的实际经验,拿出来和大家一起交流。我相信之前的项目测试工作中有不少可以改进的地方,还希望大家多多交流。项目测试经验 Judy Shen本文是对我近几年测试工作经验的总结,并以简报的方式在研发中心内进行分享及交流。1 测试团团队介绍绍在在介绍我我们之前前项目测测试工作作之前,需要首首先介绍绍一下之之前我所所在团队队的组织织架构及及测试人人员在项项目中的的工作。 我们的的测试团团队属于于质量改改进中心心下的测测试部,它和研研发团队队属于两两个不同同的中心心。测试试团队有有6个人,从图一一可以看看出来,一个人人可以参参与多个个处于不不同阶段段

2、的项目目测试工工作。图一测试试团队组组织架构构 参与项项目的测测试人员员以测试试组的形形式进入入项目,测试组组和需求求组、开开发组并并列。每每个测试试组有一一个测试试组长负负责项目目测试工工作。项项目经理理不直接接面对测测试组成成员,而而是通过过测试组组长进行行任务安安排、协协调、沟沟通。测测试部经经理知情情测试人人员的项项目测试试工作,项目测测试组的的工作汇汇报均需需要抄送送给测试试部经理理。如图图二所示示:图二项目目组织架架构(旧旧) 上面说说到的是是旧的测测试人员员工作模模式,在在去年年年底,为为了有效效利用公公司测试试人员资资源,我我们开始始了测试试外包的的尝试。这里的的测试外外包模式

3、式是指,测试组组不进入入项目,而是由由项目组组将测试试工作以以一个项项目的方方式分包包给测试试部,由由测试部部根据项项目组提提供的信信息,进进行计划划、执行行测试,并按照照项目要要求提交交测试成成果给项项目组。 这个模模式还在在探索中中,如图图三所示示,测试试部经理理直接负负责项目目的测试试工作,测试组组的工作作情况抄抄送给项项目经理理。这种种模式需需要进行行独立核核算,包包括成本本估算、预算、结算等等。但是是这种模模式的整整体思路路还不是是很成熟熟,从这这个组织织架构上上大家也也可以看看出来,很多东东西还没没有理顺顺,所以以一直都都处于尝尝试过程程中。后后面提到到的内容容,如果果没有特特殊说

4、明明,都是是在旧的的模式下下进行的的。图三项目目组织架架构(测测试外包包方式) 我想不不可否认认,大家家都认为为测试人人员应该该是测试试技术上上的专家家,但是是,测试试人员是是否需要要熟悉并并擅长一一定的业业务呢?不管答答案是什什么都没没有关系系,但是是我认为为一个好好的测试试人员不不仅是测测试专家家,他同同时也是是业务专专家。有有一些测测试人员员,因为为系统的的业务知知识很复复杂,就就一头扎扎进去,几乎全全力去学学习业务务知识,测试技技术的学学习和研研究没有有跟上,结果不不是设计计出大量量冗余的的测试用用例,就就是很多多方面没没考虑到到,面对对客户的的不当请请求,也也没有底底气说测测试应该该

5、怎么做做,弄得得做起项项目来辛辛苦异常常,个个个苦不堪堪言! 有着样样的说法法:“软件测测试人员员要两条条腿走路路,左腿腿是测试试技术,右腿是是业务知知识。只只有两条条腿的健健壮差不不多,走走路才稳稳当。”出于这这种思想想的考虑虑,在原原来的测测试团队队,我们们每个人人都有两两个学习习、研究究方向,一个是是技术方方向,一一个是业业务方向向。例如如: 技技术方向向: 功功能自动动化测试试 性性能测试试 单单元测试试 测测试管理理 业业务方向向: 物物流业务务 智智能交通通 知知识管理理 但这种种方式在在工作开开展上有有些困难难。如果果公司认认为测试试人员应应该绝大大部分时时间用在在项目测测试工作

6、作上,那那么测试试团队既既要研究究测试技技术,又又要挤出出时间学学习业务务知识,在操作作上是比比较困难难的。在在我们以以前的测测试团队队的工作作中,有有一部分分工作时时间是用用来进行行部门建建设的,部门建建设工作作中包括括前面说说到的技技术研究究、业务务学习,还有就就是部门门搭建所所需要进进行的一一些工作作(如部部门制度度建设)。当时时公司允允许我们们团队有有30%的工作作量投入入部门建建设上。将部门门建设工工作分开开,主要要是用于于统计部部门成本本和测试试成本用用的。 前面说说到了测测试人员员是以测测试组身身份进入入项目开开展测试试工作的的,但不不是每个个成员上上去都从从事同样样的工作作。在

7、进进入项目目组工作作时,每每个测试试人员所所充当的的角色是是不同的的,项目目的测试试角色划划分为以以下四种种,如表表一所示示。在实实际工作作中因为为测试人人员数量量有限,所以经经常是一一个人担担任多个个角色。角色职责测试管理理员负责测试试项目的的管理测试过程程问题的的处理与与反馈系统/性性能测试试组织和和计划测试过程程状态报报告测试设计计员测试需求求的描述述系统/性性能测试试用例的的设计测试工具具、方法法的引入入测试执行行员根据需要要开发测测试脚本本按照测试试用例、测试脚脚本执行行测试项目测试试工作指指导测试监督督与度量量员测试度量量测试过程程问题的的汇总与与反馈开发产品品的质量量抽检与与评定

8、表一测试试角色划划分 了解解了原来来测试团团队的分分工之后后,下面面介绍一一下测试试团队的的工作内内容。原原来的测测试团队队承接的的工作内内容包括括:承承担系统统测试、用户测测试、性性能测试试;进进行测试试技术研研究及培培训 其中,测试技技术研究究,属于于提高团团队工作作技能的的工作,在整个个部门范范围内进进行,这这里属于于部门建建设工作作;对于于项目中中的测试试人员有有可能需需要进行行,如果果项目采采用新的的测试技技术或者者测试工工具,那那么就需需要项目目测试组组成员研研究测试试技术了了,这部部分属于于项目测测试工作作。 培训,是指把把内部研研究的成成果在团团队内使使用,在在适当的的时机在在

9、公司内内传播。我们测测试团队队在20004年年开展了了21次内内部培训训,7次公司司级培训训。因为为每个人人各有研研究重点点,所以以我们每每个人都都是团队队内部培培训的讲讲师。 说到测测试工程程师的工工作内容容,那么么就涉及及到测试试工程师师该做的的和不该该做的。当然这这和公司司对测试试人员定定位有关关,这里里仅指以以前的组组织。要要说该做做的,那那么我们们需要先先明确为为什么我我们要测测试?这这是因为为存在“系统错错误很多多、系统统不是客客户想要要的东西西、系统统实现没没有遵照照系统需需求”等这样样的背景景。在这这样的背背景下,产生了了测试,但是又又因为开开发人员员自己测测试自己己的东西西,

10、难免免测试不不全面,所以产产生了测测试工程程师这个个角色。因此,测试人人员他该该做的,就是测测试软件件产品和和用户需需求不一一致的地地方,并并尽可能能多的发发现缺陷陷,能够够向项目目经理汇汇报软件件质量状状态。但但是在实实际工作作中,测测试人员员经常主主动或被被动的去去做了一一些不该该做的事事情。例例如说,测试人人员认为为自己或或者测试试能够保保证软件件的质量量,以及及有意识识或无意意识的接接受了决决定软件件是否发发布的这这个权利利。 为什么么测试无无法保证证软件的的质量,是因为为项目的的质量,需要项项目组的的所有成成员共同同努力,才能达达到质量量保证的的目的。单纯靠靠测试工工程师的的力量,是

11、无法法实现软软件质量量保证的的目的。 为什么么测试人人员不适适合承担担决定软软件是否否发布的的权利,是因为为软件的的发布,是需要要项目组组各个小小组负责责人等相相关人一一起对系系统现在在的缺陷陷、质量量状况进进行评估估后,由由项目经经理(或或者与会会者)做做出是否否发布的的决定。在这个个过程中中,测试试工程师师可以提提供测试试数据、系统当当前质量量状态报报告给与与会者参参考。 当然,我知道道这两点点会有很很多人不不认同,但是没没有关系系的。我我接触的的同行中中对两点点经常有有争论。但是,有一些些质量大大师等权权威人士士还是全全部或部部分赞同同这两个个观点的的,如:菲利普普.克劳士士比曾在在他的

12、书书中提到到软件质质量的保保证需要要全员努努力,需需要过程程的控制制的,而而不是某某个英雄雄可以保保证软件件质量的的等。2 项目测测试工作作 做了背背景介绍绍后,下下面我介介绍之前前项目如如何开展展测试工工作的。 因为测测试过程程是整个个测试工工作的一一个纲要要,所以以首先得得从测试试过程讲讲起。2.1 测试过过程 测试过过程,我我们包括括四个环环节:测测试计划划、测试试设计、测试执执行、测测试分析析。图四测试试过程2.1.1 测试试计划 测试计计划主要要是进行行描述测测试需求求、分析析制定测测试计划划工作。在制定定测试计计划时,经常有有人认为为测试计计划是在在整个项项目计划划制定之之后才开开

13、始进行行测试计计划的,事实上上并不是是这样的的。测试试计划和和项目计计划是互互相影响响的。举举个例子子。假设设项目有有进行性性能测试试的需求求,但是是测试工工具又需需要学习习,那么么我们在在测试计计划中就就需要预预留这部部分的时时间,还还有,测测试用例例的评审审,也需需要预留留时间。或者,如果某某部分比比较复杂杂,可能能测试需需要的时时间会较较多,或或者需要要测试的的次数会会比较多多,那么么可能要要求开发发组先安安排这个个核心模模块的开开发,这这样需要要调整开开发计划划的顺序序。所以以,测试试计划和和项目计计划是互互相影响响的。在在测试计计划环节节还包括括测试需需求的描描述,主主要是确确认需求

14、求是可测测试的,并将需需求细化化为具体体的可测测试点,保证测测试设计计时可以以根据测测试需求求编写测测试用例例,而避避免遗漏漏测试点点。我们们的测试试需求需需要得到到业务分分析人员员的评审审,测试试计划要要得到项项目经理理的审批批认可。 对于于测试计计划,还还需要说说明的是是,在具具体的每每个测试试阶段工工作计划划中,我我们需要要定义本本阶段测测试需要要进行的的次数。每一轮轮测试是是一个完完整的测测试周期期,按照照这里介介绍的测测试过程程进行。通常我我们是一一天一轮轮测试,最多是是两天一一轮测试试。通过过这种方方式,减减少了测测试和开开发之间间的空挡挡时间,即测试试等开发发,开发发等测试试。例

15、子子如图五五所示:图五测试试迭代例例子 肯定会会有人疑疑问,如如果一个个系统很很庞大的的话,怎怎么能在在一两天天内完成成测试呢呢?是的的,如果果系统比比较大的的话,确确实没法法在一两两天内完完成所有有测试点点的全面面测试,有可能能需要一一周或更更长的时时间,但但是这样样的话,就出现现了测试试、开发发互相等等待的情情况了。所以,在我们们制定的的测试阶阶段计划划时,需需要指明明本次测测试的测测试重点点,测试试范围。我可以以这一轮轮测试进进行A、B模块基基本功能能测试,第二轮轮测试进进行C、D模块基基本功能能测试,第三轮轮测试,进行主主要业务务流程测测试,第第四轮测测试,关关注负面面测试。在我之之前

16、的实实践中,发现这这种方法法还是比比较有效效的。可可能大家家也注意意到了,这个例例子是另另一个项项目的。没错,在今天天提到的的移动的的这个项项目中我我们没有有按照这这种策略略进行测测试,弄弄得当时时我们测测试小组组工作很很累,很很被动,经常是是开发说说测试我我们就要要马上开开始测试试,而缺缺乏计划划。实施施这种方方法后,测试的的计划性性就比较较强,测测试不用用总是被被打扰。2.1.2 测试试设计 测试设设计,主主要是根根据需求求、设计计文档进进行的测测试用例例设计工工作。如如何从需需求导出出测试用用例并设设计测试试用例,是整个个测试过过程中很很重要的的一部分分工作,关系到到测试执执行效果果。但

17、是是在刚开开始时,系统没没有界面面,所以以我们只只能根据据系统用用例搭建建测试用用例的初初步框架架,能写写多少写写多少。随着对对系统的的理解深深入,加加上后面面也开发发了系统统原型,我们就就可以不不断完善善测试用用例。即即使是在在测试阶阶段,我我们仍不不断修改改测试用用例。测测试用例例我们分分为两种种,一种种是内部部测试用用例,项项目组内内部使用用;一种种是验收收测试用用例,偏偏重于业业务,供供客户使使用。项项目组内内部用的的测试用用例例子子如图六六所示:图六测试试用例例例子(项项目内用用) 从图中中大家也也可以感感觉到项项目组内内部使用用的测试试用例在在维护上上比较不不方便。因为我我们的需需

18、求并没没有做到到很细,加上需需求本身身就是变变化的,所以我我们的测测试需求求经常修修改,一一旦测试试需求新新增、修修改、删删除时,测试用用例要相相应进行行调整。这就造造成了11)定位位测试用用例比较较不方便便,2)测试用用例编号号修改不不方便,3)阅读读、执行行测试用用例不方方便。所所以,我我在20004年年底开始始准备在在团队内内自主开开发一个个测试用用例管理理系统。2.1.3 测试试执行 在测试试执行阶阶段,主主要进行行测试的的执行工工作。如如果项目目有需要要编写或或录制测测试脚本本的话,那么也也在这个个阶段进进行。测测试执行行结果是是在原有有测试用用例的副副本上编编写实际际执行结结果而形

19、形成。在在东南融融通,它它是把这这个活动动单独为为“测试实实施”环节。2.1.4 测试试分析 在测试试执行结结束后,我们开开始对测测试执行行结果进进行测试试分析并并编写测测试报告告。测试试报告的的编写上上,主要要的内容容在于对对投入的的资源、测试结结果、缺缺陷进行行分析,并对整整体测试试情况进进行总结结分析。对于资资源的分分析,包包括各个个测试任任务投入入的人力力情况、实际工工作量与与计划工工作量的的对比,并进行行分析。测试结结果分析析,可以以通过对对测试需需求的覆覆盖情况况、测试试用例的的覆盖情情况及测测试用例例执行结结果情况况进行统统计,并并进行分分析。缺缺陷分析析,可以以通过对对严重性性

20、、优先先级、模模块缺陷陷数、缺缺陷修复复情况等等方面进进行统计计,并分分析。例例如,对对系统缺缺陷进行行统计后后,发现现存在比比较多的的可用性性问题,如修改改操作员员所属的的组后,无法登登录系统统等。整整体情况况的总结结可以从从测试充充分性、软件质质量情况况、测试试活动情情况、经经验教训训等方面面进行总总结。 测试分分析中有有个很重重要的活活动是对对测试活活动和测测试过程程进行经经验教训训的总结结。因为为测试经经验教训训是很重重要的,所以我我们团队队有专人人负责对对每个项项目测试试报告中中的经验验教训进进行汇总总,目的的是让后后面项目目测试工工作可以以吸取前前面项目目测试的的经验,避免犯犯前面

21、项项目测试试工作同同样的错错误。 注:本测试试过程对对于每个个阶段的的测试活活动、每每一轮测测试活动动、测试试团队承承接的各各种测试试类型均均适用。 也就是是说,每每一轮测测试之前前,测试试组组长长都需要要准备测测试计划划,确定定测试执执行重点点、目标标、测试试内容等等,选取取测试用用例,并并按照预预先选取取的测试试用例执执行测试试,测试试执行结结束,需需要进行行测试汇汇报。2.1.5 测试试准则 在测试试过程中中有个很很重要的的内容是是:测试试准则。 在实际际执行中中,我们们不难碰碰到以下下类似情情况:提提交测试试的系统统经常在在测试执执行初期期,就出出现页面面访问失失败或者者正常功功能失效

22、效的情况况;测试试人员不不知道提提交测试试的版本本改了什什么内容容或者新新增了什什么功能能,改了了哪些缺缺陷,导导致经常常碰到开开发人员员说测试试人员提提交的某某些缺陷陷所对应应的功能能不属于于本版本本集成内内容等等等。存在在这些情情况的很很大一部部分的原原因是因因为在项项目策划划阶段时时,测试试组未就就测试准准则和项项目组达达成一致致意见,或者已已经达成成一致,但是并并没有严严格执行行。我们们今天要要讲的测测试准则则,主要要是针对对前者,后者属属于管理理层面问问题,不不在我们们的考虑虑范围内内。 设置测测试准时时需要注注重实用用性。测测试准则则,通常常包括测测试进入入、暂停停、恢复复、退出出

23、准则。这些测测试准则则的例子子如表二二所示:进入准则则暂停准则则恢复准则则退出准则则含义描述开始始执行测测试的时时机描述系统统在什么么情况下下暂停全全部或部部分测试试工作。描述系统统恢复测测试的必必要条件件。描述测试试退出的的条件,有正常常退出,也有非非正常或或意外的的退出。集成测试试测试环境境已经准准备好;已经完成成提交测测试的模模块内容容;主要功能能无页面面点击错错误;测试所需需的文档档资料已已经完整整。测试环境境被破坏坏;主要功能能页面点点击错误误。测试环境境重新搭搭建好;主要功能能不会出出现页面面点击错错误的情情况。完成已提提交内容容所能完完成的测测试系统测试试测试环境境已经准准备好;

24、系统基本本业务流流程能走走通无任何功功能的页页面点击击错误;测试所需需的文档档资料已已经完整整。测试环境境被破坏坏;系统基本本业务流流程不通通;任何功能能的页面面点击错错误。测试环境境重新搭搭建好;系统基本本业务流流程可以以走通;页面点击击错误问问题解决决。测试内容容已经完完成;阻塞测试试的内容容(即测测试暂停停的产生生原因)在短时时间内无无法解决决。内部确认认测试/UATT 测试环境境已经准准备好;系统正常常功能已已正确实实现;业务流程程能走通通。测试环境境被破坏坏;系统业务务流程不不通;正常功能能未正确确实现;用户很容容易重现现的严重重缺陷产产生。测试环境境重新搭搭建好;系统业务务流程能能

25、走通;正常功能能实现;需要解决决的缺陷陷解决。测试内容容已经全全部完成成;PM根据据测试报报告,认认为系统统可以满满足客户户的要求求;PM要求求修改的的缺陷已已经全部部修复;到了时间间,系统统必须发发布。验收测试试测试环境境已经准准备好;客户要求求的功能能都已经经完成。业务流程程可以走走通。测试环境境被破坏坏;发现需要要修改的的缺陷。测试环境境重新搭搭建好;修改完需需要修改改的缺陷陷。所有要求求的测试试用例和和测试程程序都已已经执行行,并且且没有发发现新的的必须修修改的缺缺陷性能测试试测试环境境已经准准备好;系统的功功能正常常实现;不存在影影响系统统流程的的缺陷。测试环境境被破坏坏;系统流程程

26、存在缺缺陷;被测试功功能存在在缺陷;程序的版版本更新新,存在在影响系系统功能能实现的的缺陷。测试环境境重新搭搭建好;解决影响响性能测测试的缺缺陷。所有要求求的测试试用例和和测试脚脚本都已已执行;完成性能能分析工工作。表二测试试准则例例子 恢复测测试时,一般是是需要把把前面测测试内容容重新进进行测试试,因为为会花费费较大的的工作量量,所以以测试组组长在决决定暂停停测试时时需要很很慎重。 在表二二显示的的集成测测试的退退出准则则中写到到“完成已已提交测测试内容容所能完完成的测测试”,这里里的“所能完完成的测测试”是指,在当前前版本所所能进行行的测试试内容,如在系系统刚集集成时,可进行行界面测测试,

27、基基本模块块的基本本功能的的测试。 上面的的测试准准则的例例子,也也不是很很恰当及及规范,至少缺缺少了数数据度量量部分,这里只只是拿出出来和大大家一起起交流。这部分分内容我我一直认认为是很很重要的的,如果果做的不不好,测测试组的的负担会会很重。 需要注注意的一一点是:测试准准则,是是在制定定测试计计划时沟沟通确定定的,它它需要和和相关人人沟通,且得到到项目经经理审批批通过的的。 测试准准则是固固定的,实际处处理方式式是灵活活的。在在实际测测试过程程中碰到到同样的的问题,是否继继续测试试,或者者需要暂暂停测试试,处理理方式不不是一成成不变的的,这是是需要根根据项目目所处阶阶段来具具体情况况具体分

28、分析的。 下面举举个例子子,这个个例子是是经常性性的一种种情况。假设在在测试过过程中,我们发发现了一一个阻塞塞性错误误(流程程无法继继续往下下走等类类似情况况),是是否继续续进行测测试呢? 在在项目初初期,进进行单个个或多个个模块的的测试时时:因为为可以执执行界面面测试及及熟悉系系统,我我们可以以接受该该版本,继续进进行测试试。这就就属于已已提交测测试内容容所能完完成的测测试。在在项目测测试初期期,要求求不可过过于严格格。 系系统测试试:基本本流程必必须走通通。如果果基本业业务流程程(主干干)不能能走通,则需要要根据实实际情况况来灵活活处理。(是否否暂停测测试或继继续测试试?)如如果是整整个流

29、程程的初始始节点失失效,没没有这个个节点的的数据,后面所所有节点点均无法法进行,那么这这种情况况下就只只能暂停停测试。如果说说是分支支流程出出现阻塞塞,那么么可以考考虑继续续测试,然后在在测试报报告中说说明该分分支未测测试。此此时不暂暂停测试试,主要要是考虑虑重新集集成一个个版本的的性价比比,也就就是是否否值得重重新集成成。 发发布前的的确认测测试:一一旦有阻阻塞性缺缺陷,马马上停止止测试。2.2 测试实实施过程程 上面说说的是测测试过程程。下面面简单介介绍一下下我们实实际的测测试工作作。 我们的的测试组组一般是是在项目目启动时时进入项项目组的的。在项项目立项项时,项项目经理理会向测测试部经经

30、理申请请测试资资源。经经过评估估衡量后后,测试试部经理理会安排排一个测测试人员员作为项项目测试试组长。当项目目启动时时,测试试组长进进入项目目,开始始了解项项目用户户需求,起草项项目测试试计划。在到了了一定阶阶段,例例如测试试设计阶阶段,测测试部经经理会根根据项目目规模,项目在在公司的的重要性性以及团团队其他他人员工工作负荷荷情况,安排其其他人进进入项目目组。一一般来说说,我们们一个项项目是223名名测试人人员。在在项目进进入维护护阶段时时,则是是一个测测试人员员跟进项项目。 测试组组长根据据项目情情况及项项目阶段段计划,定义项项目本阶阶段测试试次数。项目经经理参考考测试组组长提供供的测试试次

31、数建建议,以以及项目目开发的的情况,和项目目组各个个小组负负责人沟沟通后,定义了了系统本本阶段版版本集成成时间。在我们们的项目目里,有有一个开开发人员员兼职做做集成人人员。在在指定的的版本集集成时间间之前的的一段时时间,各各个开发发人员将将他们的的程序提提交配置置库,由由集成人人员进行行集成(不同语语言有不不同的集集成方式式)。集集成后,集成人人员会进进行简单单的自测测,验证证是否集集成成功功。如果果集成成成功,就就在服务务器上给给该版本本程序打打上标签签。如果果集成不不成功,那么返返工给相相应开发发人员修修改并重重新集成成,如此此反复直直至集成成成功。集成成成功后,集成人人员会提提交一份份集

32、成说说明给测测试组长长。集成成说明内内容包括括:集成成版本路路径、版版本标签签、修改改内容、新增内内容等。测试组组长则根根据预先先准备好好的测试试计划开开始测试试。在开开始测试试时测试试组长会会通知项项目组,告诉他他们测试试开始,请勿更更新测试试环境。测试结结束后,也会通通知项目目组测试试结束。 这里要要很注意意一点的的是,对对于数据据库的更更新也需需要采用用同样的的管理,即数据据库维护护也是需需要进行行统一管管理,避避免出现现客户环环境和测测试环境境不一致致的情况况。在正常情情况下,开发组组是在预预定的集集成日期期的当天天晚上集集成,测测试组第第二天上上班后开开始测试试。如果果遇到特特殊情况

33、况需要当当天集成成当天测测试的话话,我们们的开发发人员会会等到测测试组发发出测试试结束的的通知后后,才离离岗。 如果在在完成计计划的测测试次数数后,系系统质量量仍不稳稳定或没没有达到到预期目目标的话话,那么么测试组组长将和和项目经经理沟通通,相应应增加测测试次数数。 关于测测试用例例的执行行,我不不知道公公司现在在是采用用怎样的的一种方方式的。在我原原来的团团队中,测试用用例的主主要作用用是保证证系统功功能的测测试覆盖盖率,避避免某些些功能因因为测试试周期长长而导致致测试遗遗漏。但但是我们们也采用用经验法法、试探探法、转转换思维维的方式式进行测测试,所所以,我我们一般般使用测测试用例例执行33

34、4次次测试。这可能能和我们们的测试试用例设设计能力力有关。 在缺陷陷管理上上,整体体流程基基本类似似,但是是在缺陷陷分配上上,我们们测试人人员是直直接分配配给项目目缺陷分分配专员员,缺陷陷分配专专员一般般是由业业务分析析员担任任。缺陷陷分配专专员对缺缺陷进行行分析后后,再进进行缺陷陷的再分分配。对对于缺陷陷分配专专员处理理为不修修改的缺缺陷,测测试人员员需要进进行确认认。如果果测试人人员不认认可缺陷陷分配专专员的处处理意见见,可以以同他进进行沟通通,或向向相关人人员(如如项目经经理)提提出自己己的意见见,最终终以项目目经理的的意见为为准。在在系统阶阶段确认认测试前前的23天,测试组组长会将将系

35、统未未解决的的缺陷清清单给项项目经理理确认,并要求求项目经经理提供供缺陷应应对方案案。缺陷陷应对方方案在系系统发布布时,作作为项目目发布说说明的附附件。 我们是是采用公公司自主主开发的的缺陷管管理系统统进行缺缺陷管理理的,使使用exxcell、worrd进行行其他测测试工件件的编写写的。 3 如何搭搭建一个个高效的的测试团团队 俗话说说“工欲善善其事,必先利利其器”,要做做好测试试工作,首先需需要建立立并维护护一个高高效的测测试团队队。然而而,许多多小型软软件企业业却将测测试作为为产品面面临发布布时的一一个小“插曲”,往往往临时抽抽调几名名程序员员对产品品的功能能粗略测测试一下下即交付付客户(

36、甚至在在进度和和成本不不足时首首先砍掉掉这一块块)。这这种仓促促完成的的产品通通常质量量问题很很多,所所以我们们首先应应抛弃小小企业惯惯常的思思维模式式,不计计较一时时一地之之利益,立足长长远,着着手组建建高效测测试团队队。第一步:招募测测试人员员 在国内内的软件件企业中中有一种种普遍做做法,那那就是把把那些刚刚涉足软软件行业业的技术术新手或或业绩不不突出的的开发人人员安排排去做测测试工作作。笔者者认为这这绝对是是一种欠欠妥当的的行为。事实上上,对一一个系统统进行有有效测试试所需要要的技能能绝对不不比进行行软件开开发所需需要的技技能少,测试从从业者甚甚至可能能面对许许多开发发人员都都不会遇遇到

37、的技技术难题题。那么么,测试试团队需需要招募募什么样样的成员员呢?这这里,笔笔者总结结了以下下两点: 首首先,测测试人员员要具备备良好的的沟通能能力、自自信心、外交能能力、迁迁移能力力以及怀怀疑精神神。 其其次,测测试组成成员应具具备良好好的专业业技能或或者技术术学习能能力。 当然,新招募募的测试试人员不不可能像像上面说说的那么么理想。关键是是他们是是否热爱爱测试这这项工作作,对相相关的工工作内容容是否感感兴趣以以及他们们的学习习能力如如何。 第二步:测试团团队制度度建设 良好的的制度可可以规范范测试团团队的工工作开展展,同时时也便于于对团队队成员进进行业绩绩考评。相反,则很有有可能导导致人心心涣散,滋长负负面风气气。建设设良好的的测试团团队制度度,可以以考虑以以下几个个方面: 汇汇报制度度 团队队成员汇汇报本周周工作情情况及下下周工作作计划、遇到的的问题以以及需要要提供的的帮助,培养团团队成员员的汇报报及计划划习惯。 工工作总结结制度 成员每每个阶段段汇报上上阶段工工作经验验和教训训,并在在部门例例会上交交流、分分享经验验及教训训,避免免同样的的问题重重复出现现。 奖奖惩制度度 对于于贡献突突出的成成员予以以奖励,对于业业绩差的的提出批批评,有有效地保保持测试试团队的的工作热热情。 测测试件

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论