测试计划安排与进度监控汇总.docx

测试计划安排与进度监控如果要测试一个大型系统， 将面对在一年甚至更长的时间内编写、 执行、 验证成千上万的测试用例，处理上千的模块，修订成千上万的错误，雇用上千的员工，显然，这将在计划、监视、控制测试过程中面对无穷的项目管理方面的挑战在计划一个测试过程时， 主要的错误是默许对不发现任何错误的假设， 这种错误明显的后果是大大低估了计划资源（人、时间、计算机） ，这是计算机工业声名狼籍的一个问题良好测试计划的组成：（ 1）目标：必须定义每个测试阶段的目标 2）完成准则：设计准则来指定判断每个测试阶段何时完成 3）进度：每个阶段都需要日程安排，指出何时设计、编写、执行测试用例 4）职责：每个阶段必须识别设计、编写、执行和验证测试用例的人员，修订被发现的错误的人员 在大型项目中， 会引起有些测试结果是否是错误的争论， 所以需要识别仲裁人 5）测试用例库和标准：在一个大型项目中，必须要有系统的关于识别、编写、存储测试用例的方法 6）工具：识别所需的测试工具，包括谁将开发或去获取工具，工具将如何被使用，何时是必需的 7）计算机时间：这是关于每个测试阶段所需的计算机时间的总量的计划，包括编译应用程序的服务器、安装测试的桌面机、WEB应用的 WEB服务器、网络设备等。

8）硬件配置：如果需要特殊的硬件配置或设备，需要一个计划来描述这种需求，它们如何满足、何时需要 9）集成：测试计划的一部分是定义程序如何结合在一起（如增量从上到下的测试）一个包含大量子系统或程序的系统可以增量地结合起来使用从上到下或从下到上的方法，但是构造块是程序或子系统，不是模块如果情况是这样的，那么需要一个系统基础计划系统集成计划定义了集成的次序， 系统每个版本的功能， 有责任去创建“脚手架”代码来仿真不存在的部件的功能，（ 10）跟踪过程： 定义了机制来跟踪测试过程的方方面面，位、计划、资源、完成准则等各方面进展的估计包括倾向于错误的模块的定（11）调试过程：定义了机制来报告检测到的错误，跟踪纠正的进展，将纠正好的添加到系统中计划、职责、工具、计算机时间 / 资源都是调试计划的组成部分12）回归测试：作了功能改进或对程序修订后，需要执行回归测试目的是确定改变是否已经回归了程序的其他方面， 一般是通过重新允许程序的测试用例的子集来执行 回归测试的重要性在于变更和纠错倾向于产生更多的错误， 所以一份回归测试的计划 （谁、如何、何时）是有必要的如何制定软件项目测试计划摘要 随着测试走向规范化管理， 测试计划成为测试经理必须完成的重要任务之一，本文根据实践经验结合理论，探讨如何制定软件项目测试计划。

关键字 测试计划 变更正文软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的在越来越多公司的软件开发中， 软件质量日益受到重视， 测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中， 这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定测试计划因此也成为测试工作的赖于展开的基础一个好的测试计划可以起到如下作用1． 避免测试的“事件驱动”2． 使测试工作和整个开发工作融合起来3． 资源和变更事先作为一个可控制的风险测试计划的模板在各个公司中都大同小异， 在个人实践中发现， 测试计划制定中存在的问题具有相似性， 下面重点就这些相似的问题谈谈如何制定软件项目测试计划问题一：测试阶段划分就通常软件项目而言，基本上采用“瀑布型”开发方式，这种开发方式下，各个项目主要活动比较清晰， 易于操作整个项目生命周期为“需求－设计－编码－测试－发布－实施－维护” 然而，在制定测试计划时候， 有些测试经理对测试的阶段划分还不是十分明晰， 经常性遇到的问题是把测试单纯理解成系统测试，或者把把各类型测试设计 （测试用例的编写和测试数据准备） 全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的项目日程，另一方面造成测试不足。

合理的测试阶段应遵循下面划分方法：照上图所述，相应阶段可以同步进行相应的测试计划编制， 而测试设计也可以结合在开发过程中实现并行， 测试的实施即执行测试的活动即可连贯在开发之后值得注意的是： 单元测试和集成测试往往由开发人员承担， 因此这部分的阶段划分可能会安排在开发计划而不是测试计划中问题二：系统测试阶段日程安排划分阶段清楚了，随之而来的问题是测试执行需要多长的时间？标准的工程方法或 CMM 方式是对工作量进行估算，然后得出具体的估算值但是这种方法过于复杂， 可以另辟专题讨论 一个可操作的简单方法是： 根据测试执行上一阶段的活动时间进行换算， 换算方法是与上一阶段活动时间 1 ：1 1~1 举个例子，对测试经理来说， 因为开发计划可能包含了单元测试和集成测试， 系统测试的时间大概是编码阶段（包含单元测试和集成测试） 1 到1这种方法的优点是简单，依赖于项目计划的日程安排，缺点是水分太多，难于量化那么，可以采用的另一个简单方法是经验评估评估方法如下：1． 计算需求文档的页数，得出系统测试用例的页数需求页数：系统测试用例页数 ≈ 1：12． 由系统测试用例页数计算编写系统测试用例时间编写系统测试用例时间 ≈ 系统测试用例页数× 1小时3． 计算执行系统测试用例时间编写系统用例用时：执行系统测试用时 ≈ 1：24． 计算回归测试包含的时间系统测试用时：回归测试用时≈ 2 ： 1注：以上比值是个人工程经验值， 需要更正比值的测试经理可以在具体实践中收集数据。

基于以上方法优点是需求为已知的， 可以利用已知来推算未知， 适用于需求是已知且相对稳定的情况下； 缺点是处于研发状态的项目， 需求不清晰的时候比较难计算现套用一个例子加于说明：需求文档页数为 500 ，系统测试用例页数推算为 500 ，则编写系统测试用例时间为 500 小时，执行系统测试用例时间为1000 小时，回归测试需要 500 小时，加起来总共为 2000 小时，按一天 8 小时计算，共计 250 个工作日 / 人；假如一个月为 22 个工作日，则共计约 11 人 / 月，即投入 4个人需要 3个月左右时间工作量完成当然，这是系统测试需要的全部时间根据测试阶段划分原则， 设计用例时间可以和开发同步进行， 只需在测试阶段中安排的时间为 1500 小时即 4人2 个月工作量测试经理在编写测试计划时候，测试进度中的计划开始 / 结束时间往往用如 2005010-20051201 的具体时间划分方式，这样引起的问题是当项目计划进行变更的时候，测试计划时间不得不随时调整，这种变更可能是频繁而琐碎的，可以替代的办法是取消这种方式， 采用 30 工作日 /2 人或者 2 人月这种工作量记录方式，这样一来，只需在项目计划中跟踪阶段的具体开始时间即可， 不必反复修改测试计划。

值得注意的是： 国内大多数公司的测试时间都是不足的， 不可能按照这样的理想比例进行运作，因为测试执行的时间实际上不可能占据整个项目周期的 1/2 ，甚至要短于其中任何一个项目阶段时间 即使是微软的测试结束原则也并不是完成所有必需的测试，而是测试在按计划结束的那一天结束！在测试时间不足的情况下，可参考下面项目计划变更时的做法，因为计划变更也涉及到测试时间不足的情况问题三：变更的控制测试计划改变了已往根据任务进行测试的方式， 因此，为使测试计划得到贯彻和落实，测试组人员必须及时跟踪软件开发的过程，对产品提交测试做准备，测试计划的目的， 本身就是强调按规划的测试战略进行测试， 淘汰以往以任务为主的临时性在这种情况下，测试计划中强调对变更的控制显得尤为重要变更来源于以下几个方面1． 项目计划的变更2． 需求的变更3． 测试产品版本的变更4． 测试资源的变更测试阶段的风险主要是对上述变更所造成的不确定性， 有效的应对这些变更就能降低风险发生的几率 要想计划本身不成为空谈和空白无用的纸质文档， 对不确定因素的预见和事先防范必须做到心中有数对于项目计划的变更， 除了测试人员及时跟进项目以外， 项目经理必须认识到测试组也是项目成员， 因此必须把这些变更信息及时通知到项目组， 使得整个项目得到顺延。

项目计划变更一般涉及都是日程变更， 令人遗憾的是， 往往为了进度的原因，交付期限是既定的，项目经理不得不减少测试的时间，这样，执行测试的时间就被压缩了 在这种情况下， 测试经理常常固执的认为进度缩减的唯一的方法就是向上级通报并主观认为产品质量一定会下降， 这种做法和想法不一定是正确的由于时间不足，不能“完美”的执行所有测试，为了保证质量，第一种办法是调整测试计划中的测试策略和测试范围， 实践中测试经理常常忽略测试计划的这个章节 调整的目的是重新检查不重要的测试部分， 调换测试的次序和减少测试规模， 对测试类型重新组合择优， 力求在限定时间内做最重要部分的测试，可以把忽略部分留给确认测试或现场测试 其他应对办法包括减少进入测试的阻力，例如降低测试计划中系统测试准入准则； 分步提交测试， 例如改成迭代方式增量测试； 减少回归测试的要求， 例如开发人员实时修改， 在测试计划中对缺陷修复响应时间和过程进行约定； 和公司 QA 商量进行简化配置管理， 跳过正式发布环节；缺陷进行局部回归而不是重新全部测试等等第二：项目进行过程中最不可避免的就是需求的变更 那么，测试计划中就不能进行控制和约束的吗？答案是未必。

当制定计划时， 如果项目需求处于动态变化时，在测试用例章节就要进行说明许多测试经理在编制测试用例时往往没有把测试用例和测试数据进行区分，因此，造成的问题是当需求变化时辛辛苦苦设计的数据就作废了 在这时，假使面临一个需求动态的项目， 必须在计划中对需求变更造成的测试 （设计）方式变化进行说明， 例如采用用例和数据分离、 流程和界面分离、 字典项和数据元素分离的设计方式， 然后等到最终需求确定后细化测试设计； 另一个方面是最好制定一个变更周期的约定――尤其在执行测试阶段发现需求的变更――定义变更的最大频度和重新测试的界限， 计划从一定程度上能够降低不可预期需求变化造成的投入损失值得注意的是： 需求发生变更时测试经理额外的工作是记住要在需求跟踪矩阵上做记录对于测试产品版本的变更， 除了部分是由于需求变更造成之外， 很有可能是由于修改缺陷引发的问题或配置管理不严格造成 众所周知，测试必须是基于一个稳定的“基线”进行， 否则，因反复修改造成测试资源和开发资。