09 测试计划

17. 计划测试工作

17.1 测试计划的目标

规定测试活动的范围、方法、资源、进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人、以及与计划相关的风险。
测试计划只是创建详细计划过程的一个副产品，重要的是计划过程，而不是产生的结果文档。
测试计划过程的最终目标是交流（而不是记录）软件测试小组的意图、期望，以及对将要执行的测试任务的理解。

17.2 测试计划主题

测试计划的动态书写，而不是规定模板。

17.2.1 高级期望

A) 测试计划过程和软件测试计划的目的：必须让所有人看懂。测试的什么产品？版本是重写还是维护升级？独立程序还是几千个小程序？自行开发还是第三方开发？产品到底是什么？
B) 产品的质量和可靠性目标：产品开发的速度、技术程度、缺陷程度权衡。软件计划过程的结果必须是清晰、简洁、在产品质量和可靠性目标上一致通过的定义。目标必须绝对，让销售人员、程序员、产品经理清晰明白目的。不成熟的技术即使缺陷。目标比如：自动测试 24 小时不崩溃，执行全部测试用例而找不到新的软件缺陷，等等。针对性强。

17.2.2 人、地点和事

明确项目中工作的人，干什么，怎么联系。
文档存放位置，软件在哪里下载，测试工具在哪里，还有邮件地址、服务器和网站地址。
硬件放在哪？如何取得？配置测试地点，怎么安排进度。

17.2.3 定义

构造：测试用例的创建和设计过程。测试计划应该定义构造的频率，以及期望的质量等级。
测试发布文档：是在软件测试完成后准备的一份文档，用于记录测试过程、测试结果和测试团队对于软件质量的评估。TRD 通常是交付给项目团队、开发团队和其他相关利益相关者的重要文档之一。
Alpha 版：对少数主要客户和市场进行数量有限的分发，用于演示目的的早期构成。
Beta 版：意在向潜在客户广泛分发的正式构造。
说明书完成：说明书预计完成并且不可再更改的日程。
特性完成：程序员不再向代码增加新特性。
软件缺陷会议：测试经理、项目经理、开发经理、产品经理组成。召开会议审查软件缺陷，明确修复和如何修复内容。

17.2.4 团队之间的责任

x 代表责任人 --- 代表任务参与者 空白代表不负责

17.2.5 哪些要测试，哪些不要测试

以被测试过

17.2.6 测试的阶段

瀑布式开发的测试阶段固定。
敏捷式开发只有一个测试，就是不断测试。

17.2.7 测试策略

考虑手工测试、工具和自动化测试，使用什么工具？是否需要开发？已有的商用解决方案，是否外包给专业测试公司。

17.2.8 资源需求

A) 人员：数量、经验、专长。
B) 设备：计算机、硬件、打印机、工具。
C）软件：文字处理工具、数据库程序、自定义工具。购买哪些东西？写什么材料？
D）外包测试公司。
E）其他设备：磁盘、参考书、资料等。

17.2.9 测试员的任务分配

17.2.10 测试进度

17.2.11 测试用例

下个章节介绍

17.2.12 软件测试报告

记录和跟踪所发现的软件缺陷的技术。

17.2.13 度量和统计

跟踪项目发展、成效和测试的手段。详情见 20 章 “成效评价”

17.2.14 风险和问题

测试计划中常用且实用的部分是明确之处问题或者风险区域