《测试计划安排及进度监控汇总》由会员分享,可在线阅读,更多相关《测试计划安排及进度监控汇总(17页珍藏版)》请在金锄头文库上搜索。
1、.测试计划安排与进度监控如果要测试一个大型系统,将面对在一年甚至更长的时间内编写、执行、验证成千上万的测试用例,处理上千的模块,修订成千上万的错误,雇用上千的员工,显然,这将在计划、监视、控制测试过程中面对无穷的项目管理方面的挑战。在计划一个测试过程时,主要的错误是默许对不发现任何错误的假设,这种错误明显的后果是大大低估了计划资源人、时间、计算机,这是计算机工业声名狼籍的一个问题。良好测试计划的组成:1目标:必须定义每个测试阶段的目标。2完成准则:设计准则来指定判断每个测试阶段何时完成。3进度:每个阶段都需要日程安排,指出何时设计、编写、执行测试用例。4职责:每个阶段必须识别设计、编写、执行和
2、验证测试用例的人员,修订被发现的错误的人员。在大型项目中,会引起有些测试结果是否是错误的争论,所以需要识别仲裁人。5测试用例库和标准:在一个大型项目中,必须要有系统的关于识别、编写、存储测试用例的方法。6工具:识别所需的测试工具,包括谁将开发或去获取工具,工具将如何被使用,何时是必需的。7计算机时间:这是关于每个测试阶段所需的计算机时间的总量的计划,包括编译应用程序的服务器、安装测试的桌面机、WEB应用的WEB服务器、网络设备等。8硬件配置:如果需要特殊的硬件配置或设备,需要一个计划来描述这种需求,它们如何满足、何时需要。9集成:测试计划的一部分是定义程序如何结合在一起如增量从上到下的测试,一
3、个包含大量子系统或程序的系统可以增量地结合起来。使用从上到下或从下到上的方法,但是构造块是程序或子系统,不是模块。如果情况是这样的,那么需要一个系统基础计划。系统集成计划定义了集成的次序,系统每个版本的功能,有责任去创建脚手架代码来仿真不存在的部件的功能。10跟踪过程:定义了机制来跟踪测试过程的方方面面,包括倾向于错误的模块的定位、计划、资源、完成准则等各方面进展的估计。11调试过程:定义了机制来报告检测到的错误,跟踪纠正的进展,将纠正好的添加到系统中。计划、职责、工具、计算机时间/资源都是调试计划的组成部分。12回归测试:作了功能改进或对程序修订后,需要执行回归测试。目的是确定改变是否已经回
4、归了程序的其他方面,一般是通过重新允许程序的测试用例的子集来执行。回归测试的重要性在于变更和纠错倾向于产生更多的错误,所以一份回归测试的计划谁、如何、何时是有必要的。如何制定软件项目测试计划摘要 随着测试走向规范化管理,测试计划成为测试经理必须完成的重要任务之一,本文根据实践经验结合理论,探讨如何制定软件项目测试计划。关键字 测试计划 变更正文软件测试计划作为软件项目计划的子计划,在项目启动初期是必须规划的。在越来越多公司的软件开发中,软件质量日益受到重视,测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中,这样,如何规划整个项目周期的测试工作;如何将测试工作上升到测试管理的高度
5、都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。一个好的测试计划可以起到如下作用 1 避免测试的事件驱动2 使测试工作和整个开发工作融合起来3 资源和变更事先作为一个可控制的风险测试计划的模板在各个公司中都XX小异,在个人实践中发现,测试计划制定中存在的问题具有相似性,下面重点就这些相似的问题谈谈如何制定软件项目测试计划。 问题一:测试阶段划分就通常软件项目而言,基本上采用瀑布型开发方式,这种开发方式下,各个项目主要活动比较清晰,易于操作。整个项目生命周期为需求设计编码测试发布实施维护。然而,在制定测试计划时候,有些测试经理对测试的阶段划分还不是十分明晰,经常性遇到的问题是
6、把测试单纯理解成系统测试,或者把把各类型测试设计测试用例的编写和测试数据准备全部放入生命周期的测试阶段,这样造成的问题是浪费了开发阶段可以并行的项目日程,另一方面造成测试不足。合理的测试阶段应遵循下面划分方法: 照上图所述,相应阶段可以同步进行相应的测试计划编制,而测试设计也可以结合在开发过程中实现并行,测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是:单元测试和集成测试往往由开发人员承担,因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。问题二:系统测试阶段日程安排划分阶段清楚了,随之而来的问题是测试执行需要多长的时间?标准的工程方法或CMM方式是对工作量进行估算,然后得出
7、具体的估算值。但是这种方法过于复杂,可以另辟专题讨论。一个可操作的简单方法是:根据测试执行上一阶段的活动时间进行换算,换算方法是与上一阶段活动时间1:1。11。5左右。举个例子,对测试经理来说,因为开发计划可能包含了单元测试和集成测试,系统测试的时间大概是编码阶段包含单元测试和集成测试1到1。5倍。这种方法的优点是简单,依赖于项目计划的日程安排,缺点是水分太多,难于量化。那么,可以采用的另一个简单方法是经验评估。评估方法如下:1 计算需求文档的页数,得出系统测试用例的页数需求页数:系统测试用例页数 1:1 2 由系统测试用例页数计算编写系统测试用例时间编写系统测试用例时间 系统测试用例页数1小
8、时3 计算执行系统测试用例时间编写系统用例用时:执行系统测试用时 1:24 计算回归测试包含的时间系统测试用时:回归测试用时 2:1注:以上比值是个人工程经验值,需要更正比值的测试经理可以在具体实践中收集数据。基于以上方法优点是需求为已知的,可以利用已知来推算未知,适用于需求是已知且相对稳定的情况下;缺点是处于研发状态的项目,需求不清晰的时候比较难计算。现套用一个例子加于说明:需求文档页数为500,系统测试用例页数推算为500,则编写系统测试用例时间为500小时,执行系统测试用例时间为1000小时,回归测试需要500小时,加起来总共为2000小时,按一天8小时计算,共计250个工作日/人;假如
9、一个月为22个工作日,则共计约11人/月,即投入4个人需要3个月左右时间工作量完成。当然,这是系统测试需要的全部时间。根据测试阶段划分原则,设计用例时间可以和开发同步进行,只需在测试阶段中安排的时间为1500小时即4人2个月工作量。测试经理在编写测试计划时候,测试进度中的计划开始/结束时间往往用如2005010-20051201的具体时间划分方式,这样引起的问题是当项目计划进行变更的时候,测试计划时间不得不随时调整,这种变更可能是频繁而琐碎的,可以替代的办法是取消这种方式,采用30工作日/2人或者2人月这种工作量记录方式,这样一来,只需在项目计划中跟踪阶段的具体开始时间即可,不必反复修改测试计
10、划。值得注意的是:国内大多数公司的测试时间都是不足的,不可能按照这样的理想比例进行运作,因为测试执行的时间实际上不可能占据整个项目周期的1/2,甚至要短于其中任何一个项目阶段时间。即使是微软的测试结束原则也并不是完成所有必需的测试,而是测试在按计划结束的那一天结束!在测试时间不足的情况下,可参考下面项目计划变更时的做法,因为计划变更也涉及到测试时间不足的情况。 问题三:变更的控制测试计划改变了已往根据任务进行测试的方式,因此,为使测试计划得到贯彻和落实,测试组人员必须及时跟踪软件开发的过程,对产品提交测试做准备,测试计划的目的,本身就是强调按规划的测试战略进行测试,淘汰以往以任务为主的临时性。
11、在这种情况下,测试计划中强调对变更的控制显得尤为重要。变更来源于以下几个方面1 项目计划的变更2 需求的变更3 测试产品版本的变更4 测试资源的变更测试阶段的风险主要是对上述变更所造成的不确定性,有效的应对这些变更就能降低风险发生的几率。要想计划本身不成为空谈和空白无用的纸质文档,对不确定因素的预见和事先防范必须做到心中有数。对于项目计划的变更,除了测试人员及时跟进项目以外,项目经理必须认识到测试组也是项目成员,因此必须把这些变更信息及时通知到项目组,使得整个项目得到顺延。项目计划变更一般涉及都是日程变更,令人遗憾的是,往往为了进度的原因,交付期限是既定的,项目经理不得不减少测试的时间,这样,
12、执行测试的时间就被压缩了。在这种情况下,测试经理常常固执的认为进度缩减的唯一的方法就是向上级通报并主观认为产品质量一定会下降,这种做法和想法不一定是正确的。由于时间不足,不能完美的执行所有测试,为了保证质量,第一种办法是调整测试计划中的测试策略和测试范围,实践中测试经理常常忽略测试计划的这个章节。调整的目的是重新检查不重要的测试部分,调换测试的次序和减少测试规模,对测试类型重新组合择优,力求在限定时间内做最重要部分的测试,可以把忽略部分留给确认测试或现场测试。其他应对办法包括减少进入测试的阻力,例如降低测试计划中系统测试准入准则;分步提交测试,例如改成迭代方式增量测试;减少回归测试的要求,例如
13、开发人员实时修改,在测试计划中对缺陷修复响应时间和过程进行约定;和公司QA商量进行简化配置管理,跳过正式发布环节;缺陷进行局部回归而不是重新全部测试等等。第二:项目进行过程中最不可避免的就是需求的变更。那么,测试计划中就不能进行控制和约束的吗?答案是未必。当制定计划时,如果项目需求处于动态变化时,在测试用例章节就要进行说明。许多测试经理在编制测试用例时往往没有把测试用例和测试数据进行区分,因此,造成的问题是当需求变化时辛辛苦苦设计的数据就作废了。在这时,假使面临一个需求动态的项目,必须在计划中对需求变更造成的测试设计方式变化进行说明,例如采用用例和数据分离、流程和界面分离、字典项和数据元素分离
14、的设计方式,然后等到最终需求确定后细化测试设计;另一个方面是最好制定一个变更周期的约定尤其在执行测试阶段发现需求的变更定义变更的最大频度和重新测试的界限,计划从一定程度上能够降低不可预期需求变化造成的投入损失。值得注意的是:需求发生变更时测试经理额外的工作是记住要在需求跟踪矩阵上做记录。对于测试产品版本的变更,除了部分是由于需求变更造成之外,很有可能是由于修改缺陷引发的问题或配置管理不严格造成。众所周知,测试必须是基于一个稳定的基线进行,否则,因反复修改造成测试资源和开发资源的浪费是可观的。合理的测试计划在章节中应增加一个测试更新管理的章节,在此章节明确更新周期和暂停测试的原则。例如,小版本的
15、产品更新不能大于每天三次,一个相对大的版本不能每周大于1次,规定紧急发布产品仅限于何种类型的修改或变更,由谁负责统一维护和同步更新测试环境。测试计划通常制定了准入和准出准则,这是不够的,要考虑测试暂停的时候,产品错误发布或者服务器数据更新就是一个例子,暂停的时候如果测试经理不进行跟踪,可能发生测试组等待测试而没人通知继续测试的情况,所以,增加更新周期和暂停测试原则是很有必要的。 最后,测试资源的变更是源自测试组内部的风险而非开发组风险,当测试资源不足或者冲突,测试部门不可能安排如此多的人手和足够时间参与测试时,在测试计划中的控制方法与测试时间不足相类似。没有测试经理愿意承担资源不足的测试工作,只能说公司本身是否具备以质量为主的体系或者项目经理对产品质量的重视程度如何决定了对测试资源投入的大小,最终产品质量取决因素不仅仅在于测试经理。为了排除这种风险,除了象时间不足、测试计划变更时那样缩减测试规模等等方法以外,测试经理必须在人力资源和测试环境一栏标出明确需要保证的资源,否则,必须将这个问题作为风险记录。规避风险的办法可能有:一,项目组的需求和实施人员参与系统测试;二,抽调不同模块开发者进行交叉系统测试或借用其他项目开发人员;三,组织客户方进行确