第1章引言
1.1目的
本测试计划文档作为指导此测试项目循序渐进的基础，帮助我们安排合适的资源和进度，避免可能的风险。本文档有助于实现以下目标：
1) 确定现有项目的信息和应测试的软件结构。
2) 列出推荐的测试需求
3) 推荐可采用的测试策略，并对这些策略加以详细说明
4) 确定所需的资源，并对测试的工作量进行估计。
5) 列出测试项目的可交付元素，包括用例以及测试报告等。
1.2名词解释
|
缩写词或术语 |
英文解释 |
中文解释 |
|
Debug |
debug |
漏洞 |
1.3测试摘要
1.3.1 重点事项
l 测试软件运行情况是否正常
l 测试软件功能的准确性
l 测试软件的性能得分
1.3.2 时间进度
在软件开发出之后开始测试，大约测试半周的时间。
1.3.3 测试目标
测试计划中所有测试方法和模块能执行通过
所有的测试案例能执行过
所有的重要等级为1/2的Bug能解决并由测试验证
第2章项目背景
2.1测试范围
（1）手机系统出现问题的情况不去测试。
（2）名单的文件大小会影响软件的载入速度。
（3）手机突然关机会影响载入文件的数据。
2.2测试目标
测试计划中所有测试方法和模块能执行通过
所有的测试案例能执行过
所有的重要等级为1/2的Bug能解决并由测试验证
2.3联系方式
|
职务 |
姓名 |
|
开发工程师 |
张昊 |
|
CVS Builder |
曹金钰 |
|
开发经理 |
郭翠 |
|
测试负责人 |
王建斌 |
2.4风险及约束
l 手机系统出现问题的情况不去测试。
l 名单的文件大小会影响软件的载入速度。
l 手机突然关机会影响载入文件的数据。
2.5测试文档
2.5.1测试参考文档
|
文档说明 |
作者 |
|
需求文档 |
张昊 |
|
总体设计 |
张昊 |
|
白皮书 |
王建斌 |
|
使用手册 |
王建斌 |
|
管理手册 |
曹金钰 |
|
测试文档 |
曹金钰 |
|
API文档 |
郭翠 |
2.5.2测试提交文档
|
文档说明 |
作者 |
|
《总体测试计划》 |
张昊 |
|
《总体测试方案》（可根据项目情况进行裁剪） |
张昊 |
|
测试用例 |
王建斌 |
|
《性能测试方案（报告）》 |
王建斌 |
|
《测试报告》 |
曹金钰 |
|
《Readme》 |
曹金钰 |
|
《产品操作手册(后台)》 |
郭翠 |
|
《产品操作手册(前台)》 |
郭翠 |
|
《产品安装维护手册》 |
张昊 |
|
《产品错误代码说明文档》 |
王建斌 |
第3章质量目标
3.1产品质量目标
可以是产品的质量达到什么样的目标，产品的流程联通性达到什么样的要求。
|
测试质量目标 |
确认者（如需说明） |
|
测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确 |
张昊 |
|
产品规定的操作和运行稳定 |
|
3.2测试质量目标
|
测试质量目标 |
确认者（如需说明） |
|
所有的测试案例已经执行过 |
张昊 |
|
所有的自动测试脚本已经执行通过 |
张昊 |
|
所有的重要等级为1/2的Bug已经解决并由测试验证 |
张昊 |
|
每一部分的测试已经被Test Lead确认完成 |
张昊 |
|
重要的功能不允许有等级为1/2/3的Bug |
张昊 |
|
一般的功能或与最终使用者不直接联系的功能不允许有等级为1/2的bug,且bug等级为3的问题不得超过1/功能 |
张昊 |
|
轻量的功能允许有少量2/3等级的错误 |
张昊 |
|
发现错误等级为1/2/3的Bug的速率正在下降并接近0 |
张昊 |
|
在最后的三天内没有发现错误等级为1/2/3类的Bug |
张昊 |
第4章测试策略
4.1 整体测试策略
用Junit进行测试，将测试结果写到测试文档里。
4.2开始/中断/完成标准
说明中断/开始/完成测试的标准。
|
开始/中断/完成测试 |
标准说明 |
|
开始测试标准 |
硬件环境可用且软件正确安装完成 |
|
中断测试标准 |
安装无法正确完成或程序的文档有相当多的失误或系统服务异常或发现Block Bug |
|
完成测试标准 |
完成测试计划中的测试规划并达到程序和测试质量目标,并由Test Lead/R&D Manager确认 |
4.3测试类型
|
测试类型 |
是否采用 |
说明 |
|
功能测试 |
采用 |
根据系统需求文档和设计文档，检查产品是否正确实现了功能。 |
|
流程测试 |
采用 |
按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程、正反流程，检查软件在按流程操作时是否能够正确处理 |
|
边界值测试 |
采用 |
选择边界数据进行测试，确保系统功能正常，程序无异常。 |
|
容错性测试 |
采用 |
检查系统的容错能力，错误的数据输入不会对功能和系统产生非正常的影响，且程序对错误的输入有正确的提示信息 |
|
异常测试 |
采用 |
检查系统能否处理异常 |
|
启动停止测试 |
采用 |
检查每个模块能否正常启动停止、异常停止后能否正常启动 |
|
安装测试 |
采用 |
检查系统能否正确安装、配置 |
|
易用性测试 |
采用 |
检查系统是否易用友好 |
|
界面测试 |
采用 |
检查界面是否美观合理 |
|
接口测试 |
采用 |
检查系统能否与外部接口正常工作 |
|
配置测试 |
采用 |
检查配置是否合理、配置是否正常 |
|
安全性和访问控制测试 |
采用 |
应用程序级别的安全性：检查Actor只能访问其所属用户类型已被授权访问的那些功能或数据。 系统级别的安全性：检查只有具备系统和应用程序访问权限的Actor才能访问系统和应用程序。 |
|
性能测试 |
采用 |
提取系统性能数据，检查系统是否满足在需求中所规定达到的性能。 |
|
压力测试 |
采用 |
检查系统能否承受大压力，测试产品应该能够在高强度条件下正常运行，不会出现任何错误。 |
|
兼容性测试 |
采用 |
对于 C/S 架构的系统来说，需要考虑客户端支持的系统平台。 对于 B/S 架构的系统来说需要考虑用户端浏览器的版本。 |
|
割接/升级测试 |
采用 |
进行专门的割接测试或升级测试，提供工程升级割接方案 |
|
文挡测试 |
采用 |
检查文档是否足够、描述是否合理 |
|
回归测试 |
采用 |
检查程序修改后有没有引起新的错误、是否能够正常工作以及能否满足系统的需求 |
4.4 测试技术
|
测试技术 |
是否采用 |
说明 |
|
里程碑技术 |
采用 |
里程碑的达成标准及验收方法在测试完后制订 |
|
自动测试技术 |
采用 |
核心业务流程采用自动测试技术 |
|
审评测试 |
采用 |
对软件产品功能说明文档和设计说明文档进行检查，在需求与设计阶段进行 |
|
编写测试用例 |
采用 |
在产品编码阶段编写测试用例 |
|
单元测试 |
不采用 |
由开发人员进行 |
|
集成测试 |
采用 |
检测模块集成后的系统是否达到需求对业务流程及数据流的处理是否符合标准、系统对业务流处理是否存在逻辑不严谨及错误以及是否存在不合理的标准及要求。 |
|
确认测试 |
采用 |
在产品发布前，对照feature list 进行基本需求的确认，确认产品是否正确实现了功能。 |
|
系统测试 |
采用 |
包括性能测试、压力测试和回归测试 |
|
验收测试 |
不采用 |
由工程实施人员进行 |
第5章测试计划
5.1进度计划
在此章节，对各阶段的测试给出里程碑计划，包括阶段、里程碑、资源等。
5.1.1测试时间进度
|
测试阶段 |
开始时间 |
完成时间 |
测试人员 |
|
制定测试计划 |
6月2日 |
6月10日 |
张昊 |
|
需求Review |
6月2日 |
6月10日 |
张昊 |
|
设计Review |
6月2日 |
6月10日 |
张昊 |
|
设计测试用例 |
6月2日 |
6月10日 |
张昊 |
|
测试开发 |
6月2日 |
6月10日 |
张昊 |
|
测试环境准备 |
6月2日 |
6月10日 |
张昊 |
|
测试实施 |
6月2日 |
6月10日 |
张昊 |
|
功能测试 |
6月2日 |
6月10日 |
张昊 |
|
集成测试 |
6月2日 |
6月10日 |
张昊 |
|
性能测试 |
6月2日 |
6月10日 |
张昊 |
|
系统测试 |
6月2日 |
6月10日 |
张昊 |
|
验收测试 |
6月2日 |
6月10日 |
张昊 |
|
文档编写 |
6月2日 |
6月10日 |
张昊 |
5.1.2测试里程碑
|
里程碑 |
完成时间 |
完成标准 |
|
测试正式开始 |
6月2日 |
完成可接受性测试和烟雾测试 |
|
进行CVS LOCK |
进行cvs lock |
完成所有里程碑测试和标准测试,测试种类包括确认测试和系统测试,且所有以发现的Bug等级为1/2/3的Bug已修复,近期内无发现新的Bug等级为1/2/3的Bug |
|
产品Release |
6月2日 |
重复进行主路径测试和进行Bug检查测试,产品处于可交付状态并由测试经理和高级经理确认 |
5.2测试准备
5.2.1 测试环境准备
|
准备事项 |
开始时间 |
完成时间 |
测试人员 |
|
测试环境准备 |
6月2日 |
6月10日 |
张昊 |
5.2.2 安装测试
|
准备事项 |
开始时间 |
完成时间 |
测试人员 |
|
安装测试 |
6月2日 |
6月10日 |
张昊 |
5.2.3 烟雾测试
|
准备事项 |
开始时间 |
完成时间 |
测试人员 |
|
烟雾测试 |
6月2日 |
6月10日 |
张昊 |