最近入职了新公司，项目组只有我一个测试，自成一家，哈哈，领导让编写测试计划，于是在网上看了很多，最终自己拟了一份，希望能和大家共勉！
目录
1 引言... 4
1.1 产品简介... 4
1.2 编写目的... 4
1.3 参考文档... 4
1.4 限制条件... 5
2 测试概要... 5
2.1 测试目标... 5
2.2 测试范围... 5
2.3 测试资源... 6
2.3.1 测试人力资源... 6
2.3.2 测试环境... 6
2.3.3 BUG管理工具... 6
3 测试规范... 7
3.1 测试接收标准... 7
3.2 BUG规范... 7
4 测试策略... 8
4.1 测试流程及工作量估算... 8
4.2 测试种类... 9
4.3 测试输出文档... 10
5 发布标准... 10
5.1 测试完成标准... 10
5.2 产品发布标准... 10
6 测试风险... 10
1 引言
1.1 产品简介
1.2 编写目的
此文档根据项目需求文档，制定测试策略、评估测试风险，确定所需的资源，并对测试的工作量进行估计，进行人员和进度安排，并且列出测试项目的可交付元素。
本文档预期读者对象主要为项目经理、产品、开发、测试等。
1.3 参考文档
1.4 限制条件
本测试计划受限于开发人员提交测试的内容和时间。根据开发人员提交模块的实际情况，本计划会做出相应修改。
2 测试概要
2.1 测试目标
通过测试，达到以下目标：
- 测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。
- 产品规定的操作和系统运行稳定。
- Bug数和缺陷率控制在可接收的范围之内，遗留BUG一般不超过所有BUG的10%。
2.2 测试范围
列出测试最终需要交付的功能模块列表
2.3 测试资源
2.3.1 测试人力资源
2.3.2 测试环境
- 服务器环境
操作系统：windows IP:
操作系统：linux IP:
- 终端环境
PC：windows10（ie10、chrome、Firefox）、windows7（ie10、chrome、Firefox）
- 网络环境
公司办公内网、外网
2.3.3 BUG管理工具
在测试过程中发现的缺陷及可用性问题，使用禅道来进行 bug 管理。
3 测试规范
3.1 测试接收标准
3.2 BUG规范
测试人员提交缺陷记录时，应清晰、准确地描述缺陷发生的条件和步骤，并
设置缺陷的严重等级如下：
4 测试策略
4.1 测试流程及工作量估算
4.2 测试种类
本次测试计划对系统进行以下类型的测试，针对不同的测试类型分别进行规划和设计，包括测试方法和标准等。测试类型罗列如下：
4.3 测试输出文档
本次测试完成后的提交物：
- 测试计划
- 测试用例
- 测试Bug单
- 使用手册
- 测试报告
5 发布标准
5.1 测试完成标准
- 需求规格说明书中的需求必须全部实现并测试通过。
- 主流程畅通，系统没有一类和二类Bug（参考3.2 BUG规范），没有影响用户正常使用的BUG。
- 所有功能和性能测试用例100％执行完成。
- 剩余三类四类有争议的bug，如果无法达成一致，测试人员需与产品、开发、项目经理开会讨论决定是否遗留有争议的Bug，若最终决定项目上线时有遗留BUG，需将BUG说明附在测试结果报告里，给出原因或最终解决方案。
- 按照交互文档、需求文档完全的实现需求。
- 符合交互稿的交互设计规范、符合视觉要求，并已经通过设计评审。
- 核心代码100％经过代码Review。
- 允许遗留可能会对用户正常使用造成一定影响的三类、四类缺陷，但应在发布前告知项目组，并经风险评估一致同意发布后方可发布。
5.2 产品发布标准
6 测试风险
本次测试过程中，可能出现的风险如下：
- 开发提交测试版本比该计划延迟，发生此种情况时，执行测试的时间应该合理顺延；
- 如果测试计划执行过程中出现需求变更超出预计的情况，可能导致编写测试用例和执行测试相关工作量增加，测试进度延迟；
- 如果开发提测版本质量较低，bug较多，可能导致比该计划更多轮次的回归测试；
- 人员调整、人员经验以及对软件的熟悉度可能会影响测试计划；
- 测试需依赖于服务器环境，如果环境不稳定，如代码编译不通过，tomcat异常、jar包异常、数据库异常等情况，可能会影响测试进度。