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

测试计划安排与进度监控

如果要测试一个大型系统，将面对在一年甚至更长的时间内编写、执行、验证成千上万的测试用例，处理上千的模块，修订成千上万的错误，雇用上千的员工，显然，这将在计划、监视、控制测试过程中面对无穷的工程管理方面的挑战。在计划一个测试过程时，主要的错误是默许对不发现任何错误的假设，这种错误明显的后果是大大低估了计划资源（人、时间、计算机），这是计算机工业声名狼籍的一个问题。良好测试计划的组成：（1）目标：必须定义每个测试阶段的目标。（2）完成准则：设计准则来指定判断每个测试阶段何时完成。（3）进度：每个阶段都需要日程安排，指出何时设

计、编写、执行测试用例。（4）职责：每个阶段必须识别设计、编写、执行和验证测试用例的人员，修订被发现的错误的人员。在大型工程中，会引起有些测试结果是否是错误的争论，所以需要识别仲裁人。（5）测试用例库和标准：在一个大型工程中，必须

要有系统的关于识别、编写、存储测试用例的方法。（6）工具：识别所需的测试工具，包括谁将开发或去获取工具，工具将如何被使用，何时是必需的。（7）计算机时间：这是关于每个测试阶段所需的计算机时间的总量的计划，包括编译应用程序的服务器、安装测试的桌面机、WEB应用的WEB服务器、网络设备等。（8）硬件配置：如果需要特殊的硬件配置或设备，需要一个计划来描述这种需求，它们如何满足、何时需要。（9）集成：测试计划的一部分是定义程序如何结合在一起（如增量从上到下的测试），一个包含大量子系统或程序的系统可以增量地结合起来。使用从上到下或从下到上的方法，但是构造块是程序或子系统，不是模块。如果情况是这样的，那么需要一个系统基础计划。系统集成计划定义了集成的次序，系统每个版本的功能，有责任去创建“脚手架”代码来仿真不存在的部件的功能。（10）跟踪过程：定义了机制来跟踪测试过程的方方面面，包括倾向于错误的模块的定位、计划、资源、完成准则等各方面进展的估计。（11）调试过程：定义了机制来报告检测到的错误，跟踪纠正的进展，将纠正好的添加到系统中。计划、职责、工具、计算机时间/ 资源都是调试计划的组成部分。（12）回归

测试：作了功能改进或对程序修订后，需要执行回归测试。目的是确定改变是否已经回归了程序的其他方面，一般是通过重新允许程序的测试用例的子集来执行。回归测试的重要性在于变更和纠错倾向于产生更多的错误，所以一份回归测试的计划（谁、如何、何时）是有必要的。

如何制定软件工程测试计划

摘要随着测试走向规范化管理，测试计划成为测试经理必须完成的重要任务之一，本文根据实践经验结合理论，探讨如何制定软件工程测试计划。

关键字测试计划变更

正文软件测试计划作为软件工程计划的子计划，在工程启动初期是必须规划的。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中，这样，如何规划整个工程周期的测试工作；如何将测试工作上升到测试管理的高度都

依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。

一个好的测试计划可以起到如下作用

1．避免测试的“事件驱动”

2．使测试工作和整个开发工作融合起来

3．资源和变更事先作为一个可控制的风险

测试计划的模板在各个公司中都大同小异，在个人实践中发现，测试计划制定中存在的问题具有相似性，下面重点就这些相似的问题谈谈如何制定软件工程测试计划。

问题一：测试阶段划分

就通常软件工程而言，基本上采用“瀑布型”开发方式，这种开发方式下，各个工程主要活动比较清晰，易于操作。整个工程生命周期为“需求－设计－编码－测试－发布－实施－维护”。然而，在制定测试计划时候，有些测试经理对测试的阶段划分还不是十分明晰，经常性遇到的问题是把测试单纯理解成系统测试，或者把把各类型测试设计（测试用例的编写和测试数据准备）全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的工程日程，另一方面造成测试不足。

合理的测试阶段应遵循下面划分方法：

照上图所述，相应阶段可以同步进行相应的测试计划编制，而测试设计也可以结合在开发过程中实现并行，测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是：单元测试和集成测试往往由开发人员承担，因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。

问题二：系统测试阶段日程安排

划分阶段清楚了，随之而来的问题是测试执行需要多长的时间？标准的工程方法或CMM 方式是对工作量进行估算，然后得出具体的估算值。但是这种方法过于复杂，可以另辟专题讨论。一个可操作的简单方法是：根据测

试执行

上一阶段的活动时间进行换算，换算方法是与上一阶段活动时间1：1 。

1~1 。

5左右。举个例子，对测试经理来说，因为开发计划可能包含了单元测试和集成测试，系统测试的时间大概是编码阶段（包含单元测试和集成测试）1到1。5

倍。这种方法的优点是简单，依赖于工程计划的日程安排，缺点是水分太多，难于量化。那么，可以采用的另一个简单方法是经验评估。评估方法如下：

1．计算需求文档的页数，得出系统测试用例的页数需求页数：系统测试用例页数≈ 1 ：1

2．由系统测试用例页数计算编写系统测试用例时间编写系统测试用例时间≈ 系统测试用例页数× 1 小时3．计算执行系统测试用例时间

编写系统用例用时：执行系统测试用时≈ 1 ：2

4．计算回归测试包含的时间

系统测试用时：回归测试用时≈ 2：1 注：以上比值是个人工程经验值，需要更正比值的测试经理可以在具体实践中收集数据。

基于以上方法优点是需求为已知的，可以利用已知来推算未知，适用于需求是已知且相对稳定的情况下；缺点是处于研发状态的工程，需求不清晰的时候比较难计算。现套用一个例子加于说明：需求文档页数为500 ，系统测试用例页数推算为500 ，则编写系统测试用例时间为500 小时，执行系统测试用例时间为1000小时，回归测试需要500小时，加起来总共为2000小时，按一天8小时计算，共计250个工作日/人；假如一个月为22个工作日，则共计约11人/ 月，即投入4个人需要3个月左右时间工作量