模板-测试计划-AAA系统android应用V1.0.0测试计划

AAA系统android应用V1.0.0测试计划
版本控制
版本号 日期 作者 审核人 说明
V1.0

目录
产品v1.0.0测试计划模板 1
1 项目简介部分 2
1.1 文档编写目的 2
1.2 测试项目背景描述 2
1.3 测试工作内容和范围 2
2 测试文档 2
2.1 测试所需参考文档 2
2.2 测试需提交文档 3
3 测试安排和计划 3
3.1 项目整体计划 3
3.2 测试工作量评估 5
3.3 测试资源安排 5
3.3.1 人力资源分工 5
3.3.2 测试环境安排和使用 6
3.3.3 所需的合作方配合 6
3.3.4 测试所需工具 7
4 风险预估和应对 7
5 冒烟测试测试方案 8
6 功能测试方案 9
6.1 测试规范 9
6.2 测试需求分析和策略制定 9
6.2.1 分功能测试需求分析 9
6.2.2 测试工具需求 10
7 性能测试方案[可裁减]—根据项目情况而定，不需要可删除第7节 10
7.1 性能测试工具需求 10
7.2 场景名xxx1 11
7.2.1 场景概述 11
7.2.2 执行策略设计 11
7.2.3 测试数据需求 11
7.2.4 性能测试结果分析方法和预期 12
7.3 压力测试场景设计 12
7.3.1 场景名XXX 12

1项目简介
1.1编写目的
AAA系统android应用测试方案目的，确定现有项目的信息和应测试的软件构件。列出推荐的测试需求（高级需求）。推荐可采用的测试策略，并对这些策略加以说明。确定所需的资源，并对测试的工作量进行估计。预估项目的风险和成本，对制定应对措施。列出测试项目的可交付元素]
1.2背景描述
对测试对象（应用程序、模块、子模块、系统等）及其开发设计目标进行简要说明。需要包括的信息有：主要的功能和性能、测试对象的构架以及项目的简史、测试对象的设计开发初衷和目标。
1.3内容和范围
[AAA系统android应用测试阶段：需求评审、需求分析、测试设计、设计评审（包括用例）、冒烟测试、系统测试、回归测试、自动化测试、镜像环境性能测试、验收测试。
AAA系统android应用测试范围：根据产品需求指定这期需要上线的功能（写一级模块）；
简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。
如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。
列出可能会影响测试设计、开发或实施的所有风险或意外事件。
列出可能会影响测试设计、开发或实施的所有约束。]
2测试文档
2.1测试所需参考文档
下表列出了制定和实施该测试方案时所需要使用的相关文档，并标明了各文档的可用性：
[注：列表中为文档项，需要具化，可适当地删除或添加文档项。]
文档[具体的文档名称和列表（版本/日期）] 已创建或可用 已被接收或已经过复审 作者或来源[角色和姓名] 备注
背景相关资料 是□否□ 是　否□
调研相关资料 是□否□ 是　否□
需求文档 是□否□ 是□否□
概要设计 是□否□ 是□否□
详细设计 是□否□ 是□否□
接口文档 是□否□ 是□否□
接口测试报告 是□否□ 是□否□
产品性能要求 是□否□ 是□否□
运维部署文档 是□否□ 是□否□
上线步骤 是□否□ 是□否□
产品总测试方案（性能） 是□否□ 是□否□
测试工具参考文档 是□否□ 是□否□
测试报告 是□否□ 是□否□

2.2测试需提交文档
下表列出了制定和实施该测试方案时测试所需要提交的相关文档，并标明了各文档的可用性：
[注：列表中为文档项，需要具化，可适当地删除或添加文档项。]
文档[具体的文档名称和列表（版本/日期）] 已创建或可用 已被接收或已经过复审 作者或来源[角色和姓名] 备注
需求文档、详细设计等评审批注意见 是□否□ 是　否□
接口测试设计（接口测试报告） 是□否□ 是□否□
测试方案（性能） 是□否□ 是□否□
测试计划 是□否□ 是□否□
测试设计 是□否□ 是□否□
测试报告（功能、性能、自动化） 是□否□ 是□否□
项目总结 是□否□ 是□否□
缺陷分析和测试设计补充 是□否□ 是□否□
缺陷记录表 是□否□ 是□否□

3测试安排和计划
3.1项目整体计划
项目阶段 时间段 参与人员 测试工作内容安排 产出 备注
调研阶段 参与调研讨论
需求评审阶段 1.了解项目背景资料
2.阅读mrd
3.反馈评审问题
4.参与需求评审
5.确认评审结论
6.初步评估测试计划 评审批注反馈
初步测试计划
详细设计阶段 1.分析产品功能，确认测试需求
2.进行测试点拆分
3.反馈评审问题
4.参与设计评审
5.确认设计评审结论
6.确定测试初步方案 评审批注反馈
测试框架
功能点拆分文档
测试点拆分文档
初步测试方案
测试计划调整
开发阶段 1.确定测试方案
2.确定自动化测试点
3.撰写测试case和相关关键字
4.准备测试数据
5.自动生成自动化case
6.开发测试工具
7.测试方案和测试设计评审 关键字列表
Case书写规范
测试case文档
自动化case
测试工具和程序
冒烟测试阶段 1.环境部署
2.冒烟测试 测试环境
冒烟测试报告
第一遍全面测试 1.执行手工测试
2.执行自动化case
3.性能测试
4.完善自动化case 手工测试结论
部分关键字
完善或新补充的自动化case
性能测试结果
自动化case结果
Bug回归测试 1.确认bug修复情况
2.执行自动化case
3.完善自动化case
4.性能测试 Bug确认结论
部分关键字
完善或新补充的自动化case
自动化case结果
性能测试结果
全面回归测试 1.执行手工回归测试
2.执行自动化casee
3.性能测试 测试结论和测试报告
交叉自由测试 1.PM、RD、QA交叉自由测试
2.常规检查自动化case执行 测试结论和测试报告
上线阶段 1.上线辅助
2.线上检查
3.Bug回归 Bug回归
项目总结阶段 1.相关总结；
2.Case和框架合并；
3.自动化case管理

3.2测试工作量评估
[列出产品当前版本需要实现的功能所需测试时间]
功能模块 描述 执行人 时间 备注
[注：一、二级模块] [每个模块的所有功能点都实现]
[注：根据项目情况天/小时]

详细测试计划请参加《xx项目v0.0.0_测试计划》文档
3.3测试资源安排
3.3.1人力资源分工
下表列出了在此项目的人员配备方面所作的各种假定。
[注：可适当地删除或添加角色和人员项。]
角色 人员 所推荐的投入 主要职责或注释[需要具化]
项目负责人 80%—100% 处理插入事务
协调项目安排
分析测试需求
制定测试方案和测试计划
负责管理文档资料、case、程序、工具
测试全程参与
测试工程师 50%—100% 测试全程参与
分析测试需求
撰写测试case（即自动化case）
提出关键字和自动化工具需求
完善补充自动化case并执行测试
测试分析和测试报告
辅助测试开发工程师 10%—30% 参与测试工作
辅助关键字、工具开发、执行问题修复
辅助自动化框架制定和实施

3.3.2测试环境安排和使用
[网络硬件，如拓扑图、硬件设备、规格、数量、配置等信息；
网络软件，如协议、通讯和连接方式等信息。]

下表列出了测试的系统环境
硬件环境（服务器、网络、虚拟机等需求）

软件环境（相关操作系统、软件及环境配置等）

3.3.3所需的合作方配合

配合方 配合人员 希望提供的资源 希望的配合工作 配合阶段 配合时间 备注
PM 人员 资源协调和推动
交叉自由测试安排 全程
RD/FE 利于测试的程序、页面及其部署安装文档 分阶段提供被测程序
在开发周期的后20%前提供页面 测试设计和测试执行
XX产品QA Xx服务器的xx服务、xx数据
人员 联调环境准备；
联调资源提供
联调问题辅助定位 测试执行（联调测试）

3.3.4测试所需工具
项目中需要用到的辅助性测试工具所作的各种假定。

工具 获取和访问地址 用途 支持人员 备注

4风险预估和应对
下表列出了在此项目的测试工作所存在的各种风险的假定，需要考虑项目测试过程中可能发生的具体事务，分别分析并加以应对，然后体现在测试计划中。
[注：可适当地删除或添加风险项。]
风险类型 风险责任方 风险内容 相应处理优先级 可能发生的阶段 可能发生的时间段 应对所需资源 应对措施[只是建议，需要具化] 备注
时间计划 提测计划延期，或者冒烟测试频繁不通过 参考3.1.1计划和阶段 参考3.1.1计划和阶段 合理计划
及时调整
人员风险 请假、离职、调离等意外情况 充分估计
预留buffer
及时调整
资源协调 测试数据提供补充分 充分估计
预留buffer
及时调整
插入事务 使用第三方数据或者服务器故障 预留buffer
及时调整
任务超预期 需求有较大变动 及时调整

[注：各个风险类型解释如下。
时间计划：关键milestone无法匹配的延期风险。诸如项目存在deadline、计划受到客观条件限制、非己方责任导致地被动延期等等；
人员风险：测试人员和需配合方的人员的变动导致的工作任务无法按计划完成或者完成质量无法保证的风险，包括新人风险、人员变化、投入不足、投入质量不高等；
资源协调：包括所需资源不能如期到位，或者资源质量低于预期等风险。比如测试工具开发的风险、各个阶段交付物的质量风险等。
插入事务：包括临时插入高优先级的事务，打乱原有计划等风险。
任务超预期：实际执行时的工作复杂程度、结果的质量同预期不符所带来的风险。属于不可预期的风险，只能待出现时及时合理地调整。
风险分为可预期的和不可预期的，对于可预期的风险，可以要求资源，制定提前的应对措施。但是对于不可预期的风险，只能待出现时，充分考虑各方因素，及时调整。所以，对于可预期的风险，需要的能力是充分预估，对于不可预期的风险，需要的是及时察觉并调整应对。
]

5冒烟测试测试方案
[本节可根据是否做冒烟测试进行裁减]

说明准入测试中各测试内容的LIST和预期结果，其它内容可选
]
分类 测试内容（可分级描述） 输入（可选） 操作步骤（可选） 预期结果 辅助工具（可选）
环境搭建 依据上线步骤成功搭建测试环境 环境搭建成功

功能测试 测试数据加载成功 测试输入数据 冒烟用例 加载成功、日志记录准确 ***脚本

6功能测试方案
6.1测试规范
[参考文档 《测试规范-171103.docx》]
6.2测试需求分析和策略制定
6.2.1分功能测试需求分析
[
根据测试框架中的各个部分，进行测试需求分析，确定测试内容和测试方法。
]
6.2.1.1XX功能模块
1.主要功能描述
[
根据需求和设计，将该部分的功能做简要描述。
]

2.测试点分析

测试点 所需回归的相关测试点 测试方法类型 测试方法详述
A[依据该功能分析可以测试的点] [依据测试框架所选择的复用case的测试点列表] 手工测试
自动化测试
自动化辅助测试
新旧版本对比测试 [描述依据测试类型而选择的测试策略，包括需要准备的数据，需要使用的辅助工具，需要使用的自动化方法，以及需要抽象的关键字等等]

[注：各个测试方法类型解释如下。
手工测试：采用人工操作，并人工观察确认测试结果的测试方法。如无特别的创新方法，诸如数据准备和场景描述策略等，此方法可以一笔带过。
自动化测试：使用提前准备好的自动化case完全无人工干预的测试。该方法如果需要特别的工具、关键字开发，需要注明。
自动化辅助测试：使用工具，将测试的部分过程，比如结果保存（抓图）、数据上传、结果验证等用程序自动化实现，但是部分过程还需要人工验证的测试。该方法可以提高部分效率，但是或许需要人工去分析严重结果。
新旧版本对比测试：在版本升级测试中，如果有两套环境，可以通过同样的输入和操作来对比验证结果的方式来进行测试和自动化测试，自动化测试可以使用coco2.0工具，常用与规避数据计算逻辑复杂的结果对比测试。
]

6.2.2测试工具需求
[测试工具需求的列表，可以单独文档进行描述]
7性能测试方案
7.1性能测试工具需求
[测试工具需求的列表，可以单独文档进行描述]

7.2场景名xxx1
7.2.1场景概述
[此处概要说明此场景对应的业务流程，如果多个场景业务流程一致，只是数据方面的差异，可将场景概述提前在所有场景前进行统一描述。
例如：用户登录系统->进入系统->退出系统]
7.2.2执行策略设计
[此处描述对于这一场景的执行策略，如并发用户数量、重复次数、性能测试执行时间等内容，同时说明性能测试过程中重点监控的性能指标。为便于说明，可采用如下表格的形式，例如：]
性能场景 执行策略（并发数、时长） 备注
登录系统，进入考场 10用户并发，登录系统，进入系统 ，重复操作15分钟，退出。 得到不同并发数下系统的性能指标
对系统的容量做出估计
列出测试的数据指标项有哪些，值在什么区间内
20用户并发，登录系统，进入系统，重复操作15分钟，退出。
40用户并发，登录系统，进入系统，退出。重复操作15分钟

7.2.3测试数据需求
[测试数据准备需求说明]
7.2.4性能测试结果分析方法和预期
[性能测试结果分析方法和预期的整体目标]