作为一个想成为leader(不论是整个测试部门还是小项目组的leader）的人，测试计划编写是必备技能。
有些朋友可能会说，我不想成为leader，那正所谓不想成为将军的士兵不是好士兵… 咳咳咳，没有调侃啦，只是多一个技能傍身也是极好的~~
言归正传，直入主题。测试计划具体包含的内容包括以下：
1、概述
1.1 项目标识
项目编号项目名称
项目类别■新建类 □升级类合作供应商
1.2 目的
1.2.1 根据需求列表确认现有功能，保证软件质量
1.2.2 验证软件的一致性、稳定性、兼容性、安全性、可靠性、有效性、功能性
1.2.3 通过分析以前项目的测试状态，预估该项目的测试状态，确保软件测试的有效性
1.2.4 分析漏测原因，提前做好解决方案，降低风险
1.2.5 分析每个阶段计划的有效性并且及时更新，保证各阶段测试的质量
1.2.6 根据计划，及时对文档、测试用例进行评审，保证文档的正确性和测试用例的有效性、可执行性 1.2.7 根据计划，及时对文档、测试用例进行评审，保证文档的正确性和测试用例的有效性、可执行性 1.2.8 保证测试报告的交付时间
1.2.9 提前计划所需测试资源，确保测试工作的正常进行
1.2.10 明确缺陷级别定义，规范提交缺陷模板，以便及时解决缺陷
1.2.11 组织结构图说明每个角色的具体任务，在实际工作中起指导作用
1.2.12 针对各种测试类型的测试目的来判断测试的有效性
1.3 范围
[描述测试的各个阶段（例如集成测试和系统测试），并说明本计划所针对的测试类型（如功能测试或性能测试）。 简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。
如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。 列出可能会影响测试设计、开发或实施的所有风险或意外事件。
列出可能会影响测试设计、开发或实施的所有约束。
1.4 参考资料
主要参考项目总体计划、需求规格说明书
2、组织结构
人员角色姓名单位职责移动电话电子邮件备注
项目经理
测试经理
测试组组长
测试组成员
3、测试资源需求
测试过程中，根据项目各阶段需根据项目的情况进行资源调整。
3.1 人力资源需求
角色地点数量所需知识技能期望到位时间计划释放时间是否需要培训备注
3.2 办公位需求
类型地点数量期望到位时间计划释放时间备注
办公座位
办公网络
开发测试网络
其它
3.3 测试环境
测试环境类型主机存储网络外围设备操作系统软件数据库中间件系统配置参数测试用业务数据
web服务器
3.4 其它软件/系统
类型型号数量备注
测试工具
缺陷跟踪工具
测试案例管理工具
浏览器
关联系统
其它
4、测试范围
xxx项目功能列表
一级菜单二级三级研发负责人测试案例设计人优先级
5、测试目标
5.1 测试目标
类别目标
进度目标系统测试完成日期:
性能测试工作完成日期：
性能指标
执行目标缺陷清除率:100%
测试用例覆盖率:100%
测试用例通过率:100%
文档质量目标交付文档:
测试计划
系统测试用例
系统测试记录
系统测试报告
性能测试方案
性能测试报告
缺陷记录
\
5.2 测试类型
序号测试类型子测试项测试目的是否采用备注
1功能性测试根据系统需求文档和设计文档，检查产品是否正确实现了功能
3用户界面 (UI) 测试检查界面是否美观合理
4兼容性测试在不同浏览器上能正常运行
5流程测试按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程、正反流程，
检查软件在按流程操作时 是否能够正确处理
6回归测试检查程序修改后有没有引起新的错误、是否能够正常工作以及能否满足系统的需求
7性能测试提取系统性能数据，检查系统是否
满足需求中所规定达到的性能
8接口测试检查系统能否与外部接口正常工作
9安全性和访问控制测试应用程序级别的安全性：检查用户只能访问其所属用户类型已被授权访问的那些功能或数据。
系统级别的安全性检查只有具备
系统和应用程序访问权限的用户才能访问系统和应用程序。
6、测试里程碑
序号测试阶段任务描述责任人阶段目标计划开始时间计划结束时间
1制定测试计划识别需求功能，预估工作量
制定测试进度，编写测试计划
工作量预估完成
测试方案、测试计划编写完成
通过项目组内部评审
2系统测试案例测试需求分解
编写测试案例
评审测试案例
测试案例编写完成
通过评审
纳入配置管理
3系统测试验证系统软件是否与需求相符，执行业务流程通顺模块集成后的系统业务流程正确
记录发现的缺陷、修改缺陷、复测缺陷
完成测试记录和测试报告
4性能测试验证系统集成后，软件是否符合各项性能指标软件在模拟真实环境的条件下各项性能达到需求指标
测试脚本、场景的编写
记录发现的缺陷、修改缺陷、复测缺陷
完成测试记录和测试报告
5业务验收测试根据业务需求和《业务需求功能规格说明书》/《业务需求功能说明单》编写测试案例，测试是否实现所有功能业务测试小组完成测试工作（测试案例编写、记录发现的缺陷、复测缺陷、完成测试记录和测试报告）
软件质量达到预期标准
6文档编写记录测试记录、完成测试报告、对测试案例进行维护完成测试报告及相关文档整理，测试案例更新归档
7、测试进度安排
开始时间：
结束时间：
任务名称负责人开始时间完成时间
1.制定测试计划
编写测试方案与计划
2.测试案例设计
3.集成/系统/验收测试
第一阶段测试
第二阶段测试
第三阶段测试
4.性能测试
5.文档编写
8、风险评估
风险描述影响程度应对措施责任人
测试目标不清晰或不够明确严重明确测试目标
测试时间有限严重推迟上线或加班
测试人员的不足严重
代码编写的质量严重
缺陷修改进度严重
回归测试不充分（一般不运行全部测试用例，是有选择性的执行）一般
案例功能点覆盖率未达到100%一般
测试案例不能100%执行一般
开发计划变更严重
需求的变更严重
9、交付物
序号交付物提交时间
1测试计划
2测试方案
3系统测试记录
4系统测试报告
5性能测试用例
6性能测试报告
7缺陷
10、缺陷级别标准
描述需求阶段与客户确定的缺陷等级定义；
缺陷 级别描述
一级致命问题
1. 程序运行过程中不断申请，但没有完全释放资源，造成系统性能越来越低，并出现无规律的死机现象。
2. 程序运行导致系统崩溃。
3. 由程序引起的资源严重不足、非法退出等
4. 严重的关键计算错误（如计费等）。
5. 数据库发生死锁，且无法自动恢复。
6. 与需求要求差距较大。
7. 系统无响应。
二级严重问题
1. 因错误操作导致的程序中断。
2. 功能没有实现。
3. 正确操作导致的错误结果。
4. 与数据库连接错误,无法自动恢复。
5. 数据通讯错误，无法自动恢复。、
6. 数据库的表、业务规则、缺省值未加完整性等约束条件。
7. 界面中的信息不能及时刷新，不能正确反映当前数据状态，可能误导用户。（数据库中剩余记录个数和参数设置对话框中的预设值常常显示为历史值而不是当前值）
8. 对输入数据没有进行充分并且有效的有效性检查，造成不合要求的数据进入数据库。
三级一般问题
1. 操作界面错误。（包括数据窗口内列名定义、含义是否一致，界面中英文混杂，界面元素参差不齐，文字显示不全）
2. 打印内容、格式错误。
3. 删除操作未给出提示。
4. 数据库表中有过多的空字段。
5. 提示信息意文不明或为原始的英文提示。
6. 要求用户输入多余的、本来系统可以自动获取的数据。（服务是否启动，安装后用户需要手动修改某些配置文件）。
7. 辅助说明描述不清楚，有歧义。
8. 长操作未给用户提示。
四级改进建议
1. 辅助说明描述不清楚。
2. 输入输出不规范。
3. 可输入区域和只读区域没有明显的区分标志。
4. 某一项功能的冗余操作太多。如：对话框嵌套层次太多，影响用户操作。
5. 不能记忆用户的设置或操作习惯，用户每次进入系统都需要重新操作初始环境。
6. 不符合用户操作习惯。（快捷键定义不科学、不实用，键位分布不合理、按键太多，甚至没有快捷键）。
7. 界面不规范。
8. 提示窗口文字未采用行业术语。
11、培训计划
序号分类培训内容培训日期培训人参加人备注
1业务培训详见培训计划
2技能培训
3工具培训
12、相关软件
在测试过程中将使用到以下软件
1 .缺陷跟踪工具
管理bug并跟踪bug状态:禅道
2 .用例与文档管理工具
管理项目文档和需求:SVN
以上就是测试计划中包含的所有内容，如果公司没有模板的话，直接按照这个来写吧，no趴笨~
网友评论