项目管理协会[PMI-2004]把项目正式定义为“创建某种特有的产品或者服务的临时性工作”。这意味着每个项目都有一个明确的开始和一个明确的结束，而且产品或者服务能以某种方式与类似的产品或者服务区分开来。
测试被集成到创建给定产品或者服务的工作中，每个测试阶段和测试类型都有不同的性质，对每个版本的测试内容也可能不同。因此，测试完全符合这种关于项目的定义。
由于测试本身可以看作是一种项目，因此也需要测试、执行、跟踪和定期报告。
测试策划
准备测试计划
1、什么需要测试----测试的范围，需要清晰地确定要测试什么，不测试什么
2、测试应该如何实施-----将测试分解为小的可管理的任务，并确定完成这些任务要采取的措施。
3、测试需要什么资源-----计算机和人力资源。
4、测试活动展开的时间线。
5、所有以上面临的风险，以及合适的对应和处置计划。
测试范围管理：决定要测试和不测试的特性
有各种测试团队完成不同测试阶段的测试工作，准备一份统一的测试计划可以包含所有阶段或每类测试准备一份计划。例如，需要单元测试、集成测试、性能测试、确认测试等的计划。这些内容可以是一份统一计划的一部分，也可以包含在多份计划中，对于多份测试计划的情况，应该有一份计划包含所有计划的公共活动，这种计划叫主测试计划。
范围管理要描述项目的范围，包括：
1、理解哪些内容构成产品的发布版本
2、将发布版本分解为特性
3、确定特性测试的优先级
4、确定哪些要测试哪些不需要测试
5、收集数据，准备估计测试资源
最好从确定项目的最终目标或者产品发布版本视角开始，获得整个产品的完整图像，以确定测试范围和优先级。通常，在发布版本的策划阶段要确定构成发布版本的特性，例如，仓库控制系统的某个特定发布版本可能引入新特性，以自动集成供应链管理，并向用户提供各种成本核算。测试团队应该在策划周期的初期参与策划并了解特性，了解特性并从使用角度进行了解，是测试团队能够确定测试的优先级。
选择并确定待测特性的优先级有以下考虑因素：
新特性的对发布版本至关重要的特性发布版本的新特性确立了客户的预期，必须能正确运行。这些新特特性会引入新的程序代码，因此更容易引入和发生缺陷。不仅如此，这些新特性很可能对于开发团队和测试团队来说都有个熟悉的过程。因此，把这些特性放在优先测试的位置上是合理的。
失效会造成严重后果的特性不管特性是否新创建，其失效有可能产生严重后果，或对商业拓展带来负面影响的特性，都应该是测试重点。
有可能测试起来很复杂的特性团队应该尽早参与很难测试的特性。
对以前容易出现错误的特性的拓展特性有些区域的代码很容易出现缺陷，需要彻底测试，以防老的缺陷再次蔓延。这些容易出现缺陷的特性应该在更稳定的特性前进行测试。
由于资源和时间的限制，很可能不能穷尽测试所有组合，在策划时，测试经理应该精心确定不测试的特性和特性组合。应该综合考虑时间和资源的需求，同时不会使严重缺陷暴露给用户。因此，测试计划应该就不测试特定组合的理由，以及不测试面临的风险作出明确的分析。
确定测试方法和策略
深入分析需要测试的细节，估计规模、工作量和进度，包括确定：
1、测试各个功能需要使用什么测试类型？
2、测试特性需要什么配置或场景？
3、采用什么样的集成测试以及保证这些特性能够协调运行？
4、需要怎样的本地化确认？
5、需要作什么“非功能”测试？
确定测试准则
各个阶段都应该有明确的进入和退出准则。各种特性和特性组合的测试策略应该确定如何对其进行测试。在理想的情况下，必须尽早进行测试，以最大限度地降低开发拖延后给执行测试带来的巨大压力。
测试的进入准则：每个测试阶段或者类型的门槛准则，这个测试活动的开始也可以有进入准则。
完成/退出准则：什么时候测试周期或者测试活动可以结束，如果没有客观的退出准则，测试就有可能继续下去，超过最佳回报点。
挂起准则：什么时候测试应该被挂起，什么时候挂起的测试可以接着执行。包括：
1、遇到超过一定数量的缺陷，是测试活动频繁中断。
2、遇到测试不能继续进行的严重问题
3、开发人员提供了新版本，希望用期替代正在测试的版本（由于修复了某些重要的缺陷）。
确定责任、人员和培训计划
确定资源需求
确定测试可交付的产品
测试任务：规模与工作量估计
规模估计、工作量估计、进度估计
被测产品的规模（被测产品越大，测试量越大）
1、代码行数
2、功能点
3、表示应用程序规模的一种简单的方法是屏幕数、报表数或者事务数。
所需自动化范围
要测试平台和互操作环境的数量
规模估计可以采用以下任何形式表述：
1、测试用例数
2、测试场景数
3、要测试的场景数
工作量估计有：
生产率数据
生产率指各种测试活动的完成速度，其基石公司内部可以得到的历史数据（每天可以开发的用例数、每天可以运行的测试用例数、每天可以测试的文档页数等）。有了这些细粒度的生产率就可以更好进行策划，并提高估计的可信水平和准确性。
重用机会
过程健壮性
1、针对编写测试规格说明、测试脚本等的形成规范文档的标准
2、针对完成评审、审计等活动的经过实践检验是很有效的过程
3、一致的人员培训方法
4、度量遵循过程有效性的客观方法
工作量估算以人天、人月或者人年的形式给出。再把工作量估计转换为进度估计。
活动分解与进度估计
活动分解与进度估计将所需的工作量转换为具体的时间帧，包含以下步骤：
1、确定活动之间的外部和内部依赖关系
2、根据预期所需的工期和依赖关系确定活动完成的顺序
3、根据以上两个因素确定每个工作分解结构活动所需要的时间
4、监视项目实际时间的工作量的耗费情况
5、需要时重新协调进度和资源
常见的外部依赖关系：
1、开发人员是否按时提交产品
2、招聘
3、培训以及所需的软硬件资源
4、是否有供测试的经过转换的消息文件
内部依赖关系包括：
1、测试规格说明的完成
2、测试用例的编码和脚本化
3、测试的执行
沟通管理
包括制订并遵循的沟通规程，保证每个人都在合适的细节层次上保持同步。
风险管理
确定可能的风险
1、使用检查单
2、利用公司的历史和指标
3、整个行业的非正式网络
对风险进行量化
以数字的形式描述风险，一是风险发生的可能性，而是风险发生带来影响。
策划如何缓解风险
确定如果风险出现的对应风险事件的替代策略，最好能有多种策略。
风险真的出现时应对的措施
测试项目常见的风险：
不明确的需求
进度依赖性
测试数据不足
“影响测试继续进行”的缺陷
测试人员的技能和测试积极性
不能获得测试自动化工具
典型的风险、征兆、影响和缓解计划
测试管理
标准的选择
内部标准
1、测试工作产品的命名和保管规定
2、文档编写标准
3、测试编程标准
4、测试报告编写标准
测试基础设施管理
1、测试用例管理数据库
2、缺陷库
3、配置管理和工具
测试人员管理
与产品发布集成
测试的进度计划必须直接与产品发布关联，以下是一些决策内容：
1、开发和测试的同步点，什么时候可以开始不同类型的测试
2、开发和测试之间的服务等级约定，即测试团队需要多长时间完成测试，
3、缺陷各种优先级的严重等级的一致定义
4、与文档编写小组的沟通机制，保证文档与产品在已知缺陷的产品所面临的风险。
测试过程
1、把各种要素放在一起并确定测试计划基线
2、测试用例规格说明
3、可跟踪性矩阵的更新
4、确定有可能实现自动化的测试用例
5、测试用例的开发和基线确立
6、测试用例的执行和可跟踪性矩阵的更新
7、指标的采集与分析
8、准备测试总结报告
9、推荐产品发布准则
测试报告
测试事件报告
告知在测试周期内遇到缺陷时的沟通。
测试周期报告
1、本周期内完成的活动总结
2、本周期内发现的缺陷，按缺陷的严重等级和影响分类
3、在缺陷修改方面前一个周期到当前周期的进展
4、本周期还没有修改的严重问题
5、工作量或者进度上的任何偏差
测试总结报告
1、本测试周期或者阶段完成的活动总结
2、活动的实际执行和策划之间的偏差，包括：
计划运行但不能运行的测试（说明原因）
对原始测试规格说明的修改
运行的补充测试
策划和实际工作量和时间的偏差
与计划的任何其他偏差
3、结果总结应该包括
未通过的测试用例，并描述未通过的原因
测试发现的缺陷的影响严重级别
4、对发布的综合评估和建议应该包括：
“发布适宜性”的评估
发布建议
产品发布建议
