欢迎来到天天文库
浏览记录
ID:44149749
大小:91.05 KB
页数:5页
时间:2019-10-19
《如何制定软件项目测试计划》由会员上传分享,免费在线阅读,更多相关内容在工程资料-天天文库。
1、如何制定软件项目测试计划软件测试计划作为软件项日计划的子计划,在项1=1启动初期是必须规划的。在越来越多公司的软件开发屮,软件质量日益受到重视,测试过程也从一个相对独立的步骤越來越紧密嵌套在软件整个生命周期中,这样,如何规划整个项目周期的测试工作;如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。一个好的测试计划可以起到如下作用1.避免测试的“事件驱动”2.使测试工作和整个开发工作融合起来3.资源和变更事先作为一个可控制的风险测试计划的模板在各个公司屮都大同小异,在个人实践屮发现,测试计划制定屮存在的问题具有相似性,下面重点就这些相似的问题谈
2、谈如何制定软件项日测试计划。问题一:测试阶段划分就通常软件项目而言,基本上采用“瀑布型”开发方式,这种开发方式下,各个项目主要活动比较清晰,易于操作。整个项目生命周期为“需求一设计一编码一测试一发布一实施一维护”。然而,在制定测试计划时候,有些测试经理对测试的阶段划分还不是十分明晰,经常性遇到的问题是把测试单纯理解成系统测试,或者把把各类型测试设计(测试用例的编写和测试数据准备)全部放入生命周期的“测试阶段”,这样造成的问题是浪费了开发阶段可以并行的项目FI程,另一方面造成测试不足。合理的测试阶段应遵循下面划分方法:照上图所述,相应阶段可以同步进行和应的测试计划编制,而测试设计也可以结合在开发
3、过程中实现并行,测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是:单元测试和集成测试往往由开发人员承担,因此这部分的阶段划分可能会安排在开发计划而不是测试计划屮。问题二:系统测试阶段日程安排划分阶段清楚了,随之而来的问题是测试执行需要多长的时间?标准的工程方法或CMM方式是对T作量进行估算,然后得岀具体的估算值。但是这种方法过于复朵,可以另辟专题讨论。一个可操作的简单方法是:根据测试执行上一阶段的活动时间进行换算,换算方法是与上一阶段活动时间1:lorio5左右。举个例子,对测试经理来说,因为开发计划可能包含了单元测试和集成测试,系统测试的时间人概是编码阶段(包含单元测试和集成测试)
4、1到1。5倍。这种方法的优点是简单,依赖于项H计划的日程安排,缺点是水分太多,难于量化。那么,可以采用的另一个简单方法是经验评估。评估方法如下:1.计算需求文档的页数,得出系统测试用例的页数需求页数:系统测试用例页数1:12.由系统测试用例页数计算编写系统测试用例时间编写系统测试用例时间〜系统测试用例页数XI小时3.计算执行系统测试用例时间编写系统用例用时:执行系统测试用时〜1:24.计算冋归测试包含的时间系统测试用时:回归测试用时~2:1注:以上比值是个人工程经验值,需要更正比值的测试经理可以在具体实践屮收集数据。基于以上方法优点是需求为已知的,可以利用已知來推算未知,适用于需求是已知且相对
5、稳定的情况下;缺点是处于研发状态的项目,需求不清晰的时候比较难计算。现套用一个例子加于说明:需求文档页数为500,系统测试用例页数推算为500,则编写系统测试用例时间为500小时,执行系统测试用例时间为1000小时,冋归测试需要500小时,加起來总共为2000小时,按一天8小时计算,共计250个工作□/人;假如一个月为22个工作口,则共计约11人/月,即投入4个人需要3个月左右时间工作量完成。当然,这是系统测试需要的全部时间。根据测试阶段划分原则,设计用例时间可以和开发同步进行,只需在测试阶段中安排的时间为1500小时即4人2个月工作量。(测试经理在编写测试计划时候,测试进度中的计划开始/结束
6、时间往往用如20050101-20051201的具体时间划分方式,这样引起的问题是当项目计划进行变更的时候,测试计划时间不得不随时调整,这种变更可能是频繁而琐碎的,可以替代的办法是取消这种方式,采用30工作日/2人或者2人月这种工作量记录方式,这样一来,只需在项冃计划中跟踪阶段的具体开始时间即可,不必反复修改测试计划。)值得注意的是:国内大多数公司的测试时间都是不足的,不可能按照这样的理想比例进行运作,因为测试执行的时间实际上不可能占据整个项忖周期的1/2,甚至要短于其中任何一个项忖阶段时间。即使是微软的测试结束原则也并不是完成所有必需的测试,而是测试在按计划结朿的那一天结朿!在测试时间不足的
7、情况下,可参考下面项冃计划变更时的做法,因为计划变更也涉及到测试时间不足的情况。问题三:变更的控制测试计划改变了己往根据任务进行测试的方式,因此,为使测试计划得到贯彻和落实,测试组人员必须及时跟踪软件开发的过程,对产品提交测试做准备,测试计划的目的,本身就是强调按规划的测试战略进行测试,淘汰以往以任务为主的临时性。在这种情况下,测试计划中强调对变更的控制显得尤为重要。变更来源于以下儿个方面1.项目
此文档下载收益归作者所有