测试计划是在需求分析之后进行的，可发现需求不合理地方。
1 测试计划需要先列出大纲，再一步步填充 ，用于掌握整个项目进度和方向
2 规定合理的期限和目标，使人员有效率的完成任务
3 是对未来工作的规划-对风险评估，列出影响因素，制定对应方案减少损失
4 对人员合理安排，对模块找对应的专业人员来测试。难度大的到难度小的由对应人员进行测试
5 多个部门之间的合作，工作交接在时间上做好备注
6 列出测试步骤、应留心的步骤
测试计划的内容
测试范围明确测什么？比如：产品的具体业务需求有哪些？产品是web端的还是移动端的，还是两者都有？
测试策略明确怎么测。对不同业务需求，具体要有哪些测试类型、测试场景、测试方法。
资源安排包括测试人员的安排，测试环境是怎样的，测试工具的选择等。
进度安排在明确测试范围、方法和人员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、上线计划衔接。
发布标准发布标准是测试完成和产品上线需要满足的条件，以便项目内所有角色都有一致认可的目标。怎样才算是测完了？达到怎样的标准才可以上线？
风险预防最后，我们需要对整个测试过程中可能存在的风险，以及当这些风险发生时的应对措施提前进行一些考虑和准备，并在测试计划中体现出来
测试范围的确定来源于需求文档
1 引言
1.1 编写目的
根据项目需求文档，提炼测试功能点、制定测试策略、评估测试风险、预估编写测试用例、执行功能测试和回归测试的工作量，进行进度、人员安排
1.2 预期读者
项目经理、产品、开发、测试
1.3 参考资料
需求稿.doc 需求分析
2 测试范围
X项目功能模块：浏览课程、参加课程、学习课程；
根据产品应用场景和架构设计，还需要做性能测试和兼容性测试
测试类型：功能测试、兼容性测试、性能测试、接口测试、安全性测试
将需要用到的测试类型按测试场景、测试方法等以引用文件的形式填写到测试计划中去。以便让所有项目人员清楚的知道要做哪些测试工作以及怎么做
3 测试策略
对需求中的功能改进进行完整测试，并根据应用场景和并发数考虑兼容性和性能测试方案
3.1 功能测试策略
具体见 XX项目测试用例
3.2 系统兼容性测试
1 浏览器：ie10/chrome/firfox下进行完整测试
2 在 ios9 ios8/iphone6s/iphone5s 上进行测试
3 在android 5.0 4.4系统上进行完成的测试，手机选取市场点有率高的三星、华为、小米等 ，分辨率覆盖800*480、1280*720
3.3 性能测试
1 登录模块，大批用户用时登录，服务器负载情况，页面响应速度
2 参加课程模块，大批量用户同时参加一个课程，或者同时参加多个课程，服务器负载和响应速度。
测试资源一般包括两方面：测试人力资源和测试环境资源。
测试人力资源包含2个维度：测试人员数量和测试人员经验、能力。
环境资源：测试服务器环境
与线上服务器的差异
终端测试环境
PC的配置
手机的型号
测试工具
Bug管理工具
用例管理工具
性能测试工具
在测试计划中，测试人员分配、测试环境资源、网络资源、工具使用都要明确写出来
4 测试资源
4.1 测试人员
测试负责人 ：，团队成员：
4.2 测试环境
1 服务器环境： 试服、线上服
2 终端环境：PC：win10 ie10 chrome
iphone手机：iphone5s
android手机：红米、华为
3 网络环境：办公网络环境：移动4G、电信4G
4.3 Bug管理工具
在测试过程发现缺陷后使用禅道进行记录，提交记录时应清晰、准确的描述缺陷发生的条件 步骤，并设置缺陷严重重等级，导致程序崩溃的缺陷设为 1级，严重影响程序运行或阻碍使用的设为 2级，对用户使用造成一定影响的缺陷设为 3 级。可用性或改进意见设为 4 级
5 进度安排
测试工作进度安排依赖于开发工作的节点和提交测试进度的时间，并且直接影响预期上线时间。
需要根据业务复杂度、测试类型的复杂度、产品上线的质量要求的高低、测试人员的数量、能力和经验这些因素，来评估不同阶段、不同类型的测试工作的工作量。然后对测试人员的分工进行安排，明确职责。最终来预估测试工作开始和结束的时间节点。
列明测试过账中需要输出的文档。
项目的里程碑：开发节点、提测节点、上线节点
评估因素：业务复杂度、测试复杂度、产品质量要求、人员数量能力
进度安排：评估工作量、分配人力、预估时间
输出文档：测试计划、测试用例、Bug数据、测试报告
5.1 测试进度及工作量估算 ：任务、时间、执行人员、预期工作量
6 发布标准
这个标准包含2个方面：一是测试工作完成的标准，二是产品可以上线发布的标准
测试完成标准：1 测试计划里所有测试类型都已经完成了
2 功能上、兼容性上没有影响用户使用的Bug
3 允许遗留小部分影响不是很大的Bug，但这个数量应该小于一个值
4 性能上符合设计目标和上线要求 这些标准都是针对测试工作本身的要求
产品发布标准：1 产品需求都已完成
2 交互视觉走查都已完成
3 小部分Bug项目组完成了风险评估 都认为且问题不大
4 产品使用说明或用户手册或更新log都已完备等
6.1 测试完成标准
1 没在影响用户正常傅的缺陷
2 完成测试内容中的功能测试/系统兼容性测试和服务端性能测试
3 未修改的缺陷不超过10个
6.2 产品发布标准：
1 已按需求文档实现需求
2 符合交互设计规范/符合视觉要求/通过设计评审
3 允许遗留可能会对用户正常使用造成一定影响的缺陷，但在发布前告知项目组，并经风险评估一至同意发布后可发布
7 风险说明
一是测试范围的风险：需求不准确 不到位漏了测试点，甚至某个测试类型遗漏了。这是产品需求变更的风险，加需求/减需求/改需求都需要重新进行测试/分析，需要测的要测到，不需要测试的不浪费人力工作量
二是测试进度的风险：工作量估计不准/开发没有按时或改缺陷不及时，测试人员请假/变动
三是产品质量风险：代码质量低/不熟悉业务/能力经验有限
测试范围风险;测试遗漏、需求变更
测试进度风险：工作量预估不准确
合作任务延迟
测试 人员变动
产品质量风险：代码质量
测试 人员能力