一、计划的意义
1、leader：根据计划进行资源的分配
2、根据计划调整目标
3、根据计划各职位的人员进行配合
二、计划内容
1、项目概述
a、项目背景：项目的使用人员和项目的基本功能和目的
b、该计划的使用和阅读人员
2、项目的组织形式
a、组织结构图：描述团队职位，职位直接的关系，成员负责的内容
b、角色和职责：职位和它的工作内容
c、团队协作：协作的团队、合作方式、会议方式
3、测试对象
a、质量模型分析测试点
b、描述测试特性
应测特性：软件测试的模块、质量模型中的特性
不测特性：哪些特性本次无需进行测试并且说明不测原因
4、测试通过和失败的标准
a、覆盖率：95%以上用例通过；重要的用例100%通过
b、bug修复率：bug修复率达到95%以上；允许遗留的bug等级和数量
c、具体判定标准根据时间情况而定
5、挂起和恢复的标准
a、无法继续测试或继续测试意义不大
b、测试环境破坏，无法进行测试
c、预测试不通过
d、用户的需求发生重大的改变，造成基本功能和大部分主要功能的变化
e、开发的设计发生根本变化，大部分功能受到影响
6、测试任务安排
a、完成系统测试计划的生成和评审
b、方法和标准，如使用xxx工具
c、输入和输出：输入就是依据什么，输出是产出的东西
d、风险和假设：测试过程中可能遇到的风险
假设是为了完成该任务，需要做好的准备工作
e、角色和职责：xxx人负责xxx部分
6.1.几个时间节点要卡主
a.需求评审时间（决定你写测试用例的时间，最好评审过后就写，以免忘记）
b.用例 评审时间（决定你写用例的时间，用例需要经过评审，这样可以让参与的所有人都知道你测了那些东西，一个时候避免漏写，一个是规避责任）
c.测试交付日期（这个很重要，代表你有多长时间去测试）
d.测试安全时间（一定要留出一部分安全时间，1.给开发修复缺陷 2.以免有新的紧急需求插入）
7、工作量
a、描述方式：人日、人时、人月
b、根据测试范围和测试方法进行评估：可以用图解的方式说明
c、根据项目背景估算
d、根据开发阶段估算
e、根据经验估算
f、根据风险估算
估算原则：
任务分解的越详细，估算的越准确
团队协作完成
7.1.开发周期与测试周期的协调
a.如果开发周期很长这就应该能说明这块的内容很多，如果后面开发完成之后全堵到测试这块来了，我们可以和研发组协商，完成拆开几段来完成，这样整个项目完成后我们的压力也不是很大。
b.在开发期间我们需要准备好测试用例，测试环境，测试数据，还测试策略，正确开发完成的部分我们就能上手测试。
7.2.风险预警
a.在一个阶段完成是需要发出一封邮件，反映出，目前测试，开发的各自进度，现在完成了多少，还有多少，和原来的计划偏差了多少，预计风险在哪里，以及缺陷频率高的模块（就说明这块地风险很大），发到各负责人。
b.在测试中遇到比较影响整个测试进度的缺陷，时也需要发风险预警，总之问题不能在测试这块卡主。
c.在感觉与原来计划偏差较大，以至于发版日发版，风险过大时最少要提前两天以上，及时反馈出来，好协商调配资源，重新整理存在风险的这部分计划。
8、资源明细
用到的人力、物力（电脑等）
9、附件
参考的文档
部分参考：测试计划
一、计划的意义
1、leader：根据计划进行资源的分配
2、根据计划调整目标
3、根据计划各职位的人员进行配合
二、计划内容
1、项目概述
a、项目背景：项目的使用人员和项目的基本功能和目的
b、该计划的使用和阅读人员
2、项目的组织形式
a、组织结构图：描述团队职位，职位直接的关系，成员负责的内容
b、角色和职责：职位和它的工作内容
c、团队协作：协作的团队、合作方式、会议方式
3、测试对象
a、质量模型分析测试点
b、描述测试特性
应测特性：软件测试的模块、质量模型中的特性
不测特性：哪些特性本次无需进行测试并且说明不测原因
4、测试通过和失败的标准
a、覆盖率：95%以上用例通过；重要的用例100%通过
b、bug修复率：bug修复率达到95%以上；允许遗留的bug等级和数量
c、具体判定标准根据时间情况而定
5、挂起和恢复的标准
a、无法继续测试或继续测试意义不大
b、测试环境破坏，无法进行测试
c、预测试不通过
d、用户的需求发生重大的改变，造成基本功能和大部分主要功能的变化
e、开发的设计发生根本变化，大部分功能受到影响
6、测试任务安排
a、完成系统测试计划的生成和评审
b、方法和标准，如使用xxx工具
c、输入和输出：输入就是依据什么，输出是产出的东西
d、风险和假设：测试过程中可能遇到的风险
假设是为了完成该任务，需要做好的准备工作
e、角色和职责：xxx人负责xxx部分
6.1.几个时间节点要卡主
a.需求评审时间（决定你写测试用例的时间，最好评审过后就写，以免忘记）
b.用例 评审时间（决定你写用例的时间，用例需要经过评审，这样可以让参与的所有人都知道你测了那些东西，一个时候避免漏写，一个是规避责任）
c.测试交付日期（这个很重要，代表你有多长时间去测试）
d.测试安全时间（一定要留出一部分安全时间，1.给开发修复缺陷 2.以免有新的紧急需求插入）
7、工作量
a、描述方式：人日、人时、人月
b、根据测试范围和测试方法进行评估：可以用图解的方式说明
c、根据项目背景估算
d、根据开发阶段估算
e、根据经验估算
f、根据风险估算
估算原则：
任务分解的越详细，估算的越准确
团队协作完成
7.1.开发周期与测试周期的协调
a.如果开发周期很长这就应该能说明这块的内容很多，如果后面开发完成之后全堵到测试这块来了，我们可以和研发组协商，完成拆开几段来完成，这样整个项目完成后我们的压力也不是很大。
b.在开发期间我们需要准备好测试用例，测试环境，测试数据，还测试策略，正确开发完成的部分我们就能上手测试。
7.2.风险预警
a.在一个阶段完成是需要发出一封邮件，反映出，目前测试，开发的各自进度，现在完成了多少，还有多少，和原来的计划偏差了多少，预计风险在哪里，以及缺陷频率高的模块（就说明这块地风险很大），发到各负责人。
b.在测试中遇到比较影响整个测试进度的缺陷，时也需要发风险预警，总之问题不能在测试这块卡主。
c.在感觉与原来计划偏差较大，以至于发版日发版，风险过大时最少要提前两天以上，及时反馈出来，好协商调配资源，重新整理存在风险的这部分计划。
8、资源明细
用到的人力、物力（电脑等）
9、附件
参考的文档
部分参考：测试计划